An entity may currently terminate itself early using ZIO.interrupt or be externally interrupted, but this comes at the expense of a SendTimeoutException eventually being issued for every message in the entity's queue before the queue shuts down. It would be nice to have at least one fail-fast/recovery mechanism that stops accepting new messages into the queue and allows processing of any remaining messages in the queue so that the senders do not have to wait the full timeout period.
Broad-strokes ideas for termination strategies:
enqueue a custom message and start a configurable termination timeout. the entity may continue processing the queue, eventually handling the termination message and interrupt itself or discard the custom message where it will be interrupted after the termination timeout
register a callback accepting the Dequeue and invoke that upon any kind of termination signal
a conditional method that stops the entity only when the queue is currently empty. this may either require synchronization or be combined with the first two options to cover the simultaneous issuance of a termination and the receipt of a message
an immediate restart, where if the shard still manages the entity it is re-created using the non-empty queue, and may be combined with the first two strategies in the event the entity is no longer managed by the shard
It might be enough to have a single Sharding.terminateEntity[T](typ: EntityType[T], id: String, termination: TerminationStrategy[T]) style method, but perhaps specific methods like Sharding.terminateMessage[T](typ: EntityType[T], id: String, termination: T) and Sharding.terminateRemaining[T](typ: EntityType[T], id: String)(termination: Dequeue[T] => ZIO[...]) and variants make sense
ghostdogpr
commented
5 months ago
An entity may currently terminate itself early using
ZIO.interruptor be externally interrupted, but this comes at the expense of aSendTimeoutExceptioneventually being issued for every message in the entity's queue before the queue shuts down. It would be nice to have at least one fail-fast/recovery mechanism that stops accepting new messages into the queue and allows processing of any remaining messages in the queue so that the senders do not have to wait the full timeout period.Broad-strokes ideas for termination strategies:
Dequeueand invoke that upon any kind of termination signalIt might be enough to have a single
Sharding.terminateEntity[T](typ: EntityType[T], id: String, termination: TerminationStrategy[T])style method, but perhaps specific methods likeSharding.terminateMessage[T](typ: EntityType[T], id: String, termination: T)andSharding.terminateRemaining[T](typ: EntityType[T], id: String)(termination: Dequeue[T] => ZIO[...])and variants make sense