[akka-user] Re: Akka http 1.0-M2, trouble getting a route to see my implicit jsonFormat

[Łukasz Sowa]

Hi Tom,

What imports are you bringing into the scope? It's common to get errors 
like yours if you don't have 
import akka.http.marshallers.sprayjson.SprayJsonSupport._

Best,
Łukasz

W dniu środa, 28 stycznia 2015 19:26:26 UTC+1 użytkownik Tom Bray napisał:
>
> I've created the actor below and when I attempt to run my app, I get the 
> error "could not find implicit value for parameter um: 
> akka.http.unmarshalling.FromRequestUnmarshaller" for the Person class 
> despite the fact that I have defined an implicit formatter for it.
>
> When I had this same route and server binding defined outside of an actor 
> (in the main app), I didn't have this problem. Any thoughts? Thanks in 
> advance. I was following this post as a guide, BTW: 
> http://blog.michaelhamrah.com/2015/01/adding-http-server-side-events-to-akka-streams/
>
> class HttpService
>   extends Actor
>   with Directives
>   with ImplicitFlowMaterializer
>   with CoreActors
>   with DefaultJsonProtocol
>   with ActorLogging{
>
>   implicit val system = context.system //used by CoreActors trait
>   implicit val executionContext = context.system.dispatcher
>   implicit val personFormat = jsonFormat1(Person)
>   implicit val timeout = new Timeout(1 second)
>   implicit val materializer = FlowMaterializer()
>
>   override def receive: Receive = Actor.emptyBehavior
>
>   Http()(context.system)
> .bind("localhost", 8081)
> .startHandlingWith(route)
>
>   private def route: Route =
> path("person" ) {
>   post {
> handleWith { person:Person =>
>   (personServiceActor ? person).mapTo[String]
> }
>   }
> }
> }
>
> object HttpService {
>   def props = Props(new HttpService)
> }
>
>

-- 
>>  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] Is forwarding a message to all children via an actor selection more efficient than iterating over the child ActorRefs?

[Nick Ebbitt]

I have a scenario where when an actor receives a specific message it must 
forward the message to all of it's children that exist at that time.

I think I have 2 options to solve this.

getContext().actorSelection("*").forward(message, getContext());

or

getContext().getChildren().forEach(child -> child.forward(message, 
getContext()));

Without fully understanding the internal implementation of actor selection 
it's hard to know which will perform better. I plan to perform some bench 
marks with the kind of scale I am expecting to require but would appreciate 
any insight to this that experienced users may have.

Thanks

I've also created a stack overflow question for this if anyone would like 
to answer that: 
http://stackoverflow.com/questions/28189059/is-forwarding-a-message-to-all-children-via-an-actor-selection-more-efficient-th

-- 
>>  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: Akka HTTP - Responding to requests early

[Daniel Armak]

I can't comment on akka-http, but here's my understanding of the HTTP spec.

It's certainly legal to send a response before receiving the request 
entity, but the client isn't obligated to start reading the response before 
it finishes sending the request. And if the server closes the connection 
without reading the whole request, the client may not see the response, 
depending on whether it fit into its receive buffer and on how it's 
written. If you just close the connection, the client might think it a 
network error and retry the request. So if you want to guarantee the client 
sees the rejection response, you have to read and discard the whole 
request. 

If you control the client as well as the server, and the server can reject 
the request based on its headers, the standard HTTP solution is to send 
Expect: 100-continue in the request, and then either 100 Continue or a 4xx 
rejection from the server. But if the server can only reject the request 
based on some prefix of the entity, HTTP provides no way to abort without 
closing the connection. You could cheat though: use chunked encoding for 
the request entity, and send an empty chunk ending the request entity as 
soon as you read the server's rejection headers.

On Wednesday, January 28, 2015 at 6:33:47 PM UTC+2, Joe Edwards wrote:
>
> I have an application in which clients can upload large request entities 
> to the server. In some situations the request will be rejected early 
> (before the request body is totally consumed, as this may be hundreds of 
> MB).
>
> Is there a standard way of handling this situation? Since the rejections 
> may happen asynchronously, I can't guarantee how much (if any) of the 
> request body has been read.
>
> As far as I can tell from RFC 7230 section 6.5
>
>- If the request is still in flight, we should respond early with a 
>'Connection: Close' (and the request stream will die as the connection 
>closes).
>- If the request has been totally received, we can respond normally 
>and reuse the connection.
>
> Is there any easy way to determine when a response is being sent early?
>
> More generally, is it even *legal* to send a response before the entire 
> request is received *without* closing the connection? I can't really tell 
> from the spec, but if not *it would make much more sense for akka-http to 
> close the connection for us*.
>
> Thanks, Joe
>

-- 
>>  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 1.0-M2, trouble getting a route to see my implicit jsonFormat

[Tom Bray]

I've created the actor below and when I attempt to run my app, I get the
error "could not find implicit value for parameter um:
akka.http.unmarshalling.FromRequestUnmarshaller" for the Person class
despite the fact that I have defined an implicit formatter for it.

When I had this same route and server binding defined outside of an actor
(in the main app), I didn't have this problem. Any thoughts? Thanks in
advance. I was following this post as a guide, BTW:
http://blog.michaelhamrah.com/2015/01/adding-http-server-side-events-to-akka-streams/

class HttpService
  extends Actor
  with Directives
  with ImplicitFlowMaterializer
  with CoreActors
  with DefaultJsonProtocol
  with ActorLogging{

  implicit val system = context.system //used by CoreActors trait
  implicit val executionContext = context.system.dispatcher
  implicit val personFormat = jsonFormat1(Person)
  implicit val timeout = new Timeout(1 second)
  implicit val materializer = FlowMaterializer()

  override def receive: Receive = Actor.emptyBehavior

  Http()(context.system)
.bind("localhost", 8081)
.startHandlingWith(route)

  private def route: Route =
path("person" ) {
  post {
handleWith { person:Person =>
  (personServiceActor ? person).mapTo[String]
}
  }
}
}

object HttpService {
  def props = Props(new HttpService)
}

-- 
>>  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 - Responding to requests early

[Joe Edwards]

I have an application in which clients can upload large request entities to 
the server. In some situations the request will be rejected early (before 
the request body is totally consumed, as this may be hundreds of MB).

Is there a standard way of handling this situation? Since the rejections 
may happen asynchronously, I can't guarantee how much (if any) of the 
request body has been read.

As far as I can tell from RFC 7230 section 6.5

   - If the request is still in flight, we should respond early with a 
   'Connection: Close' (and the request stream will die as the connection 
   closes).
   - If the request has been totally received, we can respond normally and 
   reuse the connection.

Is there any easy way to determine when a response is being sent early?

