Hi Patrik, Thanks for your reply. I can see that sending replies via the local region would introduce a bottleneck on each node, but using the AtLeastOnceDeliveryTrait would that not be your only option? Otherwise the trait would constantly try sending the reply to a dead address. However, instead if you try to deliver to the local region, then region could forward onto the replacement node once it was up.
I'm thinking about a scenario, for example, where an API actor sends a command to a shard entry. That command triggers a chain of events in other entries actors, where each command from actor to actor is mutable and has a hard requirement that the next actor processes the next command - such as a money transfer. Then each command, would need to be send using the AtLeastOnceDelivery trait to ensure that the original API call never results in a half completed state - for example money left one account, but never arrived in the other account. Perhaps the best approach is to API timeout and then send a "Undo" command down that chain. But it seems to me I must be missing something in regards to the new trait as the "Undo" command could also hit the same problems. Cheers, Dom On Friday, 4 July 2014 13:11:53 UTC+1, Patrik Nordwall wrote: > > Hi Dom, > > The actor of the Cluster Singleton instance and the Cluster Sharding entry > actors are user defined (you supply the Props of them) and therefore these > actors should implement such sender replacement mechanism, not the the > Singleton and Sharding tools. > > I don't think you win much by implementing such a thing. The replies might > be lost anyway. > If you have a crash it takes some time until that is detected, and > meanwhile messages will be lost. > For Cluster Sharding rebalancing we try to buffer and route the messages > to the new location, but I still don't think it would be worth sending > replies via the region. You must anyway deal with the fact that messages > can be lost in case of node crash. > > Cheers, > Patrik > > > On Thu, Jul 3, 2014 at 4:32 PM, Dom B <[email protected] <javascript:>> > wrote: > >> 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] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> Visit this group at http://groups.google.com/group/akka-user. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > > Patrik Nordwall > Typesafe <http://typesafe.com/> - Reactive apps on the JVM > Twitter: @patriknw > > -- >>>>>>>>>> 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.
