Akka поток ActorSubscriber не работает с удаленными актерами

Question

http://doc.akka.io/docs/akka-stream-and-http-experimental/1.0-M2/scala/stream-integrations.html говорит:

«ActorPublisher и ActorSubscriber не могут быть использованы с удаленными участниками, потому что если сигналы протокола Реактивного Streams (например, запрос) теряются поток может взаимоблокировку. "

Означает ли это, что поток акка не является прозрачным? Как использовать поток akka для разработки системы клиент-сервер с обратным давлением, где клиент и сервер находятся на разных машинах?

Должно быть, я что-то не понял. Спасибо за любые разъяснения.

Answer 1

Они строго местные объект в это время. Вы можете подключить его к раковине/источнику TCP, и он будет применять противодавление, используя TCP, хотя (это то, что делает Akka Http).

Answer 2

Как использовать поток akka для создания системы клиент-сервер с обратным противодавлением, где клиент и сервер находятся на разных машинах?

Заканчивать streams in Artery (декабрь 2016, так что через 18 месяцев):

The new remoting implementation for actor messages was released in Akka 2.4.11 two months ago.
Артерии это кодовое название для него. Во многих случаях это замена замены старого удаленного устройства, но реализация совершенно новая, и в ней есть много важных улучшений.

(Remoting позволяет Actor системы на разных хостах или виртуальных машинах, чтобы общаться друг с другом)

Что касается обратного давления, это не полное решение, но оно может помочь:

Что о противодавлении? Akka Streams - это все что касается резервного давления, но обмен сообщениями с актерами - это безотлагательное и беззаботное забывание. Как это обрабатывается в этом проекте?

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

Когда сообщение отправляется удаленному получателю, оно добавляется в очередь, обрабатывается первый этап, называемый SendQueue. Эта очередь ограничена, и если она будет переполнена, сообщения будут удалены, что согласуется с тем, что передача сообщений актера наиболее важна при доставке. Большое количество сообщений не должно отправляться без управления потоком уровня приложения. Например, если сериализация сообщений медленная и не может идти в ногу со скоростью передачи, эта очередь будет переполняться.

Aeron будет распространять противодавление от принимающего узла на отправляющий узел, то есть AeronSink в исходящем потоке не будет прогрессировать, если AeronSource на другом конце будет медленнее и буферы будут заполнены.
Если сообщения отправляются с большей скоростью, чем то, что может быть принято принимающим узлом, то SendQueue будет переполняться и сообщения будут удалены. Aeron сам имеет большие буферы для обработки всплесков сообщений.

То же самое произойдет и в случае сетевого раздела. Когда буферы Aeron будут заполнены, сообщения будут отброшены SendQueue.

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

Нижняя линия, Управление потоком для сообщений актера должно быть реализовано на уровне приложения. Артерия не меняет этот факт.