More generally, is it even *legal* to send a response before the entire 
request is received *without* closing the connection? I can't really tell 
from the spec, but if not *it would make much more sense for akka-http to 
close the connection for us*.

Thanks, Joe

-- 
>>  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] Basic Akka Configuration and parallelism

[Cosmin Marginean]

Yes, I think I can totally understand that philosophy. It's probably worth 
making that decision a bit more explicit though.

Thanks again everyone for the insights.

Cos

On Wednesday, 28 January 2015 15:18:24 UTC, √ wrote:
>
> Yes, we chose it to be non transparent to use routers or not since it 
> fundamentally changes semantics.
>
> -- 
> Cheers,
> √
> On 28 Jan 2015 16:09, "Cosmin Marginean" > 
> wrote:
>
>> Right, I got it now.
>> So that needs to be explicit about using a router in the code using the 
>> actor. So this is not entirely enough on its own
>>
>> /myactor {
>>   ...
>>   router = round-robin-pool
>>
>>
>> Thanks, at least I know that now.
>>
>> Cos
>>
>> On Wednesday, 28 January 2015 14:27:10 UTC, √ wrote:
>>>
>>> Hi all,
>>>
>>> if you want a router, then you need to create a router:
>>>
>>>
>>>1. ActorRef actorRef =
>>>2. actorSystem.actorOf(FromConfig.getInstance().props(Props.create(
>>>MyActor.class)), 
>>>3. "myActor");
>>>
>>>
>>> On Wed, Jan 28, 2015 at 3:24 PM, Björn Antonsson <
>>> bjorn.a...@typesafe.com> wrote:
>>>
 Hi Cos,

 Your single actor will process one single message at a time, in 
 sequence. That is a fundamental principle of actors.

 If you want to have things happening in parallel then you need to have 
 mutliple actors.

 B/

 On 28 January 2015 at 15:21:14, Cosmin Marginean (cosm...@gmail.com) 
 wrote:

 We're running Akka 2.3.7 (Java) and I'm now working on reconfiguring to 
 scale for more throughput (as it apparently isn't happening). 

 I am struggling with the Akka documentation as well as some of the 
 examples out there as there is always some contextual information that 
 seems to be missing.
 However, in order to make sure I'm not going mad, I've extracted the 
 code and config in a dead-simple unit test (I even removed akka's 
 JavaTestKit).

 The code and config here suggest that there should be a lot of messages 
 processed in parallel, however the entire processing is totally serialised 
 and I can't understand where have I failed in this setup.

 Any suggestion would be helpful.

 Thank you
 Cos

  @Test
 public void testAkka() throws Exception {
 Config cfg = ConfigFactory.load("test-akka.conf");
 ActorSystem actorSystem = ActorSystem.create("main", 
 cfg.getConfig("main"));
 ActorRef actorRef = actorSystem.actorOf(Props.create(MyActor.class), 
 "myactor");
 for (int i = 0; i < 150; i++) {
 actorRef.tell("nothing", ActorRef.noSender());
 }
 Thread.sleep(100);
 }

 public static final class MyActor extends UntypedActor {
 @Override
 public void onReceive(Object message) throws Exception {
 System.out.println("Doing stuff");
 Thread.sleep(2000);
 }

 } 


 And the test-akka.conf file

  main {
   app-dispatcher {
 type = Dispatcher
 executor = "fork-join-executor"
 fork-join-executor {
   parallelism-min = 16
   parallelism-factor = 32.0
   parallelism-max = 512
 }
 throughput = 1
   }

   akka.actor.deployment {
 /myactor {
   dispatcher = app-dispatcher
   router = round-robin-pool
   nr-of-instances = 16
 }
   }
 }

  --
 >> 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  – Reactive Apps on the JVM
 twitter: @bantonsson 

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

Re: [akka-user] Basic Akka Configuration and parallelism

[Cosmin Marginean]

Yes, I want a router and I was expecting that this
/myactor {
  ...
 router = round-robin-pool


is how a router is configured. Now I understand that when you create the 
actor, if you want a router (that you already configured) to be used, you 
have to specify that.
You are right, I didn't blindly follow the docs, which explicitly do either 
FromConfig.props or RoundRobinPool(5). (I followed my instincts instead)

Thank you for your help
Cos

On Wednesday, 28 January 2015 15:10:12 UTC, Björn Antonsson wrote:
>
> I'm not sure what you mean by hardcoding and automatic actor creation.
>
> As Viktor pointed out, it fyou want a router, that will create actors for 
> you, then you need to create a router, like the example here 
> http://doc.akka.io/docs/akka/snapshot/scala/routing.html#Pool
>
> It shows you both configuration based and programmatic router creation.
>
> B/
>
> On 28 January 2015 at 16:04:54, Cosmin Marginean (cosm...@gmail.com 
> ) wrote:
>
> Thanks, I believe that's pretty clear. 
> What is confusing though is this in the context of round robin pools, 
> which the documentation is not entirely clear about: 
> http://doc.akka.io/docs/akka/snapshot/scala/routing.html
>
> I can't seem to find a reference to a best practice that doesn't involve 
> hardcoding /myactor1, /myactor2 etc, but that would allow automatic actor 
> creation (if required) using a round robin pool (or other parallelisation 
> mechanism).
>
> Cos
>
> On Wednesday, 28 January 2015 14:25:01 UTC, Björn Antonsson wrote: 
>>
>>  Hi Cos,
>>  
>>  Your single actor will process one single message at a time, in 
>> sequence. That is a fundamental principle of actors.
>>  
>>  If you want to have things happening in parallel then you need to have 
>> mutliple actors.
>>  
>>  B/
>>
>> On 28 January 2015 at 15:21:14, Cosmin Marginean (cosm...@gmail.com) 
>> wrote:
>>
>>  We're running Akka 2.3.7 (Java) and I'm now working on reconfiguring to 
>> scale for more throughput (as it apparently isn't happening). 
>>
>> I am struggling with the Akka documentation as well as some of the 
>> examples out there as there is always some contextual information that 
>> seems to be missing.
>> However, in order to make sure I'm not going mad, I've extracted the code 
>> and config in a dead-simple unit test (I even removed akka's JavaTestKit).
>>
>> The code and config here suggest that there should be a lot of messages 
>> processed in parallel, however the entire processing is totally serialised 
>> and I can't understand where have I failed in this setup.
>>
>> Any suggestion would be helpful.
>>
>> Thank you
>> Cos
>>
>>  @Test
>> public void testAkka() throws Exception {
>> Config cfg = ConfigFactory.load("test-akka.conf");
>> ActorSystem actorSystem = ActorSystem.create("main", 
>> cfg.getConfig("main"));
>> ActorRef actorRef = actorSystem.actorOf(Props.create(MyActor.class), 
>> "myactor");
>> for (int i = 0; i < 150; i++) {
>> actorRef.tell("nothing", ActorRef.noSender());
>> }
>> Thread.sleep(100);
>> }
>>
>> public static final class MyActor extends UntypedActor {
>> @Override
>> public void onReceive(Object message) throws Exception {
>> System.out.println("Doing stuff");
>> Thread.sleep(2000);
>> }
>>
>> } 
>>
>>
>> And the test-akka.conf file
>>
>>  main {
>>   app-dispatcher {
>> type = Dispatcher
>> executor = "fork-join-executor"
>> fork-join-executor {
>>   parallelism-min = 16
>>   parallelism-factor = 32.0
>>   parallelism-max = 512
>> }
>> throughput = 1
>>   }
>>
>>   akka.actor.deployment {
>> /myactor {
>>   dispatcher = app-dispatcher
>>   router = round-robin-pool
>>   nr-of-instances = 16
>> }
>>   }
>> }
>>
>>  --
>> >> 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  – Reactive Apps on the JVM
>>  twitter: @bantonsson 
>>
>>--
> >> 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

Re: [akka-user] Basic Akka Configuration and parallelism

[Viktor Klang]

Yes, we chose it to be non transparent to use routers or not since it
fundamentally changes semantics.

-- 
Cheers,
√
On 28 Jan 2015 16:09, "Cosmin Marginean"  wrote:

> Right, I got it now.
> So that needs to be explicit about using a router in the code using the
> actor. So this is not entirely enough on its own
>
> /myactor {
>   ...
>   router = round-robin-pool
>
>
> Thanks, at least I know that now.
>
> Cos
>
> On Wednesday, 28 January 2015 14:27:10 UTC, √ wrote:
>>
>> Hi all,
>>
>> if you want a router, then you need to create a router:
>>
>>
>>1. ActorRef actorRef =
>>2. actorSystem.actorOf(FromConfig.getInstance().props(Props.create(
>>MyActor.class)),
>>3. "myActor");
>>
>>
>> On Wed, Jan 28, 2015 at 3:24 PM, Björn Antonsson > > wrote:
>>
>>> Hi Cos,
>>>
>>> Your single actor will process one single message at a time, in
>>> sequence. That is a fundamental principle of actors.
>>>
>>> If you want to have things happening in parallel then you need to have
>>> mutliple actors.
>>>
>>> B/
>>>
>>> On 28 January 2015 at 15:21:14, Cosmin Marginean (cosm...@gmail.com)
>>> wrote:
>>>
>>> We're running Akka 2.3.7 (Java) and I'm now working on reconfiguring to
>>> scale for more throughput (as it apparently isn't happening).
>>>
>>> I am struggling with the Akka documentation as well as some of the
>>> examples out there as there is always some contextual information that
>>> seems to be missing.
>>> However, in order to make sure I'm not going mad, I've extracted the
>>> code and config in a dead-simple unit test (I even removed akka's
>>> JavaTestKit).
>>>
>>> The code and config here suggest that there should be a lot of messages
>>> processed in parallel, however the entire processing is totally serialised
>>> and I can't understand where have I failed in this setup.
>>>
>>> Any suggestion would be helpful.
>>>
>>> Thank you
>>> Cos
>>>
>>>  @Test
>>> public void testAkka() throws Exception {
>>> Config cfg = ConfigFactory.load("test-akka.conf");
>>> ActorSystem actorSystem = ActorSystem.create("main", 
>>> cfg.getConfig("main"));
>>> ActorRef actorRef = actorSystem.actorOf(Props.create(MyActor.class), 
>>> "myactor");
>>> for (int i = 0; i < 150; i++) {
>>> actorRef.tell("nothing", ActorRef.noSender());
>>> }
>>> Thread.sleep(100);
>>> }
>>>
>>> public static final class MyActor extends UntypedActor {
>>> @Override
>>> public void onReceive(Object message) throws Exception {
>>> System.out.println("Doing stuff");
>>> Thread.sleep(2000);
>>> }
>>>
>>> }
>>>
>>>
>>> And the test-akka.conf file
>>>
>>>  main {
>>>   app-dispatcher {
>>> type = Dispatcher
>>> executor = "fork-join-executor"
>>> fork-join-executor {
>>>   parallelism-min = 16
>>>   parallelism-factor = 32.0
>>>   parallelism-max = 512
>>> }
>>> throughput = 1
>>>   }
>>>
>>>   akka.actor.deployment {
>>> /myactor {
>>>   dispatcher = app-dispatcher
>>>   router = round-robin-pool
>>>   nr-of-instances = 16
>>> }
>>>   }
>>> }
>>>
>>>  --
>>> >> 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  – Reactive Apps on the JVM
>>> twitter: @bantonsson 
>>>
>>>  --
>>> >> Read the docs: http://akka.io/docs/
>>> >> Check the FAQ: http://doc.akka.io/docs/akka/
>>> current/additional/faq.html
>>> >> Search the archives: https://groups.google.com/
>>> group/akka-user
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Akka User List" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to akka-user+...@googlegroups.com.
>>> To post to this group, send email to akka...@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/akka-user.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Cheers,
>> √
>>
>  --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.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 ema

Re: [akka-user] Basic Akka Configuration and parallelism

[Björn Antonsson]

I'm not sure what you mean by hardcoding and automatic actor creation.

As Viktor pointed out, it fyou want a router, that will create actors for you, 
then you need to create a router, like the example here 
http://doc.akka.io/docs/akka/snapshot/scala/routing.html#Pool

It shows you both configuration based and programmatic router creation.

B/

On 28 January 2015 at 16:04:54, Cosmin Marginean (cosmin...@gmail.com) wrote:

Thanks, I believe that's pretty clear.
What is confusing though is this in the context of round robin pools, which the 
documentation is not entirely clear about: 
http://doc.akka.io/docs/akka/snapshot/scala/routing.html

I can't seem to find a reference to a best practice that doesn't involve 
hardcoding /myactor1, /myactor2 etc, but that would allow automatic actor 
creation (if required) using a round robin pool (or other parallelisation 
mechanism).

Cos

On Wednesday, 28 January 2015 14:25:01 UTC, Björn Antonsson wrote:
Hi Cos,

Your single actor will process one single message at a time, in sequence. That 
is a fundamental principle of actors.

If you want to have things happening in parallel then you need to have mutliple 
actors.

B/

On 28 January 2015 at 15:21:14, Cosmin Marginean (cosm...@gmail.com) wrote:

We're running Akka 2.3.7 (Java) and I'm now working on reconfiguring to scale 
for more throughput (as it apparently isn't happening).

I am struggling with the Akka documentation as well as some of the examples out 
there as there is always some contextual information that seems to be missing.
However, in order to make sure I'm not going mad, I've extracted the code and 
config in a dead-simple unit test (I even removed akka's JavaTestKit).

The code and config here suggest that there should be a lot of messages 
processed in parallel, however the entire processing is totally serialised and 
I can't understand where have I failed in this setup.

Any suggestion would be helpful.

Thank you
Cos

@Test
public void testAkka() throws Exception {
Config cfg = ConfigFactory.load("test-akka.conf");
ActorSystem actorSystem = ActorSystem.create("main", cfg.getConfig("main"));
ActorRef actorRef = actorSystem.actorOf(Props.create(MyActor.class), 
"myactor");
for (int i = 0; i < 150; i++) {
actorRef.tell("nothing", ActorRef.noSender());
}
Thread.sleep(100);
}

public static final class MyActor extends UntypedActor {
@Override
public void onReceive(Object message) throws Exception {
System.out.println("Doing stuff");
Thread.sleep(2000);
}


} 


And the test-akka.conf file

main {
  app-dispatcher {
type = Dispatcher
executor = "fork-join-executor"
fork-join-executor {
  parallelism-min = 16
  parallelism-factor = 32.0
  parallelism-max = 512
}
throughput = 1
  }

  akka.actor.deployment {
/myactor {
  dispatcher = app-dispatcher
  router = round-robin-pool
  nr-of-instances = 16
}
  }
}
--
>> 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 – Reactive Apps on the JVM
twitter: @bantonsson

--
>> 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 – Reactive Apps on the JVM
twitter: @bantonsson

-- 
>>  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, v

Re: [akka-user] Basic Akka Configuration and parallelism

[Cosmin Marginean]

Right, I got it now.
So that needs to be explicit about using a router in the code using the 
actor. So this is not entirely enough on its own

/myactor {
  ...
  router = round-robin-pool


Thanks, at least I know that now.

Cos

On Wednesday, 28 January 2015 14:27:10 UTC, √ wrote:
>
> Hi all,
>
> if you want a router, then you need to create a router:
>
>
>1. ActorRef actorRef =
>2. actorSystem.actorOf(FromConfig.getInstance().props(Props.create(
>MyActor.class)), 
>3. "myActor");
>
>
> On Wed, Jan 28, 2015 at 3:24 PM, Björn Antonsson  > wrote:
>
>> Hi Cos,
>>
>> Your single actor will process one single message at a time, in sequence. 
>> That is a fundamental principle of actors.
>>
>> If you want to have things happening in parallel then you need to have 
>> mutliple actors.
>>
>> B/
>>
>> On 28 January 2015 at 15:21:14, Cosmin Marginean (cosm...@gmail.com 
>> ) wrote:
>>
>> We're running Akka 2.3.7 (Java) and I'm now working on reconfiguring to 
>> scale for more throughput (as it apparently isn't happening). 
>>
>> I am struggling with the Akka documentation as well as some of the 
>> examples out there as there is always some contextual information that 
>> seems to be missing.
>> However, in order to make sure I'm not going mad, I've extracted the code 
>> and config in a dead-simple unit test (I even removed akka's JavaTestKit).
>>
>> The code and config here suggest that there should be a lot of messages 
>> processed in parallel, however the entire processing is totally serialised 
>> and I can't understand where have I failed in this setup.
>>
>> Any suggestion would be helpful.
>>
>> Thank you
>> Cos
>>
>>  @Test
>> public void testAkka() throws Exception {
>> Config cfg = ConfigFactory.load("test-akka.conf");
>> ActorSystem actorSystem = ActorSystem.create("main", 
>> cfg.getConfig("main"));
>> ActorRef actorRef = actorSystem.actorOf(Props.create(MyActor.class), 
>> "myactor");
>> for (int i = 0; i < 150; i++) {
>> actorRef.tell("nothing", ActorRef.noSender());
>> }
>> Thread.sleep(100);
>> }
>>
>> public static final class MyActor extends UntypedActor {
>> @Override
>> public void onReceive(Object message) throws Exception {
>> System.out.println("Doing stuff");
>> Thread.sleep(2000);
>> }
>>
>> } 
>>
>>
>> And the test-akka.conf file
>>
>>  main {
>>   app-dispatcher {
>> type = Dispatcher
>> executor = "fork-join-executor"
>> fork-join-executor {
>>   parallelism-min = 16
>>   parallelism-factor = 32.0
>>   parallelism-max = 512
>> }
>> throughput = 1
>>   }
>>
>>   akka.actor.deployment {
>> /myactor {
>>   dispatcher = app-dispatcher
>>   router = round-robin-pool
>>   nr-of-instances = 16
>> }
>>   }
>> }
>>
>>  --
>> >> 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  – Reactive Apps on the JVM
>> twitter: @bantonsson 
>>
>>  -- 
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >> Search the archives: https://groups.google.com/group/akka-user
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to akka-user+...@googlegroups.com .
>> To post to this group, send email to akka...@googlegroups.com 
>> .
>> Visit this group at http://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Cheers,
> √
>  

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.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] Basic Akka Configuration and parallelism

[Cosmin Marginean]

Thanks, I believe that's pretty clear.
What is confusing though is this in the context of round robin pools, which 
the documentation is not entirely clear 
about: http://doc.akka.io/docs/akka/snapshot/scala/routing.html

I can't seem to find a reference to a best practice that doesn't involve 
hardcoding /myactor1, /myactor2 etc, but that would allow automatic actor 
creation (if required) using a round robin pool (or other parallelisation 
mechanism).

Cos

On Wednesday, 28 January 2015 14:25:01 UTC, Björn Antonsson wrote:
>
> Hi Cos,
>
> Your single actor will process one single message at a time, in sequence. 
> That is a fundamental principle of actors.
>
> If you want to have things happening in parallel then you need to have 
> mutliple actors.
>
> B/
>
> On 28 January 2015 at 15:21:14, Cosmin Marginean (cosm...@gmail.com 
> ) wrote:
>
> We're running Akka 2.3.7 (Java) and I'm now working on reconfiguring to 
> scale for more throughput (as it apparently isn't happening). 
>
> I am struggling with the Akka documentation as well as some of the 
> examples out there as there is always some contextual information that 
> seems to be missing.
> However, in order to make sure I'm not going mad, I've extracted the code 
> and config in a dead-simple unit test (I even removed akka's JavaTestKit).
>
> The code and config here suggest that there should be a lot of messages 
> processed in parallel, however the entire processing is totally serialised 
> and I can't understand where have I failed in this setup.
>
> Any suggestion would be helpful.
>
> Thank you
> Cos
>
>  @Test
> public void testAkka() throws Exception {
> Config cfg = ConfigFactory.load("test-akka.conf");
> ActorSystem actorSystem = ActorSystem.create("main", 
> cfg.getConfig("main"));
> ActorRef actorRef = actorSystem.actorOf(Props.create(MyActor.class), 
> "myactor");
> for (int i = 0; i < 150; i++) {
> actorRef.tell("nothing", ActorRef.noSender());
> }
> Thread.sleep(100);
> }
>
> public static final class MyActor extends UntypedActor {
> @Override
> public void onReceive(Object message) throws Exception {
> System.out.println("Doing stuff");
> Thread.sleep(2000);
> }
>
> } 
>
>
> And the test-akka.conf file
>
>  main {
>   app-dispatcher {
> type = Dispatcher
> executor = "fork-join-executor"
> fork-join-executor {
>   parallelism-min = 16
>   parallelism-factor = 32.0
>   parallelism-max = 512
> }
> throughput = 1
>   }
>
>   akka.actor.deployment {
> /myactor {
>   dispatcher = app-dispatcher
>   router = round-robin-pool
>   nr-of-instances = 16
> }
>   }
> }
>
>  --
> >> 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  – Reactive Apps on the JVM
> twitter: @bantonsson 
>
>

-- 
>>  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] Basic Akka Configuration and parallelism

[Viktor Klang]

Hi all,

if you want a router, then you need to create a router:


   1. ActorRef actorRef =
   2. actorSystem.actorOf(FromConfig.getInstance().props(Props.create(
   MyActor.class)),
   3. "myActor");


On Wed, Jan 28, 2015 at 3:24 PM, Björn Antonsson <
bjorn.antons...@typesafe.com> wrote:

> Hi Cos,
>
> Your single actor will process one single message at a time, in sequence.
> That is a fundamental principle of actors.
>
> If you want to have things happening in parallel then you need to have
> mutliple actors.
>
> B/
>
> On 28 January 2015 at 15:21:14, Cosmin Marginean (cosmin...@gmail.com)
> wrote:
>
> We're running Akka 2.3.7 (Java) and I'm now working on reconfiguring to
> scale for more throughput (as it apparently isn't happening).
>
> I am struggling with the Akka documentation as well as some of the
> examples out there as there is always some contextual information that
> seems to be missing.
> However, in order to make sure I'm not going mad, I've extracted the code
> and config in a dead-simple unit test (I even removed akka's JavaTestKit).
>
> The code and config here suggest that there should be a lot of messages
> processed in parallel, however the entire processing is totally serialised
> and I can't understand where have I failed in this setup.
>
> Any suggestion would be helpful.
>
> Thank you
> Cos
>
>  @Test
> public void testAkka() throws Exception {
> Config cfg = ConfigFactory.load("test-akka.conf");
> ActorSystem actorSystem = ActorSystem.create("main", 
> cfg.getConfig("main"));
> ActorRef actorRef = actorSystem.actorOf(Props.create(MyActor.class), 
> "myactor");
> for (int i = 0; i < 150; i++) {
> actorRef.tell("nothing", ActorRef.noSender());
> }
> Thread.sleep(100);
> }
>
> public static final class MyActor extends UntypedActor {
> @Override
> public void onReceive(Object message) throws Exception {
> System.out.println("Doing stuff");
> Thread.sleep(2000);
> }
>
> }
>
>
> And the test-akka.conf file
>
>  main {
>   app-dispatcher {
> type = Dispatcher
> executor = "fork-join-executor"
> fork-join-executor {
>   parallelism-min = 16
>   parallelism-factor = 32.0
>   parallelism-max = 512
> }
> throughput = 1
>   }
>
>   akka.actor.deployment {
> /myactor {
>   dispatcher = app-dispatcher
>   router = round-robin-pool
>   nr-of-instances = 16
> }
>   }
> }
>
>  --
> >> 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  – Reactive Apps on the JVM
> twitter: @bantonsson 
>
>  --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

-- 
>>  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] Basic Akka Configuration and parallelism

[Björn Antonsson]

Hi Cos,

Your single actor will process one single message at a time, in sequence. That 
is a fundamental principle of actors.

If you want to have things happening in parallel then you need to have mutliple 
actors.

B/

On 28 January 2015 at 15:21:14, Cosmin Marginean (cosmin...@gmail.com) wrote:

We're running Akka 2.3.7 (Java) and I'm now working on reconfiguring to scale 
for more throughput (as it apparently isn't happening).

I am struggling with the Akka documentation as well as some of the examples out 
there as there is always some contextual information that seems to be missing.
However, in order to make sure I'm not going mad, I've extracted the code and 
config in a dead-simple unit test (I even removed akka's JavaTestKit).

The code and config here suggest that there should be a lot of messages 
processed in parallel, however the entire processing is totally serialised and 
I can't understand where have I failed in this setup.

Any suggestion would be helpful.

Thank you
Cos

@Test
public void testAkka() throws Exception {
Config cfg = ConfigFactory.load("test-akka.conf");
ActorSystem actorSystem = ActorSystem.create("main", cfg.getConfig("main"));
ActorRef actorRef = actorSystem.actorOf(Props.create(MyActor.class), 
"myactor");
for (int i = 0; i < 150; i++) {
actorRef.tell("nothing", ActorRef.noSender());
}
Thread.sleep(100);
}

public static final class MyActor extends UntypedActor {
@Override
public void onReceive(Object message) throws Exception {
System.out.println("Doing stuff");
Thread.sleep(2000);
}

} 


And the test-akka.conf file

main {
  app-dispatcher {
type = Dispatcher
executor = "fork-join-executor"
fork-join-executor {
  parallelism-min = 16
  parallelism-factor = 32.0
  parallelism-max = 512
}
throughput = 1
  }

  akka.actor.deployment {
/myactor {
  dispatcher = app-dispatcher
  router = round-robin-pool
  nr-of-instances = 16
}
  }
}
--
>> 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 – Reactive Apps on the JVM
twitter: @bantonsson

-- 
>>  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] Basic Akka Configuration and parallelism

[Cosmin Marginean]

We're running Akka 2.3.7 (Java) and I'm now working on reconfiguring to 
scale for more throughput (as it apparently isn't happening).

I am struggling with the Akka documentation as well as some of the examples 
out there as there is always some contextual information that seems to be 
missing.
However, in order to make sure I'm not going mad, I've extracted the code 
and config in a dead-simple unit test (I even removed akka's JavaTestKit).

The code and config here suggest that there should be a lot of messages 
processed in parallel, however the entire processing is totally serialised 
and I can't understand where have I failed in this setup.

Any suggestion would be helpful.

Thank you
Cos

@Test
public void testAkka() throws Exception {
Config cfg = ConfigFactory.load("test-akka.conf");
ActorSystem actorSystem = ActorSystem.create("main", cfg.getConfig("main"));
ActorRef actorRef = actorSystem.actorOf(Props.create(MyActor.class), 
"myactor");
for (int i = 0; i < 150; i++) {
actorRef.tell("nothing", ActorRef.noSender());
}
Thread.sleep(100);
}

public static final class MyActor extends UntypedActor {
@Override
public void onReceive(Object message) throws Exception {
System.out.println("Doing stuff");
Thread.sleep(2000);
}

} 


And the test-akka.conf file

main {
  app-dispatcher {
type = Dispatcher
executor = "fork-join-executor"
fork-join-executor {
  parallelism-min = 16
  parallelism-factor = 32.0
  parallelism-max = 512
}
throughput = 1
  }

  akka.actor.deployment {
/myactor {
  dispatcher = app-dispatcher
  router = round-robin-pool
  nr-of-instances = 16
}
  }
}

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka cluster unreachable

[Idar Borlaug]

I know, we have a few problems with upgradeing to 2.3.9. (we might wait
until eventstore has a cluster connector for java)

The only thing i can see is that the nodes have been almost idle for a good
while. But there are a few requests coming in. It dosen work fine for 2-3
days.

Will the state actor die if say a firewall cuts the tcp connection because
its been alive too long?

I will see if operations can monitor more data, and consider upgrading to
2.3.9 again.

On 27 January 2015 at 14:27, Björn Antonsson 
wrote:

> Hi Idar,
>
> A lot of things have been fixed in akka since 2.2.4. Would it be possible
> to upgrade to 2.3.9?
>
> From the log that you pasted it seems like the akka protocol state actor
> for the connection to node 2 has died on node 1, before your log starts. Is
> there something unusual going on on the machines, like GC or something else
> that would consume resources at the time of the failure? Are you monitoring
> other health metrics like disk space and swap usage?
>
> B/
>
> On 26 January 2015 at 12:31:19, Idar Borlaug (idar.borl...@gmail.com)
> wrote:
>
> Hi
>
> I have a 2 node akka cluster, which looses connection once every two days.
> Often when the server i almost idle. We are still on akka 2.2.4, using
> oracle java 1.8_25. Its a virtual servers running on vmware esx.
> The application have been running fine for 3 years, but started with this
> a few weeks ago.
> Anyone have any ideas on were to start troubleshooting this?
>
> My clusterconfig:
> remote {
>log-sent-messages = on
>log-received-messages = on
>log-remote-lifecycle-events = off
>netty.tcp {
>port = 45000
>  }
>  watch-failure-detector.threshold = 15
>}
>
>   cluster {
>  log-info = on
> auto-down = on
> auto-join = on
> failure-detector {
> threshold = 15
> min-std-deviation = 500 ms
> acceptable-heartbeat-pause = 20 s
>  }
> heartbeat-request {
> grace-period = 20 s
> expected-response-after = 10 s
> time-to-live = 60 s
> }
> use-dispatcher = cluster-dispatcher
> }
> }
>
> cluster-dispatcher {
>  type = "Dispatcher"
>  executor = "fork-join-executor"
> fork-join-executor {
> parallelism-min = 2
> parallelism-max = 4
>  }
> }
>
>
> logoutput:
> node1:
>  2015-01-24 03:30:02,242 [svarut-akka.actor.default-dispatcher-25] WARN
>  n.k.e.DeadLetterLogger - Dead letter:
> DeadLetter(Timer(heartbeat-timer,HeartbeatTimer,true,0),Actor[akka://svarut/dea
>
> dLetters],Actor[akka://svarut/system/transports/akkaprotocolmanager.tcp0/akkaProtocol-tcp%3A%2F%2Fsvarut%40193.161.171.182%3A53119-2#-1998086621])
> 2015-01-24 03:30:02,242 [svarut-akka.actor.default-dispatcher-25] WARN
>  n.k.e.DeadLetterLogger - Dead letter:
> DeadLetter(Disassociated(Unknown),Actor[akka://svarut/deadLetters],Actor[akka:/
>
> /svarut/system/transports/akkaprotocolmanager.tcp0/akkaProtocol-tcp%3A%2F%2Fsvarut%40193.161.171.182%3A53119-2#-1998086621])
> 2015-01-24 03:30:02,312 [svarut-akka.actor.default-dispatcher-24] WARN
>  n.k.e.DeadLetterLogger - Dead letter:
> DeadLetter(DisassociateUnderlying(Unknown),Actor[akka://svarut/deadLetters],Act
>
> or[akka://svarut/system/transports/akkaprotocolmanager.tcp0/akkaProtocol-tcp%3A%2F%2Fsvarut%40193.161.171.182%3A53119-2#-1998086621])
> 2015-01-24 03:30:02,312 [svarut-akka.actor.default-dispatcher-24] WARN
>  n.k.e.DeadLetterLogger - Dead letter:
> DeadLetter(Timer(AckIdleTimer,AckIdleCheckTimer,true,0),Actor[akka://svarut/dea
>
> dLetters],Actor[akka://svarut/system/endpointManager/endpointWriter-akka.tcp%3A%2F%2Fsvarut%40193.161.171.182%3A45000-1#1403595424])
> 2015-01-24 03:30:02,312 [svarut-akka.actor.default-dispatcher-24] WARN
>  n.k.e.DeadLetterLogger - Dead letter:
> DeadLetter(Timer(AckIdleTimer,AckIdleCheckTimer,true,0),Actor[akka://svarut/dea
>
> dLetters],Actor[akka://svarut/system/endpointManager/endpointWriter-akka.tcp%3A%2F%2Fsvarut%40193.161.171.182%3A45000-1#1403595424])
> 2015-01-24 03:30:02,312 [svarut-akka.actor.default-dispatcher-24] WARN
>  n.k.e.DeadLetterLogger - Dead letter:
> DeadLetter(Timer(AckIdleTimer,AckIdleCheckTimer,true,0),Actor[akka://svarut/dea
>
> dLetters],Actor[akka://svarut/system/endpointManager/endpointWriter-akka.tcp%3A%2F%2Fsvarut%40193.161.171.182%3A45000-1#1403595424])
> 2015-01-24 03:30:02,312 [svarut-akka.actor.default-dispatcher-24] WARN
>  n.k.e.DeadLetterLogger - Dead letter:
> DeadLetter(TakeOver(akka.remote.transport.AkkaProtocolHandle@40711a86
> ),Actor[ak
>
> ka://svarut/system/endpointManager#1220933312],Actor[akka://svarut/system/endpointManager/endpointWriter-akka.tcp%3A%2F%2Fsvarut%40193.161.171.182%3A45000-1#1403595424])
> 2015-01-24 03:30:27,666 [svarut-akka.actor.default-dispatcher-31] ERROR
> a.c.ClusterCoreDaemon - Cluster Node [akka.tcp://
> svarut@193.161.171.181:45000] - Marking node(s) as 

Re: [akka-user] ShardRegionTerminated with LocalRef Issue

[Patrik Nordwall]

On Wed, Jan 28, 2015 at 10:46 AM, Saparbek Smailov 
wrote:

> It seems that we found a way around the problem.
> It is a normal behaviour to serialize LocalActorRef without address,
> however to Cluster Sharding to work, we do need to persist messages with
> RemoteActorRef.
> If you serialize PersistentRepr, MessageSerializer will serialize with
> RemoteActorRef. However we were serializing payload separately and
> reconstructing PersistentRepr on recovery in our custom journal.
> Changing the journal to serialize whole PersistentRepr instead solved the
> issue.
> I hope someone will find this useful.
>

Thanks for sharing. The important piece is that the serialization must be
done within a Serialization.currentTransportInformation.withValue block.
That is done automatically by akka remoting and by the persistence
MessageSerializer.

/Patrik


>
> On Monday, 26 January 2015 09:58:19 UTC, Patrik Nordwall wrote:
>
>>
>>
>> On Mon, Jan 26, 2015 at 10:57 AM, Saparbek Smailov > > wrote:
>>
>>> Hello Patrik,
>>>
>>> Just for your information, one of my friends asked the same question:
>>> https://github.com/akka/akka/pull/2117# (Akrome)
>>>
>>> Thank you for your time and consideration!
>>>
>>
>> Thanks. I will take a look at the debug log.
>> /Patrik
>>
>>
>>>
>>>
>>>
>>>
>>> On Monday, January 26, 2015 at 9:54:33 AM UTC, Saparbek Smailov wrote:

 2.3.4

 On Monday, January 26, 2015 at 9:36:17 AM UTC, Patrik Nordwall wrote:
>
> What version of Akka do you use?
> /Patrik
>
> On Mon, Jan 26, 2015 at 10:23 AM, Saparbek Smailov <
> saparbek...@gmail.com> wrote:
>
>> Hello everyone,
>>
>> In our project we use Cluster Sharding with Cluster Singletons. Our
>> Cluster is set up on AWS Elastic Beanstalk.
>> The set up works perfectly until you start removing instances from
>> the cluster. The issue arises when a shard is recreated using Akka
>> persistence: during the recovery we get an error saying "Shard already
>> allocated".
>>
>> I went through the logs and realised that some of
>> ShardRegionTerminated events are persisted using LocalRef.
>> Let me elaborate on this a little bit:
>>  - During the recovery I get ShardRegionRegistered event with
>> RemoteActorRef.
>>  - Then I get ShardHomeAllocated event which allocates shard on the
>> region
>>  - I get ShardRegionTerminated with LocalActorRef, which does not
>> remove the Shard and Region from Maps, as RemoteActorRef is not equal to
>> LocalActorRef
>>  - Then I get ShardRegionRegistered with Ref haveing different IP
>> address
>>  - Finally when next ShardHomeAllocated is replayed I get "Shard
>> already allocated" error.
>>
>> How can I avoid the problem? Is there any way to force Akka use only
>> RemoteActorRef or at least serialize using RemoteActorRef? Am I not using
>> the library properly?
>> I would appreciate any help/hint on this issue.
>>
>> Thank you very much!
>>
>> --
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ: http://doc.akka.io/docs/akka/c
>> urrent/additional/faq.html
>> >> Search the archives: https://groups.google.com/grou
>> p/akka-user
>> ---
>> You received this message because you are subscribed to the Google
>> Groups "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it,
>> send an email to akka-user+...@googlegroups.com.
>> To post to this group, send email to akka...@googlegroups.com.
>> Visit this group at http://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
>
>   --
>>> >> 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
>>
>>
> Notice:  This email is confidential and may contain copyright material of
> members of the Ocado Group. Opinions and views expressed in this message
> may not necessarily reflect the opinions and views of the members of the
> Ocado Group.
>
>
>
> If you are not the intended recipient, 

Re: [akka-user] ShardRegionTerminated with LocalRef Issue

[Saparbek Smailov]

It seems that we found a way around the problem. 
It is a normal behaviour to serialize LocalActorRef without address, 
however to Cluster Sharding to work, we do need to persist messages with 
RemoteActorRef.
If you serialize PersistentRepr, MessageSerializer will serialize with 
RemoteActorRef. However we were serializing payload separately and 
reconstructing PersistentRepr on recovery in our custom journal.
Changing the journal to serialize whole PersistentRepr instead solved the 
issue.
I hope someone will find this useful.

On Monday, 26 January 2015 09:58:19 UTC, Patrik Nordwall wrote:
>
>
>
> On Mon, Jan 26, 2015 at 10:57 AM, Saparbek Smailov  > wrote:
>
>> Hello Patrik,
>>
>> Just for your information, one of my friends asked the same question: 
>> https://github.com/akka/akka/pull/2117# (Akrome)
>>
>> Thank you for your time and consideration!
>>
>
> Thanks. I will take a look at the debug log.
> /Patrik
>  
>
>>
>>
>>
>>
>> On Monday, January 26, 2015 at 9:54:33 AM UTC, Saparbek Smailov wrote:
>>>
>>> 2.3.4
>>>
>>> On Monday, January 26, 2015 at 9:36:17 AM UTC, Patrik Nordwall wrote:

 What version of Akka do you use?
 /Patrik

 On Mon, Jan 26, 2015 at 10:23 AM, Saparbek Smailov <
 saparbek...@gmail.com> wrote:

> Hello everyone,
>
> In our project we use Cluster Sharding with Cluster Singletons. Our 
> Cluster is set up on AWS Elastic Beanstalk. 
> The set up works perfectly until you start removing instances from the 
> cluster. The issue arises when a shard is recreated using Akka 
> persistence: during the recovery we get an error saying "Shard already 
> allocated".
>
> I went through the logs and realised that some of 
> ShardRegionTerminated events are persisted using LocalRef.
> Let me elaborate on this a little bit:
>  - During the recovery I get ShardRegionRegistered event with 
> RemoteActorRef.
>  - Then I get ShardHomeAllocated event which allocates shard on the 
> region
>  - I get ShardRegionTerminated with LocalActorRef, which does not 
> remove the Shard and Region from Maps, as RemoteActorRef is not equal to 
> LocalActorRef
>  - Then I get ShardRegionRegistered with Ref haveing different IP 
> address
>  - Finally when next ShardHomeAllocated is replayed I get "Shard 
> already allocated" error.
>
> How can I avoid the problem? Is there any way to force Akka use only 
> RemoteActorRef or at least serialize using RemoteActorRef? Am I not using 
> the library properly?
> I would appreciate any help/hint on this issue.
>
> Thank you very much!
>
> -- 
> >> 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

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


Notice:  This email is confidential and may contain copyright material of 
members of the Ocado Group. Opinions and views expressed in this message 
may not necessarily reflect the opinions and views of the members of the 
Ocado Group. 

 

If you are not the intended recipient, please notify us immediately and 
delete all copies of this message. Please note that it is your 
responsibility to scan this message for viruses. 

 

Fetch and Sizzle are trading names of Speciality Stores Limited, a member 
of the Ocado Group.

 

References to the “Ocado Group” are to Ocado Group plc (registered in 
England and Wales with number 7098618) and its subsidiary undertakings (as 
that expre

Re: [akka-user] Akka HTTP - back-pressure on incoming connections

[Jean Rossier]

Hi Roland,

thanks for the reply.
Do you know if this feature will be available in the 1.0 release ? if yes, 
when should it be available ? 

Regarding the "awkward" implementation, and following your advise, I'm 
trying to do something like the following:
val serverBinding = Http(system).bind(interface = host, port = port)
serverBinding.connections.buffer(5, 
OverflowStrategy.dropTail).map(incomingConnectionToHttpRequest).mapAsync[HttpResponse](httpRequestToHttpResponseFuture).to(BlackholeSink).run()

but I can't figure out how to get an HttpRequest out of an 
IncomingConnection. Is there any helper available in Akka HTTP ?

Thanks,
Jean

On Monday, January 26, 2015 at 10:35:59 AM UTC+1, rkuhn wrote:
>
> Hi Jean,
>
> calling “connection handleWith myFlow” is a really quick operation, hence 
> you see no back-pressure kicking in. The feature you are after is currently 
> rather awkward to implement, you’d have to replace handleWith with 
> manually joining and running the connection’s Flow in order to obtain a 
> Future for its termination, and then you’d mapAsync into a BlackholeSink 
> instead of using a ForeachSink.
>
> Since this is a common thing people will want to do, we will provide this 
> (or an equivalent solution) with Akka HTTP; this is one of the joys of 
> using development previews :-) But thanks for reporting in any case!
>
> Regards,
>
> Roland
>
> 26 jan 2015 kl. 10:04 skrev Jean Rossier  >:
>
> I would have expected some failed requests.
> In my test, I'm sending 200 concurrent requests (the processing of each 
> request takes circa 200ms), Since I have a buffer of 5, I thought that some 
> requests would have been dropped and my client would have received some 
> errors. But, in my test, all requests are replied sucessfully.
> I thought OverflowStrategy.dropTail would drop the incoming requests when 
> the buffer is full.
>
> Jean
>
> On Monday, January 26, 2015 at 9:38:36 AM UTC+1, drewhk wrote:
>>
>> Hi Jean,
>>
>> On Mon, Jan 26, 2015 at 9:03 AM, Jean Rossier  
>> wrote:
>>
>>> Hello,
>>>
>>> I'm wondering if there is a way to use back-pressure mechanism on 
>>> incoming connections with Akka HTTP ? 
>>> The documentation mentions clearly that there is no back-pressure 
>>> applied to the connections Source if we use the startHandlingWith* 
>>> functions (
>>> http://doc.akka.io/api/akka-stream-and-http-experimental/1.0-M2/?_ga=1.267496717.2041479737.1421658563#akka.http.Http$$ServerBinding).
>>>  
>>> Therefore, I tried to do something like the following:
>>> val serverBinding = Http(system).bind(interface = "localhost", port = 
>>> port)
>>> serverBinding.connections.buffer(5, 
>>> OverflowStrategy.dropTail).to(ForeachSink(_ handleWith myFlow)).run()
>>>
>>> But, when sending a bunch of concurrent connections to my server, the 
>>> buffer in the above code doesn't seem to have any effect.
>>>
>>
>> What do yo mean it had no effect? What did you expect it do do and what 
>> happened? What do you think OverflowStrategy.dropTail will do here?
>>
>> -Endre
>>  
>>
>>> Am I doing anything wrong ?
>>>
>>> Cheers,
>>> Jean
>>>
>>> -- 
>>> >> 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.
>>>
>>
>>
> -- 
> >> 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

Re: [akka-user] empty testActor mailbox before each test

[Patrik Nordwall]

Another possibility is to create a new TestKit for each test:

 new TestKit(system) {
target.tell(message, testActor)
expectMsg(answer)
  }

/Patrik

On Tue, Jan 27, 2015 at 2:53 PM, Björn Antonsson <
bjorn.antons...@typesafe.com> wrote:

> Hi,
>
> One posibillity would be to use a new test probe for each test, instead of
> the implicit test actor, like this.
>
> val testProbe = TestProbe()
> testProbe.send(target, message)
> testProbe.expectMsg(answer)
>
> B/
>
> On 27 January 2015 at 13:58:10, Jeremy Vuillermet (
> jeremy.vuiller...@gmail.com) wrote:
>
> I'm using akka testkit to test some actors.
>
> I have issues with tests that do not catch all the messages and yet are
> "valid" tests.
> Then we the next test is executed, the first expectMsg will throw because
> it's actually catching messages from the previous one.
>
> Although I could understand it's the test responsibility to catch all
> messages, even if it tries to do so, it will be hard to find the source of
> the error when some one send too many messages.
>
> How are you doing it ?
> Can I empty the testActor mailbox ? Is it OK to do that ?
>  --
> >> 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  – Reactive Apps on the JVM
> twitter: @bantonsson 
>
>  --
> >> 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.
>



-- 

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

-- 
>>  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] ActorSystem disappear [akka 2.3.8 , 2.3.9]

[Wolfgang Friedl]

Hi together!

Since a few days we observed that our actor-system crashes (disappear) 
without giving us any traces (no exception in the logs nothing, no logs 
from our postStop() functions)  why, moreover the funny thing is that our 
jvm doen't die.
Unfortunately we have no clue how to reproduce the problem. Whats we could 
say is that it is not related to memory problems because we observed the 
crash under no load as well as under medium load.

How we know that just the actor-system disapperead? Because our logger 
(slf4j) which we use for monitoring still logs reports after the 
actor-system disappears
Once we where connected via JConsole when the actor-system disappears we 
saw that the akka MBean was removed from the list.

Some of our dependencies which might have an impact on this

akka-http " Version1.0-M2
akka-stream Version1.0-M2
reactive-mongo Version "0.11.0_slf4j-SNAPSHOT"

...as well we are using the cluster feature.

Now we ask ourself how it is possible that the Actor-system could disappear 
without any traces? Any hints ?

Regards

Wolfgang

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