[akka-user] Configuring or knowing number number of dispatcher threads launched by ActorSystem

[Krishna Kadam]

Hi all,

I have a question, can we configure actor system to launch certain number 
of dispatcher threads every time? 
Please do help.


Thanks & Regards
Krishna Kadam

-- 
>>  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] Help Understanding Benefits of Asynchronous/NIO Architecture

[Björn Antonsson]

On 3 March 2015 at 18:11:24, jamiexpatr...@gmail.com (jamiexpatr...@gmail.com) 
wrote:


Sorry if perhaps too general for this group but I've been struggling with 
somewhere appropriate to ask.
I have done quite a bit of reading but haven't found anywhere yet that answers 
my questions in a way my small brain can understand.


I understand what Asynchronous and Non-Blocking I/O means, what I am trying to 
understand is when I can expect to see improvements in performance by adopting 
an Asynchronous and NIO framework such as Akka.



I have the following assumptions - it would be great if anyone could 
agree/disagree (Assume a Request/Response in a Web Application that has some 
blocking calls in the business tier):


1. Even though some actors will process their messages and quickly delegate to 
other child actors asynchronously, there will be some child actors that will 
eventually have to deal with blocking I/O at the boundaries of an application 
right?

These actors will still be running in a thread which will block for the IO 
right?


There might just be one thread that is actually blocking, the one servicing the 
NIO selector for the I/O, and the actors awaiting messages about their 
reads/writes/connects et.c.

Such Actors would (at high level) be equivalent to the Workers in languages 
such as Node right?



2. In an asynchronous architecture, I'm assuming that I will only see 
improvements in the speed of a request/response round trip if there are several 
transactions (as part of the request) that I can now parallize (assuming 
multi-cores available). 

ie. Lets say I have the following scenarios for my request/response:

1 Single blocking call to do    -     Even though messages used to deal with 
this transaction will largely be passed around the system asynchronously, I 
will likely not see an improvement in speed of the request/response round trip 
since the single piece of I/O work will still take as long as it takes right?


It depends on if you allow multiple executions of the code to run in parallel. 
Reducing the number of threads and OS level context switching can have a big 
impact on performance, even though each piece of "blocking" I/O work will take 
the same amount of time. 


Multiple Blocking calls to do that I can run in parallel      -     if (in 
servicing the request) I have several pieces of blocking work to do (maybe 1 
web service call, 1 DB transaction, 1 cache call) AND I can run them in 
parallel then I will likely see an improvement in speed of the round trip based 
on the divide and conquer approach of the I/O stuff


Yes, this will definitley benefit. Also for the same reasons as above.


Multiple Blocking calls to do that I CANNOT run in parallel      -     if the 
several pieces of blocking work need to run in sequence then I am still 
unlikely to see an improvement in speed since I cannot parallelize the I/O 
right?


Same as two steps above.

B/




Many thanks
James


--
>> 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.
--
Björn Antonsson
Typesafe Inc. – Reactive Apps on the JVM
twitter: bantonsson

JOIN US. REGISTER TODAY!
Scala
Days
March 16th-18th,
San Francisco

-- 
>>  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] ANNOUNCE: Akka 2.2.5 Maintenance Release

[Konrad Malawski]

Dear hakkers,

We—the Akka committers—are pleased to be able to announce the availability 
of Akka 2.2.5. 
This is the fourth maintenance release of the 2.2 branch, and was sponsored 
by Manhattan Associates, Inc.

It includes a fix concerning file-based durable mailboxes, which might have 
grown indefinitely on some operating systems.

For the full stats see the announcement 
 on the website.

*Happy hakking!*

-- 
Konrad 'ktoso' Malawski
Akka  @ 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] akka-http Java documentation

[Björn Antonsson]

Hi,

I can't give you any dates, but we are working hard on finishing akka streams 
and akka-http, and both java and scala documentation is an integral part of a 
complete release.

B/

On 4 March 2015 at 20:56:24, Nicolaas Frederick Huysamen 
(nico.huysa...@gmail.com) wrote:

Any idea when this will become available? We are starting a new project and 
would love to use akka for building micro-services. Due to in-house skills we 
need to use Java and not Scala.
--
>> 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.
--
Björn Antonsson
Typesafe Inc. – Reactive Apps on the JVM
twitter: bantonsson

JOIN US. REGISTER TODAY!
Scala
Days
March 16th-18th,
San Francisco

-- 
>>  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] maximum value for "nr-of-instances" for remotely deployed routees

[Björn Antonsson]

Hi,

There is no hard limit on nr-of-instances.

Which version of akka/scala are you using?

When does the warnig message appear? Is it on the router node (local) or on the 
routee (remote) node?

Do you send anything else to the remote system before going throught the 
router, or do you just start remote deploying directly?

B/

On 5 March 2015 at 07:24:25, Kyunam Kim (kim.kyu...@gmail.com) wrote:

Is there a maximum value set for "nr-of-instances"?
When I set it to 300, it works fine.
When I set it to 400, I see "[WARN] 
[xxx-akka.remote.default-remote-dispatcher-5] [Remoting] Association to 
[akka.tcp://xxx@127.0.0.1:2552] with unknown UID is irrecoverably failed. 
Address cannot be quarantined without knowing the UID, gating instead for 5000 
ms.".

I have one remote akka system defined in target.nodes[] and round-robin-pool is 
used.

Thanks in advance.
Q
--
>> 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.
--
Björn Antonsson
Typesafe Inc. – Reactive Apps on the JVM
twitter: bantonsson

JOIN US. REGISTER TODAY!
Scala
Days
March 16th-18th,
San Francisco

-- 
>>  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] Configuring or knowing number number of dispatcher threads launched by ActorSystem

