Hi, I've been building a prototype application using the Cluster and Persistence module, trying to work out various issues a production system would need to be aware of. I'm come across a possible issue with the sender ActorRef, which the documentation never talks about and I'm unsure what the best approach to solving the issue is.
With either a Cluster Singleton, or a Cluster based sharded persistent actor when they send messages out to other actors on other nodes, those receiving actors see addresses like "akka.tcp://[email protected]:2551/user/singleton/mySingleton". Now if you are using the AtLeastOnceDelivery trait, the receiving actor needs to reply to Ack, however if the Singleton or Shard is moved to a different node in the mean time, the sender() reference is no longer correct as the singleton could now be "akka.tcp://ClusterPrototype@ *remote-host*:2551/user/singleton/mySingleton". This means the receiving actor cannot Ack the message, causing the new instance of the Singleton to resend the message. I understand that the sending actor could use the tell method, passing in the reference for the local SingletonProxy or ShardRegion, meaning that the receiver could just do "sender() ! Ack(msg)". But it seems to me that we would be constantly adding boilerplate to cover this scenario. Would it not be better to have messages sent from a Singleton or Shard have proxies automatically set as the sender reference, such that a reply would still be received by a new instance of the given Singleton/Shard. The problem with this approach is still for ShardRegions that the receiving actors have to be coded to reply with a message with has an ID for the ShardRegion to extract, which means perhaps if we build generic local actors for say logs they always have to have a ID field in the replies to support replying to Shards, even when they are replying to regular actors. What is the best way people get around the issue of sender ActorRefs becoming invalid due to a node failure? Cheers, Dom PS. Please note I understand the concept of building the messages such that the second time you receive it, it has no affect. But for things such as logging or simple counters I haven't figured out a way (without infinite memory) of detecting that this "Add one to the counter" is a new request, rather than a previous request. -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
