date:20150114

Re: [akka-user] Re: ResendUnfulfillableException in remoting

2015-01-14 Thread Endre Varga

Hi Jim,

We are aware of the issue, a fix is being prepared:
https://github.com/akka/akka/pull/16640

-Endre

On Wed, Jan 14, 2015 at 2:24 AM, Jim Newsham  wrote:

>
> P.S.  I've checked the release notes and didn't see anything specifically
> related to ResendUnfulfillableException, although some closed issues were
> related to connections and acks.  I thought it would be better to ask.
>
>
> On Tuesday, January 13, 2015 at 3:17:51 PM UTC-10, Jim Newsham wrote:
>>
>>
>> We are using Akka 2.3.5 via Java.  We have had a few rare reports of
>> akka-remoting communication failing with ResendUnfulfillableException.
>> When this happens, the log spews a lot of error messages as shown below,
>> and requires a restart of the node to resolve.  Due to the rarity of the
>> issue, I doubt we'd be able to find a reproduction.  Are there any known
>> issues resolved in later versions (2.3.6 - 2.3.8) which could account for
>> this problem?  It would be nice to know before upgrading whether it has any
>> chance of fixing the issue.
>>
>> ERROR Remoting - Error encountered while processing system message
>> acknowledgement [] ACK[11, {4, 6, 7, 3, 5, 8, 9, 2}]
>> akka.remote.transport.Transport$InvalidAssociationException: Error
>> encountered while processing system message acknowledgement [] ACK[11, {4,
>> 6, 7, 3, 5, 8, 9, 2}]
>> Caused by: akka.remote.ResendUnfulfillableException: Unable to fulfill
>> resend request since negatively acknowledged payload is no longer in
>> buffer. The resend states between two systems are compromised and cannot be
>> recovered.
>> at akka.remote.AckedSendBuffer.acknowledge(AckedDelivery.scala:103)
>> at akka.remote.ReliableDeliverySupervisor$$anonfun$receive$1.applyOrElse(
>> Endpoint.scala:288)
>> at akka.actor.Actor$class.aroundReceive(Actor.scala:465)
>> at akka.remote.ReliableDeliverySupervisor.aroundReceive(Endpoint.scala:
>> 185)
>> at akka.actor.ActorCell.receiveMessage(ActorCell.scala:516)
>> at akka.actor.ActorCell.invoke(ActorCell.scala:487)
>> at akka.dispatch.Mailbox.processMailbox(Mailbox.scala:238)
>> at akka.dispatch.Mailbox.run(Mailbox.scala:220)
>> at akka.dispatch.ForkJoinExecutorConfigurator$AkkaForkJoinTask.exec(
>> AbstractDispatcher.scala:393)
>> at scala.concurrent.forkjoin.ForkJoinTask.doExec(ForkJoinTask.java:260)
>> at scala.concurrent.forkjoin.ForkJoinPool$WorkQueue.
>> runTask(ForkJoinPool.java:1339)
>> at scala.concurrent.forkjoin.ForkJoinPool.runWorker(
>> ForkJoinPool.java:1979)
>> at scala.concurrent.forkjoin.ForkJoinWorkerThread.run(
>> ForkJoinWorkerThread.java:107)
>> Thanks in advance,
>> Jim
>>
>  --
> >> 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.
>

-- 
>>  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.

Re: [akka-user] Dokumentation inconsistency

2015-01-14 Thread Konrad Malawski

Hi Gerald,
thanks for noticing this!

It seems that the akka-http-marshallers jar is not even published even.
I opened a ticket to track the investigation on this:
https://github.com/akka/akka/issues/16646
I don't think this was intentional but need to confirm with the team.

On Fri, Jan 9, 2015 at 11:48 PM, Gerald Mixa  wrote:

> Hi,
>
> i want to report a inconsisty of the akka documentation.
>
> the folloing class should be in akka http
>
> http://doc.akka.io/api/akka-stream-and-http-experimental/1.0-M2/index.html#akka.http.marshallers.sprayjson.SprayJsonSupport
>
> at least to the scaladoc documentation.
>
> Due to the javadoc documentation it is not.
>
> In the jar files its not contained. Seems there is som flaw in the doc and
> code publishing process
>
> Greetings
>
> Gerald
>
> --
> >> 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.
>



-- 
Cheers,
Konrad 'ktoso' Malawski
hAkker @ Typesafe

-- 
>>  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.

Re: [akka-user] Dokumentation inconsistency

2015-01-14 Thread Konrad Malawski

Hello again,
This isn't a bug, and in fact should be asymmetric as is, because this
trait is only really useful for scaja - it is implicit defs that bring in
marshallers into scope - that is not really usable from Java.
The jar is published properly and contains the SprayJsonSupport class as
expected - see here:
http://search.maven.org/#artifactdetails%7Ccom.typesafe.akka%7Cakka-http-spray-json-experimental_2.10%7C1.0-M2%7Cjar

My imminent reaction that something might be wrong on our side was
(thankfully) wrong, all seems to be fine - thanks for keeping an eye out
though!
(And sorry for my wrong first impression).

On Wed, Jan 14, 2015 at 1:31 PM, Konrad Malawski  wrote:

> Hi Gerald,
> thanks for noticing this!
>
> It seems that the akka-http-marshallers jar is not even published even.
> I opened a ticket to track the investigation on this:
> https://github.com/akka/akka/issues/16646
> I don't think this was intentional but need to confirm with the team.
>
> On Fri, Jan 9, 2015 at 11:48 PM, Gerald Mixa 
> wrote:
>
>> Hi,
>>
>> i want to report a inconsisty of the akka documentation.
>>
>> the folloing class should be in akka http
>>
>> http://doc.akka.io/api/akka-stream-and-http-experimental/1.0-M2/index.html#akka.http.marshallers.sprayjson.SprayJsonSupport
>>
>> at least to the scaladoc documentation.
>>
>> Due to the javadoc documentation it is not.
>>
>> In the jar files its not contained. Seems there is som flaw in the doc
>> and code publishing process
>>
>> Greetings
>>
>> Gerald
>>
>> --
>> >> 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.
>>
>
>
>
> --
> Cheers,
> Konrad 'ktoso' Malawski
> hAkker @ Typesafe
>



-- 
Cheers,
Konrad 'ktoso' Malawski
hAkker @ Typesafe

-- 
>>  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.

Re: [akka-user] Re: UnboundedPriorityMailbox breaks message ordering?

2015-01-14 Thread Konrad Malawski

Awesome contribution David, thanks a lot!
We'll think of a plan on how to include or replace the old impl with your
PR and ping that issue again soon :-)

On Sat, Jan 10, 2015 at 4:08 PM, David Hotham 
wrote:

