@Horusiath Thanks for the response. I would expect that a simple demo to create an actor in an actor system and then terminating the system would not produce such an unexpected result.
hi How can I get recover the message in supervisor?
Bart de Boer
@hidavidpeng either in the 'character' actor you do smth with it in PreRestart (or PostStop), or have the supervisor 'remember' it when sending it to the inner actor, and keep it until 'OK' or 'NOK (deadwatchnotification)'
Can I check if a (cluster) router currently has any routees?
In more words: I would like to know if there is currently any node connected which has actors capable of the job I want to do.
await router.Ask<Routees>(new GetRoutees())
@corneliutusnea THANK YOU for putting it on git finally. =D
are there any screenshots of the visualizer?
man, amazing what one small change can do in the right place in terms of performance
removed one allocation inside the dispatcher system and saw a bump immediately
going to add a unit test that does the equivalent of what our NBench specs do for measuring actor message throughput
to make it easier to hook up a profiler like dotTrace, mostly
since NBench doesn't offer that level of granularity
actually, hmmm... I'm going to need to rethink that
@Aaronontheweb is there anyway to have both a Priority Mailbox and a Stash?
do I just have to implement IDequeBasedMailbox on my custom priority mailbox?
or is the whole concept a conflict of interests
you should be to able to do both
to be honest I'm not sure due to the changes coming in 1.1
how much longer until 1.1?
like a week
Chris G. Stevens
Jordan S. Jones
Can anyone point to a snippet of code or documentation about the recommended way to “properly” shutdown the ActorSystem while gracefully leaving the cluster?
I know I have seen somethings in here, but I am failing at searching
Is there a way to get an exception when the akka hocon is not parse-able rather than simply failing silently?
Ivan R. Perez
@Aaronontheweb when you get a chance, take a look at this issue. Wanted to get your thoughts. akkadotnet/akka.net#2115
so I've seen people ask for something like that before
needing to guarantee that at least 1 subscriber handles a published message
my suggestion to them was to have an AtLeastOnceDeliveryActor publish the message to DistributedPubSub
as long as you don't care about multiple subscribers handling it
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
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
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
@corneliutusnea thanks for publishing your Visualizer on GitHub.