Re: [akka-user] flexible path router

[Henry Story]

> On 29 Feb 2016, at 20:17, Viktor Klang  wrote:
> 
> Actors can process millions of messages per second. What are your 
> requirements?
> 
At present that should do, as I am just building up an initial platform for a 
distributed social web. But longer term you can think of all the requests that 
Twitter or Facebook need to do, but now distributed globally. I want to be 
efficient it order to be able to deploy the server both on resource constrained 
machines (such as a Freedbom Box) and on larger servers with a lot more 
traffic. 

Even on a small personal Freedom Box, there may actually be quite a bit going 
on on the type of service I am building, such as reasoning, fetching thousands 
of resources of the internet, parsing, serialising data, querying it, etc... 
Each request may have to fetch many other resources to verify access control, 
etc... We are not there yet, but I just want to get the architecture right as I 
am rewriting it with akka http.

Having worked at  AltaVista I tend to be a little concerned about wasting 
resources unecessarily.  Also if I mention the use case now then either I will 
be told about the right way to do things, or in a year or so there may actually 
be an optimal feature in akka, so that my code when it gets deployed in larger 
services can become a lot more efficient. 

Imagine I have a url with 30 nested directories, then if each actor needs to 
send the message to each directory, to be passed on from there to the next 
actor then the message would need to go through 30 message boxes to get to its 
destination. Each actor must block to finish processing each message, so the 
speed at which a message goes through an actor depends on the speed at which 
the code for that actor is executed, and the length of the message queue. If 
every message has to go through the root then we have to sequentially process 
all messages. And this would have to be done 30 times. On the other hand if we 
could direct it as quickly as possible directly to the actor that is the 
destintion then this bottleneck would not occur.  The data already seems to be 
available in the ActorCells so it should be possible to avoid all of that.

Anyway, I was not sure if I had missed a feature that would avoid the scenario 
described above.  
For the moment I can just make the message go through each 
directory/supervisor. But perhaps this use 
case may make sense and so the feature I was thinking of can get added to akka 
in due course. 

Henry
> -- 
> Cheers,
> √
> 
> On Feb 29, 2016 2:05 PM, "Henry Story"  > wrote:
> Hi,
> 
>I am writing an Http Server where each resource on the file system is the 
> responsibility of an actor. 
> To keep it simple, there are at least two types of actors: one responsible 
> for directories and one responsible 
> for files. Directory actors will be actors with children and files will be 
> actors without. 
> 
> Now clearly we don't really want to load all actors for the whole file system 
> in one go, as it could be huge.
> So I'd like to have actors appear as they are requested. 
> 
> The way I was thinking of going about it is creating a Router that would take 
> a RoutingLogic which would have 
> a contructor  taking a root  ActorContext (or something) and try to follow 
> the HttpRequest's Akka.Uri path segment 
> by  segment until it finds either a remote ActorRef or one that does not 
> exist. Then the Router could send the HttpRequest to that actor, and it could 
> check out different things:
> 
> if the request is a GET on a resource which is available but not created, 
> create that actor and send it the HttpRequest.
> if the request is a PUT on a resource that does not exist, check if the 
> author of the GET has access rights to create it, and if so make the actor 
> for it.
>   ...
> 
> But I can't find an efficient way of walking through the contexts, though as 
> I look at the akka code it seems to be available, just all of it is private. 
> Would it make sense to have a method context.findFirst(path) that would do 
> this? Or have I missed an obvious api?
> 
> Of course I could just send messages to the root actor, but that would be 
> quite inefficient I think in the longer term, as the root Actor would receive 
> every single message sent its way.
> 
> Henry
> 
> -- 
> >> 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 

Re: [akka-user] flexible path router

[Viktor Klang]

Actors can process millions of messages per second. What are your
requirements?

-- 
Cheers,
√
On Feb 29, 2016 2:05 PM, "Henry Story"  wrote:

