[akka-user] If first seed node start failed, the whole cluster will start failed

[Yutao Shuai]

In a 3-node cluster, all of nodes are seed nodes, if first node start 
failed, the whole cluster can't start successful.

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

Re: [akka-user] Akka Cluster (with Sharding) not working without auto-down-unreachable-after

[Justin du coeur]

The keyword here is "auto".  Autodowning is an *incredibly braindead*
algorithm for dealing with nodes coming out of service, and if you use it
in production you more or less guarantee disaster, because that algorithm
can't cope with cluster partition.  You *do* need to deal with downing, but
you have to get something smarter than that.

Frankly, if you're already hooking into AWS, I *suspect* the best approach
is to leverage that -- when a node goes offline, you have some code to
detect that through the ECS APIs, react to it, and manually down that node.
 (I'm planning on something along those lines for my system, but haven't
actually tried yet.)  But whether you do that or something else, you've got
to add *something* that does downing.

I believe the official party line is "Buy a Lightbend Subscription",
through which you can get their Split Brain Resolver, which is a fairly
battle-hardened module for dealing with this problem.  That's not strictly
necessary, but you *do* need to have a reliable solution...

On Wed, Aug 3, 2016 at 8:42 PM, Eric Swenson  wrote:

> We have an akka-cluster/sharding application deployed an AWS/ECS, where
> each instance of the application is a Docker container.  An ECS service
> launches N instances of the application based on configuration data.  It is
> not possible to know, for certain, the IP addresses of the cluster
> members.  Upon startup, before the AkkaSystem is created, the code
> currently polls AWS and determines the IP addresses of all the Docker hosts
> (which potentially could run the akka application).  It sets these IP
> addresses as the seed nodes before bringing up the akka cluster system. The
> configuration for these has, up until yesterday always included the
> akka.cluster.auto-down-unreachable-after configuration setting.  And it has
> always worked.  Furthermore, it supports two very critical requirements:
>
> a) an instance of the application can be removed at any time, due to
> scaling or rolling updates
> b) an instance of the application can be added at any time, due to scaling
> or rolling updates
>
> On the advice of an Akka expert on the Gitter channel, I removed the
> auto-down-unreachable-after setting, which, as documented, is dangerous for
> production.  As a result the system no longer supports rolling updates.  A
> rolling update occurs thus:  a new version of the application is deployed
> (a new ECS task definition is created with a new Docker image).  The ECS
> service launches a new task (Docker container running on an available host)
> and once that container becomes stable, it kills one of the remaining
> instances (cluster members) to bring the number of instances to some
> configured value.
>
> When this happens, akka-cluster becomes very unhappy and becomes
> unresponsive.  Without the auto-down-unreachable-after setting, it keeps
> trying to talk to the old cluster members. which is no longer present.  It
> appears to NOT recover from this.  There is a constant barrage of messages
> of the form:
>
> [DEBUG] [08/04/2016 00:19:27.126]
> [ClusterSystem-cassandra-plugin-default-dispatcher-27]
> [akka.actor.LocalActorRefProvider(akka://ClusterSystem)] resolve of path
> sequence [/system/sharding/ExperimentInstance#-389574371] failed
> [DEBUG] [08/04/2016 00:19:27.140]
> [ClusterSystem-cassandra-plugin-default-dispatcher-27]
> [akka.actor.LocalActorRefProvider(akka://ClusterSystem)] resolve of path
> sequence [/system/sharding/ExperimentInstance#-389574371] failed
> [DEBUG] [08/04/2016 00:19:27.142]
> [ClusterSystem-cassandra-plugin-default-dispatcher-27]
> [akka.actor.LocalActorRefProvider(akka://ClusterSystem)] resolve of path
> sequence [/system/sharding/ExperimentInstance#-389574371] failed
> [DEBUG] [08/04/2016 00:19:27.143]
> [ClusterSystem-cassandra-plugin-default-dispatcher-27]
> [akka.actor.LocalActorRefProvider(akka://ClusterSystem)] resolve of path
> sequence [/system/sharding/ExperimentInstance#-389574371] failed
> [DEBUG] [08/04/2016 00:19:27.143]
> [ClusterSystem-cassandra-plugin-default-dispatcher-27]
> [akka.actor.LocalActorRefProvider(akka://ClusterSystem)] resolve of path
> sequence [/system/sharding/ExperimentInstance#-389574371] failed
>
> and of the form:
>
> [WARN] [08/04/2016 00:19:16.787]
> [ClusterSystem-akka.actor.default-dispatcher-9] [akka.tcp://
> ClusterSystem@10.0.3.103:2552/system/sharding/ExperimentInstance] Retry
> request for shard [5] homes from coordinator at [Actor[akka.tcp://
> ClusterSystem@10.0.3.100:2552/system/sharding/ExperimentInstanceCoordinator/singleton/coordinator#1679517511]].
> [1] buffered messages.
> [WARN] [08/04/2016 00:19:18.787]
> [ClusterSystem-akka.actor.default-dispatcher-9] [akka.tcp://
> ClusterSystem@10.0.3.103:2552/system/sharding/ExperimentInstance] Retry
> request for shard [23] homes from coordinator at [Actor[akka.tcp://
> ClusterSystem@10.0.3.100:2552/system/sharding/ExperimentInstanceCoordinator/singleton/coordinator#1679517511]].
> [1] buffered 

[akka-user] Akka Cluster (with Sharding) not working without auto-down-unreachable-after

[Eric Swenson]

We have an akka-cluster/sharding application deployed an AWS/ECS, where 
each instance of the application is a Docker container.  An ECS service 
launches N instances of the application based on configuration data.  It is 
not possible to know, for certain, the IP addresses of the cluster members. 
 Upon startup, before the AkkaSystem is created, the code currently polls 
AWS and determines the IP addresses of all the Docker hosts (which 
potentially could run the akka application).  It sets these IP addresses as 
the seed nodes before bringing up the akka cluster system. The 
configuration for these has, up until yesterday always included the 
akka.cluster.auto-down-unreachable-after configuration setting.  And it has 
always worked.  Furthermore, it supports two very critical requirements:

a) an instance of the application can be removed at any time, due to 
scaling or rolling updates
b) an instance of the application can be added at any time, due to scaling 
or rolling updates

On the advice of an Akka expert on the Gitter channel, I removed the 
auto-down-unreachable-after setting, which, as documented, is dangerous for 
production.  As a result the system no longer supports rolling updates.  A 
rolling update occurs thus:  a new version of the application is deployed 
(a new ECS task definition is created with a new Docker image).  The ECS 
service launches a new task (Docker container running on an available host) 
and once that container becomes stable, it kills one of the remaining 
instances (cluster members) to bring the number of instances to some 
configured value.  

When this happens, akka-cluster becomes very unhappy and becomes 
unresponsive.  Without the auto-down-unreachable-after setting, it keeps 
trying to talk to the old cluster members. which is no longer present.  It 
appears to NOT recover from this.  There is a constant barrage of messages 
of the form:

[DEBUG] [08/04/2016 00:19:27.126] 
[ClusterSystem-cassandra-plugin-default-dispatcher-27] 
[akka.actor.LocalActorRefProvider(akka://ClusterSystem)] resolve of path 
sequence [/system/sharding/ExperimentInstance#-389574371] failed
[DEBUG] [08/04/2016 00:19:27.140] 
[ClusterSystem-cassandra-plugin-default-dispatcher-27] 
[akka.actor.LocalActorRefProvider(akka://ClusterSystem)] resolve of path 
sequence [/system/sharding/ExperimentInstance#-389574371] failed
[DEBUG] [08/04/2016 00:19:27.142] 
[ClusterSystem-cassandra-plugin-default-dispatcher-27] 
[akka.actor.LocalActorRefProvider(akka://ClusterSystem)] resolve of path 
sequence [/system/sharding/ExperimentInstance#-389574371] failed
[DEBUG] [08/04/2016 00:19:27.143] 
[ClusterSystem-cassandra-plugin-default-dispatcher-27] 
[akka.actor.LocalActorRefProvider(akka://ClusterSystem)] resolve of path 
sequence [/system/sharding/ExperimentInstance#-389574371] failed
[DEBUG] [08/04/2016 00:19:27.143] 
[ClusterSystem-cassandra-plugin-default-dispatcher-27] 
[akka.actor.LocalActorRefProvider(akka://ClusterSystem)] resolve of path 
sequence [/system/sharding/ExperimentInstance#-389574371] failed

and of the form:

[WARN] [08/04/2016 00:19:16.787] 
[ClusterSystem-akka.actor.default-dispatcher-9] 
[akka.tcp://ClusterSystem@10.0.3.103:2552/system/sharding/ExperimentInstance] 
Retry request for shard [5] homes from coordinator at 
[Actor[akka.tcp://ClusterSystem@10.0.3.100:2552/system/sharding/ExperimentInstanceCoordinator/singleton/coordinator#1679517511]].
 
[1] buffered messages.
[WARN] [08/04/2016 00:19:18.787] 
[ClusterSystem-akka.actor.default-dispatcher-9] 
[akka.tcp://ClusterSystem@10.0.3.103:2552/system/sharding/ExperimentInstance] 
Retry request for shard [23] homes from coordinator at 
[Actor[akka.tcp://ClusterSystem@10.0.3.100:2552/system/sharding/ExperimentInstanceCoordinator/singleton/coordinator#1679517511]].
 
[1] buffered messages.
[WARN] [08/04/2016 00:19:18.787] 
[ClusterSystem-akka.actor.default-dispatcher-9] 
[akka.tcp://ClusterSystem@10.0.3.103:2552/system/sharding/ExperimentInstance] 
Retry request for shard [1] homes from coordinator at 
[Actor[akka.tcp://ClusterSystem@10.0.3.100:2552/system/sharding/ExperimentInstanceCoordinator/singleton/coordinator#1679517511]].
 
[1] buffered messages.
[WARN] [08/04/2016 00:19:18.787] 
[ClusterSystem-akka.actor.default-dispatcher-9] 
[akka.tcp://ClusterSystem@10.0.3.103:2552/system/sharding/ExperimentInstance] 
Retry request for shard [14] homes from coordinator at 
[Actor[akka.tcp://ClusterSystem@10.0.3.100:2552/system/sharding/ExperimentInstanceCoordinator/singleton/coordinator#1679517511]].
 
[1] buffered messages.
[WARN] [08/04/2016 00:19:18.787] 
[ClusterSystem-akka.actor.default-dispatcher-9] 
[akka.tcp://ClusterSystem@10.0.3.103:2552/system/sharding/ExperimentInstance] 
Retry request for shard [5] homes from coordinator at 
[Actor[akka.tcp://ClusterSystem@10.0.3.100:2552/system/sharding/ExperimentInstanceCoordinator/singleton/coordinator#1679517511]].
 
[1] buffered messages.

and then a message like this:

[WARN] [08/03/2016 

Re: [akka-user] Re: [ANNOUNCE] Akka 2.4.9-RC1 Released! (Akka HTTP Performance and Entity Streaming)

[Konrad Malawski]

Hi Jason,
sadly the sbt-osgi plugin did something rather silly (I went in and fixed
the plugin today) breaking the release if Java Marshallers are used.
See here for details and workaround:
https://github.com/akka/akka/issues/21105

Thanks for trying out the release candidate and thanks for your
understanding - sorry that it's dead-on-arrival.
A stable 2.4.9 is coming any day now – that will work then.

We did a ReleaseCandidate this time as we weren't sure about some changes,
glad we did an RC because indeed one of them turned out to be a problem.

-- 
Konrad 'ktoso’ Malawski
Akka  @ Lightbend 
java.pl / geecon.org / krakowscala.pl / lambdakrk.pl /
sckrk.com

On 4 August 2016 at 00:17:30, Jason B (jason.boutw...@gmail.com) wrote:

Got this error after upgrading Akka versions in sbt build file from 2.4.8
to 2.4.9-RC1, and attempting to integrate JSON Streaming functionality. I'm
not using javadsl in any capacity. Seems related to the migration note on
javadsl, but I am only using scaladsl in my code. An issue with the Maven
artifacts?

[error] missing or invalid dependency detected while loading class file
'JsonEntityStreamingSupport.class'.
[error] Could not access type JsonEntityStreamingSupport in value
akka.http.javadsl.common,
[error] because it (or its dependencies) are missing. Check your build
definition for
[error] missing or conflicting dependencies. (Re-run with `-Ylog-classpath`
to see the problematic classpath.)
[error] A full rebuild may help if 'JsonEntityStreamingSupport.class' was
compiled against an incompatible version of akka.http.javadsl.common.
[error] missing or invalid dependency detected while loading class file
'EntityStreamingSupport.class'.
[error] Could not access type EntityStreamingSupport in value
akka.http.javadsl.common,
[error] because it (or its dependencies) are missing. Check your build
definition for
[error] missing or conflicting dependencies. (Re-run with `-Ylog-classpath`
to see the problematic classpath.)
[error] A full rebuild may help if 'EntityStreamingSupport.class' was
compiled against an incompatible version of akka.http.javadsl.common.


On Tuesday, August 2, 2016 at 1:04:29 PM UTC-6, Konrad 'ktoso' Malawski
wrote:
>
> Dear hAkkers,
>
> We—the Akka committers—are pleased to be able to announce the availability
> of Akka 2.4.9-RC1.
>
> This version is focused on Akka HTTP performance improvements as well as
> introducing the entity streaming feature which we’ll discuss below.
>
> Highlights of the performance improvements include:
>
>
>-
>
>Overall Akka HTTP throughput and transfer rate has been improved by
>30-40%
>-
>
>Performance is on-par or better than Spray.
>-
>   -
>
>   Matching it both in raw throughput as well as latency distribution
>   across a spectrum of request rates.
>   -
>
>   We measured an overall improvement of ~14% over Spray
>   -
>
>Short lived connections throughput, which remains to be the worst-case
>scenario for Akka HTTP thought remains rare in the real world (due to
>connection pooling), has been doubled.
>-
>
>Given our EC2 infrastructure (m4.2xlarge instances) the server
>currently reaches a maximum of ~160.000 “ping / pong” requests per second
>(measured using 100 concurrent connections).
>
>
> While we did not have the chance to benchmark using dedicated boxes this
> time, based on experience from previous Spray benchmark rounds we expect
> the top throughput to be much higher on actual hardware than it is on EC2.
>
> One might want to remind remind oneself the good old post about Spray’s
> benchmarking results  
> back
> in 2013 when it won a benchmarking round, achieving 30k reqs/sec on EC2
> (m1.large) and 197k reqs/sec on dedicated i7 machines (using 256
> connections).
>
> This release also features a new feature that we think Streaming API
> authors will be delighted to see: EntityStreamingSupport.
>
> It makes marshalling of Akka Streams into/from HTTP requests and responses
> as simple as adding enabling streaming and calling complete(tweets), given
> tweets was a Source[Tweet, _].
>
> Learn more about it in the Entity Streaming section of the documentation
> 
> .
>
> We would like to encourage Akka HTTP users to try out this Release
> Candidate and provide feedback or report regressions if you find any.
>
> API has remained largely unchanged, though the usual experimental module
> incompatibility caveat still remains so upgrading should be simple.
>
> You may want to refer to the migration guide
> ,
> as some classes moved to more appropriate places. A stable 2.4.9 should
> follow shortly after we’ve gathered some community feedback.
> Next steps for Akka HTTP
>
> 

[akka-user] Re: [ANNOUNCE] Akka 2.4.9-RC1 Released! (Akka HTTP Performance and Entity Streaming)

[Jason B]

Got this error after upgrading Akka versions in sbt build file from 2.4.8 
to 2.4.9-RC1, and attempting to integrate JSON Streaming functionality. I'm 
not using javadsl in any capacity. Seems related to the migration note on 
javadsl, but I am only using scaladsl in my code. An issue with the Maven 
artifacts?

[error] missing or invalid dependency detected while loading class file 
'JsonEntityStreamingSupport.class'.
[error] Could not access type JsonEntityStreamingSupport in value 
akka.http.javadsl.common,
[error] because it (or its dependencies) are missing. Check your build 
definition for
[error] missing or conflicting dependencies. (Re-run with `-Ylog-classpath` 
to see the problematic classpath.)
[error] A full rebuild may help if 'JsonEntityStreamingSupport.class' was 
compiled against an incompatible version of akka.http.javadsl.common.
[error] missing or invalid dependency detected while loading class file 
'EntityStreamingSupport.class'.
[error] Could not access type EntityStreamingSupport in value 
akka.http.javadsl.common,
[error] because it (or its dependencies) are missing. Check your build 
definition for
[error] missing or conflicting dependencies. (Re-run with `-Ylog-classpath` 
to see the problematic classpath.)
[error] A full rebuild may help if 'EntityStreamingSupport.class' was 
compiled against an incompatible version of akka.http.javadsl.common.


On Tuesday, August 2, 2016 at 1:04:29 PM UTC-6, Konrad 'ktoso' Malawski 
wrote:
>
> Dear hAkkers,
>
> We—the Akka committers—are pleased to be able to announce the availability 
> of Akka 2.4.9-RC1. 
>
> This version is focused on Akka HTTP performance improvements as well as 
> introducing the entity streaming feature which we’ll discuss below. 
>
> Highlights of the performance improvements include:
>
>
>- 
>
>Overall Akka HTTP throughput and transfer rate has been improved by 
>30-40%
>- 
>
>Performance is on-par or better than Spray. 
>- 
>   
>   Matching it both in raw throughput as well as latency distribution 
>   across a spectrum of request rates.
>   - 
>   
>   We measured an overall improvement of ~14% over Spray
>   - 
>
>Short lived connections throughput, which remains to be the worst-case 
>scenario for Akka HTTP thought remains rare in the real world (due to 
>connection pooling), has been doubled.
>- 
>
>Given our EC2 infrastructure (m4.2xlarge instances) the server 
>currently reaches a maximum of ~160.000 “ping / pong” requests per second 
>(measured using 100 concurrent connections).
>
>
> While we did not have the chance to benchmark using dedicated boxes this 
> time, based on experience from previous Spray benchmark rounds we expect 
> the top throughput to be much higher on actual hardware than it is on EC2. 
>
> One might want to remind remind oneself the good old post about Spray’s 
> benchmarking results  
> back in 2013 when it won a benchmarking round, achieving 30k reqs/sec on 
> EC2 (m1.large) and 197k reqs/sec on dedicated i7 machines (using 256 
> connections).
>
> This release also features a new feature that we think Streaming API 
> authors will be delighted to see: EntityStreamingSupport. 
>
> It makes marshalling of Akka Streams into/from HTTP requests and responses 
> as simple as adding enabling streaming and calling complete(tweets), given 
> tweets was a Source[Tweet, _]. 
>
> Learn more about it in the Entity Streaming section of the documentation 
> 
> .
>
> We would like to encourage Akka HTTP users to try out this Release 
> Candidate and provide feedback or report regressions if you find any. 
>
> API has remained largely unchanged, though the usual experimental module 
> incompatibility caveat still remains so upgrading should be simple. 
>
> You may want to refer to the migration guide 
> ,
>  
> as some classes moved to more appropriate places. A stable 2.4.9 should 
> follow shortly after we’ve gathered some community feedback.
> Next steps for Akka HTTP
>
> Having that said, we’ll want to officially announce the end-of-life of 
> Spray and confidently request users to upgrade to Akka HTTP. 
>
> Yes, this means we’ll soon be lifting the experimental flag from Akka 
> HTTP. 
>
> The exact timeline for this is yet to be decided, as we want to discuss 
> with the community about the best way to go about this.
>
> The other question that is on everyone’s minds is one about HTTP/2.
>
> We’d like to announce that we’ll spend some time working on an HTTP/2 
> Proof-of-Content within a few months. 
>
> You can follow our sprint plans on akka-meta be up to date about our 
> sprint plans and progress.
>
>
> Credits:
>
> commits added removed
>
>   3957531748 Konrad 

[akka-user] Re: [ANNOUNCE] Akka 2.4.9-RC1 Released! (Akka HTTP Performance and Entity Streaming)

[Jim Hazen]

Some quick feedback on raw iron performance, on my local workstation.  Your 
mileage my vary, but I'm pretty happy with these numbers.

Minimal example Webserver code 
from: http://doc.akka.io/docs/akka/2.4/scala/http/routing-dsl/index.html

wrk -d30 -c100 -t12 http://localhost:8080/hello
Running 30s test @ http://localhost:8080/hello
  12 threads and 100 connections
  Thread Stats   Avg  Stdev Max   +/- Stdev
Latency 2.15ms   12.36ms 309.76ms   97.72%
Req/Sec21.98k 4.54k   39.19k75.18%
  7827755 requests in 30.08s, 1.28GB read
Requests/sec: 260269.56
Transfer/sec: 43.69MB

Thanks Akka Team!  Been looking forward to this for a long time.

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

[akka-user] No configuration setting found for key 'akka.version' when running jar-with-dependencies

[Dean Schulze]

I've added the maven-shade-plugin from the Akka docs 
 to my 
pom.xml, and it is the first plugin in .  The shade plugin 
is doing something as evidenced by this in my maven by this output in my 
maven build

[INFO] --- maven-shade-plugin:1.5:shade (default) @ remoting.example ---
[INFO] Including com.typesafe.akka:akka-remote_2.11:jar:2.4.8 in the shaded 
jar.
[INFO] Including org.scala-lang:scala-library:jar:2.11.8 in the shaded jar.
[INFO] Including com.typesafe.akka:akka-protobuf_2.11:jar:2.4.8 in the 
shaded jar.
[INFO] Including io.netty:netty:jar:3.10.6.Final in the shaded jar.
[INFO] Including org.uncommons.maths:uncommons-maths:jar:1.2.2a in the 
shaded jar.
[INFO] Including com.typesafe.akka:akka-actor_2.11:jar:2.4.8 in the shaded 
jar.
[INFO] Including com.typesafe:config:jar:1.3.0 in the shaded jar.
[INFO] Including org.scala-lang.modules:scala-java8-compat_2.11:jar:0.7.0 
in the shaded jar.
[INFO] Attaching shaded artifact.



When I execute the jar-with-dependencies it still gives

Exception in thread "main" com.typesafe.config.ConfigException$Missing: No 
configuration setting found for key 'akka.version'


What do I have to do to build a jar-with-dependencies with akka?

Thanks.

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

Re: [akka-user] Retry only has meaning for restart in SuperVisorStragety?

[Yan Pei]

Johan,

   Thank you!
   If the exception caused by external Server, both actor state and message 
are good, we can also retry the message when choosing resume.
   I have a question about RESTART, will RESTART start the Actor and resend 
the failed message again? Does the MailBox of the Actor still keep the 
failed message?

Yan

On Wednesday, July 27, 2016 at 7:55:48 AM UTC-5, Akka Team wrote:
>
> Hi Yan,
>
> If you choose resume, you think that the actor state is ok, but the 
> message bad, so you don't want to retry the message. If you choose restart 
> then it may have been the actor state that was bad, that will be fixed by 
> the restart and then it may be reasonable to retry the message, if you 
> stopped the actor it definitely does not make sense to retry the message as 
> the actor will be no more.
>
> --
> Johan
>
> On Thu, Jul 21, 2016 at 10:05 PM, Yan Pei  
> wrote:
>
>> Hello,
>>
>>From the doc and my testing, looks like "retry only is meaningful if I 
>> want to restart the Actor? For resume() it will not apply the retry? Do I 
>> understand it correctly?
>>
>> Thanks,
>> Yan
>>
>> -- 
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >> Search the archives: https://groups.google.com/group/akka-user
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to akka-user+...@googlegroups.com .
>> To post to this group, send email to akka...@googlegroups.com 
>> .
>> Visit this group at https://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>
>

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

Re: [akka-user] Question about how to use PeekMailBox

[Yan Pei]

Hi Johan,

   Thank you very much for your suggestions. The supervisor strategy has 
options of stop/resume/escalate/restart, I didn't figure out how to resend 
the failed message via supervisor strategy.  The sender is in sending and 
forgot mode and no confirmation for sender since it's batch process, so the 
send option will not apply.  I will try the third option.

Thanks again,
Yan

On Wednesday, July 27, 2016 at 9:24:51 AM UTC-5, Akka Team wrote:
>
> Hi Yan,
>
> I'd recommend you to try to start out with some messaging pattern instead 
> of reaching for special mailboxes.
>
> Did you try just catching the exception and retrying your logic rather 
> than relying on supervision for this?
> A second option would be to have the sender retry sending the message 
> after a timeout. A third option would
> be to provide a parent actor that outside actors interact with who 
> contains the retry logic (which messages are in
> flight and what child is processing what message, how many retries for a 
> specific message) and lets the children
> just fail without caring about the retry logic.
>
> --
> Johan
>
> On Mon, Jul 25, 2016 at 8:52 PM, Yan Pei  
> wrote:
>
>> Hello All,
>>
>>   I am trying to use PeekMailBox for retrying after the message 
>> processing failed.
>>   In the Actor, I am using Future to delivery the message for processing 
>> and piping the result back to itself. Do some matching(Failure or something 
>> else) after that.
>>   Where am I supposed to put PeekMailboxExtension.lookup().ack(context)? 
>> I couldn't put inside the future or before after future or matching section.
>>
>> Thanks for helping!
>> Yan
>>
>> -- 
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >> Search the archives: https://groups.google.com/group/akka-user
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to akka-user+...@googlegroups.com .
>> To post to this group, send email to akka...@googlegroups.com 
>> .
>> Visit this group at https://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

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

[akka-user] How to deal with "connection pool shut down unexpectedly" ?

[Guofeng Zhang]

Hi,

I want to capture this exception in my application, but It cannot be
capturued using CompletionStage.exceptionally().

How could I do capture it?

The follwing is the code:

final HttpRequest request =
HttpRequest.create(uri).addHeader(range) ;
final CompletionStage responseFuture =
Http.get(system)
.singleRequest(request, materializer);

responseFuture.exceptionally(ex -> {
failed(chunk, ex);
return null ;
}) ;

The following is the exception:

[error] a.a.ActorSystemImpl - Outgoing request stream error
akka.http.scaladsl.model.EntityStreamException: Entity stream truncation
at
akka.http.impl.engine.parsing.HttpMessageParser$$anonfun$defaultEntity$1$$anonfun$1.applyOrElse(HttpMessageParser.scala:344)
at
akka.http.impl.engine.parsing.HttpMessageParser$$anonfun$defaultEntity$1$$anonfun$1.applyOrElse(HttpMessageParser.scala:342)
at akka.stream.impl.fusing.Collect$$anon$2$$anonfun$4.apply(Ops.scala:175)
at
akka.stream.impl.fusing.SupervisedGraphStageLogic.withSupervision(Ops.scala:142)
at akka.stream.impl.fusing.Collect$$anon$2.onPush(Ops.scala:177)
at
akka.stream.impl.fusing.GraphInterpreter.processElement$1(GraphInterpreter.scala:590)
at
akka.stream.impl.fusing.GraphInterpreter.processEvent(GraphInterpreter.scala:601)
at
akka.stream.impl.fusing.GraphInterpreter.execute(GraphInterpreter.scala:542)
at
akka.stream.impl.fusing.GraphInterpreterShell.runBatch(ActorGraphInterpreter.scala:471)
at
akka.stream.impl.fusing.GraphInterpreterShell.receive(ActorGraphInterpreter.scala:423)
[info] a.a.LocalActorRef - Message
[akka.http.impl.engine.client.PoolInterfaceActor$PoolRequest] from
Actor[akka://application/user/pool-master#-922799551] to
Actor[akka://application/user/pool-master/PoolInterfaceActor-0#1525660917]
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] a.a.LocalActorRef - Message
[akka.http.impl.engine.client.PoolInterfaceActor$PoolRequest] from
Actor[akka://application/user/pool-master#-922799551] to
Actor[akka://application/user/pool-master/PoolInterfaceActor-0#1525660917]
was not delivered. [2] 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'.
[error] a.h.i.e.c.PoolMasterActor - connection pool for PoolGateway(hcps =
HostConnectionPoolSetup(runner.dressbad.com,80,ConnectionPoolSetup(ConnectionPoolSettings(4,0,5,32,1,30
seconds,ClientConnectionSettings(Some(User-Agent: akka-http/2.4.8),10
seconds,1
minute,512,,List(),ParserSettings(2048,16,64,64,8192,64,8388608,256,1048576,Strict,RFC6265,true,Full,Map(If-Range
-> 0, If-Modified-Since -> 0, If-Unmodified-Since -> 0, default -> 12,
Content-MD5 -> 0, Date -> 0, If-Match -> 0, If-None-Match -> 0, User-Agent
->
32),false,,,))),akka.http.scaladsl.HttpConnectionContext$@7994f4f8,akka.event.BusLogging@421bed04)))
has shut down unexpectedly

When the exception occurred, my application hung up because my application
cannot capture the exception so that it cannot recover from it.

Thanks for your help very much.

I use Akka 2.4.8, Java 8.

Guofeng

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

Re: [akka-user] Unable to receive UDP packets after restarting network interface

[Endre Varga]

Hi,

I am not sure what Akka can do about this. We just use the NIO interfaces
from the JDK. If we didn't report an error then likely we didn't get one
from Java in the first place. I might be wrong of course but I don't really
know what we could do here.

-Endre

On Wed, Aug 3, 2016 at 2:46 PM, BlueZL  wrote:

> Hi all,
>
> After binding to an UDP port, my own UDP actor has been able to
> send/receive UDP packets without issues until one day we restarted the
> network interface "service network restart". After that the UDP actor
> stopped getting UDP packets without receiving any failure/exception
> messages. I had to restart the actor system to force it to bind to the port
> again in order to work. Is there any configuration on UDP binding I can
> specify to avoid this?
>
> Thanks!
> BZL
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

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

[akka-user] Unable to receive UDP packets after restarting network interface

[BlueZL]

Hi all,

After binding to an UDP port, my own UDP actor has been able to 
send/receive UDP packets without issues until one day we restarted the 
network interface "service network restart". After that the UDP actor 
stopped getting UDP packets without receiving any failure/exception 
messages. I had to restart the actor system to force it to bind to the port 
again in order to work. Is there any configuration on UDP binding I can 
specify to avoid this?

Thanks!
BZL

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

[akka-user] Re: RoundRobinPool with remote routees

[Gabor Kolok]

Problem was that ActorSystem was not remote-enabled, because 
ConfigFactory.load silently fallback to empty config if config resource 
name is wrong.

Gabor

2016. augusztus 2., kedd 21:00:31 UTC+2 időpontban Gabor Kolok a következőt 
írta:
>
> Hi,
>
> I am creating a router with the following code in an Actor:
>
>   val router: ActorRef = {
> val addresses = Seq(
>   Address("akka.tcp", "workersSystem", "localhost", 2555)
> )
> context.actorOf(
>   RemoteRouterConfig(RoundRobinPool(1), addresses).props(Props[
> WorkerActor]))
>   }
>
> The workers are created locally (in the same system where the parent Actor 
> is created) without error message.
> It seems that addresses are ignored.
> What could be the problem?
>
> Thanks
> Gabor
>
>
>
>

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

[akka-user] Event sourcing user database with akka persistence and sharding

['Christian Hoffmeister' via Akka User List]

Hi folks,

I am just starting with event sourcing and still struggle to get domain 
problems solved. Maybe a user database is not a good fit for ES, dunno :)

What do I want to achieve:

* Users can be created (having an immutable UUID and an email which is used 
as username)
* Email can be changed
* Email should be unique (since used as login username)
* Lookup users is needed by email (for login) and by UUID (for everything 
else)

*Lookup by email and change email*

Since user database is potentially unbound I wanted to use sharding over 
the UUID to be able to split the state hold in memory across nodes. So I 
would end up with multiple ES event streams, one for each user UUID. So 
getting the current user state by ID is done. But how do I look up the user 
by email? Would it be a common solution to have a secondary event stream, 
one for each email and have that be updated whenever a new user is created 
or a user changes it's email address?

*Uniqueness of email*

As I read uniqueness is expensive to be guaranteed. I thought about not 
creating the user object directly, but instead on registration, send an 
email to the given email address that contains a verification link. But 
this link does not only contain a nonce, but instead is an encrypted and 
signed JWT. Only when the user clicks that link, the user account is 
actually created. This does not totally solve the uniqueness constraint, 
but it at least ensures that not two different persons create an account 
with the same email.

*Choosing persistenceId (and maybe also shardingId/entityId)*

Here is some code I have so far, but it is not totally working (for example 
the akka.persistence.Update event is not properly propagated through the 
sharding). Also when using sharding this fails, because multiple instances 
of UserProcessor share the same `persistenceId`. But I did not now what to 
do, since when I include the user UUID in the `persistenceId`, which would 
make sense, then the `EmailView` does not get all events to build up the 
email lookup dictionary. TL;DR: this code is probably total nonsense.

// UserProcessor.scala

package io.airfocus.user

import akka.actor.{Actor, ActorLogging, ActorRef}
import akka.persistence.{PersistentActor}
import de.choffmeister.auth.common.{PBKDF2, PasswordHasher, Plain}
import io.airfocus.common.{RandomString, WithPassivation}
import io.airfocus.model.User
import io.airfocus.model.UserProcessor._

import scala.concurrent.duration._

class UserProcessor(userView: ActorRef, emailView: ActorRef) extends Actor with 
ActorLogging with PersistentActor with WithPassivation {
  private val passwordHasher = new PasswordHasher("pbkdf2", "hmac-sha1" :: 
"1" :: "128" :: Nil, PBKDF2 :: Plain :: Nil)

  override def passivationTimeout: FiniteDuration = 5.seconds

  override def persistenceId: String = "users"

  override def receiveRecover: Receive = {
case ev: CreateUser =>
  }

  override def receiveCommand: Receive = withPassivation({
case cmd @ CreateUser(userId, email, password) =>
  persistAsync(UserCreated(User(id = userId, emails = Map(email -> 
Some(RandomString.base32(32))), passwordHash = passwordHasher.hash(password 
{ ev =>
userView ! io.airfocus.model.UserView.Update(userId)
emailView ! io.airfocus.model.EmailView.Update(email)
sender() ! ev.user
  }
  })

  override def preStart() = log.info("Starting {}", self.path)
  override def postStop() = log.info("Stopped {}", self.path)
}



// UserView.scala

package io.airfocus.user

import java.util.UUID

import akka.actor.{Actor, ActorLogging}
import akka.persistence.PersistentView
import io.airfocus.common.WithPassivation
import io.airfocus.model.User
import io.airfocus.model.UserProcessor._
import io.airfocus.model.UserView._

import scala.concurrent.duration._

class UserView extends Actor with ActorLogging with PersistentView with 
WithPassivation {
  var users = Map.empty[UUID, User]

  override def passivationTimeout: FiniteDuration = 5.seconds

  override def persistenceId: String = "users"

  override def viewId: String = s"users-user-${self.path.name}"

  override def autoUpdate: Boolean = true

  override def autoUpdateInterval: FiniteDuration = 1.second

  override def receive: Receive = withPassivation({
case ev @ UserCreated(u) =>
  println(ev)
  users = users + (u.id -> u)

case GetUser(userId) =>
  sender() ! users.get(userId)

case Update(_) =>
  self ! akka.persistence.Update(await = true)
  })
}



// EmailView.scala

package io.airfocus.user

import java.util.UUID

import akka.actor.{Actor, ActorLogging}
import akka.persistence.PersistentView
import io.airfocus.common.WithPassivation
import io.airfocus.model.EmailView.{LookupEmail, Update}
import io.airfocus.model.UserProcessor._

import scala.concurrent.duration._

class EmailView extends Actor with ActorLogging with PersistentView with 
WithPassivation {
  var users = Map.empty[String, UUID]

  override def