[Björn Antonsson]

Hi,

I'm not sure that I know what you are trying to achieve, but the configuration 
of dispatchers is described here in the docs 
http://doc.akka.io/docs/akka/2.3.9/scala/dispatchers.html

There is no ActorSystem wide setting, you have to configure the individual 
dispatchers.

B/

On 5 March 2015 at 09:12:31, Krishna Kadam (shrikrishna.kad...@gmail.com) wrote:

Hi all,

I have a question, can we configure actor system to launch certain number of 
dispatcher threads every time? 
Please do help.


Thanks & Regards
Krishna Kadam
--
>> 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.
--
Björn Antonsson
Typesafe Inc. – Reactive Apps on the JVM
twitter: bantonsson

JOIN US. REGISTER TODAY!
Scala
Days
March 16th-18th,
San Francisco

-- 
>>  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] maximum value for "nr-of-instances" for remotely deployed routees

[Roland Kuhn]

Sending many Supervise messages over the wire at once may flood that system 
message channel, depending also on how large the Props are (e.g. what they 
close over or how big the constructor arguments for the actor are).

Why not remote-deploy the Router itself? There is no benefit to keeping the 
Router on one machine and all its routees on exactly one other.

Regards,

Roland

> 5 mar 2015 kl. 13:52 skrev Björn Antonsson :
> 
> Hi,
> 
> There is no hard limit on nr-of-instances.
> 
> Which version of akka/scala are you using?
> 
> When does the warnig message appear? Is it on the router node (local) or on 
> the routee (remote) node?
> 
> Do you send anything else to the remote system before going throught the 
> router, or do you just start remote deploying directly?
> 
> B/
> 
> On 5 March 2015 at 07:24:25, Kyunam Kim (kim.kyu...@gmail.com 
> ) wrote:
> 
>> Is there a maximum value set for "nr-of-instances"?
>> When I set it to 300, it works fine.
>> When I set it to 400, I see "[WARN] 
>> [xxx-akka.remote.default-remote-dispatcher-5] [Remoting] Association to 
>> [akka.tcp://xxx@127.0.0.1:2552] with unknown UID is irrecoverably failed. 
>> Address cannot be quarantined without knowing the UID, gating instead for 
>> 5000 ms.".
>> 
>> I have one remote akka system defined in target.nodes[] and round-robin-pool 
>> is used.
>> 
>> Thanks in advance.
>> Q
>> --
>> >> 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 
>> .
> --
> Björn Antonsson
> Typesafe Inc.  – Reactive Apps on the JVM
> twitter: bantonsson 
> 
> JOIN US. REGISTER TODAY! 
> Scala 
> Days 
> March 16th-18th, 
> San Francisco 
> 
> -- 
> >> 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 
> .



Dr. Roland Kuhn
Akka Tech Lead
Typesafe  – Reactive apps on the JVM.
twitter: @rolandkuhn
 

-- 
>>  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] Shard coordinator persisting actor addresses containing the node IP

[Johannes Berg]

Okay, so following the other discussion as well I guess there's no need for 
a bug report then since the uid is part of the address. The problem we saw 
only occured because we had the clusters wrongfully configured and 
shouldn't happen if you shutdown and move the node to another cluster.

Thanks for clearing this out.

Johannes

