Hi, On Wed, Sep 9, 2015 at 10:17 PM, Andrzej Dębski <[email protected]> wrote:
> Hello, > > Currently I am in process of rewriting and unifying old JGroups based > messaging mechanisms in an application to akka based solution. > > For now akka-cluster will be used as a mechanism to know about currently > available nodes by listening to MemberEvent and ReachabilityEvent, based on > those events mechanism similar to DistributedPubSub will deliver messages > to subscribed recipients from different nodes. The thing I am interested in > is the current (2.3.13) state of network/partitions handling. > > As far as I know (I am not an expert on JGroups) if there will be some > kind of network partition/temporary node failure the nodes will happily > work along and when everything goes back to normal nodes will reform single > cluster and shared cluster state will be merged (in my situation it is > trivial - application does not use this feature of JGroups). This state of > affairs is OK for in my case - even if there is a partition between nodes > (nodes A,B do not see nodes C,D) some of the operations can be performed > without the need to contact nodes in other partition. Now I am interested > in possible differences between JGroups and akka-cluster behaviour in > failure scenarios. > > If I assume that: > > > 1. I will have auto-down-unreachable-after=off > 2. I will not use remote deployment/remote death watch > 3. the actors one one node know about others by using actorSelection > based on known path and node addresses from cluster events > > then can I assume that: > > 1. no system will be put to quarantined state (no "system" messages) > > Correct. There will actually not be any quarantine when using Akka Cluster until the node is downed/removed, also when using watch and remote deployment. That is different when using plain Remoting without Cluster. > > 1. actors inside the partitions can still send messages to themselves > normally, if I will try to send message to actor ref from unreachable node > the message will simply be not delivered (and optionally logged as > dead-letter) > > Correct > > 1. when network partition heals up all members will form single > cluster by sending each other gossip messages and unmarking unreachable > nodes > > Correct > > 1. in situation when some node is restarted ungracefully - remote > actor system does not use leave method - when new incarnation of old > ActorSystem connects old one will be automatically marked as down without > the need of issuing manual down command thanks to > https://github.com/akka/akka/issues/16726 > > Correct Cheers, Patrik > > -- > >>>>>>>>>> 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]. 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.