> Hi,
>
>I am writing an Http Server where each resource on the file system is
> the responsibility of an actor.
> To keep it simple, there are at least two types of actors: one responsible
> for directories and one responsible
> for files. Directory actors will be actors with children and files will be
> actors without.
>
> Now clearly we don't really want to load all actors for the whole file
> system in one go, as it could be huge.
> So I'd like to have actors appear as they are requested.
>
> The way I was thinking of going about it is creating a Router that would
> take a RoutingLogic which would have
> a contructor  taking a root  ActorContext (or something) and try to
> follow the HttpRequest's Akka.Uri path segment
> by  segment until it finds either a remote ActorRef or one that does not
> exist. Then the Router could send the HttpRequest to that actor, and it
> could check out different things:
>
>
>- if the request is a GET on a resource which is available but not
>created, create that actor and send it the HttpRequest.
>- if the request is a PUT on a resource that does not exist, check if
>the author of the GET has access rights to create it, and if so make
>the actor for it.
>
>   ...
>
> But I can't find an efficient way of walking through the contexts, though
> as I look at the akka code it seems to be available, just all of it is
> private. Would it make sense to have a method context.findFirst(path)
> that would do this? Or have I missed an obvious api?
>
> Of course I could just send messages to the root actor, but that would be
> quite inefficient I think in the longer term, as the root Actor would
> receive every single message sent its way.
>
> Henry
>
> --
> >> 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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Re: flexible path router

[Henry Story]

I opened akka issue 19919  for 
 this, as it seems to me that there is a small piece of functionality 
missing,
that it would not be that difficult to add, namely something like 
context.actorReach(path) to find
the ActorRef for the actor or its closest supervisor. 

Otherwise one could get by creating a global database for the VM, but that 
would end up just duplicating all
the code in ActorCell, from what I can tell by having studied the code a 
bit.
   


On Monday, 29 February 2016 13:04:56 UTC, Henry Story wrote:
>
> Hi,
>
>I am writing an Http Server where each resource on the file system is 
> the responsibility of an actor. 
> To keep it simple, there are at least two types of actors: one responsible 
> for directories and one responsible 
> for files. Directory actors will be actors with children and files will be 
> actors without. 
>
> Now clearly we don't really want to load all actors for the whole file 
> system in one go, as it could be huge.
> So I'd like to have actors appear as they are requested. 
>
> The way I was thinking of going about it is creating a Router that would 
> take a RoutingLogic which would have 
> a contructor  taking a root  ActorContext (or something) and try to 
> follow the HttpRequest's Akka.Uri path segment 
> by  segment until it finds either a remote ActorRef or one that does not 
> exist. Then the Router could send the HttpRequest to that actor, and it 
> could check out different things:
>
>
>- if the request is a GET on a resource which is available but not 
>created, create that actor and send it the HttpRequest.
>- if the request is a PUT on a resource that does not exist, check if 
>the author of the GET has access rights to create it, and if so make 
>the actor for it.
>
>   ...
>
> But I can't find an efficient way of walking through the contexts, though 
> as I look at the akka code it seems to be available, just all of it is 
> private. Would it make sense to have a method context.findFirst(path) 
> that would do this? Or have I missed an obvious api?
>
> Of course I could just send messages to the root actor, but that would be 
> quite inefficient I think in the longer term, as the root Actor would 
> receive every single message sent its way.
>
> Henry
>

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: DDShardCoordinator gets confused after some nodes are removed

[Bert Robben]

Sure. https://github.com/akka/akka/issues/19917 it is.

On Mon, Feb 29, 2016 at 5:17 PM, Endre Varga 
wrote:

>
>
> On Mon, Feb 29, 2016 at 5:03 PM, Bert Robben 
> wrote:
>
>> I kill the node (to simulate that the node crashes); the cluster detect
>> this as unreachable and because I have auto-down configured as "yes", the
>> master DOWNs it after some seconds (I have auto-down-unreachable-after =
>> 10s).
>>
>> I see this clearly in the logs that the node is DOWN'ed.
>>
>> And I wait way longer (5 minutes).
>>
>> So I don't think this has to do with downing. I'm with Marek on this;
>> From the docs:
>>
>>  In such case the state of the ShardCoordinator will be replicated
>> inside a cluster by the Distributed Data module with WriteMajority/
>> ReadMajority consistency
>>
>> in case my cluster is small, at some point there may no longer be a
>> majority of original nodes. And then the shard is just stuck. Bummer :-((.
>>
>
> I don't think that is supposed to happen though. I think (unless someone
> from the team corrects me) UNREACHABLE nodes should count against majority
> (since they can come back with a stale state and hence corrupt the quorum),
> but DOWN-ed nodes not (sine they cannot come back due to Quarantine --
> which is btw why this feature is so important), so this feels like a bug to
> me. Can you open a ticket and continue discussion there?
>
> -Endre
>
>
>>
>> -- Bert
>>
>> On Monday, February 29, 2016 at 4:22:43 PM UTC+1, drewhk wrote:
>>>
>>> Well, when you say "remove" nodes, do you actually DOWN them, or you
>>> just let them be marked UNREACHABLE? I think the issue might be that Akka
>>> Cluster does treat UNREACHABLE nodes as still part of the cluster and hence
>>> they count against majority decisions. DOWN-ing them removes them from the
>>> membership ring though and I think you will not see this problem.
>>>
>>> -Endre
>>>
>>> On Mon, Feb 29, 2016 at 4:08 PM, Marek Żebrowski 
>>> wrote:
>>>
 That is my experience - but I do strange things, like rolling restarts.

 --
 >> 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 https://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 https://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/I8K4fGvo4NQ/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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: DDShardCoordinator gets confused after some nodes are removed

[Endre Varga]

On Mon, Feb 29, 2016 at 5:03 PM, Bert Robben  wrote:

> I kill the node (to simulate that the node crashes); the cluster detect
> this as unreachable and because I have auto-down configured as "yes", the
> master DOWNs it after some seconds (I have auto-down-unreachable-after =
> 10s).
>
> I see this clearly in the logs that the node is DOWN'ed.
>
> And I wait way longer (5 minutes).
>
> So I don't think this has to do with downing. I'm with Marek on this; From
> the docs:
>
>  In such case the state of the ShardCoordinator will be replicated inside
> a cluster by the Distributed Data module with WriteMajority/ReadMajority
>  consistency
>
> in case my cluster is small, at some point there may no longer be a
> majority of original nodes. And then the shard is just stuck. Bummer :-((.
>

I don't think that is supposed to happen though. I think (unless someone
from the team corrects me) UNREACHABLE nodes should count against majority
(since they can come back with a stale state and hence corrupt the quorum),
but DOWN-ed nodes not (sine they cannot come back due to Quarantine --
which is btw why this feature is so important), so this feels like a bug to
me. Can you open a ticket and continue discussion there?

-Endre


>
> -- Bert
>
> On Monday, February 29, 2016 at 4:22:43 PM UTC+1, drewhk wrote:
>>
>> Well, when you say "remove" nodes, do you actually DOWN them, or you just
>> let them be marked UNREACHABLE? I think the issue might be that Akka
>> Cluster does treat UNREACHABLE nodes as still part of the cluster and hence
>> they count against majority decisions. DOWN-ing them removes them from the
>> membership ring though and I think you will not see this problem.
>>
>> -Endre
>>
>> On Mon, Feb 29, 2016 at 4:08 PM, Marek Żebrowski 
>> wrote:
>>
>>> That is my experience - but I do strange things, like rolling restarts.
>>>
>>> --
>>> >> 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 https://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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: DDShardCoordinator gets confused after some nodes are removed

[Bert Robben]

Having thought a bit further on this. Given the fact that ddata 
writemajority/readmajority replication is not guaranteed to be consistent, 
I'm having even more doubts on the behavior of sharding based on ddata in 
case of severe node failures in the cluster.

Any simple solutions for this? 

Bert

On Monday, February 29, 2016 at 5:03:11 PM UTC+1, Bert Robben wrote:
>
> I kill the node (to simulate that the node crashes); the cluster detect 
> this as unreachable and because I have auto-down configured as "yes", the 
> master DOWNs it after some seconds (I have auto-down-unreachable-after = 
> 10s). 
>
> I see this clearly in the logs that the node is DOWN'ed.
>
> And I wait way longer (5 minutes).
>
> So I don't think this has to do with downing. I'm with Marek on this; From 
> the docs:
>
>  In such case the state of the ShardCoordinator will be replicated inside 
> a cluster by the Distributed Data module with WriteMajority/ReadMajority
>  consistency
>
> in case my cluster is small, at some point there may no longer be a 
> majority of original nodes. And then the shard is just stuck. Bummer :-((.
>
> -- Bert
>
> On Monday, February 29, 2016 at 4:22:43 PM UTC+1, drewhk wrote:
>>
>> Well, when you say "remove" nodes, do you actually DOWN them, or you just 
>> let them be marked UNREACHABLE? I think the issue might be that Akka 
>> Cluster does treat UNREACHABLE nodes as still part of the cluster and hence 
>> they count against majority decisions. DOWN-ing them removes them from the 
>> membership ring though and I think you will not see this problem.
>>
>> -Endre
>>
>> On Mon, Feb 29, 2016 at 4:08 PM, Marek Żebrowski  
>> wrote:
>>
>>> That is my experience - but I do strange things, like rolling restarts.
>>>
>>> -- 
>>> >> 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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: DDShardCoordinator gets confused after some nodes are removed

[Bert Robben]

I kill the node (to simulate that the node crashes); the cluster detect 
this as unreachable and because I have auto-down configured as "yes", the 
master DOWNs it after some seconds (I have auto-down-unreachable-after = 
10s). 

I see this clearly in the logs that the node is DOWN'ed.

And I wait way longer (5 minutes).

So I don't think this has to do with downing. I'm with Marek on this; From 
the docs:

 In such case the state of the ShardCoordinator will be replicated inside a 
cluster by the Distributed Data module with WriteMajority/ReadMajority
 consistency

in case my cluster is small, at some point there may no longer be a 
majority of original nodes. And then the shard is just stuck. Bummer :-((.

-- Bert

On Monday, February 29, 2016 at 4:22:43 PM UTC+1, drewhk wrote:
>
> Well, when you say "remove" nodes, do you actually DOWN them, or you just 
> let them be marked UNREACHABLE? I think the issue might be that Akka 
> Cluster does treat UNREACHABLE nodes as still part of the cluster and hence 
> they count against majority decisions. DOWN-ing them removes them from the 
> membership ring though and I think you will not see this problem.
>
> -Endre
>
> On Mon, Feb 29, 2016 at 4:08 PM, Marek Żebrowski  > wrote:
>
>> That is my experience - but I do strange things, like rolling restarts.
>>
>> -- 
>> >> 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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] [akka-stream] tcp retransmission?

[Val P]

Thanks. I am going to write something outside the JDK to test it out. Maybe 
I have a confused IP stack, who knows.



On Monday, February 29, 2016 at 2:21:36 AM UTC-6, drewhk wrote:
>
> Hi Val,
>
> I don't really know what is going on there, Akka works via JDK NIO and 
> have no access to that low level TCP features. In other words, I really 
> don't know what is going on on your machine and why you are seeing it, but 
> I don't think we can do anything about it.
>
> -Endre
>
> On Mon, Feb 29, 2016 at 2:08 AM, Val P  
> wrote:
>
>> I am trying to understand why I'm seeing TCP retransmissions on a simple 
>> program. I created a small program based on the 2.4.2 docs:
>>
>>
>> object HelloWorld {
>>   def main(args: Array[String]): Unit = {
>> implicit val system = ActorSystem("Sys")
>> implicit val materializer = ActorMaterializer()
>>
>> val connections: Source[IncomingConnection, Future[Tcp.ServerBinding]] = 
>>  Tcp().bind("localhost", )
>> connections runForeach { connection =>
>>   // server logic, parses incoming commands
>>   val commandParser = Flow[String].takeWhile(_ != "BYE").map(_ + "!")
>>
>>   import connection._
>>   val welcomeMsg = s"Welcome to: $localAddress, you are: $remoteAddress!"
>>   val welcome = Source.single(welcomeMsg)
>>
>>
>>   val serverLogic = Flow[ByteString]
>> .via(Framing.delimiter( ByteString("\n"),  256 ))
>> .map(_.utf8String)
>> .via(commandParser)
>> // merge in the initial banner after parser
>> .merge(welcome)
>> .map(_ + "\n")
>> .map(ByteString(_))
>>
>>   connection.handleWith(serverLogic)
>> }
>>   }
>>  }
>>
>>
>>
>> But when I connect to localhost/ via telnet, type in a few lines, and 
>> watch the traffic with wireshark, I'm seeing various retransmits and out of 
>> order:
>>
>> 46482→ [SYN] Seq=0 Win=43690 Len=0 MSS=65495 SACK_PERM=1 
>> TSval=47383693 TSecr=0 WS=128 
>> →46482 [SYN, ACK] Seq=0 Ack=1 Win=43690 Len=0 MSS=65495 SACK_PERM=1 
>> TSval=47383693 TSecr=47383693 WS=128 
>> 46482→ [ACK] Seq=1 Ack=1 Win=43776 Len=0 TSval=47383693 TSecr=47383693 
>> →46482 [PSH, ACK] Seq=1 Ack=1 Win=43776 Len=56 TSval=47383719 
>> TSecr=47383693 
>> 46482→ [ACK] Seq=1 Ack=57 Win=43776 Len=0 TSval=47383719 
>> TSecr=47383719 
>> [TCP Out-Of-Order] 46482→ [SYN] Seq=0 Win=43690 Len=0 MSS=65495 
>> SACK_PERM=1 TSval=47383693 TSecr=0 WS=128 
>> [TCP Retransmission] →46482 [SYN, ACK] Seq=0 Ack=1 Win=43690 Len=0 
>> MSS=65495 SACK_PERM=1 TSval=47383693 TSecr=47383693 WS=128 
>> 46482→ [ACK] Seq=1 Ack=1 Win=43776 Len=0 TSval=47383693 TSecr=47383693 
>> [TCP Retransmission] →46482 [PSH, ACK] Seq=1 Ack=1 Win=43776 Len=56 
>> TSval=47383719 TSecr=47383693 
>> 46482→ [ACK] Seq=1 Ack=57 Win=43776 Len=0 TSval=47383719 
>> TSecr=47383719 
>> 46482→ [PSH, ACK] Seq=1 Ack=57 Win=43776 Len=6 TSval=47384746 
>> TSecr=47383719 
>> →46482 [ACK] Seq=57 Ack=7 Win=43776 Len=0 TSval=47384746 
>> TSecr=47384746 
>> →46482 [PSH, ACK] Seq=57 Ack=7 Win=43776 Len=7 TSval=47384747 
>> TSecr=47384746 
>> 46482→ [ACK] Seq=7 Ack=64 Win=43776 Len=0 TSval=47384747 
>> TSecr=47384747 
>> [TCP Retransmission] 46482→ [PSH, ACK] Seq=1 Ack=57 Win=43776 Len=6 
>> TSval=47384746 TSecr=47383719 
>> →46482 [ACK] Seq=57 Ack=7 Win=43776 Len=0 TSval=47384746 
>> TSecr=47384746 
>> [TCP Retransmission] →46482 [PSH, ACK] Seq=57 Ack=7 Win=43776 Len=7 
>> TSval=47384747 TSecr=47384746 
>> 46482→ [ACK] Seq=7 Ack=64 Win=43776 Len=0 TSval=47384747 
>> TSecr=47384747 
>> 46482→ [PSH, ACK] Seq=7 Ack=64 Win=43776 Len=6 TSval=47386128 
>> TSecr=47384747 
>> →46482 [PSH, ACK] Seq=64 Ack=13 Win=43776 Len=7 TSval=47386129 
>> TSecr=47386128 
>> 46482→ [ACK] Seq=13 Ack=71 Win=43776 Len=0 TSval=47386129 
>> TSecr=47386129 
>> [TCP Retransmission] 46482→ [PSH, ACK] Seq=7 Ack=64 Win=43776 Len=6 
>> TSval=47386128 TSecr=47384747 
>> [TCP Retransmission] →46482 [PSH, ACK] Seq=64 Ack=13 Win=43776 Len=7 
>> TSval=47386129 TSecr=47386128 
>> 46482→ [ACK] Seq=13 Ack=71 Win=43776 Len=0 TSval=47386129 
>> TSecr=47386129 
>>
>> Full trace at http://pastebin.com/09xi1kGa
>>
>> Could someone explain to me if I'm doing something wrong, or what's going 
>> on?
>>
>>
>>
>>
>>
>>
>>
>> -- 
>> >> 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 https://groups.google.com/group/akka-user.
>> For more options, visit 

Re: [akka-user] Re: DDShardCoordinator gets confused after some nodes are removed

[Endre Varga]

Well, when you say "remove" nodes, do you actually DOWN them, or you just
let them be marked UNREACHABLE? I think the issue might be that Akka
Cluster does treat UNREACHABLE nodes as still part of the cluster and hence
they count against majority decisions. DOWN-ing them removes them from the
membership ring though and I think you will not see this problem.

-Endre

On Mon, Feb 29, 2016 at 4:08 PM, Marek Żebrowski 
wrote:

> That is my experience - but I do strange things, like rolling restarts.
>
> --
> >> 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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Re: DDShardCoordinator gets confused after some nodes are removed

[Marek Żebrowski]

That is my experience - but I do strange things, like rolling restarts.

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Re: DDShardCoordinator gets confused after some nodes are removed

[Bert Robben]

So should I read this as "sharding with ddata is not usable in small 
clusters with unreliable nodes" ? That would be a bummer.

On Monday, February 29, 2016 at 2:42:43 PM UTC+1, Marek Żebrowski wrote:
>
> I had similar problem - basically shardcoordinator needs to read data from 
> Majority of the nodes - it seems impossible in small cluster when nodes are 
> added/removed 
>

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Re: DDShardCoordinator gets confused after some nodes are removed

[Marek Żebrowski]

I had similar problem - basically shardcoordinator needs to read data from 
Majority of the nodes - it seems impossible in small cluster when nodes are 
added/removed 

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] flexible path router

[Henry Story]

Hi,

   I am writing an Http Server where each resource on the file system is 
the responsibility of an actor. 
To keep it simple, there are at least two types of actors: one responsible 
for directories and one responsible 
for files. Directory actors will be actors with children and files will be 
actors without. 

Now clearly we don't really want to load all actors for the whole file 
system in one go, as it could be huge.
So I'd like to have actors appear as they are requested. 

The way I was thinking of going about it is creating a Router that would 
take a RoutingLogic which would have 
a contructor  taking a root  ActorContext (or something) and try to follow 
the HttpRequest's Akka.Uri path segment 
by  segment until it finds either a remote ActorRef or one that does not 
exist. Then the Router could send the HttpRequest to that actor, and it 
could check out different things:


   - if the request is a GET on a resource which is available but not 
   created, create that actor and send it the HttpRequest.
   - if the request is a PUT on a resource that does not exist, check if 
   the author of the GET has access rights to create it, and if so make the 
   actor for it.
   
  ...

But I can't find an efficient way of walking through the contexts, though 
as I look at the akka code it seems to be available, just all of it is 
private. Would it make sense to have a method context.findFirst(path) that 
would do this? Or have I missed an obvious api?

Of course I could just send messages to the root actor, but that would be 
quite inefficient I think in the longer term, as the root Actor would 
receive every single message sent its way.

Henry

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] DDShardCoordinator gets confused after some nodes are removed

[Bert Robben]

Hi,

I'm getting strange results when using sharding with state-store-mode = 
ddata.

This is my scenario:

* I have a cluster with 4 nodes (A1, B1, A2, B2). In this cluster there are 
3 shards:
  - I have one set of primary actors sharded across all these nodes (A1, 
B1, A2, B2). 
  - I also have a set of secondary actors sharded over nodes that have role 
A (these are the nodes A1, A2); on nodes that have role B (i.e. B1 and B2) 
I have set up a shard proxy that points to this shard of secondary A 
actors. 
  - Exactly like above (but with A replaced by B and vice versa), I have 
set up a second set of secondary actors sharded over nodes that have role B 
and a proxy towards this on nodes that have role A.

* I then attach 3 client nodes to the cluster. These clients live each on 
their separate node that has neither role A nor role B. These nodes join 
the cluster. They set up a proxy to the shard of the primary actors and 
start sending messages. For each message sent, they expect a single reply. 
That all works fine.

* Then I kill node B1 and while B1 is being removed I also kill A2. As soon 
as A2 becomes unreachable I start getting ERROR messages from 
DDataShardCoordinator (see below). 
These error messages are repeated all the time (I waited almost five 
minutes). While I get these error messages, my clients don't get any 
replies any more; they resend their requests, but these messages never 
reach my primary actors.

* Strange thing is, that after I then kill 2 of my 3 clients, the error 
messages go away and everything works again as it should.


Note that this is very repeatable.


Should I file a bug report for this in github, or am I doing something 
wrong?

Bert

PS: I'm using the latest Akka version 2.4.2; all tests are done on a single 
machine.

PPS Here are the log messages that are being repeated every5 seconds

11:19:26.906 [Main-akka.actor.default-dispatcher-28] ERROR 
a.c.sharding.DDataShardCoordinator - The ShardCoordinator was unable to 
update a distributed state within 'updating-state-timeout'=5000 millis (was 
retrying), 
event=ShardRegionProxyTerminated(Actor[akka.tcp://Main@DIENB218:62685/system/sharding/SecondaryEventLogWriter-datacenter_a#-658916159])
11:19:26.906 [Main-akka.actor.default-dispatcher-28] ERROR 
a.c.sharding.DDataShardCoordinator - The ShardCoordinator was unable to 
update a distributed state within 'updating-state-timeout'=5000 millis (was 
retrying), 
event=ShardRegionTerminated(Actor[akka.tcp://Main@DIENB218:62685/system/sharding/EventLog#-228113409])
11:19:27.276 [Main-akka.actor.default-dispatcher-3] WARN 
 akka.cluster.sharding.ShardRegion - Trying to register to coordinator at 
[Some(ActorSelection[Anchor(akka.tcp://Main@DIENB218:62731/), 
Path(/system/sharding/SecondaryEventLogWriter-datacenter_bCoordinator/singleton/coordinator)])],
 
but no acknowledgement. Total [105] buffered messages.
11:19:29.276 [Main-akka.actor.default-dispatcher-28] WARN 
 akka.cluster.sharding.ShardRegion - Trying to register to coordinator at 
[Some(ActorSelection[Anchor(akka.tcp://Main@DIENB218:62731/), 
Path(/system/sharding/SecondaryEventLogWriter-datacenter_bCoordinator/singleton/coordinator)])],
 
but no acknowledgement. Total [106] buffered messages.
11:19:31.286 [Main-akka.actor.default-dispatcher-27] WARN 
 akka.cluster.sharding.ShardRegion - Trying to register to coordinator at 
[Some(ActorSelection[Anchor(akka.tcp://Main@DIENB218:62731/), 
Path(/system/sharding/SecondaryEventLogWriter-datacenter_bCoordinator/singleton/coordinator)])],
 
but no acknowledgement. Total [107] buffered messages.


-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: Akka persistence with AtLeastOnceDelivery - Replay only unconfirmed messages

[Ganta Murali Krishna]

Thanks Patrick. It did the trick.

On Friday, 26 February 2016 18:59:58 UTC+5:30, Patrik Nordwall wrote:
>
> You can save snapshot to reduce number of replayed events. Note 
> documentation around snapshots and AtLeastOnceDelivery.
>
>
>
> On Fri, Feb 26, 2016 at 6:23 AM, Ganta Murali Krishna  > wrote:
>
>>
>> *Update:* If I call deleteMessages(deliveryId,permanent = true)  after 
>> confirmDelivery(deliveryId), then only *MsgSent *are getting deleted. 
>> *MsgConfirmed *are still getting replayed on restart
>>
>>
>> On Friday, 26 February 2016 09:23:21 UTC+5:30, Ganta Murali Krishna wrote:
>>>
>>> Hello,
>>>
>>> I am trying out Akka persistence with AtleastOnceDelivery example from 
>>> here 
>>> http://doc.akka.io/docs/akka/snapshot/scala/persistence.html#At-Least-Once_Delivery
>>>
>>> Everything is running fine and exactly as per my requirement, its really 
>>> beautiful peace of . However, when I restart, I am expecting to replay only 
>>> unconfirmed messages, but every message is being replayed. 
>>>
>>> How can I configure PersistentActor to *only replay unconfirmed *messages 
>>> on restart of the system/PersistentActor ?
>>>
>>> Any help would be really appreciated.
>>>
>>> Regards
>>> Murali
>>>
>> -- 
>> >> 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 https://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
>
> Patrik Nordwall
> Lightbend  -  Reactive apps on the JVM
> Twitter: @patriknw
>
> [image: Lightbend] 
>
>

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Akka cluster: Passivation + reshard

[Eduardo Fernandes]

Hi.

Suppose that we have all actors of a particular shard passivated. The next 
time an actor of that shard receive a message the new incarnation will be 
in the same physical node where the shard was before or the the logic of 
new shard is triggered again and the shard is created for example where 
there is less shards?

Obs: in my case the rebalancing logic is switched off so there is no 
automatic resharding. 

Thanks for your time.

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] [akka-stream] tcp retransmission?

[Endre Varga]

Hi Val,

I don't really know what is going on there, Akka works via JDK NIO and have
no access to that low level TCP features. In other words, I really don't
know what is going on on your machine and why you are seeing it, but I
don't think we can do anything about it.

-Endre

On Mon, Feb 29, 2016 at 2:08 AM, Val P  wrote:

> I am trying to understand why I'm seeing TCP retransmissions on a simple
> program. I created a small program based on the 2.4.2 docs:
>
>
> object HelloWorld {
>   def main(args: Array[String]): Unit = {
> implicit val system = ActorSystem("Sys")
> implicit val materializer = ActorMaterializer()
>
> val connections: Source[IncomingConnection, Future[Tcp.ServerBinding]] =  
> Tcp().bind("localhost", )
> connections runForeach { connection =>
>   // server logic, parses incoming commands
>   val commandParser = Flow[String].takeWhile(_ != "BYE").map(_ + "!")
>
>   import connection._
>   val welcomeMsg = s"Welcome to: $localAddress, you are: $remoteAddress!"
>   val welcome = Source.single(welcomeMsg)
>
>
>   val serverLogic = Flow[ByteString]
> .via(Framing.delimiter( ByteString("\n"),  256 ))
> .map(_.utf8String)
> .via(commandParser)
> // merge in the initial banner after parser
> .merge(welcome)
> .map(_ + "\n")
> .map(ByteString(_))
>
>   connection.handleWith(serverLogic)
> }
>   }
>  }
>
>
>
> But when I connect to localhost/ via telnet, type in a few lines, and
> watch the traffic with wireshark, I'm seeing various retransmits and out of
> order:
>
> 46482→ [SYN] Seq=0 Win=43690 Len=0 MSS=65495 SACK_PERM=1
> TSval=47383693 TSecr=0 WS=128
> →46482 [SYN, ACK] Seq=0 Ack=1 Win=43690 Len=0 MSS=65495 SACK_PERM=1
> TSval=47383693 TSecr=47383693 WS=128
> 46482→ [ACK] Seq=1 Ack=1 Win=43776 Len=0 TSval=47383693 TSecr=47383693
> →46482 [PSH, ACK] Seq=1 Ack=1 Win=43776 Len=56 TSval=47383719
> TSecr=47383693
> 46482→ [ACK] Seq=1 Ack=57 Win=43776 Len=0 TSval=47383719 TSecr=47383719
> [TCP Out-Of-Order] 46482→ [SYN] Seq=0 Win=43690 Len=0 MSS=65495
> SACK_PERM=1 TSval=47383693 TSecr=0 WS=128
> [TCP Retransmission] →46482 [SYN, ACK] Seq=0 Ack=1 Win=43690 Len=0
> MSS=65495 SACK_PERM=1 TSval=47383693 TSecr=47383693 WS=128
> 46482→ [ACK] Seq=1 Ack=1 Win=43776 Len=0 TSval=47383693 TSecr=47383693
> [TCP Retransmission] →46482 [PSH, ACK] Seq=1 Ack=1 Win=43776 Len=56
> TSval=47383719 TSecr=47383693
> 46482→ [ACK] Seq=1 Ack=57 Win=43776 Len=0 TSval=47383719 TSecr=47383719
> 46482→ [PSH, ACK] Seq=1 Ack=57 Win=43776 Len=6 TSval=47384746
> TSecr=47383719
> →46482 [ACK] Seq=57 Ack=7 Win=43776 Len=0 TSval=47384746 TSecr=47384746
> →46482 [PSH, ACK] Seq=57 Ack=7 Win=43776 Len=7 TSval=47384747
> TSecr=47384746
> 46482→ [ACK] Seq=7 Ack=64 Win=43776 Len=0 TSval=47384747 TSecr=47384747
> [TCP Retransmission] 46482→ [PSH, ACK] Seq=1 Ack=57 Win=43776 Len=6
> TSval=47384746 TSecr=47383719
> →46482 [ACK] Seq=57 Ack=7 Win=43776 Len=0 TSval=47384746 TSecr=47384746
> [TCP Retransmission] →46482 [PSH, ACK] Seq=57 Ack=7 Win=43776 Len=7
> TSval=47384747 TSecr=47384746
> 46482→ [ACK] Seq=7 Ack=64 Win=43776 Len=0 TSval=47384747 TSecr=47384747
> 46482→ [PSH, ACK] Seq=7 Ack=64 Win=43776 Len=6 TSval=47386128
> TSecr=47384747
> →46482 [PSH, ACK] Seq=64 Ack=13 Win=43776 Len=7 TSval=47386129
> TSecr=47386128
> 46482→ [ACK] Seq=13 Ack=71 Win=43776 Len=0 TSval=47386129
> TSecr=47386129
> [TCP Retransmission] 46482→ [PSH, ACK] Seq=7 Ack=64 Win=43776 Len=6
> TSval=47386128 TSecr=47384747
> [TCP Retransmission] →46482 [PSH, ACK] Seq=64 Ack=13 Win=43776 Len=7
> TSval=47386129 TSecr=47386128
> 46482→ [ACK] Seq=13 Ack=71 Win=43776 Len=0 TSval=47386129
> TSecr=47386129
>
> Full trace at http://pastebin.com/09xi1kGa
>
> Could someone explain to me if I'm doing something wrong, or what's going
> on?
>
>
>
>
>
>
>
> --
> >> 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 https://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