> I've submitted a first stab at an implementation at pull request #16634.
>
> On Friday, 9 January 2015 21:02:21 UTC, √ wrote:
>
>>
>>
>> On Fri, Jan 9, 2015 at 9:40 PM, David Hotham 
>> wrote:
>>
>>> Of course it's normal and expected that a PriorityQueue returns equal
>>> priority elements in arbitrary order.  That's just how heaps work.  However
>>> that doesn't imply that a mailbox has to do the same thing!
>>>
>>
>> Absolutely, the reordering is not a requirement :) However, silently
>> switching to a new, non-reordering-of-same-priority implementation would
>> risk breaking existing code (that for some reason relies on this behavior).
>>
>>
>>>
>>> For instance, I guess that it shouldn't be very hard for the mailbox to
>>> maintain a sequence number that it associates with each message.
>>>
>>
>> Sure! The question is how how big the impact is on memory consumption and
>> performance.
>>
>>
>>> Then it could order messages first according to the comparator that it
>>> currently uses, and second according to the sequence number.  That way it
>>> would return equal priority messages in the same order that it saw them
>>> arrive - which gives exactly the property that I'd hoped for.
>>>
>>
>> Absolutely :)
>>
>>
>>>
>>> I can't tell from your reply whether you think that maintaining order
>>> for equal priority messages is desirable or not.
>>>
>>
>> I think it could be interesting as an alternative to the current version
>> of the PriorityMailbox, or perhaps even as a replacement if it is
>> performing as well as the thing it replaces.
>>
>>
>>>
>>>- If yes, what do you think about an implementation along these
>>>lines?  Is it worth me raising an issue at github?
>>>
>>> I wish I had time to do that, is it something you'd be willing/able to
>> take a stab at? Would love to see something like that.
>>
>>>
>>>- If no, can I at least encourage the Akka maintainers to add an
>>>explicit note to the documentation, so that other users are less likely 
>>> to
>>>fall into my error?
>>>
>>> I think this should be done anyway, since it as you said, and I
>> confirmed, surprising at first. :)
>>
>>
>>
>>> Cheers,
>>>
>>> David
>>>
>>> On Friday, 9 January 2015 19:43:27 UTC, √ wrote:

 Hi David,

 yes, I can definitely understand that it can be surprising, but I
 wouldn't call it a bug -per se-, since it is not a promise that was
 violated.

 If you happen to have, or come by, a performant version of a
 PriorityQueue with the semantics you described, please don't hesitate to
 share it.

 On Fri, Jan 9, 2015 at 7:21 PM, David Hotham 
 wrote:

> It occurs to me that I wasn't completely clear:
>
>- Of course the priority mailbox must break message ordering in
>some general sense. Else it wouldn't be a priority mailbox at all!
>- But it is highly surprising to me that it should break ordering
>for messages of equal priority between a sender-receiver pair.
>
>
> On Friday, 9 January 2015 17:58:40 UTC, David Hotham wrote:
>>
>> Hi,
>>
>> We've been tracking down a bug in which reading from a TCP stream was
>> getting all messed up.
>>
>> It turns out that we see the problem only when our actor handling
>> Tcp.Received messages is using an UnboundedPriorityMailbox; the default
>> mailbox doesn't exhibit any problem.
>>
>> I believe that the issue is that the UnboundedPriorityMailbox is
>> backed by a PriorityBlockingQueue; and that, per the documentation for 
>> that
>> class, "Operations on this class make no guarantees about the ordering of
>> elements with equal priority".
>>
>> That is, it seems that the UnboundedPriorityMailbox breaks the
>> guarantee of message ordering per sender–receiver pair.  In our case, the
>> result being that different chunks of the TCP data stream arrive not in 
>> the
>> order in which they were read from the wire.
>>
>> Does this analysis seem to be correct?
>>
>> If yes, is it a bug?  Would you like me to raise a ticket?
>>
>> Thanks!
>>
>> David
>>
>  --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ: http://doc.akka.io/docs/akka/c
> urrent/additional/faq.html
> >> Search the archives: https://groups.google.com/grou
> p/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://g

Re: [akka-user] Re: UnboundedPriorityMailbox breaks message ordering?

2015-01-14 Thread Endre Varga

On Fri, Jan 9, 2015 at 10:02 PM, Viktor Klang 
wrote:

>
>
> On Fri, Jan 9, 2015 at 9:40 PM, David Hotham 
> wrote:
>
>> Of course it's normal and expected that a PriorityQueue returns equal
>> priority elements in arbitrary order.  That's just how heaps work.  However
>> that doesn't imply that a mailbox has to do the same thing!
>>
>
> Absolutely, the reordering is not a requirement :) However, silently
> switching to a new, non-reordering-of-same-priority implementation would
> risk breaking existing code (that for some reason relies on this behavior).
>

I disagree, previously the order between same priority entries was
undefined, and undefined includes that the order is unchanged (the new
behavior). Just my 2c.

-Endre


>
>
>>
>> For instance, I guess that it shouldn't be very hard for the mailbox to
>> maintain a sequence number that it associates with each message.
>>
>
> Sure! The question is how how big the impact is on memory consumption and
> performance.
>
>
>> Then it could order messages first according to the comparator that it
>> currently uses, and second according to the sequence number.  That way it
>> would return equal priority messages in the same order that it saw them
>> arrive - which gives exactly the property that I'd hoped for.
>>
>
> Absolutely :)
>
>
>>
>> I can't tell from your reply whether you think that maintaining order for
>> equal priority messages is desirable or not.
>>
>
> I think it could be interesting as an alternative to the current version
> of the PriorityMailbox, or perhaps even as a replacement if it is
> performing as well as the thing it replaces.
>
>
>>
>>- If yes, what do you think about an implementation along these
>>lines?  Is it worth me raising an issue at github?
>>
>> I wish I had time to do that, is it something you'd be willing/able to
> take a stab at? Would love to see something like that.
>
>>
>>- If no, can I at least encourage the Akka maintainers to add an
>>explicit note to the documentation, so that other users are less likely to
>>fall into my error?
>>
>> I think this should be done anyway, since it as you said, and I
> confirmed, surprising at first. :)
>
>
>
>> Cheers,
>>
>> David
>>
>> On Friday, 9 January 2015 19:43:27 UTC, √ wrote:
>>>
>>> Hi David,
>>>
>>> yes, I can definitely understand that it can be surprising, but I
>>> wouldn't call it a bug -per se-, since it is not a promise that was
>>> violated.
>>>
>>> If you happen to have, or come by, a performant version of a
>>> PriorityQueue with the semantics you described, please don't hesitate to
>>> share it.
>>>
>>> On Fri, Jan 9, 2015 at 7:21 PM, David Hotham 
>>> wrote:
>>>
 It occurs to me that I wasn't completely clear:

- Of course the priority mailbox must break message ordering in
some general sense. Else it wouldn't be a priority mailbox at all!
- But it is highly surprising to me that it should break ordering
for messages of equal priority between a sender-receiver pair.


 On Friday, 9 January 2015 17:58:40 UTC, David Hotham wrote:
