Hi Patrik, Thank you for clarifying that. Assuming I have a watchdog or we have durable shard entries then I now understand how my problem is solved.
Cheers, Dom On Friday, 4 July 2014 15:53:31 UTC+1, Patrik Nordwall wrote: > > > > > On Fri, Jul 4, 2014 at 4:42 PM, Dom B <[email protected] <javascript:>> > wrote: > >> 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. >> > > No, that is a misunderstanding. When the new node is started, the new > PersistentActor with AtLeastOnceDeliveryTrait will see that it did not > received the confirmation and then it will resend, and the sender of that > message will be the new instance, which you can reply to. > > The missing piece for that, when using cluster sharding, is discussed > here: https://groups.google.com/d/msg/akka-user/aB5afTjK8bs/JpZYSc9gsgcJ > (ticket #15496 <https://github.com/akka/akka/issues/15496>) > > > >> However, instead if you try to deliver to the local region, then region >> could forward onto the replacement node once it was up. >> > > Yes, that is also possible, but then you would not use sender() at all. > Sorry if I misunderstood what you meant with local region here. You mean > local to the destination. That makes sense. Anyway, it complicates things, > as you have noticed, and the local region will most likely route the reply > to the dead destination anyway, because it takes some time to detect the > failure. > > >> >> 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]> 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://ClusterPrototype@ >>>> 127.0.0.1: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. >>>> >>> >>> >>> >>> -- >>> >>> 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] <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.
