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

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

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

Разве использование Закреплен позволит мне безопасно использовать такой сокет внутри Актера, при условии, что я позабочусь о том, чтобы не блокировать (по крайней мере, не на чрезмерное количество времени)?

This dispatcher dedicates a unique thread for each actor using it; i.e. each actor will have its own thread pool with only one thread in the pool

через: https://doc.akka.io/docs/akka/2.5/dispatchers.html#types-of-dispatchers

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

У тебя уже есть ответ на свой вопрос? Ваш подход (с использованием PinnedDispatcher) работает? Мне также нужно интегрировать связь ZMQ с Akka 2.5.

Jonny Dee 08.10.2019 08:52

Я не припоминаю, чтобы у меня были какие-либо серьезные проблемы, но я не могу подтвердить со 100% уверенностью. Я не работал над этим проектом больше года, и у меня больше нет к нему доступа. Но удачи!

Patryk Koryzna 09.10.2019 22:18
0
2
258
1

Ответы 1

Что ж, потокобезопасность имеет свою цену.

ZeroMQ, начиная с самой ранней версии ( you refer to API ver. 2.1, while there are API versions past 4.2+ released and available in 2018/Q2+ ), создавался с использованием общего набора значений, также известного как Zen-of-Zero, который стремится сделать вещи максимально эффективными, с минимальными затратами ресурсов и получая только разумное количество ( лучше вообще нет) задержка.


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

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

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

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

В любом случае, примечание Akka предупреждает, что совместимость as-is была заморожена на уровне API v.2:

The currently used version of zeromq-scala-bindings is only compatible with zeromq 2; zeromq 3 is not supported.


Так как ?

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

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

Остерегаться :
ZeroMQ Socket()-instance - это нет a tcp-socket-as-you-know-it-as-you-it-it. Лучше прочитать об основных концептуальных различиях в Иерархия ZeroMQ менее чем за пять секунд или другие сообщения и обсуждения здесь.

Экземпляры Context() имеют свои собственные пулы потоков ввода-вывода под их собственным доменом-контролем, а также имеют "DMA-подобный преобразователь" между соответствующим экземпляром ContextSocket(), разрешенным сродством к соответствующим Context (группам) 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
    }
  }
}

Я использую Akka 2.5 - расширения ZeroMQ были удалены довольно давно: github.com/akka/akka/issues/15864

Patryk Koryzna 12.04.2018 10:00

Другие вопросы по теме