Безопасно ли использовать сокет ZMQ в Actor, работающем на PinnedDispatcher?

Question

Насколько я могу судить из документации, сокеты ZeroMQ не должны использоваться (например, считываться / записываться) из разных потоков.

Это, в свою очередь, мешает мне использовать сокет ZMQ в Akka Actor, работающем в диспетчере по умолчанию (нет гарантии, какой поток будет выполнять мой receive метод).

Позволит ли использование PinnedDispatcher мне безопасно использовать такой сокет внутри Actor, при условии, что я позабочусь о том, чтобы не блокировать (по крайней мере, не слишком много времени)?

Этот диспетчер выделяет уникальный поток для каждого актера, использующего его; т.е. каждый актер будет иметь свой собственный пул потоков с одним потоком в пуле

через: https://doc.akka.io/docs/akka/2.5/dispatchers.html

Я использую JeroMQ 0.4.0 и Akka 2.5. Я понимаю, что раньше у Akka было расширение ZeroMQ, но это, похоже, в основном заброшено.

Answer 1

Ну, безопасность нитей приходит по цене.

ZeroMQ, начиная с самой ранней версии _{(вы ссылаетесь на API} версии _{2.1, в то время как есть версии API после 4.2+, выпущенные и доступные в 2018 / Q2 +)}, строился на основе общего набора значений, известного как Zen-of-Zero, который стремится сделать вещи настолько эффективными, насколько возможно, дружественным к ресурсам способом и получая только разумную величину (лучше всего вообще) задержки.

---

Возможно, в последнее время будут предприняты попытки повысить безопасность потоков в рефакторинге ZeroMQ 4.2+.

тем не менее, это не значит, что это может быть достигнуто бесплатно, не так ли?

Никто не пострадал бы, если бы он использовал надлежащие инструменты надлежащим образом, не так ли?

Тем не менее, никто не может игнорировать принципиальную неопределенность в отношении того, какая версия API ZeroMQ появится в области развертывания, поэтому использование функции, доступной в более новых версиях API, не обязательно должно быть действительным для каждого (удаленного) агента, встречающегося в течение срока службы. Размах, так что будьте осторожны.

Во всяком случае, Akka note предупреждает, что совместимость "как есть" была заморожена на уровне API v.2:

Используемая в настоящее время версия zeromq-scala-bindings совместим только с ZEROMQ 2; zeromq 3 не поддерживается.

---

Так как?

Если действительно необходимо смешать несколько различных циклов событий (как указано выше), я бы предпочел делегировать задачу на набор независимо работающих (будь то совместно или распределенных) Context() экземпляры, а не пытаться поделиться Socket() -Экземпляры уровня AccessPoint или попытка использовать "закрепленное"-обещание, только что опосредованное внешней (одновременно сосуществующей) структурой цикла событий, отличной от ZeroMQ.

Чистые, не требующие участия проекты ZeroMQ намного безопаснее и быстрее, чем пытаться искусно манипулировать все большим количеством артефактов проектирования (и если для вашего домена требуются процедуры Q A, тем более, если подтверждения дизайна и подтверждения должны быть предоставлены раньше) приемка может даже быть запланирована - попробуйте просто представить затраты на тестирование, QA / доказательства подтверждения для дикого набора игрушек, которые просто хотели иметь детерминированные, неблокирующие, безошибочные и устойчивые / устойчивые полевые операции)

Остерегайтесь:
ZeroMQ Socket()-экземпляр не является tcp-сокетом, как вы знаете. Лучше прочитайте об основных концептуальных различиях в иерархии ZeroMQ менее чем за пять секунд или о других публикациях и обсуждениях здесь.

Context() -экземпляры имеют свои собственные пулы потоков ввода-вывода под своим собственным доменом контроля, а также имеют "DMA-подобный" преобразователь между соответствующими Context "s Socket() -экземпляр допускается сродство к соответствующему Context s (groups of) I/O-thread(s), поэтому глобальное представление о "закреплении" может не повлиять на предполагаемые предпочтения отображения ресурсов.

---

И последнее, но не менее важное - конкретные конфигурации Akka-порта,
которые не соответствуют стандартным настройкам API ZeroMQ:

#####################################
# Akka ZeroMQ Reference Config File #
#####################################

# This is the reference config file that contains all the default settings.
# Make your edits/overrides in your application.conf.

akka {

  zeromq {

    # The default timeout for a poll on the actual zeromq socket.
    poll-timeout = 100ms

    # Timeout for creating a new socket
    new-socket-timeout = 5s

    socket-dispatcher {
      # A zeromq socket needs to be pinned to the thread that created it.
      # Changing this value results in weird errors and race conditions within
      # zeromq
      executor = thread-pool-executor
      type = "PinnedDispatcher"
      thread-pool-executor.allow-core-timeout = off
    }
  }
}