On Monday, March 2, 2015 at 1:58:45 PM UTC+2, Patrik Nordwall wrote:
>
> Thinking some more about this. Actually, this can only happen if you split 
> an existing cluster in two separate clusters, typically by using auto-down. 
> It is not only using host:port. It is using full ActorRef of the shard 
> region and that includes the uid of the actor incarnation. That means that 
> it will not match and this will not be an issue if you shutdown the system.
>
> /Patrik
>
> On Mon, Mar 2, 2015 at 12:38 PM, Patrik Nordwall  > wrote:
>
>> This is an oversight. Please create an issue 
>> . For now I would recommend that 
>> you use unique names (actor system name) of the the clusters to avoid 
>> accidental cross talk like this.
>>
>> Thanks for reporting!
>>
>> Regards,
>> Patrik
>>
>> On Mon, Mar 2, 2015 at 11:04 AM, Brice Figureau > > wrote:
>>
>>> On Tue, 2015-02-24 at 23:06 -0800, Johannes Berg wrote:
>>> > Hi!
>>> >
>>> > We recently made a mistake by having two separate clusters use the
>>> > same journal DB which obviously doesn't work but it lead to some
>>> > questions about how the cluster sharding works.
>>> >
>>> > We detected our problem by seeing a stack trace containing lines of
>>> > code that didn't exist anywhere in the code deployed in that cluster
>>> > and after tripple checking that we were sure we did run the correct
>>> > code in all places in the cluster we finally found out that it in fact
>>> > must be talking with an actor outside of the cluster. Looking at what
>>> > the cluster sharding coordinator persists in the journal we found an
>>> > IP address of a node in the other cluster.
>>>
>>> What a coincidence! I observed the exact same issue a couple of days
>>> after you.
>>> See here:
>>> https://groups.google.com/d/msg/akka-user/OJKGEgKBn2g/BQLRWkoK8zcJ
>>>
>>> So I tested a bit more and found that the system would heal by itself (a
>>> bit later), because if there's no ActorSystem running on those other
>>> nodes, the ShardCoordinator would finally receive a Terminated message
>>> (at least under akka 2.3.9), and allocate the region to another place.
>>> Granted if the node moved to another cluster using the same ActorSystem
>>> name, it might be more problematic.
>>>
>>> Still this look a bit strange to me, or something that had been
>>> oversighted during design.
>>>
>>> > Granted the data in the journal table is pretty invalid but this still
>>> > raises the question why the shard coordinator could start using nodes
>>> > that aren't part of the cluster just based on some historical
>>> > persisted info in the journal table. For example what happens if you
>>> > run sharding over two nodes and decide to move the second node to
>>> > another cluster. You take down the system and change the config files
>>> > and then start the two systems again, could the sharding coordinator
>>> > on the first node under any circumstances still use the second node
>>> > based on the info in the journal table even though it's now not part
>>> > of the same cluster anymore?
>>>
>>> Yes, this isn't practical at all in an elastic environment. I would have
>>> preferred a mechanism when recovering the ShardCoordinator that would
>>> allocate the region locally then rebalance the shards based on the
>>> discovered regions at the end of the recovery.
>>>
>>> I think I'll enter a bug report for this problem.
>>>
>>> --
>>> Brice Figureau >
>>>
>>> --
>>> >>  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.
>>>
>>
>>
>>
>> -- 
>>
>> Patrik Nordwall
>> Typesafe  -  Reactive apps on the JVM
>> Twitter: @patriknw
>>
>> [image: Scala Days] 
>>
>>  
>
>
> -- 
>
> Patrik Nordwall
> Typesafe  -  Reactive apps on the JVM
> Twitter: @patriknw
>
> [image: Scala Days] 
>
>  

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/

[akka-user] Problem with dispatcher configuration

[kishore.k Nayar]

Hi,

 I'm new to Akka framework. I was experimenting some sample code where 
I have trouble with configuring dispatcher in application.conf.
 
 When I tried to execute the code I having *Exception in thread "main" 
akka.ConfigurationException: Dispatcher [my-dispatcher] not configured for 
path akka://Calculator_Actor/user/*

 Can you guys help me to figure out what I have done wrong here ? and 
How to fix this

 Code :

final ActorSystem actorSystem = ActorSystem.create("Calculator_Actor", 
ConfigFactory.load("test"));
CalculatorInt calculator = TypedActor.get(actorSystem).typedActorOf(
new TypedProps(CalculatorInt.class,
Calculator.class).withDispatcher("my-dispatcher"));

   application.conf :

test{
 my-dispatcher {
 type = Dispatcher
executor = "fork-join-executor"
 fork-join-executor {
 parallelism-min = 2
 parallelism-factor = 2.0
  parallelism-max = 4
}
 throughput = 100
 mailbox-capacity = -1
 mailbox-type =""
}
   akka.actor.deployment {
  /Calculator_Actor {
 dispatcher = my-dispatcher
  }
  }
}

-- 
>>  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] Shard coordinator persisting actor addresses containing the node IP

[Patrik Nordwall]

On Thu, Mar 5, 2015 at 2:49 PM, Johannes Berg  wrote:

> Okay, so following the other discussion as well I guess there's no need
> for a bug report then since the uid is part of the address. The problem we
> saw only occured because we had the clusters wrongfully configured and
> shouldn't happen if you shutdown and move the node to another cluster.
>
> Thanks for clearing this out.
>

You're welcome. Thanks for sharing your observations. I was also thinking
it was a bug for a moment.
/Patrik


