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.
@object can you send a screenshot
i haven't seen any yet
and i haven't set it up for myself yet
I'd be curious to see it also
Jordan S. Jones
I am far from my work pc right now. But will make a screenshot when I am back to work from my short vacation. It's an alpha state but looks promising.
in today's public service announcement
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
interesting - looks like it takes about 3x as long to put a message in an actor's mailbox vs. how long it takes the dispatcher to dequeue that message and push it into the actor's cell
Does anyone know a reliable way of distinguishing if an actor is available from an actorSelection. IE no actor is at that address
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