>
> Hi,
>
> We've been tracking down a bug in which reading from a TCP stream was
> getting all messed up.
>
> It turns out that we see the problem only when our actor handling
> Tcp.Received messages is using an UnboundedPriorityMailbox; the default
> mailbox doesn't exhibit any problem.
>
> I believe that the issue is that the UnboundedPriorityMailbox is
> backed by a PriorityBlockingQueue; and that, per the documentation for 
> that
> class, "Operations on this class make no guarantees about the ordering of
> elements with equal priority".
>
> That is, it seems that the UnboundedPriorityMailbox breaks the
> guarantee of message ordering per sender–receiver pair.  In our case, the
> result being that different chunks of the TCP data stream arrive not in 
> the
> order in which they were read from the wire.
>
> Does this analysis seem to be correct?
>
> If yes, is it a bug?  Would you like me to raise a ticket?
>
> Thanks!
>
> David
>
  --
 >> 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+...@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.

>>>
>>>
>>>
>>> --
>>> Cheers,
>>> √
>>>
>>  --
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ:
>> http://doc.ak

Re: [akka-user] Re: UnboundedPriorityMailbox breaks message ordering?

2015-01-14 Thread Viktor Klang

On Wed, Jan 14, 2015 at 2:44 PM, Endre Varga 
wrote:

>
>
> On Fri, Jan 9, 2015 at 10:02 PM, Viktor Klang 
> wrote:
>
>>
>>
>> On Fri, Jan 9, 2015 at 9:40 PM, David Hotham > > wrote:
>>
>>> Of course it's normal and expected that a PriorityQueue returns equal
>>> priority elements in arbitrary order.  That's just how heaps work.  However
>>> that doesn't imply that a mailbox has to do the same thing!
>>>
>>
>> Absolutely, the reordering is not a requirement :) However, silently
>> switching to a new, non-reordering-of-same-priority implementation would
>> risk breaking existing code (that for some reason relies on this behavior).
>>
>
> I disagree, previously the order between same priority entries was
> undefined, and undefined includes that the order is unchanged (the new
> behavior). Just my 2c.
>

The proposed solution has worse performance than the current though. That
would be a regression.


>
> -Endre
>
>
>>
>>
>>>
>>> For instance, I guess that it shouldn't be very hard for the mailbox to
>>> maintain a sequence number that it associates with each message.
>>>
>>
>> Sure! The question is how how big the impact is on memory consumption and
>> performance.
>>
>>
>>> Then it could order messages first according to the comparator that it
>>> currently uses, and second according to the sequence number.  That way it
>>> would return equal priority messages in the same order that it saw them
>>> arrive - which gives exactly the property that I'd hoped for.
>>>
>>
>> Absolutely :)
>>
>>
>>>
>>> I can't tell from your reply whether you think that maintaining order
>>> for equal priority messages is desirable or not.
>>>
>>
>> I think it could be interesting as an alternative to the current version
>> of the PriorityMailbox, or perhaps even as a replacement if it is
>> performing as well as the thing it replaces.
>>
>>
>>>
>>>- If yes, what do you think about an implementation along these
>>>lines?  Is it worth me raising an issue at github?
>>>
>>> I wish I had time to do that, is it something you'd be willing/able to
>> take a stab at? Would love to see something like that.
>>
>>>
>>>- If no, can I at least encourage the Akka maintainers to add an
>>>explicit note to the documentation, so that other users are less likely 
>>> to
>>>fall into my error?
>>>
>>> I think this should be done anyway, since it as you said, and I
>> confirmed, surprising at first. :)
>>
>>
>>
>>> Cheers,
>>>
>>> David
>>>
>>> On Friday, 9 January 2015 19:43:27 UTC, √ wrote:

 Hi David,

 yes, I can definitely understand that it can be surprising, but I
 wouldn't call it a bug -per se-, since it is not a promise that was
 violated.

 If you happen to have, or come by, a performant version of a
 PriorityQueue with the semantics you described, please don't hesitate to
 share it.

 On Fri, Jan 9, 2015 at 7:21 PM, David Hotham 
 wrote:

> It occurs to me that I wasn't completely clear:
>
>- Of course the priority mailbox must break message ordering in
>some general sense. Else it wouldn't be a priority mailbox at all!
>- But it is highly surprising to me that it should break ordering
>for messages of equal priority between a sender-receiver pair.
>
>
> On Friday, 9 January 2015 17:58:40 UTC, David Hotham wrote:
>>
>> Hi,
>>
>> We've been tracking down a bug in which reading from a TCP stream was
>> getting all messed up.
>>
>> It turns out that we see the problem only when our actor handling
>> Tcp.Received messages is using an UnboundedPriorityMailbox; the default
>> mailbox doesn't exhibit any problem.
>>
>> I believe that the issue is that the UnboundedPriorityMailbox is
>> backed by a PriorityBlockingQueue; and that, per the documentation for 
>> that
>> class, "Operations on this class make no guarantees about the ordering of
>> elements with equal priority".
>>
>> That is, it seems that the UnboundedPriorityMailbox breaks the
>> guarantee of message ordering per sender–receiver pair.  In our case, the
>> result being that different chunks of the TCP data stream arrive not in 
>> the
>> order in which they were read from the wire.
>>
>> Does this analysis seem to be correct?
>>
>> If yes, is it a bug?  Would you like me to raise a ticket?
>>
>> Thanks!
>>
>> David
>>
>  --
> >> 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+...@googlegroups.com.
> To post to this group, send em

Re: [akka-user] Akka 2.3.8: context.stop(self) and self ! PoisonPill fail on remotely deployed actors

2015-01-14 Thread Akka Team

