Re: [akka-user] Not loosing message due to remote actor unavailable.

[Roland Kuhn]

Hi Juan Pablo,

30 jan 2013 kl. 22:08 skrev Juan Pablo Vergara Villarraga:

If a remote actor is not available due to power loss Can the supervision strategy handle the situation?

No, loss of actors is managed by the Death Watch (http://doc.akka.io/docs/akka/2.1.0/general/supervision.html#What_Lifecycle_Monitoring_Means), but support for detecting unreachable remote nodes is only present in the cluster module.

I have coded the example and I have shut down the remote actor system but it seems that the supervision strategy only takes into account Exceptions thrown by the remote actor once reached.

Yes, that is correct.

I have already implemented the subscription to the events that indicates that error in the connection have occurred. I still need to have access to message the sender sent originally so the message do not get lost.

There is nothing you can subscribe to which tells you whether a given message was processed on the remote system. If you cannot lose messages then you need to persist them and use explicit acknowledgements from the receiving actor to retire them from the local storage. You will also need to implement resending and deduplication if you need exactly-once delivery; you might want to read the documentation on message delivery guarantees: http://doc.akka.io/docs/akka/2.1.0/general/message-delivery-guarantees.html

Regards,

Roland

JP.

--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ: http://akka.io/faq/
>>>>>>>>>> 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 akka-user+...@googlegroups.com.
To post to this group, send email to akka...@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

Dr. Roland Kuhn
Akka Tech Lead
Typesafe – Empowering professional developers to build amazing apps.
twitter: @rolandkuhn

[Matan Safriel]

Sorry for awakening this old thread... 

Is it really the case that there is all this fancy supervision architecture, and then a remote actor that has gone non-responsive, needs to be handled outside of the supervision hierarchy alltogether? was it considered enabling supervision to work such that the supervisor would know in case its remote child has gone unresponsive/gated/quarantined?

Perhaps I misinterpret the reference to the "cluster module" in the response by Dr. Roland Kuhn below.

Thanks for clarifying,

Matan

[Patrik Nordwall]

On Thu, Jan 8, 2015 at 9:56 PM, Matan Safriel <dev....@gmail.com> wrote:

Sorry for awakening this old thread... 

Is it really the case that there is all this fancy supervision architecture, and then a remote actor that has gone non-responsive, needs to be handled outside of the supervision hierarchy alltogether? was it considered enabling supervision to work such that the supervisor would know in case its remote child has gone unresponsive/gated/quarantined?

The information in this thread is outdated. We have added support for proper remote death watch also when using remoting only (without cluster).

 

>>>>>>>>>> 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 akka-user+...@googlegroups.com.
To post to this group, send email to akka...@googlegroups.com.

Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

--

Patrik Nordwall
Typesafe -  Reactive apps on the JVM
Twitter: @patriknw

[Matan Safriel]

Thanks Patrik, good to know, because the cluster module may seem like a very specific and rather unfinished reference implementation; Good to have this in the core without relying on the cluster module. 

[Endre Varga]

Hi,

On Fri, Jan 9, 2015 at 4:12 PM, Matan Safriel <dev....@gmail.com> wrote:

Thanks Patrik, good to know, because the cluster module may seem like a very specific and rather unfinished reference implementation;

What do you mean by unfinished reference implementation? It is a fully supported module of Akka.

-Endre

[Matan Safriel]

Thanks, good to know! Does it include a leader election process for when the leader isn't available? I was not sure from the documentation whether the leader is a single point of failure, or its relationship to seed nodes. Maybe this should be a different thread.

You received this message because you are subscribed to a topic in the Google Groups "Akka User List" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/akka-user/68TuTZLxqFI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to akka-user+...@googlegroups.com.

[Endre Varga]

Hi Matan,

On Fri, Jan 9, 2015 at 4:30 PM, Matan Safriel <dev....@gmail.com> wrote:

Thanks, good to know! Does it include a leader election process for when the leader isn't available?

From the docs:

"After gossip convergence a leader for the cluster can be determined. There is no leader election process, the leader can always be recognised deterministically by any node whenever there is gossip convergence. The leader is just a role, any node can be the leader and it can change between convergence rounds. The leader is simply the first node in sorted order that is able to take the leadership role, where the preferred member states for a leader are upand leaving (see the Membership Lifecycle section below for more information about member states)."

There is no explicit leader election because the leader can be always implicitly determinable from the cluster CRDT state.

 

I was not sure from the documentation whether the leader is a single point of failure, or its relationship to seed nodes.

Leader is not a single point of failure, it changes many times during the life of a cluster. 

Seed nodes are not special either, they are just a set of known IP addresses to bootstrap from (i.e. a set of nodes that can be used to enter the cluster, only one of them that is needed to be up at any time) when a node wants to join. This idea is not unique to Akka, for example quoting from the Cassandra docs:

"Cassandra nodes exchange information about one another using a mechanism called Gossip, but to get the ball rolling a newly started node needs to know of at least one other, this is called a Seed. It's customary to pick a small number of relatively stable nodes to serve as your seeds, but there is no hard-and-fast rule here. Do make sure that each seed also knows of at least one other, remember, the goal is to avoid a chicken-and-egg scenario and provide an avenue for all nodes in the cluster to discover one another."

-Endre

[Patrik Nordwall]

http://doc.akka.io/docs/akka/2.3.8/common/cluster.html

http://doc.akka.io/docs/akka/2.3.8/scala/cluster-usage.html

http://doc.akka.io/docs/akka/2.3.8/java/cluster-usage.html

[Matan Safriel]

Thanks Endre