>
> Johannes
>
> On Monday, March 2, 2015 at 1:58:45 PM UTC+2, Patrik Nordwall wrote:
>>
>> Thinking some more about this. Actually, this can only happen if you
>> split an existing cluster in two separate clusters, typically by using
>> auto-down. It is not only using host:port. It is using full ActorRef of the
>> shard region and that includes the uid of the actor incarnation. That means
>> that it will not match and this will not be an issue if you shutdown the
>> system.
>>
>> /Patrik
>>
>> On Mon, Mar 2, 2015 at 12:38 PM, Patrik Nordwall 
>> wrote:
>>
>>> This is an oversight. Please create an issue
>>> . For now I would recommend that
>>> you use unique names (actor system name) of the the clusters to avoid
>>> accidental cross talk like this.
>>>
>>> Thanks for reporting!
>>>
>>> Regards,
>>> Patrik
>>>
>>> On Mon, Mar 2, 2015 at 11:04 AM, Brice Figureau <
>>> bric...@daysofwonder.com> wrote:
>>>
 On Tue, 2015-02-24 at 23:06 -0800, Johannes Berg wrote:
 > Hi!
 >
 > We recently made a mistake by having two separate clusters use the
 > same journal DB which obviously doesn't work but it lead to some
 > questions about how the cluster sharding works.
 >
 > We detected our problem by seeing a stack trace containing lines of
 > code that didn't exist anywhere in the code deployed in that cluster
 > and after tripple checking that we were sure we did run the correct
 > code in all places in the cluster we finally found out that it in fact
 > must be talking with an actor outside of the cluster. Looking at what
 > the cluster sharding coordinator persists in the journal we found an
 > IP address of a node in the other cluster.

 What a coincidence! I observed the exact same issue a couple of days
 after you.
 See here:
 https://groups.google.com/d/msg/akka-user/OJKGEgKBn2g/BQLRWkoK8zcJ

 So I tested a bit more and found that the system would heal by itself (a
 bit later), because if there's no ActorSystem running on those other
 nodes, the ShardCoordinator would finally receive a Terminated message
 (at least under akka 2.3.9), and allocate the region to another place.
 Granted if the node moved to another cluster using the same ActorSystem
 name, it might be more problematic.

 Still this look a bit strange to me, or something that had been
 oversighted during design.

 > Granted the data in the journal table is pretty invalid but this still
 > raises the question why the shard coordinator could start using nodes
 > that aren't part of the cluster just based on some historical
 > persisted info in the journal table. For example what happens if you
 > run sharding over two nodes and decide to move the second node to
 > another cluster. You take down the system and change the config files
 > and then start the two systems again, could the sharding coordinator
 > on the first node under any circumstances still use the second node
 > based on the info in the journal table even though it's now not part
 > of the same cluster anymore?

 Yes, this isn't practical at all in an elastic environment. I would have
 preferred a mechanism when recovering the ShardCoordinator that would
 allocate the region locally then rebalance the shards based on the
 discovered regions at the end of the recovery.

 I think I'll enter a bug report for this problem.

 --
 Brice Figureau 

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

>>>
>>>
>>>
>>> --
>>>
>>> Patrik Nordwall
>>> Typesafe  -  Reactive apps on the JVM
>>> Twitter: @patriknw
>>>
>>> [image: Scala Days] 
>>>
>>>
>>
>>
>> --
>>
>> 

[akka-user] (re-)Chunking Source of ByteStrings, filling the gaps

[dan costelloe]

Hi all,

Following some helpful advice on this forum, I've been using the Chunker as 
defined on the Akka Streams cookbook page 

http://doc.akka.io/docs/akka-stream-and-http-experimental/1.0-M4/scala/stream-cookbook.html

To test it out, I create a ByteString Source and a re-chunked version:

val bsSource = Source(List.fill(5)("0123456789") map (x => ByteString(x)))
val chunkedSource = bsSource.transform(() => new Chunker(3))

I'm debugging / dumping values via the REPL:

val identityFlow: Flow[ByteString, ByteString] = Flow[ByteString].map(x => x
)
identityFlow.runWith(chunkedSource, ForeachSink(println))

Which produces:
ByteString(48, 49, 50)
ByteString(51, 52, 53)
ByteString(54, 55, 56)
ByteString(57)
ByteString(48, 49, 50)
ByteString(51, 52, 53)
ByteString(54, 55, 56)
ByteString(57)
ByteString(48, 49, 50)
ByteString(51, 52, 53)
ByteString(54, 55, 56)
ByteString(57)
ByteString(48, 49, 50)
ByteString(51, 52, 53)
ByteString(54, 55, 56)
ByteString(57)
ByteString(48, 49, 50)
ByteString(51, 52, 53)
ByteString(54, 55, 56)
ByteString(57)

This makes sense: each incoming block of 10 is split into (3, 3, 3, 1).

The question is: can the chunker be modified to produce a result like this 
instead: ?

ByteString(48, 49, 50)
ByteString(51, 52, 53)
ByteString(54, 55, 56)
ByteString(57, 48, 49)
ByteString(50, 51, 52)
ByteString(53, 54, 55)
ByteString(56, 57, 48)
ByteString(49, 50, 51)
ByteString(52, 53, 54)
ByteString(55, 56, 57)
ByteString(48, 49, 50)
ByteString(51, 52, 53)
ByteString(54, 55, 56)
ByteString(57, 48, 49)
ByteString(50, 51, 52)
ByteString(53, 54, 55)
ByteString(56, 57)

If so, how?

Advice welcome. Many thanks,
dan







-- 
>>  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: Problem with dispatcher configuration

[Jim Hazen]

Check the nesting.

Does test.my-dispatcher work?

-- 
>>  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: (re-)Chunking Source of ByteStrings, filling the gaps

[Jim Hazen]

Only a 10s look and I'm in a rush.  But I'm guessing the 'new Chunker()' is 
where you want to start.  In order for any chunker to process across 
message boundaries it'll need to have some type of "memory" and getting a 
new one each time probably won't accomplish that.

Now either the Chunker can already do this and we're calling it wrong, or 
you could write your own custom stage.  There are doc examples of filters 
and duplicators, etc.  You could write a custom stage that maintained an 
internal buffer and would chunk and send, or possibly partially fill and 
wait.  When new messages show up, fill and send.  If you're partially full 
but the stream ends, send your partial buffer. 

-- 
>>  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] Problems using a Remote Actor

[Sandro Martini]

Hi all,
I'm doing some tests with Akka Remote Actors, but I'm in trouble with some 
strange problem, but I think it's something that I'm doing in the wrong way 
...

