that way you can guarantee that at least one actor handled it when they send an ACK back
an out of the box atleastoncedelviery actor may not be the best candidate
since it relies on the
ActorPath to cache its sender, which can be a bit ephemeral in DistributedPubSub
i.e. probably won't work across restarts
the other scenario you'd have to cover is what if there are no subscribers for that topic
since the only way to realistically guarantee processing of a message is using an acknowledgement protocol
which means both sender and receiver need to be aware of it
i haven't seen any yet
and i haven't set it up for myself yet
Tail Recursion and C#: natural enemies
testing various parts of the actor dispatching system
for performance issues
came up with a test where I can pre-fill an actor's mailbox with 500000 messages
and none of them will be processed until I send that actor a Tell
instant stack overflow exception
is one way - you'll get an exception if the actor can't be resolved
if you want to do it without an exception, do this
ActorSelection.Ask<ActorIdentity>(new Identify(null))
ActorIdentity.Subject will be null
might also be an issue, if you're doing this over Akka.Remote, that we've fixed in 1.1
made a lot of changes related to that
timeline is on the readme
taking longer than expected to wrap up some of the clustering and low-level bits
@Aaronontheweb
it's a common problem - so coming up with a canonical solution would be a good idea. I think it's going to be something inherent in the actor on either end of the pub/sub relationship though, rather than a modification of the DistributedPubSub system itself
The problem with this is that the publisher doesn't know who all the subscribers are. So my thinking was that the mediator would ensure the message got through. Also, in my scenario, all subscribers require the message to come through, not just a single subscriber. Can't the acknowledgement protocol be used between the mediator and the subscriber?
