Насколько я могу судить из документация, сокеты 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, но оно, похоже, в основном заброшено.
Я не припоминаю, чтобы у меня были какие-либо серьезные проблемы, но я не могу подтвердить со 100% уверенностью. Я не работал над этим проектом больше года, и у меня больше нет к нему доступа. Но удачи!
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, который стремится сделать вещи максимально эффективными, с минимальными затратами ресурсов и получая только разумное количество ( лучше вообще нет) задержка.
но это не значит, что это можно сделать бесплатно, не так ли?
Никто бы не пострадал, если бы использовал надлежащие инструменты должным образом, не так ли?
Тем не менее, никто не может игнорировать принципиальную неопределенность в отношении того, какая версия 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-подобный преобразователь" между соответствующим экземпляром Context
Socket()
, разрешенным сродством к соответствующим Context
(группам) I / O-thread (s), поэтому глобальное представление о «закреплении» может не влиять на предполагаемые предпочтения сопоставления ресурсов.
#####################################
# 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
У тебя уже есть ответ на свой вопрос? Ваш подход (с использованием PinnedDispatcher) работает? Мне также нужно интегрировать связь ZMQ с Akka 2.5.