object ShardingProducerController
- Alphabetic
- By Inheritance
- ShardingProducerController
- AnyRef
- Any
- Hide All
- Show All
- Public
- Protected
Type Members
- sealed trait Command[A] extends UnsealedInternalCommand
- type EntityId = String
- final case class MessageWithConfirmation[A](entityId: EntityId, message: A, replyTo: [Done]) extends UnsealedInternalCommand with Product with Serializable
For sending confirmation message back to the producer when the message has been confirmed.
For sending confirmation message back to the producer when the message has been confirmed. Typically used with
context.ask
from the producer.If
DurableProducerQueue
is used the confirmation reply is sent when the message has been successfully stored, meaning that the actual delivery to the consumer may happen later. IfDurableProducerQueue
is not used the confirmation reply is sent when the message has been fully delivered, processed, and confirmed by the consumer. - final case class RequestNext[A](sendNextTo: [ShardingEnvelope[A]], askNextTo: [MessageWithConfirmation[A]], entitiesWithDemand: Set[EntityId], bufferedForEntitiesWithoutDemand: Map[, Int]) extends Product with Serializable
The
ProducerController
sendsRequestNext
to the producer when it is allowed to send one message via thesendNextTo
oraskNextTo
.The
ProducerController
sendsRequestNext
to the producer when it is allowed to send one message via thesendNextTo
oraskNextTo
. It should wait for nextRequestNext
before sending one more message.entitiesWithDemand
contains information about which entities that have demand. It is allowed to send to a newentityId
that is not included in theentitiesWithDemand
. If sending to an entity that doesn't have demand the message will be buffered, and that can be seen in thebufferedForEntitiesWithoutDemand
.This support for buffering means that it is even allowed to send several messages in response to one
RequestNext
but it's recommended to only send one message and wait for nextRequestNext
before sending more messages. - final class Settings extends AnyRef
- final case class Start[A](producer: [RequestNext[A]]) extends Command[A] with Product with Serializable
Initial message from the producer actor.
Initial message from the producer actor. The
producer
is typically constructed as a message adapter to map the RequestNext to the protocol of the producer actor.If the producer is restarted it should send a new
Start
message to theShardingProducerController
.
Value Members
- def apply[A](producerId: String, region: [[SequencedMessage[A]]], durableQueueBehavior: [[actor.typed.delivery.DurableProducerQueue.Command[A]]], settings: Settings)(implicit arg0: ClassTag[A]): [Command[A]]
- def apply[A](producerId: String, region: [[SequencedMessage[A]]], durableQueueBehavior: [[actor.typed.delivery.DurableProducerQueue.Command[A]]])(implicit arg0: ClassTag[A]): [Command[A]]
- def create[A](messageClass: Class[A], producerId: String, region: [[SequencedMessage[A]]], durableQueueBehavior: [[actor.typed.delivery.DurableProducerQueue.Command[A]]], settings: Settings): [Command[A]]
Java API
- def create[A](messageClass: Class[A], producerId: String, region: [[SequencedMessage[A]]], durableQueueBehavior: [[actor.typed.delivery.DurableProducerQueue.Command[A]]]): [Command[A]]
Java API
- def requestNextClass[A](): Class[RequestNext[A]]
Java API: The generic
Class
type forShardingProducerController.RequestNext
that can be used when creating amessageAdapter
forClass<RequestNext<MessageType>>
. - object Settings
Reliable delivery between a producer actor sending messages to sharded consumer actors receiving the messages.
The
ShardingProducerController
should be used together with ShardingConsumerController.A producer can send messages via a
ShardingProducerController
to anyShardingConsumerController
identified by anentityId
. A singleShardingProducerController
perActorSystem
(node) can be shared for sending to all entities of a certain entity type. No explicit registration is needed between theShardingConsumerController
andShardingProducerController
.The producer actor will start the flow by sending a ShardingProducerController.Start message to the
ShardingProducerController
. TheActorRef
in theStart
message is typically constructed as a message adapter to map the ShardingProducerController.RequestNext to the protocol of the producer actor.The
ShardingProducerController
sendsRequestNext
to the producer, which is then allowed to send one message to theShardingProducerController
via thesendNextTo
in theRequestNext
. Thereafter the producer will receive a newRequestNext
when it's allowed to send one more message.In the
RequestNext
message there is information about which entities that have demand. It is allowed to send to a newentityId
that is not included in theRequestNext.entitiesWithDemand
. If sending to an entity that doesn't have demand the message will be buffered. This support for buffering means that it is even allowed to send several messages in response to oneRequestNext
but it's recommended to only send one message and wait for nextRequestNext
before sending more messages.The producer and
ShardingProducerController
actors are supposed to be local so that these messages are fast and not lost. This is enforced by a runtime check.There will be one
ShardingConsumerController
for each entity. Many unconfirmed messages can be in flight between theShardingProducerController
and eachShardingConsumerController
. The flow control is driven by the consumer side, which means that theShardingProducerController
will not send faster than the demand requested by the consumers.Lost messages are detected, resent and deduplicated if needed. This is also driven by the consumer side, which means that the
ShardingProducerController
will not push resends unless requested by theShardingConsumerController
.Until sent messages have been confirmed the
ShardingProducerController
keeps them in memory to be able to resend them. If the JVM of theShardingProducerController
crashes those unconfirmed messages are lost. To make sure the messages can be delivered also in that scenario theShardingProducerController
can be used with a DurableProducerQueue. Then the unconfirmed messages are stored in a durable way so that they can be redelivered when the producer is started again. An implementation of theDurableProducerQueue
is provided byEventSourcedProducerQueue
inakka-persistence-typed
.Instead of using
tell
with thesendNextTo
in theRequestNext
the producer can usecontext.ask
with theaskNextTo
in theRequestNext
. The difference is that a reply is sent back when the message has been handled. If aDurableProducerQueue
is used then the reply is sent when the message has been stored successfully, but it might not have been processed by the consumer yet. Otherwise the reply is sent after the consumer has processed and confirmed the message.It's also possible to use the
ShardingProducerController
andShardingConsumerController
without resending lost messages, but the flow control is still used. This can be more efficient since messages don't have to be kept in memory in theProducerController
until they have been confirmed, but the drawback is that lost messages will not be delivered. See configurationonly-flow-control
of theShardingConsumerController
.The
producerId
is used in logging and included as MDC entry with key"producerId"
. It's propagated to theConsumerController
and is useful for correlating log messages. It can be anyString
but it's recommended to use a unique identifier of representing the producer.If the
DurableProducerQueue
is defined it is created as a child actor of theShardingProducerController
actor.ProducerController
actors are created for each destination entity. Those child actors use the same dispatcher as the parentShardingProducerController
.