then you won't see any messages
however, if you unstash on stop / restart
all of those unstashed messages will be dumped into deadletters
and DeadLetter events will be published onto the EventStream
containing each of those messages
s> o someone could theoretically grab them
To quote @Aaronontheweb a scroll's up
What I understood from that, is that you have to manually unstash messages before termination for them to go into deadLetters
But my tests indicate that INFO messages regarding "deadLetters" and "StashedMessage" still appear even if I do not unstash my messages manually.
When you have messages on the stash, and the actor is killed, by poisonpill or otherwise.
So not restarted.
The stashed messages are automatically deadlettered
Also when you have stashed messages, and the actor restarts, it automatically unstashes
This message was deleted
And more philosophical question. What is the reasoning behind unstahing messages on actor restart? Isn't stash a part of actor's state? Thus it should be discarded like any other actor's non-persistent state.
or is this handled by the base class "Testkit"?
but is it normal that after test completes there are so much debug log entries like
DeadLetter from [akka://test/user] to [akka://test/user]: <<DeathWatchNotification>: [akka://test/user/TestProbe_DetailPageVersion_9c57b66d-5cc9-4b73-8ad4-d4bdef0ad324], ExistenceConfirmed=True, AddressTerminated=False>
do I have to collect these DeathWatchNotifications by myself?
Thus the deadletter logs
nothing to worry about.
So not at this time
much nicer commandline experience for Windows
I just replace the entire HOCON section full stop
Question on Cluster Sharding: Can you have more than one instance of a given type of entity on a single Node? The only statement I could find of this issue was "One entity instance may live only at one node at the time" in the documentation, but I'm not really sure what that is supposed to mean.
@cfjames yes you can. This statement means, that if you have for example actor representing User with id=1, you may be sure that as long as cluster is not partitioned, no more than one actor representing that user will be present at the same time, keeping your user state consistent
When Lighthouse is running and a node where a Sharding Region starts, I see the following message in the Lighthouse logging: "Messge Register from akka.tcp://clustername@ip:port/user/sharding/typename to akka://clustername/user/sharding/typenameCoordinator/singleton/coordinator was not delivered"
ok. i seem to forget something. i have a topshelf service running an actorsystem and i added all the akka.remote stuff and put the config in the app.config and the logs show me the actorsystem gets started with that config. but it doesn't open up a port to listen to when i start the service in the debugger. do i still need something else?
@schepersk you probably need to restrict your cluster sharding to nodes not being lighthouse. One of the available sharding settings is the role, which tells what role does a cluster node need to have in order to support cluster sharding - without it, shard region will assume, that all nodes are capable of sharding (while lighthouse is not)