These are chat archives for petabridge/akka-bootcamp

12th
Mar 2016
Aaron Stannard
@Aaronontheweb
Mar 12 2016 00:13
@/all if you're one of those developers who's had questions about messaging guarantees in Akka.NET, I wrote this for you: https://petabridge.com/blog/akkadotnet-at-least-once-message-delivery/
Bartosz Sypytkowski
@Horusiath
Mar 12 2016 07:11
@Aaronontheweb
  1. It's great that finally there is an article on that.
  2. I think, that using snapshots instead of persisting delivered messages inside journal is that, when you're saving a snapshot, you don't wait for ACK from snapshot store. This causes the following problem: imagine that you have snapshoted last state of deliveries and immediately after that an actor crashes. It gets reincarnated and starts recovery procedure. Problems is that actor restart is way faster than most of the snapshot saving, so when trying to recover it may turn out that it won't recover from the latest snapshot (because it was not stored yet), having invalid state in result. That why snapshotting should never be used alone, only as optimization for journaling messages.
  3. What I'm missing, is dedupe pattern. We can detect duplicates (not allways but to some extent) using things like ring buffer for received delivery messages. Combined with AroundReceive we may filter them, before they come into receive methods.
Aaron Stannard
@Aaronontheweb
Mar 12 2016 17:52
@Horusiath I've always thought that it didn't make much sense for the AtLeastOnceDeliveryActor to not use the journal
seemed like a Deliver call should automatically add a record to the journal
and as long as you store the re-delivery deadline as an interval and don't have to re-journal each time there's a redelivery attempt
Bartosz Sypytkowski
@Horusiath
Mar 12 2016 17:53
you know, Akka never makes assumptions for what you might like to do ;)
Aaron Stannard
@Aaronontheweb
Mar 12 2016 17:53
probably wouldn't be that expensive, right?
Bartosz Sypytkowski
@Horusiath
Mar 12 2016 17:59
I think, you need to store the latest delivery id
Aaron Stannard
@Aaronontheweb
Mar 12 2016 18:00
could you correlate that with the SeqNo?
although I guess one potential pitfall of that is though
is that if the journal fails to write
then we're screwed, right?
Bartosz Sypytkowski
@Horusiath
Mar 12 2016 18:01
why? You're sending a message in Persist handler, once message has been confirmed to be stored
but in general, does delivery id is really so important in each use case?
Aaron Stannard
@Aaronontheweb
Mar 12 2016 18:02
nah, you're right
although...
depending on how the receiver tries to do things like eliminate duplicates
it might be nice if you have some guarantee around the delivery ID always being monotonic
or something like that
I know the snapshotting today preserves that across restarts
Bartosz Sypytkowski
@Horusiath
Mar 12 2016 18:05
I'm creating redis backend for akka.persistence - I think it will be great for at-least-once delivery scenarios, especially after profiling and optimization
Onam
@OnamChilwan
Mar 12 2016 20:58
Is it possible to moq the actor system? I have it as a singleton but wrapped an interface
Around it
Aaron Stannard
@Aaronontheweb
Mar 12 2016 22:05
you should never need to moq the ActorSystem
the Akka.NET TestKit provides plenty of tools for testing actor behavior
if you need to test the ActorSystem within some sort of external context though, I'd also encourage you to use the TestKit - gives you a fresh, testable actor system each time