Hi Eduardo,
there are several parts which will have to play together in relation to
your requirement of avoiding delay during a failover:
- first you need to decide that you want to fail over, which means that
the backup needs to determine that it has to become active
- then you need to get the backup in shape (bringing it up to the
persisted level of the primary before the failure
- then you need to switch the responsibility for persisting state
changes to the backup
The first one will probably take some time, typically of the order of
several seconds; if you make it faster then you risk failing over too
eagerly due to some GC pauses, in which case the primary node will not know
that it should deactivate itself when it comes back from the freezer.
In general having multiple sources of “truth” is a hard problem that can
only be solved by mutual exclusion or merging. This is a tough problem that
admittedly is not fully solved yet, and the Akka Persistence toolbox is
also lacking in this regard (e.g. merging the log streams from multiple
“equivalent” processors into a single journal or supporting an exclusion
scheme for disabling the old processor after a failover).
What you can currently do is to rely on the sharding infrastructure to
provide only exactly one copy of an entity at any given point in time and
reduce failover latency by judicious use of snapshots.
Regards,
Roland
On Mon, May 5, 2014 at 11:35 AM, Eduardo Fernandes edu...@gmail.com wrote:
Hi all.
I'm trying a hot swap between an active processor and a backup one, in
line with the
thishttps://www.assembla.com/spaces/akka/tickets/3938#/activity/ticket:
ticket,
to avoid delay while swapping huge actors.
I'm thinking about manually sending my commands to two different actors in
a active/passive fashion. In case of node failure I'd like to point out to
the passive instance, avoiding startup delay. I'm thinking about having two
sharding regions and then, after node failure and using a particular
sharding strategy, point out to the node where the passive object is. Maybe
the hotswap (as decribed
herehttp://doc.akka.io/docs/akka/snapshot/java/untyped-actors.html#untypedactor-hotswap)
can be used to deviate the commands to passive actor. In the meanwhile the
standard Akka persistence scheme is being used to re-initiate the original
actor that could be used later after a new node failure.
Do you think that this approach is feasible or maybe there is another
simpler way to achieve this behavior?
Many thanks for your help.
Eduardo.
--
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 akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
--
Akka Team
Typesafe - The software stack for applications that scale
Blog: letitcrash.com
Twitter: @akkateam
--
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 akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