I'm using Akka-2.2.4 (tomorrow I'll update to 2.2.5) with an updated JDK 7 
on Windows 7.
My sources are here: https://github.com/smartiniOnGitHub/akka-tests
the project is a Gradle (2.3) multi-project, because I'm trying to make it 
work with Java and then to port all in Groovy (and then in Scala), so 
please now let's focus on the Java version.

The make some test, you can run the following commands (under Windows):

rem cls && gradle tasks
cls && gradle clean build --refresh-dependencies
cls && gradle runJavaAkkaRemoteServer
or
cls && start gradle runJavaAkkaRemoteServer
cls && gradle runJavaAkkaRemoteClient

Anyway the "server" source is here: 
https://github.com/smartiniOnGitHub/akka-tests/blob/master/akka-tests-java/src/main/java/akka_tests/java/server/AkkaRemoteServer.java

When I run the "server", I get this:

:akka-tests-java:runJavaAkkaRemoteServer
Application: main, start a simple server console application for creating 
some Akka Actors and make them reachable from other (remote) processes

setup: start at Wed Mar 04 19:04:33 CET 2015.
Akka Config: akka {
loglevel = "INFO"
actor {
provider = "akka.remote.RemoteActorRefProvider"
}
remote {
enabled-transports = ["akka.remote.netty.tcp"]
netty.tcp {
hostname = "127.0.0.1"
# Server, listen on default Akka tcp port (2552)
port = 2552
}
log-sent-messages = on
log-received-messages = on
log-remote-lifecycle-events = on
log-frame-size-exceeding = on
# log-buffer-size-exceeding = 5
}
}
using Java ClassLoader: sun.misc.Launcher$AppClassLoader@187aeca
using Akka version: 2.2.4
Actor System configuration: 
Config(SimpleConfigObject({"akka":{"loglevel":"INFO","remote":{"log-remote-lifecycle-events":"on","netty":{"tcp":{"port":2552,"hostname":"127.0.0.1"}},"enabled-transports":["akka.remote.netty.tcp"],"log-frame-size-exceeding":"on","log-sent-messages":"on","log-received-messages":"on"},"actor":{"provider":"akka.remote.RemoteActorRefProvider"}}}))
[INFO] [03/04/2015 19:04:34.241] [main] [Remoting] Starting remoting
[INFO] [03/04/2015 19:04:34.408] [main] [Remoting] Remoting started; 
listening on addresses :[akka.tcp://RemoteActorSystem@127.0.0.1:2552]
[INFO] [03/04/2015 19:04:34.410] [main] [Remoting] Remoting now listens on 
addresses: [akka.tcp://RemoteActorSystem@127.0.0.1:2552]
Actor System instance: akka://RemoteActorSystem
props: 
Props(Deploy(,Config(SimpleConfigObject({})),NoRouter,NoScopeGiven,,),class 
akka_tests.java.actor.GreetingActor,List())
setup: end at Wed Mar 04 19:04:34 CET 2015.
Get Actor Reference to greetingActor: 
Actor[akka://RemoteActorSystem/user/greetingActor#-1752332594]
setup: end at Wed Mar 04 19:04:35 CET 2015.
check: start at Wed Mar 04 19:04:35 CET 2015.
Actor Reference instance is: 
Actor[akka://RemoteActorSystem/user/$a#-314651576]
[INFO] [03/04/2015 19:04:35.429] 
[RemoteActorSystem-akka.actor.default-dispatcher-6] 
[akka://RemoteActorSystem/user/$a] akka_tests.java.message.Greeting: Hello 
"Test Greeting"
[INFO] [03/04/2015 19:04:35.434] 
[RemoteActorSystem-akka.actor.default-dispatcher-2] 
[akka://RemoteActorSystem/deadLetters] Message [java.lang.String] from 
Actor[akka://RemoteActorSystem/user/$a#-314651576] to 
Actor[akka://RemoteActorSystem/deadLetters] was not delivered. [1] dead 
letters encountered. This logging can be turned off or adjusted with 
configuration settings 'akka.log-dead-letters' and 
'akka.log-dead-letters-during-shutdown'.
[INFO] [03/04/2015 19:04:35.439] 
[RemoteActorSystem-akka.actor.default-dispatcher-6] 
[akka://RemoteActorSystem/user/$a] java.lang.String: "Test String"
[WARN] [03/04/2015 19:04:35.439] 
[RemoteActorSystem-akka.actor.default-dispatcher-6] 
[akka://RemoteActorSystem/user/$a] Unknown message type 
akka_tests.java.message.GenericMessage, contents: 
"akka_tests.java.message.GenericMessage@1837e72"
[INFO] [03/04/2015 19:04:35.442] 
[RemoteActorSystem-akka.actor.default-dispatcher-5] 
[akka://RemoteActorSystem/deadLetters] Message [java.lang.String] from 
Actor[akka://RemoteActorSystem/user/$a#-314651576] to 
Actor[akka://RemoteActorSystem/deadLetters] was not delivered. [2] dead 
letters encountered. This logging canbe turned off or adjusted with 
configuration settings 'akka.log-dead-letters' and 
'akka.log-dead-letters-during-shutdown'.
check: end at Wed Mar 04 19:04:35 CET 2015.
check (remote): start at Wed Mar 04 19:04:35 CET 2015.
Akka Config: akka {
loglevel = "INFO"
actor.provider = "akka.remote.RemoteActorRefProvider"
remote.enabled-transports = ["akka.remote.netty.tcp"]
remote.netty.tcp.hostname="127.0.0.1"
remote.netty.tcp.port = 0
}
[INFO] [03/04/2015 19:04:35.980] [main] [Remoting] Starting remoting
[INFO] [03/04/2015 19:04:36.005] [main] [Remoting] Remoting

Re: [akka-user] Re: (re-)Chunking Source of ByteStrings, filling the gaps

[Endre Varga]

This is a non-trivial problem, but not totally hard either. The problem is,
if you always try to wait for a full chunk, then some data might get
delayed for an arbitrary amount of time. Consider a target of chunk size 3,
then the following events

- 2 bytes arrive
- 10 minutes elapse
- 1 byte arrives
- chunk is sent (after 10 minutes)

This is unacceptable for most use-cases. The solution is left as an
exercise to the reader: https://github.com/akka/akka/issues/16610

;)

-Endre

(Hint: take a look at buffer:
https://github.com/akka/akka/blob/release-2.3-dev/akka-stream/src/main/scala/akka/stream/impl/fusing/Ops.scala#L184
and conflate:
https://github.com/akka/akka/blob/release-2.3-dev/akka-stream/src/main/scala/akka/stream/impl/fusing/Ops.scala#L251
)

On Thu, Mar 5, 2015 at 6:48 PM, Jim Hazen  wrote:

> Only a 10s look and I'm in a rush.  But I'm guessing the 'new Chunker()'
> is where you want to start.  In order for any chunker to process across
> message boundaries it'll need to have some type of "memory" and getting a
> new one each time probably won't accomplish that.
>
> Now either the Chunker can already do this and we're calling it wrong, or
> you could write your own custom stage.  There are doc examples of filters
> and duplicators, etc.  You could write a custom stage that maintained an
> internal buffer and would chunk and send, or possibly partially fill and
> wait.  When new messages show up, fill and send.  If you're partially full
> but the stream ends, send your partial buffer.
>
>  --
> >> 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] Re: (re-)Chunking Source of ByteStrings, filling the gaps

[Jim Hazen]

Wouldn't migrating from a grouped to groupedWithin based chunker be the 
compromise that ppl are looking for?  Perform chunk packing within a given 
window, but if you're waiting for too long, send what you have?

You mention here and in the JIRA that this a conflate problem, but conflate 
deals with fast producers and slow consumers, and we have a potential 
problem with a slow producer keeping up with our chunk packer.  I don't see 
conflate helping us here, but I'm willing to learn.

-- 
>>  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: Help Understanding Benefits of Asynchronous/NIO Architecture

[jamiexpatrick]

Björn thankyou for taking the time to comment.

*Hadn't appreciated the lower number of threads / reduced context switching 
overhead so very useful.*

*Jon*




On Tuesday, March 3, 2015 at 5:11:27 PM UTC, jamiex...@gmail.com wrote:
>
>
> Sorry if perhaps too general for this group but I've been struggling with 
> somewhere appropriate to ask.
> I have done quite a bit of reading but haven't found anywhere yet that 
> answers my questions in a way my small brain can understand.
>
>
> I understand what Asynchronous and Non-Blocking I/O means, *what I am 
> trying to understand is when I can expect to see improvements in 
> performance by adopting an Asynchronous and NIO framework such as Akka.*
>
>
>
> *I have the following assumptions - it would be great if anyone could 
> agree/disagree (Assume a Request/Response in a Web Application that has 
> some blocking calls in the business tier):*
>
>
> 1. Even though some actors will process their messages and quickly 
> delegate to other child actors asynchronously, there will be some child 
> actors that will eventually have to deal with blocking I/O at the 
> boundaries of an application right?
>
> These actors will still be running in a thread which will block for the IO 
> right? 
>
> Such Actors would (at high level) be equivalent to the Workers in 
> languages such as Node right?
>
>
>
> 2. In an asynchronous architecture, I'm assuming that I will only see 
> improvements in the speed of a request/response round trip if there are 
> several transactions (as part of the request) that I can now parallize 
> (assuming multi-cores available). 
>
> *ie. Lets say I have the following scenarios for my request/response:*
>
> *1 Single blocking call to do *   - Even though messages used to deal 
> with this transaction will largely be passed around the system 
> asynchronously, I will likely not see an improvement in speed of the 
> request/response round trip since the single piece of I/O work will still 
> take as long as it takes right?
>
>
> *Multiple Blocking calls to do that I can run in parallel * - if 
> (in servicing the request) I have several pieces of blocking work to do 
> (maybe 1 web service call, 1 DB transaction, 1 cache call) AND I can run 
> them in parallel then I will likely see an improvement in speed of the 
> round trip based on the divide and conquer approach of the I/O stuff
>
>
> *Multiple Blocking calls to do that I CANNOT run in parallel * -
>  if the several pieces of blocking work need to run in sequence then I am 
> still unlikely to see an improvement in speed since I cannot parallelize 
> the I/O right?
>
>
>
>
> Many thanks
> James
>
>
>

-- 
>>  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] Stream Materialization, a larger discussion.

[Jim Hazen]

I've been following Akka Streams for bit. I've noticed the changes in M4 
and of course read the materialization sections 
of: 
http://doc.akka.io/docs/akka-stream-and-http-experimental/1.0-M4/scala/stream-flows-and-basics.html

I have tremendous respect for the Akka team and understand that getting 
this right is hard.  But, are we there yet?

Originally the concept was Map based, with the ability for stages to set 
keys within the map and eventually the client had access to this map.  Not 
really type safe, or clear as to what keys were available, or what their 
types were, etc.  So that's not great.  But on the flip side (and why I 
think it was reached for first) it was extensible.

Now with M4, we are much more clear and explicit about what materialization 
each stage offers.  This looks a lot better.  But I'm worried about what 
happens when you attempt to evolve these materialization types later, 
especially for stages provided by the core library.

I'm thinking down the road to Monk, where the goal is to provide a nice 
tracing abstraction and SPI.  And if folks are interested in tracing Actors 
today, with Streams, they'll be interested in tracing materialized flows 
tomorrow.  

Given this current mechanism for exposing a per-stage materialization 
value, how later would we switch all of our Unit materialization values to 
materialization values that contain "standard metrics"?  It isn't there 
today, but in the future a lot of runtime metrics could be gathered and 
exposed.

With M4, I don't see a clean way of evolving or exposing new "secondary" 
materialization values over time.  "Secondary" is in the eye of the 
beholder, but we have preferredMerge stages, and things like Try and Option 
that have success based affinity within flow processing.

I can't prescribe a complete solution in this post but I would like to talk 
this out.

Down the road how do we intend to support the exposure of new 
materialization based information and/or patterns?  How would "adaptive 
flows", flows that adapt to runtime realities, be implemented?  How would 
one get access to a Stream of materialization values of a running Stream?

I hope this is food for positive thought and a positive discussion.

PS:  This particular post uses tracing and metrics as an example, but I 
think there's a larger fundamental problem to be solved.  Should each stage 
need to evolve from a materialization of Unit -> tuple/wrapper -> new 
tuple/wrapper.  All the while likely breaking backward compatibility in the 
process.  

-- 
>>  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] Akka Http Client - 302 Found no redirect

[Peter Neyens]

Hello,

I'm trying to access an XML webservice with the akka http client, but 
always receive a 302 Found response.

The code I use to do a request :
  lazy val serviceConnection =
Http().outgoingConnection("hostname-of-service", 80)

  def doRequest(request: HttpRequest): Future[HttpResponse] = 
Source.single(request).via(serviceConnection).runWith(Sink.head())
  
When I use 
  val url = new java.net.URL("...")
  scala.xml.XML.load(url)
I do not receive the 302 Found response and receive the xml response.

I don't know if akka http client does not follow the redirect or if it is 
similar to this old spay issue 
.

Kind regards,
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] maximum value for "nr-of-instances" for remotely deployed routees

[Kyunam Kim]

Hi Bjorn,

- akka 2.3.8 scala 2.10.4
- Warning message comes on the router node (local).
- Remote system is stared first, then the local system is started after 
(nothing is sent & it just starts remote deploying directly).
- Configuration on the router node (local)
akka {
  actor {
deployment {
  "/creationActor/router" {
router = round-robin-pool
nr-of-instances = 400
target.nodes = [
  "akka.tcp://xxx@127.0.0.1:2552"
]
  }
}
  }
  remote.netty.tcp.port = 2554
}

Thanks!
Q


On Thursday, March 5, 2015 at 4:53:26 AM UTC-8, Björn Antonsson wrote:
>
> Hi,
>
> There is no hard limit on nr-of-instances.
>
> Which version of akka/scala are you using?
>
> When does the warnig message appear? Is it on the router node (local) or 
> on the routee (remote) node?
>
> Do you send anything else to the remote system before going throught the 
> router, or do you just start remote deploying directly?
>
> B/
>
> On 5 March 2015 at 07:24:25, Kyunam Kim (kim.k...@gmail.com ) 
> wrote:
>
>  Is there a maximum value set for "nr-of-instances"?
> When I set it to 300, it works fine. 
> When I set it to 400, I see "[WARN] 
> [xxx-akka.remote.default-remote-dispatcher-5] [Remoting] Association to 
> [akka.tcp://xxx@127.0.0.1:2552] with unknown UID is irrecoverably failed. 
> Address cannot be quarantined without knowing the UID, gating instead for 
> 5000 ms.".
>
> I have one remote akka system defined in target.nodes[] and 
> round-robin-pool is used.
>
> Thanks in advance.
> Q
>  --
> >> 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.
>
> --
> Björn Antonsson
> Typesafe Inc.  – Reactive Apps on the JVM
> twitter: bantonsson 
>
> JOIN US. REGISTER TODAY! 
> 
> Scala 
> Days 
> March 16th-18th, 
> San Francisco 
>

-- 
>>  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] maximum value for "nr-of-instances" for remotely deployed routees

[Kyunam Kim]

Hi Roland,

- The props is small and the actor is simple and no constructor arguments.
- I'll try to remote-deploy the router itself. But with this approach 
(keeping the router & its routees on the same machine), am I going to miss 
the point of being able to deploy routees over multiple machines?
- Let's assume, for now, I'm stubborn and want to stay as is. How would I 
decide /  what would be good practice to decide the magic # for 
nr-of-instances in this case?

Thanks,
Q

On Thursday, March 5, 2015 at 5:09:17 AM UTC-8, rkuhn wrote:
>
> Sending many Supervise messages over the wire at once may flood that 
> system message channel, depending also on how large the Props are (e.g. 
> what they close over or how big the constructor arguments for the actor 
> are).
>
> Why not remote-deploy the Router itself? There is no benefit to keeping 
> the Router on one machine and all its routees on exactly one other.
>
> Regards,
>
> Roland
>
> 5 mar 2015 kl. 13:52 skrev Björn Antonsson  >:
>
> Hi,
>
> There is no hard limit on nr-of-instances.
>
> Which version of akka/scala are you using?
>
> When does the warnig message appear? Is it on the router node (local) or 
> on the routee (remote) node?
>
> Do you send anything else to the remote system before going throught the 
> router, or do you just start remote deploying directly?
>
> B/
>
> On 5 March 2015 at 07:24:25, Kyunam Kim (kim.k...@gmail.com ) 
> wrote:
>
> Is there a maximum value set for "nr-of-instances"?
> When I set it to 300, it works fine.
> When I set it to 400, I see "[WARN] 
> [xxx-akka.remote.default-remote-dispatcher-5] [Remoting] Association to [
> akka.tcp://xxx@127.0.0.1:2552] with unknown UID is irrecoverably failed. 
> Address cannot be quarantined without knowing the UID, gating instead for 
> 5000 ms.".
>
> I have one remote akka system defined in target.nodes[] and 
> round-robin-pool is used.
>
> Thanks in advance.
> Q
> --
> >> 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.
>
> --
> Björn Antonsson
> Typesafe Inc.  – Reactive Apps on the JVM
> twitter: bantonsson 
>
> JOIN US. REGISTER TODAY! 
> 
> Scala 
> Days 
> March 16th-18th, 
> San Francisco 
>
> -- 
> >> 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.
>
>
>
>
> *Dr. Roland Kuhn*
> *Akka Tech Lead*
> Typesafe  – Reactive apps on the JVM.
> twitter: @rolandkuhn
> 
>  
>

-- 
>>  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] maximum value for "nr-of-instances" for remotely deployed routees

[Roland Kuhn]

Hi Q,

> 6 mar 2015 kl. 06:51 skrev Kyunam Kim :
> 
> Hi Roland,
> 
> - The props is small and the actor is simple and no constructor arguments.
> - I'll try to remote-deploy the router itself. But with this approach 
> (keeping the router & its routees on the same machine), am I going to miss 
> the point of being able to deploy routees over multiple machines?
> - Let's assume, for now, I'm stubborn and want to stay as is. How would I 
> decide /  what would be good practice to decide the magic # for 
> nr-of-instances in this case?

It is not magic at all: it defines the maximum parallelism that you allow for 
processing the kind of requests that you send to the router. Divide that by the 
time it takes to process one request and you get a rough estimate for the 
throughput that your system will have—adjust that to your needs by adding a 
little headroom to the required value.

Of course the amount of available resources must match this: if your routees 
perform CPU intensive tasks then having more than one per CPU core does not 
make sense; the same goes for database calls where the DB connection pool 
defines your maximum parallelism (ask your friendly DB admin for details).

Regards,

Roland

> 
> Thanks,
> Q
> 
> On Thursday, March 5, 2015 at 5:09:17 AM UTC-8, rkuhn wrote:
> Sending many Supervise messages over the wire at once may flood that system 
> message channel, depending also on how large the Props are (e.g. what they 
> close over or how big the constructor arguments for the actor are).
> 
> Why not remote-deploy the Router itself? There is no benefit to keeping the 
> Router on one machine and all its routees on exactly one other.
> 
> Regards,
> 
> Roland
> 
>> 5 mar 2015 kl. 13:52 skrev Björn Antonsson > >:
>> 
>> Hi,
>> 
>> There is no hard limit on nr-of-instances.
>> 
>> Which version of akka/scala are you using?
>> 
>> When does the warnig message appear? Is it on the router node (local) or on 
>> the routee (remote) node?
>> 
>> Do you send anything else to the remote system before going throught the 
>> router, or do you just start remote deploying directly?
>> 
>> B/
>> 
>> On 5 March 2015 at 07:24:25, Kyunam Kim (kim.k...@gmail.com ) 
>> wrote:
>> 
>>> Is there a maximum value set for "nr-of-instances"?
>>> When I set it to 300, it works fine.
>>> When I set it to 400, I see "[WARN] 
>>> [xxx-akka.remote.default-remote-dispatcher-5] [Remoting] Association to 
>>> [akka.tcp://xxx@127.0.0.1:2552 <>] with unknown UID is irrecoverably 
>>> failed. Address cannot be quarantined without knowing the UID, gating 
>>> instead for 5000 ms.".
>>> 
>>> I have one remote akka system defined in target.nodes[] and 
>>> round-robin-pool is used.
>>> 
>>> Thanks in advance.
>>> Q
>>> --
>>> >> 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 
>>> .
>> --
>> Björn Antonsson
>> Typesafe Inc.  – Reactive Apps on the JVM
>> twitter: bantonsson 
>> 
>> JOIN US. REGISTER TODAY! 
>> Scala 
>> Days 
>> March 16th-18th, 
>> San Francisco 
>> 
>> -- 
>> >> 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: