Hi,
I revised my implementation and done with
https://gist.github.com/whiter4bbit/22cd3b0909bb390e80db. For my particular
case there is relatively long window between requests, in many cases
Appends and Removes count will match (also possible by calling
confirmDelivery for messages, that not deliv
Hi,
Thanks for explaining delivery semantics, actually it is in scala doc at
both trait and method description, missed it, maybe some example can fit
well in documentation:). And thanks for persistence module at all - with
2.3.2 our app works well for last few months!
Regarding deliveryIds. Two t
This thread motivated me to improve the documentation on these methods a
bit, progress can be tracked in this
issue: https://github.com/akka/akka/issues/15538
-- k
--
>> Read the docs: http://akka.io/docs/
>> Check the FAQ:
>> http://doc.akka.io/docs/akka/cu
Hello Pavel,
It seems to me that you’re overdoing a lot inside that implementation.
I don’t really see what gain your own deliveryIds is meant to provide.
Let’s take a step back and look at the semantics of deliver and
confirmDelivery *during playback*.
During normal operation I think it’s clear
Hi,
I'm a bit confused with current akka-persistence changes - we used
Processor like WAL.
Use-case is: every Xmin send some request to remote http endpoint.
Endpoints can be unavailable for some time, but request should be sent in
'any way' (read as at-least-once-delivery).
I used Processor, acto