Hi Brian,
It seems to me that it is not the stopping that doesn’t work - you can
verify this by putting an override def postStop() = log.info("context.stop
really worked") into the worker actor.

What seems to be happening is the remote watch fails to be established in
time, which is part of the remoting. And it fails simply because you stop
your actor “right away”, then the system message arrives, and tries to
locate the (now already gone) actor.
It doesn’t find it so the selection fails (resolve of path sequence …
failed). Thus the remote-deathwatch is not registered on the remote actor,
because it’s “dead on arrival”.
In essence, it is a race between the system message (establishing the
remote watch - so you can get notified that the actor has died on the
allocator actor) getting to the remote worker actor and it already being
dead.

It should not impact the proper functioning of the deathwatch however.

The AssociationError looks like you’ve shut down the other actor system,
and it told this one that it is shutting down - therefore the association
gets closed as well.
It seems to have been a clean shutdown (shutting down the actor system),
since then it notifies all its connections that it will be shutting down.
Can you confirm that that was what was going on with these nodes?

Hope this helps!

—
Konrad Malawski

On Mon, Jan 12, 2015 at 11:47 AM, Brian Fowler 
wrote:

Hi,
>
> Can anyone help with the following in Akka 2.3.8
>
> The actor
>
> class SquarerActor extends Actor with ActorLogging {
>   override def receive = {
> case SquareTask(id, number, _) => {
>   log.info(s"${Thread.currentThread()} ${id}: ${number}^2 = 
> ${number*number} for ${sender}")
>   context.stop(self)
> }
> case _ => {
>   log.info(s"unknown message received")
> }
>   }
>
> }
>
> when created locally from
>
> class TaskAllocatorActor extends Actor with ActorLogging {
>   override def receive = {
> case task: SquareTask => {
>   log.info(s"${Thread.currentThread()} received ${task} from ${sender}")
>
>   context.actorOf(Props[SquarerActor],task.id) ! task
> }
> case _ => {
>   println("Unknown Task")
> }
>   }
> }
>
>
> works, but when deployed remotely using
>
>
> class TaskAllocatorActor extends Actor with ActorLogging {
>   override def receive = {
> case task: SquareTask => {
>   log.info(s"${Thread.currentThread()} received ${task} from ${sender}")
>
>
>   val actorRef = context.actorOf(Props[SquarerActor]
> .withDeploy(Deploy(scope = 
> RemoteScope(AddressFromURIString("akka.tcp://Example2BoxTwo@127.0.0.1:2553",
>  task.id)
>   actorRef ! task
> }
> case _ => {
>   println("Unknown Task")
> }
>   }
> }
>
>
> the SquarerActor context.stop(self) fails, on the remote system the log is 
> below, note that the remote actor receives the message and executes the 
> receive block but the context.stop(self) fails
>
>
> [2015-01-12 10:33:47,735] [DEBUG] 
> LocalActorRefProvider(akka://Example2BoxTwo) - Received command 
> [DaemonMsgCreate(Props(Deploy(,Config(SimpleConfigObject({})),NoRouter,RemoteScope(akka.tcp://Example2BoxTwo@127.0.0.1:2553),,),class
>  
> SquarerActor,Vector()),Deploy(,Config(SimpleConfigObject({})),NoRouter,RemoteScope(akka.tcp://Example2BoxTwo@127.0.0.1:2553),,),akka.tcp://Example2BoxTwo@127.0.0.1:2553/remote/akka.tcp/Example1OneBoxOneTaskAllocatorActor@127.0.0.1:2552/user/taskAllocatorActor/5#562890728,Actor[akka.tcp://Example1OneBoxOneTaskAllocatorActor@127.0.0.1:2552/user/taskAllocatorActor#1735676205]
>  
> )]
>  to RemoteSystemDaemon on [akka://Example2BoxTwo]
>
> [2015-01-12 10:33:47,747] [INFO] SquarerActor - 
> Thread[Example2BoxTwo-akka.actor.default-dispatcher-21,5,main] 5: 5^2 = 25 
> for 
> Actor[akka.tcp://Example1OneBoxOneTaskAllocatorActor@127.0.0.1:2552/user/taskAllocatorActor#1735676205]
>
>  [2015-01-12 10:33:47,760] [DEBUG] 
> LocalActorRefProvider(akka://Example2BoxTwo) - resolve of path sequence 
> [/remote/akka.tcp/Example1OneBoxOneTaskAllocatorActor@127.0.0.1:2552/user/taskAllocatorActor/5#562890728]
>  failed
>
> [2015-01-12 10:33:47,792] [WARN] LocalActorRefProvider(akka://Example2BoxTwo) 
> - Unknown message 
> [DeathWatchNotification(Actor[akka.tcp://Example1OneBoxOneTaskAllocatorActor@127.0.0.1:2552/user/taskAllocatorActor#1735676205],true,false)]
>  received by [Actor[akka://Example2BoxTwo/remote]]
>
> [2015-01-12 10:33:47,820] [ERROR] akka.remote.EndpointWriter - 
> AssociationError [akka.tcp://Example2BoxTwo@127.0.0.1:2553] <- 
> [akka.tcp://Example1OneBoxOneTaskAllocatorActor@127.0.0.1:2552]: Error [Shut 
> down address: akka.tcp://Example1OneBoxOneTaskAllocatorActor@127.0.0.1:2552] 
> [ akka.remote.ShutDownAssociation: Shut down addre

Re: [akka-user] Re: How to support looser coupling in scaled out Akka systems?

2015-01-14 Thread Akka Team

Hello there,
Patrik's pub-sub module definitely has been used in larger deployments
already and proved itself to be a valuable tool.
Our plans about the cluster utilities currently in contrib are to promote
them into "akka proper", that is they'll end up in new modules:
akka-cluster-sharding, akka-cluster-tools etc.

Here is the issue which talks about this move:
https://github.com/akka/akka/issues/13711

I wouldn't hesitate on using it if it fits your use-case, even though it
currently still resides in contrib.

-- 
Konrad

On Sun, Jan 11, 2015 at 6:24 AM, mark  wrote:

> Thanks Ryan, that certainly makes sense and is something I'm considering,
> though I would rather not introduce another technology if possible.
>
> That contrib from Patrik looks promising, I would be interested to know if
> anyone has used it in a meaningful production scenario and, if so, what the
> experience was like. Also if it's ever likely to make it into the main
> library..
> On 11 Jan 2015 13:18, "Ryan Tanner"  wrote:
>
>> If you want distributed pub/sub, I would use an actual pub/sub system.
>> Akka can certainly do it, but Kafka or RabbitMQ are built *specifically
>> for that purpose, *especially if you want distributed pub/sub.  Of
>> course the publishers and consumers on either end can be Akka-based.
>>
>> Though there is the distributed pub/sub extension in contrib:
>> http://doc.akka.io/docs/akka/snapshot/contrib/distributed-pub-sub.html
>>
>> On Saturday, January 10, 2015 at 8:34:17 PM UTC-7, manwood wrote:
>>>
>>> I would like to be able to publish messages on an 'message bus' within
>>> my Akka system, rather than force actors to know about the actors that
>>> consume the events they generate (ie. avoid using *context.actorOf*).
>>>
>>> I know there is the event bus construct, but my understanding is this is
>>> limited to operating within a local process. Is there a recommended way of
>>> supporting a properly message-driven Akka architecture that scales across
>>> remote processes?
>>>
>>  --
>> >> 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 a topic in the
>> Google Groups "Akka User List" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/akka-user/GXeqwgU7Bd4/unsubscribe.
>> To unsubscribe from this group and all its topics, 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.
>>
>  --
> >> 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.

Re: [akka-user] Akka Cluster and Persistence Consistency

2015-01-14 Thread Akka Team

Hi Oleg,
Your understanding of both topics, in the current version of Akka, are
correct.
More specifically:

Is it possible to configure Akka Cluster with auto-downing so that with
> 100% probability at each moment at most one cluster node thinks that he is
> the leader (or singleton) even in case of cluster partitions? Some
> emails/blog posts imply that requiring cluster partition to be majority
> quorum does the trick?

The auto-downing strategy currently provided is a rather naive one - just
timeout based. It does not guard against split brains, which is why I would
rather not encourage using auto-downing if your cluster needs any kind of
"single" entity.
The timer based auto downing works well for clusters where you have "many
workers, but no master" for example, since causing a split need not end in
a wrong "leader" being elected (since there is no leader).

Yes, quorum would help making downing more safe (avoid split brains),
however we have not implemented it yet (we are aware of the need and
possibility of course).

How to do it with auto-scaling clusters?

In general it boils down to disallowing situations where the cluster can
get "two majorities" (one side knows only old nodes, new side has more
nodes and didn't reach quorum yet).
One of the methods I'm aware of is described in the raft paper - section 6:
membership changes , which
describes how it guarantees that at no point in time there can be "two
majorities".

We have not looked into implementing a better downing strategy yet but it's
"on the radar" - it's not a given it would be raft based, needs more
thought put into it.

Am I correct that if two actors with the same persistence id work
> concurrently on different cluster partitions the sequence numbers of events
> will get mixed up?

Correct, currently these sequence numbers are "source of truth" and mixing
them up causes problems during replay.

> Does it imply that if Akka Persistence is used with Akka Cluster Sharding
> then Akka Cluster must guarantee uniqueness of ShardCoordinator?

In fact, the cluster sharding *uses* persistence in order to survive the
leader going down - so we can restore the shard allocation information once
the new coordinator boots up.

Yes, currently there is a hard requirement for "only one writer" in
akka-persistence. This can be facilitated by either cluster-sharding or
cluster-singletons.

Slightly related "future work": We do have some CRDT work by Patrik
Nordwall stashed (it's public as akka-data-replication) and will want to
move it into Akka main at some point,
those of course do not require any kind leaders in the cluster.

Hope this helps!

-- 
Konrad

On Mon, Jan 12, 2015 at 5:55 PM, Oleg Mürk  wrote:

> Hello!
>
> I would like to better understand and confirm consistency guarantees of
> Akka Cluster and Persistence (ideally in terms of CAP and CRDTs) and
> apologise if these questions have been discussed before :)
>
> Akka Cluster:
> Is it possible to configure Akka Cluster with auto-downing so that with
> 100% probability at each moment at most one cluster node thinks that he is
> the leader (or singleton) even in case of cluster partitions? Some
> emails/blog posts imply that requiring cluster partition to be majority
> quorum does the trick? How to do it with auto-scaling clusters?
>
> Akka Persistence:
> Am I correct that if two actors with the same persistence id work
> concurrently on different cluster partitions the sequence numbers of events
> will get mixed up? Does it imply that if Akka Persistence is used with Akka
> Cluster Sharding then Akka Cluster must guarantee uniqueness of
> ShardCoordinator?
>
> Some relevant messages that I managed to find are:
> * Quorum-based split brain resolution
>   https://groups.google.com/d/msg/akka-user/UBSF3QQnGaM/r8YUEzr2EtEJ
>   https://groups.google.com/d/msg/akka-user/UBSF3QQnGaM/Jsg30N9ORQQJ
> * Exactly *one* persistence actor with the same persistenceId active ?
>   https://groups.google.com/d/msg/akka-user/9E65YaKI2BE/SA3px74h0ugJ
>   https://groups.google.com/d/msg/akka-user/9E65YaKI2BE/hZon4M_z0AgJ
>
> Thank You!
> Oleg Mürk
>
> --
> >> 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/
>>  Che

Re: [akka-user] Akka Cluster and Persistence Consistency

2015-01-14 Thread Endre Varga

On Wed, Jan 14, 2015 at 5:02 PM, Akka Team  wrote:

> Hi Oleg,
> Your understanding of both topics, in the current version of Akka, are
> correct.
> More specifically:
>
> Is it possible to configure Akka Cluster with auto-downing so that with
>> 100% probability at each moment at most one cluster node thinks that he is
>> the leader (or singleton) even in case of cluster partitions? Some
>> emails/blog posts imply that requiring cluster partition to be majority
>> quorum does the trick?
>
> The auto-downing strategy currently provided is a rather naive one - just
> timeout based. It does not guard against split brains, which is why I would
> rather not encourage using auto-downing if your cluster needs any kind of
> "single" entity.
> The timer based auto downing works well for clusters where you have "many
> workers, but no master" for example, since causing a split need not end in
> a wrong "leader" being elected (since there is no leader).
>
> Yes, quorum would help making downing more safe (avoid split brains),
> however we have not implemented it yet (we are aware of the need and
> possibility of course).
>

Well, to be precise, everything is there for anyone to implement their own
downing strategy, we just not provided a prepackaged solution for example
for quorum. Akka cluster is a toolbox, but it seems like there is high
demand for pre-packaged "just works" solutions.

-Endre


>
> How to do it with auto-scaling clusters?
>
> In general it boils down to disallowing situations where the cluster can
> get "two majorities" (one side knows only old nodes, new side has more
> nodes and didn't reach quorum yet).
> One of the methods I'm aware of is described in the raft paper - section
> 6: membership changes , which
> describes how it guarantees that at no point in time there can be "two
> majorities".
>
> We have not looked into implementing a better downing strategy yet but
> it's "on the radar" - it's not a given it would be raft based, needs more
> thought put into it.
>
>
> Am I correct that if two actors with the same persistence id work
>> concurrently on different cluster partitions the sequence numbers of events
>> will get mixed up?
>
> Correct, currently these sequence numbers are "source of truth" and mixing
> them up causes problems during replay.
>
>
>> Does it imply that if Akka Persistence is used with Akka Cluster Sharding
>> then Akka Cluster must guarantee uniqueness of ShardCoordinator?
>
> In fact, the cluster sharding *uses* persistence in order to survive the
> leader going down - so we can restore the shard allocation information once
> the new coordinator boots up.
>
> Yes, currently there is a hard requirement for "only one writer" in
> akka-persistence. This can be facilitated by either cluster-sharding or
> cluster-singletons.
>
> Slightly related "future work": We do have some CRDT work by Patrik
> Nordwall stashed (it's public as akka-data-replication) and will want to
> move it into Akka main at some point,
> those of course do not require any kind leaders in the cluster.
>
>
> Hope this helps!
>
> --
> Konrad
>
> On Mon, Jan 12, 2015 at 5:55 PM, Oleg Mürk  wrote:
>
>> Hello!
>>
>> I would like to better understand and confirm consistency guarantees of
>> Akka Cluster and Persistence (ideally in terms of CAP and CRDTs) and
>> apologise if these questions have been discussed before :)
>>
>> Akka Cluster:
>> Is it possible to configure Akka Cluster with auto-downing so that with
>> 100% probability at each moment at most one cluster node thinks that he is
>> the leader (or singleton) even in case of cluster partitions? Some
>> emails/blog posts imply that requiring cluster partition to be majority
>> quorum does the trick? How to do it with auto-scaling clusters?
>>
>> Akka Persistence:
>> Am I correct that if two actors with the same persistence id work
>> concurrently on different cluster partitions the sequence numbers of events
>> will get mixed up? Does it imply that if Akka Persistence is used with Akka
>> Cluster Sharding then Akka Cluster must guarantee uniqueness of
>> ShardCoordinator?
>>
>> Some relevant messages that I managed to find are:
>> * Quorum-based split brain resolution
>>   https://groups.google.com/d/msg/akka-user/UBSF3QQnGaM/r8YUEzr2EtEJ
>>   https://groups.google.com/d/msg/akka-user/UBSF3QQnGaM/Jsg30N9ORQQJ
>> * Exactly *one* persistence actor with the same persistenceId active ?
>>   https://groups.google.com/d/msg/akka-user/9E65YaKI2BE/SA3px74h0ugJ
>>   https://groups.google.com/d/msg/akka-user/9E65YaKI2BE/hZon4M_z0AgJ
>>
>> Thank You!
>> Oleg Mürk
>>
>> --
>> >> 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 g

[akka-user] upgrading production cluster (sharded) system

2015-01-14 Thread Peter

Hi

I wonder if anyone has experience or thoughts to share about upgrading 
production cluster systems?

I would ideally like to 

   - upgrade the cluster without downtime/scheduled outage
   - not mutate infrastructure, in other words, deploy a new set of nodes 
   with the new version
   - do a staged upgrade, first just a single node taking as little as 
   possible production traffic - a canary in the coal mine


A little bit more about my specific environment

   - cluster runs as a single EC2 autoscale group
   - no akka roles (looking into this as a way to gain independence between 
   functional areas within the application & facilitate independent upgrades - 
   something akin to micro services to use the buzzword du jour) 
   - i don't use akka persistence but each sharded actor is backed by my 
   own distributed persistence mechanism based on DynamoDB
   - there is some tolerance for stale reads but there could be some cases 
   where it's not acceptable

My understanding is that the number of cluster shards should be kept 
constant irrespective of number of cluster nodes, so that the shard 
resolution also remains stable irrespective of number of cluster nodes, as 
in the example in the documentation. It sounds like the bundled rebalancing 
strategy (LeastShardAllocationStrategy) should do the trick when adding the 
first node (canary). I'm wondering if there's any suggestions for doing the 
rest?


   - start all of the remaining new cluster nodes 
  - at what point does rebalancing get kicked off? is there a specific 
  event that triggers a rebalance? is it possible to delay until all the 
new 
  nodes/X nodes has joined/Y time has passed to minimize disruption (single 
  rebalance vs rebalance for every node)
   - wait for period X to ensure rebalancing is complete and all buffered 
   messages during rebalancing has been processed 
  - is it possible to determine this programmatically?
   - stop all the old version nodes 
  - one by one with a period in between or all at once?
  - at this point, messages in flight are lost, need to fall back to 
  clients to retry
   
It gets progressively more hand wavy towards the end as I'm still thinking 
about the details, would love some input & feedback!

Thanks
Peter

-- 
>>  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.

Re: [akka-user] Re: ResendUnfulfillableException in remoting

2015-01-14 Thread Jim Newsham


Thanks Endre for the prompt reply, and the good news!  I look forward to 
the next release.

Regards,
Jim

-- 
>>  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.

Re: [akka-user] time estimate for clustering an akka app

2015-01-14 Thread Justin du coeur

Others may have different opinions, but I suspect there's too much "your
mileage may vary" to answer the question.  For example, I'm planning for
two months to cluster my app (probably starting in March) -- but that's
about forty thousand lines of code involving several dozen different Actor
types, including almost a dozen singletons that need to be properly sharded
around the system.  (The architecture of this system predates Akka
Clustering, much less Cluster Sharding, so there's a lot to be evolved.)

That's probably the upper edge.  I would guess that the correct answer
depends strongly on how "clean" your system already is.  If it's full of
relatively uniform Actors and is simply being scaled out, it's likely
relatively easy.  The more heterogeneous the system, the more singletons
you currently have, and the more you care about which Actors land on which
nodes, the more work it's likely to be...

On Tue, Jan 13, 2015 at 10:42 AM, Tim Pigden  wrote:

> Hi
> I'm doing a proposal. I need a rough time in days to turn a single machine
> akka application - using spray/akka-http into something that runs on a
> cluster (of 2 for time being, located on same site).
> Assume I have never clustered an akka and didn't sit through that last bit
> of Roland's coursera course - so I have no idea what's involved - so learn
> then do it.
> Is a week enough?
>
>  --
> >> 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.
>

-- 
>>  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-user] Re: Sharing behavior among Actors in Java

2015-01-14 Thread Adam

Hi,
I guess the correct answer is "it depends" J, but I can describe what we 
use right now, as we're also using Akka (and seeing as it's been very 
rewarding to do so we do it more and more), but are confined to Java.So 
first of all, I would recommend against inheritance.
That route quickly becomes very tangled and results in a huge hierarchy of 
classes with way too many methods.

We typically use composition.
I assume the real issue is cases where you want to reuse code that relies 
on running inside an Actor.
Unfortunately UntypedActor is not an interface, so it's indeed difficult to 
mix in behavior.However, since a class method is really not much more than 
a static method that implicitly accepts the "this" pointer (some languages 
like python and Ada even work that way and specify all arguments 
explicitly), your actors can contain other classes that either have methods 
which accept an UntypedActor as a parameter, or accept it in their 
constructor.

We use that often for synchronous paths.

An example:

public class DbAccess {
private final UntypedActor owner;
public DbAccess(UntypedActor owner) {
this.owner = owner;
}

//methods for DB access
}

public class Auth {
private final UntypedActor owner;
public Auth(UntypedActor owner) {
this.owner = owner;
}

//methods for Authentication
}

public class MyActor extends UntypedActor{
private final DbAccess db = new DbAccess(this);
private final Auth auth = new Auth(this);

public void onReceive(Object msg){
//use the shared logic of db and auth wherever needed
}
}

(One nasty issue here is that the constructor of MyActor is sending "this" 
before it's fully constructed, so it's probably better to move the 
initialization of dependencies to preStart, but I kept the code shorter 
here)

There are exceptions to this rule.

For example, if you wanted to override any of the UntypedActor methods 
(e.g. we do that for one-off actors so they will stop in case of an 
unhandled message), you'd have to use inheritance, so in some cases we do 
use that, but we try to keep it down to as few levels of it as possible.

Another alternative if you're using Java 8 AND your methods don't rely on 
state, is to use interfaces with default methods,as a poor man's 
replacement for Scala traits.

In that case, if you wanted to rely on running inside an actor you could 
require actors to implement a single interface that exposes the this 
pointer and then add as many interfaces with default methods as you wish.
For example:

public interface ActorExposer {
public UntypedActor getActor();
}

public interface DbUser extends ActorExposer{
//methods for DB access
public default ...
}

public class Auth extends ActorExposer{
//methods for Authentication
public default ...
}

public class MyActor implements DbUser, Auth{
public void onReceive(Object msg){
//use the shared logic of db and auth whereever needed
}

@Override
public UntypedActor getActor() {
return this;
}
}

Finally, for asynchronous paths we simply use more actors, but I assume 
that was already obvious to you and you were asking about the previous part 
of my answer.
I hope this helps.

Adam.

On Tuesday, January 13, 2015 at 10:46:45 PM UTC+2, Alon Goldshuv wrote:
>
> (newbie question)
>
> Hi,
>
> I'd like to write a set of Actors that behave very similarly, however have 
> a few differences as well. 
> In plain java world I'd write an Abstract parent class that includes all 
> of the shared behavior, have each child class extend it, and override only 
> the class methods that differ from the abstract class implementation.
>
> I'm not sure how to do it in Akka - Java. I've seen a very similar 
> question and a really nice answer here 
> ,
>  
> but it's using scala, and scala traits.
>
> My initial thought was something like:
>
> public abstract class MyParentActor(...) extends UntypedActor {
> ...
> 
> }
>
>
> public class MyChildActor1(...) extends MyParentActor {
> super(...);
> 
>
> public void onReceive(msg) {
>   
> }
> }
>
> Is that a good idea? will that work?
>
> BTW, since the project has yet to start, I'm not tied to a specific Akka 
> version, so I assume 2.3.8.
>
> Thanks in advance!
> Alon.
>
>

-- 
>>  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://group

[akka-user] weird reason of "association with remote system has failed"

2015-01-14 Thread Nan Zhu

Hi, all

Here is the overview of my system 

(two machines)

ActorSystem1 (RemoteActorRefProvider )  => 
ActorSystem2(ClusterActorRefProvider)

actor in ActorSystem1 sent a hello message to actorSystem2 via a 
cluster-aware router, and the receiver in the cluster replies a message 
"Reply" (defined by me)

Now, the problem is 

ActorSystem2 can see the hello message from ActorSystem1, 

however, ActorSystem1 complains that the association with ActorSystem2 has 
failed, Reason [Reply]...

I'm confused by the reason of the failed Association...the reason is the 
user-defined message?

additional information: (though I don't think it's relevant)

ActorSystem2 is running a Cluster Sharding system 

Can anyone give some hint about this situation? 

Thank you 

Nan 

-- 
>>  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-user] Re: weird reason of "association with remote system has failed"

2015-01-14 Thread Nan Zhu

sorry, the reason is [x.y.Reply$], i.e. full path of the message class

On Wednesday, January 14, 2015 at 4:53:36 PM UTC-5, Nan Zhu wrote:
>
> Hi, all
>
> Here is the overview of my system 
>
> (two machines)
>
> ActorSystem1 (RemoteActorRefProvider )  => 
> ActorSystem2(ClusterActorRefProvider)
>
> actor in ActorSystem1 sent a hello message to actorSystem2 via a 
> cluster-aware router, and the receiver in the cluster replies a message 
> "Reply" (defined by me)
>
> Now, the problem is 
>
> ActorSystem2 can see the hello message from ActorSystem1, 
>
> however, ActorSystem1 complains that the association with ActorSystem2 has 
> failed, Reason [Reply]...
>
> I'm confused by the reason of the failed Association...the reason is the 
> user-defined message?
>
> additional information: (though I don't think it's relevant)
>
> ActorSystem2 is running a Cluster Sharding system 
>
> Can anyone give some hint about this situation? 
>
> Thank you 
>
> Nan 
>
>

-- 
>>  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.

Re: [akka-user] time estimate for clustering an akka app

2015-01-14 Thread Tim Pigden

Hi thanks
I've been doing some research and concluded that was probably the case
(mileage may vary that is)
 On 14 Jan 2015 21:26, "Justin du coeur"  wrote:

> Others may have different opinions, but I suspect there's too much "your
> mileage may vary" to answer the question.  For example, I'm planning for
> two months to cluster my app (probably starting in March) -- but that's
> about forty thousand lines of code involving several dozen different Actor
> types, including almost a dozen singletons that need to be properly sharded
> around the system.  (The architecture of this system predates Akka
> Clustering, much less Cluster Sharding, so there's a lot to be evolved.)
>
> That's probably the upper edge.  I would guess that the correct answer
> depends strongly on how "clean" your system already is.  If it's full of
> relatively uniform Actors and is simply being scaled out, it's likely
> relatively easy.  The more heterogeneous the system, the more singletons
> you currently have, and the more you care about which Actors land on which
> nodes, the more work it's likely to be...
>
> On Tue, Jan 13, 2015 at 10:42 AM, Tim Pigden 
> wrote:
>
>> Hi
>> I'm doing a proposal. I need a rough time in days to turn a single
>> machine akka application - using spray/akka-http into something that runs
>> on a cluster (of 2 for time being, located on same site).
>> Assume I have never clustered an akka and didn't sit through that last
>> bit of Roland's coursera course - so I have no idea what's involved - so
>> learn then do it.
>> Is a week enough?
>>
>>  --
>> >> 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.
>>
>
>  --
> >> 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 a topic in the
> Google Groups "Akka User List" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/akka-user/Fq2QCIB0s04/unsubscribe.
> To unsubscribe from this group and all its topics, 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.
>

-- 
>>  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.

Re: [akka-user] Akka Cluster and Persistence Consistency

2015-01-14 Thread Oleg Mürk

Hello!

Thanks for the answers! I have a few more questions/clarifications below, 
if You don't mind.

On Wednesday, January 14, 2015 at 6:02:33 PM UTC+2, Akka Team wrote:
>
>
>> Is it possible to configure Akka Cluster with auto-downing so that with 
>> 100% probability at each moment at most one cluster node thinks that he is 
>> the leader (or singleton) even in case of cluster partitions? Some 
>> emails/blog posts imply that requiring cluster partition to be majority 
>> quorum does the trick? 
>
> The auto-downing strategy currently provided is a rather naive one - just 
> timeout based. It does not guard against split brains, which is why I would 
> rather not encourage using auto-downing if your cluster needs any kind of 
> "single" entity.
> The timer based auto downing works well for clusters where you have "many 
> workers, but no master" for example, since causing a split need not end in 
> a wrong "leader" being elected (since there is no leader).
>

I'd like to better understand what happens to a Leader if it becomes 
unreachable. Auto-down is impossible because it can only be performed by 
the Leader, right? Can I execute Down command on non-leader member of 
cluster when the Leader is unreachable?
 

> Am I correct that if two actors with the same persistence id work 
>> concurrently on different cluster partitions the sequence numbers of events 
>> will get mixed up? 
>
> Correct, currently these sequence numbers are "source of truth" and mixing 
> them up causes problems during replay.
>  
>
>> Does it imply that if Akka Persistence is used with Akka Cluster Sharding 
>> then Akka Cluster must guarantee uniqueness of ShardCoordinator?
>
> In fact, the cluster sharding *uses* persistence in order to survive the 
> leader going down - so we can restore the shard allocation information once 
> the new coordinator boots up.
>
Yes, currently there is a hard requirement for "only one writer" in 
> akka-persistence. This can be facilitated by either cluster-sharding or 
> cluster-singletons.
>

So Persistence and consequently Sharding cannot be used in potential 
split-brain cluster configurations? Because ShardCoordinator could 
potentially run on both partitions simultaneously?

Also if Persistence is storing state in eventually consistent replicated 
journal (eg Cassandra) wouldn't there be inconsistencies in case of journal 
cluster network partition?

Slightly related "future work": We do have some CRDT work by Patrik 
> Nordwall stashed (it's public as akka-data-replication) and will want to 
> move it into Akka main at some point, those of course do not require any 
> kind leaders in the cluster.
>

As I am sure You know, there is whole infrastructure for consistent highly 
reliable distributed coordination:
  http://zookeeper.apache.org/
  http://curator.apache.org/
  http://helix.apache.org/
Zookeeper's async API at first glance looks like a perfect match for Akka 
and FSM?

But as outlined below You discovered that Zookeeper doesn't suit Your needs 
well. May be You could share Your findings?
  http://letitcrash.com/post/26626939256/status-report-of-akka-cluster
> In the process we have implemented and thrown away prototypes using both 
ZooKeeper, JGroups and Hazelcast. 
> None of them solved the problem optimally and each one imposed its own 
set of unnecessary constraints and drawbacks. 
> We strongly believe that a loosely coupled, eventually consistent, fully 
decentralized and self-coordinating P2P solution 
> is the right way to scale an actor system and to make it fully resilient 
to failure. 

Thank You!
Oleg

-- 
>>  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.

Re: [akka-user] Akka Cluster and Persistence Consistency

2015-01-14 Thread Patrik Nordwall

On Wed, Jan 14, 2015 at 6:58 PM, Oleg Mürk  wrote:

> Hello!
>
> Thanks for the answers! I have a few more questions/clarifications below,
> if You don't mind.
>
> On Wednesday, January 14, 2015 at 6:02:33 PM UTC+2, Akka Team wrote:
>>
>>
>>> Is it possible to configure Akka Cluster with auto-downing so that with
>>> 100% probability at each moment at most one cluster node thinks that he is
>>> the leader (or singleton) even in case of cluster partitions? Some
>>> emails/blog posts imply that requiring cluster partition to be majority
>>> quorum does the trick?
>>
>> The auto-downing strategy currently provided is a rather naive one - just
>> timeout based. It does not guard against split brains, which is why I would
>> rather not encourage using auto-downing if your cluster needs any kind of
>> "single" entity.
>> The timer based auto downing works well for clusters where you have "many
>> workers, but no master" for example, since causing a split need not end in
>> a wrong "leader" being elected (since there is no leader).
>>
>
> I'd like to better understand what happens to a Leader if it becomes
> unreachable. Auto-down is impossible because it can only be performed by
> the Leader, right? Can I execute Down command on non-leader member of
> cluster when the Leader is unreachable?
>

Akka Cluster doesn't require a strict leader for managing the cluster
membership. The membership data is a Conflict Free Replicated Data Type
(CRDT) so if there are conflicting updates they can be merged anyway. The
leader is just a role for a node that performs certain actions and it is
alright if several nodes thinks they have this role.


>
>
>> Am I correct that if two actors with the same persistence id work
>>> concurrently on different cluster partitions the sequence numbers of events
>>> will get mixed up?
>>
>> Correct, currently these sequence numbers are "source of truth" and
>> mixing them up causes problems during replay.
>>
>>
>>> Does it imply that if Akka Persistence is used with Akka Cluster
>>> Sharding then Akka Cluster must guarantee uniqueness of ShardCoordinator?
>>
>> In fact, the cluster sharding *uses* persistence in order to survive the
>> leader going down - so we can restore the shard allocation information once
>> the new coordinator boots up.
>>
> Yes, currently there is a hard requirement for "only one writer" in
>> akka-persistence. This can be facilitated by either cluster-sharding or
>> cluster-singletons.
>>
>
> So Persistence and consequently Sharding cannot be used in potential
> split-brain cluster configurations? Because ShardCoordinator could
> potentially run on both partitions simultaneously?
>

It is right that you must only be one active instance of a PersistentActor
with a given persistenceId, i.e. single writer to the journal. That is true
also for the ShardCoordinator, since it is a PersistentActor.

That means that you must handle network partitions carefully and use a
proper downing strategy as discussed earlier. We have acknowledged that a
packaged solution for improving this have been requested by many users.


>
> Also if Persistence is storing state in eventually consistent replicated
> journal (eg Cassandra) wouldn't there be inconsistencies in case of journal
> cluster network partition?
>

Not if you use a proper consistency level

for the write and reads, e.g. quorum.


>
> Slightly related "future work": We do have some CRDT work by Patrik
>> Nordwall stashed (it's public as akka-data-replication) and will want to
>> move it into Akka main at some point, those of course do not require any
>> kind leaders in the cluster.
>>
>
> As I am sure You know, there is whole infrastructure for consistent highly
> reliable distributed coordination:
>   http://zookeeper.apache.org/
>   http://curator.apache.org/
>   http://helix.apache.org/
> Zookeeper's async API at first glance looks like a perfect match for Akka
> and FSM?
>

>
> But as outlined below You discovered that Zookeeper doesn't suit Your
> needs well. May be You could share Your findings?
>   http://letitcrash.com/post/26626939256/status-report-of-akka-cluster
> > In the process we have implemented and thrown away prototypes using both
> ZooKeeper, JGroups and Hazelcast.
> > None of them solved the problem optimally and each one imposed its own
> set of unnecessary constraints and drawbacks.
> > We strongly believe that a loosely coupled, eventually consistent, fully
> decentralized and self-coordinating P2P solution
> > is the right way to scale an actor system and to make it fully resilient
> to failure.
>
>
We don't need strong coordination for cluster membership and we have the
goal to support large clusters
,
which I believe would not be possible with Zookeeper. Zookeeper is great,
but it is solving a different set of problems.

It

Re: [akka-user] Re: ResendUnfulfillableException in remoting

Re: [akka-user] Dokumentation inconsistency

Re: [akka-user] Dokumentation inconsistency

Re: [akka-user] Re: UnboundedPriorityMailbox breaks message ordering?

Re: [akka-user] Re: UnboundedPriorityMailbox breaks message ordering?

Re: [akka-user] Re: UnboundedPriorityMailbox breaks message ordering?

Re: [akka-user] Akka 2.3.8: context.stop(self) and self ! PoisonPill fail on remotely deployed actors

Re: [akka-user] Re: How to support looser coupling in scaled out Akka systems?

Re: [akka-user] Akka Cluster and Persistence Consistency

Re: [akka-user] Akka Cluster and Persistence Consistency

[akka-user] upgrading production cluster (sharded) system

Re: [akka-user] Re: ResendUnfulfillableException in remoting

Re: [akka-user] time estimate for clustering an akka app

[akka-user] Re: Sharing behavior among Actors in Java

[akka-user] weird reason of "association with remote system has failed"

[akka-user] Re: weird reason of "association with remote system has failed"

Re: [akka-user] time estimate for clustering an akka app

Re: [akka-user] Akka Cluster and Persistence Consistency

Re: [akka-user] Akka Cluster and Persistence Consistency

19 matches

Site Navigation

Mail list logo

Footer information