I mean in order to keep track of available receptionist nodes it would need to monitor members up and down events..right? why wouldn’t it handle the scenario where the receptionist it’s currently connected to is going down and simply connect to one that’s available. I Have a feeling I’m missing something obvious:( or perhaps I’m not fully understanding the purpose of a clusterclient
Context.Watchwill signal you that the node is gone - or it will signal you that the actor was programmatically terminated (which automatically occurs if the cluster doesn't try to send that client a message within 60 seconds - but that value is configurable)
ClusterClientrunning outside of the cluster
But once the original cluster node is down not a single clusterclient.send message gets processed. So even though there is a prefectly healthy clusternode the clusterclient isn’t able to reach it.. I think from what you are telling me my expectation that this should work is correct so perhaps There is some configuration or something that’s causing this.
ShardIdcan be extracted the same way - but the default implementation of Akka.Cluster.Sharding that most users adopt, the
HashCodeMessageExtractor, uses a Murmur3 (consistent hashing algorithm) hash of your
EntityIdto determine which shard [0,n] your entity belongs to