[akka-user] Re: Akka Actor Per Request Java Sample
I was looking to know how to write an actor per request. I want to understand this pattern so I could create a sample similar to the one at https://github.com/muuki88/activator-play-cluster-sample that creates a frontend for an akka cluster in Java. I'm struggling with how to have a frontend actor send a send a message to an akka cluster. At this point hearing how this would be implemented would be great so I could write this in simple form even using a basic Java console application just to understand the basics of to have a frontend send a message to an akka cluster. Thanks, John On Sunday, July 20, 2014 12:20:45 PM UTC-4, Konrad Malawski wrote: Hello John, I don't think there is an equivalent repo to this out there... Although I assume you've seem this post http://techblog.net-a-porter.com/2013/12/ask-tell-and-per-request-actors/ where this code sample originates from? The concepts are pretty generic, and I would recommend checking out the concepts if you have not yet already. Is there a specific question you'd like to see answered here? -- Konrad `ktoso` Malawski hAkker @ Typesafe -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Remote: cascade disconnections when more than 10 clients connecting to same system
Hi Vitaliy,
Do you send large messages or send messages without backpressure? Since
2.2.x does not prioritize internal heartbeat messages over user messages it
can accumulate delay. You should try throttling or backpressuring your
remote sends first to see if it is the problem.
-Endre
On Mon, Jul 21, 2014 at 7:06 PM, Vitaliy Morarian vmorar...@gmail.com
wrote:
Hi Konrad,
Master is m1.xlarge instance. I checked CPU load: about 5-10%
Unfortunately we can't upgrade to 2.3.x due protobuf dependency (I tried,
but faced with some reflection exceptions during Tomcat startup)
On Friday, July 18, 2014 1:04:33 PM UTC+3, Konrad Malawski wrote:
Hi Vitaliy,
It seems the master is overloaded.
Do you have jvm monitoring in place to see if it's not in state of agony?
In other news, 2.3.4 prioritises hearbeats so missing hearbeat messages
(thus causing false positives on failure detection) because of overloaded
machine is less likely,
I would recommend trying to upgrade (maybe you can upgrade your proto
dependency somehow?).
You can also tweak the failure detector's timeout, but if it's the case
that the master is barely keeping up anyway that's not really a solution.
On Mon, Jul 14, 2014 at 5:53 PM, Vitaliy Morarian vmor...@gmail.com
wrote:
Hi,
We have MonitoringMaster actor system and N Metrics actor systems.
They are deployed in AWS, and to make it working we are substituting
public-ip in runtime.
Akka version: 2.2.4 (can't upgrade to 2.3.x due protobuf dependency)
Config file:
akka {
loglevel = INFO
log-config-on-start = on
debug {
receive = on
lifecyle = off
}
actor {
provider = akka.remote.RemoteActorRefProvider
}
remote {
enabled-transports = [akka.remote.netty.tcp]
log-remote-lifecycle-events = INFO
netty.tcp {
hostname = 127.0.0.1 //but we substitute a real IP in runtime
}
secure-cookie = #
require-cookie = on
}
}
remote {
untrusted-mode = on
log-received-messages = off
}
So everything works ok when we have less than 10 clients. Problem starts
to occur when more than 10 clients are connecting to master (sometimes
11, sometimes 15, ...).
In this case we observing cascade of exceptions (and it affects all
Metrics systems):
*MonitoringMaster*:
[INFO] [07/14/2014 15:02:06.386]
[MonitoringMaster-akka.actor.default-dispatcher-3]
[akka://MonitoringMaster/user/master] Added producer Actor[akka.tcp://
metr...@ec2-54-88-77-195.compute-1.amazonaws.com:2552/user/
metric-producer#-1020796025] with meta InstanceMeta(InstanceGlobalId(
us-east-1,i-14ffd83e),)
[WARN] [07/14/2014 15:03:03.023]
[MonitoringMaster-akka.actor.default-dispatcher-19]
[akka://MonitoringMaster/system/remote-watcher] Detected unreachable:
[akka.tcp://metr...@ec2-54-88-77-195.compute-1.amazonaws.com:2552]
[INFO] [07/14/2014 15:03:03.048]
[MonitoringMaster-akka.actor.default-dispatcher-3]
[Remoting] Address [akka.tcp://Metrics@ec2-54-88-
77-195.compute-1.amazonaws.com:2552] is now quarantined, all messages
to this address will be delivered to dead letters.
WARN] [07/14/2014 15:03:03.060]
[MonitoringMaster-akka.actor.default-dispatcher-3]
[akka://MonitoringMaster/system/endpointManager/
reliableEndpointWriter-akka.tcp%3A%2F%2FMetrics%40ec2-54-
88-77-195.compute-1.amazonaws.com%3A2552-1866/endpointWriter]
AssociationError [akka.tcp://MonitoringMaster@ec2-54-82-6-7.compute-1.
amazonaws.com:2551] - [akka.tcp://Metrics@ec2-54-88-
77-195.compute-1.amazonaws.com:2552]: Error [Invalid address:
akka.tcp://metr...@ec2-54-88-77-195.compute-1.amazonaws.com:2552] [
akka.remote.InvalidAssociation: Invalid address: akka.tcp://
metr...@ec2-54-88-77-195.compute-1.amazonaws.com:2552
Caused by: akka.remote.transport.Transport$InvalidAssociationException:
The remote system has a UID that has been quarantined. Association aborted.
]
[WARN] [07/14/2014 15:03:03.061]
[MonitoringMaster-akka.actor.default-dispatcher-3]
[Remoting] Tried to associate with unreachable remote address [akka.tcp://
metr...@ec2-54-88-77-195.compute-1.amazonaws.com:2552]. Address is now
gated for 6 ms, all messages to this address will be delivered to dead
letters. Reason: The remote system has a UID that has been quarantined.
Association aborted.
[ERROR] [07/14/2014 15:03:06.205]
[MonitoringMaster-akka.actor.default-dispatcher-19]
[akka://MonitoringMaster/system/endpointManager/
endpointWriter-akka.tcp%3A%2F%2FMetrics%40ec2-54-88-77-195.
compute-1.amazonaws.com%3A2552-1867] AssociationError [akka.tcp://
monitoringmas...@ec2-54-82-6-7.compute-1.amazonaws.com:2551] -
[akka.tcp://metr...@ec2-54-88-77-195.compute-1.amazonaws.com:2552]:
Error [Invalid address: akka.tcp://Metrics@ec2-54-88-
77-195.compute-1.amazonaws.com:2552] [
akka.remote.InvalidAssociation: Invalid address: akka.tcp://
metr...@ec2-54-88-77-195.compute-1.amazonaws.com:2552
Caused by:
Re: [akka-user] Re: Akka Actor Per Request Java Sample
Hi John, I was looking to know how to write an actor per request. I want to understand this pattern so I could create a sample similar to the one at https://github.com/muuki88/activator-play-cluster-sample that creates a frontend for an akka cluster in Java. I'm struggling with how to have a frontend actor send a send a message to an akka cluster. At this point hearing how this would be implemented would be great so I could write this in simple form even using a basic Java console application just to understand the basics of to have a frontend send a message to an akka cluster. We need a bit more information about what you want to achieve. Sending a message from an actor to another actor (irregardless whether it is in a cluster or not) is just like an ordinary message send. Is your problem how to aquire remote ActorRefs from the cluster? Btw, you can have your frontend be part of the cluster and use simply a cluster-aware router if you have a worker pool for example. You can use cluster sharding if you need persistent stateful entities maintained in the cluster. There are many ways to interact with clustered actor systems. In fact, all that core clustering does is maintaining membership information, all the others are just patterns on top of this, using remoting to send messages to remote actors. You can look at the list of activator templates, maybe you find something that fits your need: http://akka.io/downloads/ In particular http://typesafe.com/activator/template/akka-distributed-workers-java?_ga=1.42689506.61833477.1364484269 might be interesting for you. -Endre Thanks, John On Sunday, July 20, 2014 12:20:45 PM UTC-4, Konrad Malawski wrote: Hello John, I don't think there is an equivalent repo to this out there... Although I assume you've seem this post http://techblog.net-a- porter.com/2013/12/ask-tell-and-per-request-actors/ where this code sample originates from? The concepts are pretty generic, and I would recommend checking out the concepts if you have not yet already. Is there a specific question you'd like to see answered here? -- Konrad `ktoso` Malawski hAkker @ Typesafe -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout. -- Akka Team Typesafe - The software stack for applications that scale Blog: letitcrash.com Twitter: @akkateam -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] expermental http client
Hi Leon, I've been looking at the new expermental http server and the tcp echo server / client. and it looks really promising! Is it possible to create a http client using the current api (0.4), and if so, how can I adapt the tcp client code to do a http request instead? It is possible yes, although there will be an official http client later. You can already use the tcp code though, it returns you a Producer of ByteStrings and a Consumer of ByteStrings representing the input and output sides of the connection. If you want something dead simple and you don't care about character encodings or any advanced stuff, you can just map these two streams to take Strings instead and send requests as strings. -Endre -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout. -- Akka Team Typesafe - The software stack for applications that scale Blog: letitcrash.com Twitter: @akkateam -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Akka cluster - seed nodes can not connect to each other and split head is detected when the forstmost seed node gets disconnected. (Akka 2,3,2)
Hi Eugene
The order of the seed nodes in the list is important, since the first one
is important in the bootstrapping process:
http://doc.akka.io/docs/akka/2.3.4/scala/cluster-usage.html#Joining_to_Seed_Nodes
[...] the node configured as the first element in the seed-nodes
configuration list must be started when initially starting a cluster,
otherwise the other seed-nodes will not become initialized and no other
node can join the cluster. The reason for the special first seed node is to
avoid forming separated islands when starting from an empty cluster.
So you should have the same node as the first one in the seed node list on
both machines.
If you have the proper order, after initial startup you can restart any of
the nodes. You said that you have a problem even in this case, can you post
some log snippets to show what happens in that case?
Btw, you get an InitJoinNack if you try to join a member to a node that has
been not fully initialized yet. Are you sure you are restarting the first
node after the second has been fully initialized?
-Endre
On Tue, Jul 22, 2014 at 4:55 AM, Eugene Dzhurinsky jdeve...@gmail.com
wrote:
Hello!
I have a cluster with 2 nodes, with the addresses 10.9.0.1 and 10.9.0.2
the appropriate Akka configurations are:
akka {
remote {
netty.tcp {
hostname = 10.9.0.1
port = 2551
}
}
cluster {
seed-nodes = [
akka.tcp://HttpCluster@10.9.0.2:2551,
akka.tcp://HttpCluster@10.9.0.1:2551
]
}
}
and
akka {
remote {
netty.tcp {
hostname = 10.9.0.2
port = 2551
}
}
cluster {
seed-nodes = [
akka.tcp://HttpCluster@10.9.0.1:2551,
akka.tcp://HttpCluster@10.9.0.2:2551
]
}
}
So each node tries to connect to another one and then falls back to
connection to itself (the order of seed-nodes is inverted). I theory (I
assumed so) the cluster should survive the case when either of the nodes is
restarted, so the node can re-join the custer.
However this doesn't work. In the logs I can see:
INFO | jvm 1| 2014/07/21 22:37:45 | 2014-07-21 22:37:45,525 DEBUG
[EndpointWriter] sending message RemoteMessage:
[ActorSelectionMessage(InitJoin,Vector(system, cluster, core, daemon))] to
[Actor[akka.tcp://HttpCluster@10.9.0.2:2551/]
http://HttpCluster@10.9.0.2:2551/%5D]+[akka.tcp://
HttpCluster@10.9.0.2:2551/] from
[Actor[akka://HttpCluster/system/cluster/core/daemon/joinSeedNodeProcess-1#-625930305]]
INFO | jvm 1| 2014/07/21 22:37:45 | 2014-07-21 22:37:45,571 DEBUG
[EndpointWriter] received local message RemoteMessage:
[InitJoinNack(akka.tcp://HttpCluster@10.9.0.2:2551)] to
[Actor[akka://HttpCluster/system/cluster/core/daemon/joinSeedNodeProcess-1#-625930305]]+[akka://HttpCluster/system/cluster/core/daemon/joinSeedNodeProcess-1]
from [Actor[akka.tcp://
HttpCluster@10.9.0.2:2551/system/cluster/core/daemon#1007710386]()]
INFO | jvm 1| 2014/07/21 22:37:45 | 2014-07-21 22:37:45,907 DEBUG
[EndpointWriter] received local message RemoteMessage:
[ActorSelectionMessage(InitJoin,Vector(system, cluster, core, daemon))] to
[Actor[akka://HttpCluster/]]+[akka://HttpCluster/] from [Actor[akka.tcp://
HttpCluster@10.9.0.2:2551/system/cluster/core/daemon/joinSeedNodeProcess-1#400123135]()]
INFO | jvm 1| 2014/07/21 22:37:45 | 2014-07-21 22:37:45,908 DEBUG
[EndpointWriter] sending message RemoteMessage: [InitJoinNack(akka.tcp://
HttpCluster@10.9.0.1:2551)] to [Actor[akka.tcp://
HttpCluster@10.9.0.2:2551/system/cluster/core/daemon/joinSeedNodeProcess-1#400123135]
]+[akka.tcp://
HttpCluster@10.9.0.2:2551/system/cluster/core/daemon/joinSeedNodeProcess-1]
from [Actor[akka://HttpCluster/system/cluster/core/daemon#-1453271007]]
on both of the nodes. I have no ide what those InitJoinNack means, but I
guess its not acknowledged.
The JMX console shows:
#mbean = akka:type=Cluster:
ClusterStatus = {
self-address: akka.tcp://HttpCluster@10.9.0.2:2551,
members: [
],
unreachable: [
]
}
;
and
ClusterStatus = {
self-address: akka.tcp://HttpCluster@10.9.0.1:2551,
members: [
],
unreachable: [
]
}
;
respectively on the nodes.
If I change the order ot seed nodes on 10.9.0.1 to
seed-nodes = [
akka.tcp://HttpCluster@10.9.0.1:2551,
akka.tcp://HttpCluster@10.9.0.2:2551
]
then start the node 10.9.0.1 first and 10.9.0.2 second, everything works
as expected: JMX shows:
#mbean = akka:type=Cluster:
ClusterStatus = {
self-address: akka.tcp://HttpCluster@10.9.0.1:2551,
members: [
{
address: akka.tcp://HttpCluster@10.9.0.1:2551,
status: Up
}
],
unreachable: [
]
}
;
after the first node is started, and
ClusterStatus = {
self-address: akka.tcp://HttpCluster@10.9.0.1:2551,
members: [
{
address: akka.tcp://HttpCluster@10.9.0.1:2551,
status: Up
},
{
address:
Re: [akka-user] expermental http client
Thanks. I will just have to wait for the official client :) -- 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 - seed nodes can not connect to each other and split head is detected when the forstmost seed node gets disconnected. (Akka 2,3,2)
On Tue, Jul 22, 2014 at 10:45:41AM +0200, Akka Team wrote:
Hi Eugene
So you should have the same node as the first one in the seed node list on
both machines.
Okay, that's clear. So in some case I need to have some dummy cluster node
acting as a seed node and deployed onto a component of the application which
starts first.
If you have the proper order, after initial startup you can restart any of
the nodes. You said that you have a problem even in this case, can you post
some log snippets to show what happens in that case?
Nothing in the logs. It seems that the nodes aren't seeing each other at all.
I've posted the ClusterStatus from JMX - the nodes are not in the cluster
anymore - each lists itself in the list of members (see below - 10.9.0.1 is
the first seed node, and 10.9.0.2 is the second one, after the cluster is
initialized and the node 10.9.0.1 is restarted - it never sees 10.9.0.2)
ClusterStatus = {
self-address: akka.tcp://HttpCluster@10.9.0.2:2551,
members: [
{
address: akka.tcp://HttpCluster@10.9.0.2:2551,
status: Up
}
],
unreachable: [
]
}
;
and
ClusterStatus = {
self-address: akka.tcp://HttpCluster@10.9.0.1:2551,
members: [
{
address: akka.tcp://HttpCluster@10.9.0.1:2551,
status: Up
}
],
unreachable: [
]
}
;
Btw, you get an InitJoinNack if you try to join a member to a node that has
been not fully initialized yet. Are you sure you are restarting the first
node after the second has been fully initialized?
Yes, the nodes are up at the moment of the association.
Thanks!
--
Eugene N Dzhurinsky
pgp8x2f9GPQh3.pgp
Description: PGP signature
Re: [akka-user] Akka cluster - seed nodes can not connect to each other and split head is detected when the forstmost seed node gets disconnected. (Akka 2,3,2)
On Tue, Jul 22, 2014 at 4:25 PM, Eugene Dzhurinsky jdeve...@gmail.com
wrote:
On Tue, Jul 22, 2014 at 10:45:41AM +0200, Akka Team wrote:
Hi Eugene
So you should have the same node as the first one in the seed node list
on
both machines.
Okay, that's clear. So in some case I need to have some dummy cluster
node
acting as a seed node and deployed onto a component of the application
which
starts first.
It does not need to be exactly the first one to be started, but it needs to
be available at the first startup of the cluster until other seed-nodes
become fully initialized. After this initial phase is finished the first
seed node is no longer necessary to be available.
If you have the proper order, after initial startup you can restart any
of
the nodes. You said that you have a problem even in this case, can you
post
some log snippets to show what happens in that case?
Nothing in the logs. It seems that the nodes aren't seeing each other at
all.
Well, receiving an InitJoinNack (as seen in the logs) means that they see
each other, but the other node refuses the join. This means that the second
seed node is not fully up yet. I suspect that you shut down the first seed
node too early before the second one considers himself fully up and
therefore will not allow the restarted first node to join. Can you try it
again, but restarting the first node later?
If the problem is still present, can you provide a minimized example that I
can check?
-Endre
I've posted the ClusterStatus from JMX - the nodes are not in the cluster
anymore - each lists itself in the list of members (see below - 10.9.0.1 is
the first seed node, and 10.9.0.2 is the second one, after the cluster is
initialized and the node 10.9.0.1 is restarted - it never sees 10.9.0.2)
ClusterStatus = {
self-address: akka.tcp://HttpCluster@10.9.0.2:2551,
members: [
{
address: akka.tcp://HttpCluster@10.9.0.2:2551,
status: Up
}
],
unreachable: [
]
}
;
and
ClusterStatus = {
self-address: akka.tcp://HttpCluster@10.9.0.1:2551,
members: [
{
address: akka.tcp://HttpCluster@10.9.0.1:2551,
status: Up
}
],
unreachable: [
]
}
;
Btw, you get an InitJoinNack if you try to join a member to a node that
has
been not fully initialized yet. Are you sure you are restarting the first
node after the second has been fully initialized?
Yes, the nodes are up at the moment of the association.
Thanks!
--
Eugene N Dzhurinsky
--
Akka Team
Typesafe - The software stack for applications that scale
Blog: letitcrash.com
Twitter: @akkateam
--
Read the docs: http://akka.io/docs/
Check the FAQ:
http://doc.akka.io/docs/akka/current/additional/faq.html
Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups Akka
User List group.
To unsubscribe from this group and stop receiving emails from it, send an email
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
[akka-user] Waiting on multiple Akka messages
I recently posted this question on Stack Overflow, as Waiting on multiple Akka FSM messages https://stackoverflow.com/questions/24872342/waiting-on-multiple-akka-fsm-messages. I got one great answer (reproduced below) from Konrad 'ktoso' Malawski. I'm reposting it on this list just in case there are any other methods for distinguishing between responses. My question: I have an Akka FSM actor that runs the following pseudocode after receiving a message while in ReadyState lookupA ! Wrapper(Lookup(A)) lookupB ! Wrapper(Lookup(B)) lookupC ! Wrapper(Lookup(C)) goto(LookingUpDataState) using DataFound(a = None, b = None, c = None) The actor then waits for responses which can be either FullResult[T] (extending ServiceResult[T]) or Empty (extending ServiceResult[Nothing]). Successful lookup results are used to populate the DataFound instance's fields and Empty lookup results result in a logged error message and the termination of the actor. My question is this: how can I determine which lookup failed, so that I can log the failure or fallback to a default value? All I can think of is examining the sender's ActorRef (hacky) or adding a unique ID field to all messages (high overhead). This is a simple problem to solve using Ask's and Futures. Does an idiomatic Akka solution exist? Konrad's answer: There's a few patterns you could use here. You will have to resort to one of these options listed below. They all have some trade off (and benchmarking is king anyway), but I've listed them in order of bad to good, - performing the queries in-order, so send A, wait for A response, send B ... But that's *horrible* - as in needlessly sequential. - use the ask pattern, so you'll spin up (internally that's how ask works) 3 actors, and they'll complete their own future. So this also has some cost on the sender because it has to start these special purpose actors (smaller than a normal actor, but still). - Yes, you'll need to tag these messages somehow. So you'd send some ID and the response must contain the same ID, then you know it's oh it's the response for A etc. I would argue that this is the recommended way to go here. - there's a *contrib* pattern available in Akka called the Aggregator, which is designed for this use case, so you might want to check it out: http://doc.akka.io/docs/akka/2.3.4/contrib/aggregator.htmlHowever if you like it or not is very much a matter of personal taste I guess. My personal favourite (we tend to avoid ask in general) would be tagging the requests in an Envelope(id, payload) so the responses can also be wrapped in such Envelope(id, response). If you decide to call these simply envelope or more with domain terminology is up to you. Hope this helps. -- 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] Waiting on multiple Akka messages
Thanks for the detailed reply on SO! We're almost certainly going with your recommended method of tagging requests and responses with an id field, but I thought a wider discussion could be interesting. On Tuesday, July 22, 2014 10:59:41 AM UTC-4, Konrad Malawski wrote: You're welcome :-) Happy hakking! On Tue, Jul 22, 2014 at 4:53 PM, Paul Kinsky pki...@gmail.com javascript: wrote: I recently posted this question on Stack Overflow, as Waiting on multiple Akka FSM messages https://stackoverflow.com/questions/24872342/waiting-on-multiple-akka-fsm-messages. I got one great answer (reproduced below) from Konrad 'ktoso' Malawski. I'm reposting it on this list just in case there are any other methods for distinguishing between responses. My question: I have an Akka FSM actor that runs the following pseudocode after receiving a message while in ReadyState lookupA ! Wrapper(Lookup(A)) lookupB ! Wrapper(Lookup(B)) lookupC ! Wrapper(Lookup(C)) goto(LookingUpDataState) using DataFound(a = None, b = None, c = None) The actor then waits for responses which can be either FullResult[T] (extending ServiceResult[T]) or Empty (extending ServiceResult[Nothing]). Successful lookup results are used to populate the DataFound instance's fields and Empty lookup results result in a logged error message and the termination of the actor. My question is this: how can I determine which lookup failed, so that I can log the failure or fallback to a default value? All I can think of is examining the sender's ActorRef (hacky) or adding a unique ID field to all messages (high overhead). This is a simple problem to solve using Ask's and Futures. Does an idiomatic Akka solution exist? Konrad's answer: There's a few patterns you could use here. You will have to resort to one of these options listed below. They all have some trade off (and benchmarking is king anyway), but I've listed them in order of bad to good, - performing the queries in-order, so send A, wait for A response, send B ... But that's *horrible* - as in needlessly sequential. - use the ask pattern, so you'll spin up (internally that's how ask works) 3 actors, and they'll complete their own future. So this also has some cost on the sender because it has to start these special purpose actors (smaller than a normal actor, but still). - Yes, you'll need to tag these messages somehow. So you'd send some ID and the response must contain the same ID, then you know it's oh it's the response for A etc. I would argue that this is the recommended way to go here. - there's a *contrib* pattern available in Akka called the Aggregator, which is designed for this use case, so you might want to check it out: http://doc.akka.io/docs/akka/2.3.4/contrib/aggregator.htmlHowever if you like it or not is very much a matter of personal taste I guess. My personal favourite (we tend to avoid ask in general) would be tagging the requests in an Envelope(id, payload) so the responses can also be wrapped in such Envelope(id, response). If you decide to call these simply envelope or more with domain terminology is up to you. Hope this helps. -- 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 javascript:. To post to this group, send email to akka...@googlegroups.com javascript:. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout. -- Cheers, Konrad 'ktoso' Malawski hAkker @ Typesafe http://typesafe.com -- 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 Cluster 2.3.4 does not mark died nodes Unreachable
I run cluster of Actor nodes on AWS Autoscaling groups. Before migration to version 2.3.4, cluster discovery worked just fine: new instances join cluster, terminated machines switched to Unreachable and Down state. After switching to 2.3.4, I see that terminated instances never leave a cluster. I see a lot of remoting errors, but node status never changed. : 17:46:28.960UTC WARN Remoting Remoting - Tried to associate with unreachable remote address [akka.tcp://loadtes...@ec2-54-80-144-23.compute-1.amazonaws.com:2552]. Address is now gated for 5000 ms, all messages to this address will be delivered to dead letters. Reason: connection timed out: ec2-54-80-144-23.compute-1.amazonaws.com/10.238.203.225:2552 17:46:37.760UTC WARN akka.remote.EndpointWriter akka.tcp://loadtes...@ec2-54-204-110-59.compute-1.amazonaws.com:2552/system/endpointManager/reliableEndpointWriter-akka.tcp%3A%2F%2FLoadTester%40ec2-54-211-16-150.compute-1.amazonaws.com%3A2552-237/endpointWriter - AssociationError [akka.tcp://loadtes...@ec2-54-204-110-59.compute-1.amazonaws.com:2552] - [akka.tcp://loadtes...@ec2-54-211-16-150.compute-1.amazonaws.com:2552]: Error [Invalid address: akka.tcp://loadtes...@ec2-54-211-16-150.compute-1.amazonaws.com:2552] [ akka.remote.InvalidAssociation: Invalid address: akka.tcp://loadtes...@ec2-54-211-16-150.compute-1.amazonaws.com:2552 Caused by: akka.remote.transport.Transport$InvalidAssociationException: connection timed out: ec2-54-211-16-150.compute-1.amazonaws.com/10.225.5.195:2552 ] 17:46:37.760UTC WARN Remoting Remoting - Tried to associate with unreachable remote address [akka.tcp://loadtes...@ec2-54-211-16-150.compute-1.amazonaws.com:2552]. Address is now gated for 5000 ms, all messages to this address will be delivered to dead letters. Reason: connection timed out: ec2-54-211-16-150.compute-1.amazonaws.com/10.225.5.195:2552 17:46:44.960UTC WARN akka.remote.EndpointWriter akka.tcp://loadtes...@ec2-54-204-110-59.compute-1.amazonaws.com:2552/system/endpointManager/reliableEndpointWriter-akka.tcp%3A%2F%2FLoadTester%40ec2-54-225-3-180.compute-1.amazonaws.com%3A2552-238/endpointWriter - AssociationError [akka.tcp://loadtes...@ec2-54-204-110-59.compute-1.amazonaws.com:2552] - [akka.tcp://loadtes...@ec2-54-225-3-180.compute-1.amazonaws.com:2552]: Error [Invalid address: akka.tcp://loadtes...@ec2-54-225-3-180.compute-1.amazonaws.com:2552] [ akka.remote.InvalidAssociation: Invalid address: akka.tcp://loadtes...@ec2-54-225-3-180.compute-1.amazonaws.com:2552 Caused by: akka.remote.transport.Transport$InvalidAssociationException: connection timed out: ec2-54-225-3-180.compute-1.amazonaws.com/10.236.143.47:2552 ] 17:46:44.960UTC WARN Remoting Remoting - Tried to associate with unreachable remote address [akka.tcp://loadtes...@ec2-54-225-3-180.compute-1.amazonaws.com:2552]. Address is now gated for 5000 ms, all messages to this address will be delivered to dead letters. Reason: connection timed out: ec2-54-225-3-180.compute-1.amazonaws.com/10.236.143.47:2552 17:46:48.558UTC WARN akka.remote.EndpointWriter akka.tcp://loadtes...@ec2-54-204-110-59.compute-1.amazonaws.com:2552/system/endpointManager/reliableEndpointWriter-akka.tcp%3A%2F%2FLoadTester%40ec2-50-16-180-25.compute-1.amazonaws.com%3A2552-239/endpointWriter - AssociationError [akka.tcp://loadtes...@ec2-54-204-110-59.compute-1.amazonaws.com:2552] - [akka.tcp://loadtes...@ec2-50-16-180-25.compute-1.amazonaws.com:2552]: Error [Invalid address: akka.tcp://loadtes...@ec2-50-16-180-25.compute-1.amazonaws.com:2552] [ akka.remote.InvalidAssociation: Invalid address: akka.tcp://loadtes...@ec2-50-16-180-25.compute-1.amazonaws.com:2552 Caused by: akka.remote.transport.Transport$InvalidAssociationException: connection timed out: ec2-50-16-180-25.compute-1.amazonaws.com/10.239.45.179:2552 ] 17:46:48.558UTC WARN Remoting Remoting - Tried to associate with unreachable remote address [akka.tcp://loadtes...@ec2-50-16-180-25.compute-1.amazonaws.com:2552]. Address is now gated for 5000 ms, all messages to this address will be delivered to dead letters. Reason: connection timed out: ec2-50-16-180-25.compute-1.amazonaws.com/10.239.45.179:2552 17:46:50.759UTC WARN akka.remote.EndpointWriter akka.tcp://loadtes...@ec2-54-204-110-59.compute-1.amazonaws.com:2552/system/endpointManager/reliableEndpointWriter-akka.tcp%3A%2F%2FLoadTester%40ec2-54-80-144-23.compute-1.amazonaws.com%3A2552-240/endpointWriter - AssociationError [akka.tcp://loadtes...@ec2-54-204-110-59.compute-1.amazonaws.com:2552] - [akka.tcp://loadtes...@ec2-54-80-144-23.compute-1.amazonaws.com:2552]: Error [Invalid address: akka.tcp://loadtes...@ec2-54-80-144-23.compute-1.amazonaws.com:2552] [ akka.remote.InvalidAssociation: Invalid address: akka.tcp://loadtes...@ec2-54-80-144-23.compute-1.amazonaws.com:2552 Caused by: akka.remote.transport.Transport$InvalidAssociationException: connection timed out:
[akka-user] [2.2.4] Lots of AssociationErrors in the logs during testing
This is an issue I've been dealing with for a while now. I was hoping that
the fix for log-remote-lifecycle-events = off in 2.2.4 would've fixed it
but it hasn't.
During multi-JVM cluster testing, we remove and re-add a node to test
failure handling:
testConductor.exit(BackendConfig.analytics, 0).await
This leads to hundreds (if not thousands) of these statements in our logs:
[JVM-4] [ERROR] [07/22/2014 11:59:29.906] [PipelineSpec-akka.conspire-
dispatchers.remote-dispatcher-14]
[akka://PipelineSpec/system/endpointManager/reliableEndpointWriter-akka.tcp%3A%2F%2FPipelineSpec%40127.0.0.1%3A55506-3/endpointWriter]
AssociationError [akka.tcp://PipelineSpec@127.0.0.1:55505] -
[akka.tcp://PipelineSpec@127.0.0.1:55506]: Error [Association failed with
[akka.tcp://PipelineSpec@127.0.0.1:55506]] [
[JVM-4] akka.remote.EndpointAssociationException: Association failed with [
akka.tcp://PipelineSpec@127.0.0.1:55506]
[JVM-4] Caused by: akka.remote.transport.netty.
NettyTransport$$anonfun$associate$1$$anon$2: Connection refused: /127.0.0.1:
55506
[JVM-4] ]
Relevant config values:
akka {
loglevel = INFO
stdout-loglevel = OFF
log-dead-letters = off
log-dead-letters-during-shutdown = off
actor {
provider = akka.cluster.ClusterActorRefProvider
debug {
receive = off
autoreceive = off
lifecycle = off
fsm = on
}
}
remote {
log-remote-lifecycle-events = off
}
}
Is there any way to shut that actor up? It stops once that node is
quarantined at least.
--
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 cluster: stopping actor doesn't remove sharding entry
Hi. First of all thanks for your time on this. I'm using Akka version 2.3.4 (Java). I've stopped an actor getContext().stop(getSelf()); and when I look at the rebalance() method in my AllocationStrategy I still see the entry in the sharding region corresponding to the stopped actor. I'm using a consistent hash scheme so the actor has a one to one correspondence to a particular sharding entry. I expected that after the stop() method the cluster should remove the entry from the list. Is this the expected behaviour? The problem is that if we created a lot of actors (corresponding to a particular sharding value) we got many useless (?) entries in the maps processed by the allocation strategy. I'm writing a start/stop routing for the cluster so I'd like to use the info in the sharding strategy to produce a list with only the active objects in the cluster. The alternative is that I manage a list of active entries by myself, of course, using a kind of pub/sub actor. Many thanks again for your help. Edu. -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Re: actor making long http call
Konrad, thanks for the reply and input. I agree that I should just test it out and see what / if anything gets clogged and use introspection tools to find out what is going on. Cheers, Greg On Monday, July 21, 2014 2:33:08 AM UTC-7, Konrad Malawski wrote: Hi guys, That's an interesting area you work in Greg :-) You seem to already use work-pulling, so while small tweaks can be done that seams the way to go for me. And don't worry too much about the downloads until they actually clog something - you can look at the threads using visualvm to get a brief overview if they're running as expected (nio). On Sat, Jul 19, 2014 at 6:57 PM, Soumya Simanta soumya@gmail.com javascript: wrote: You can have a parent actor that spawns multiple child actors (in this case 3). Each of this child actor is responsible for send the requests to the external service and waiting for the result. Ideally I would recommend using Spray client to handle this. Can the server side of the service maintain stream state ? (i.e., can it resume in case of an error, network disconnect etc). Now in the parent actor you can have two states ( def canHandleMore : Receive and def noMoreRequests: Receive) and keep a count of how many child actors are created from the canHandleMore state. Change the state of the parent actor by using become noMoreRequests when you reach your threshold (in this case 3). The workers should similarly send a message back to the parent when they are done and the parent can go back to become canHandleMore. You can return a message back to the client from the noMoreRequest state. On Friday, July 18, 2014 2:54:45 AM UTC-4, Greg Flanagan wrote: I have an actor that makes an http call that can take a long time to complete (i.e. 10 - 30 minutes). I only want to be hitting the service at most 3 at once so I don't want the actors to consume more messages until the current call is finished. I've got it all working great using the work pulling pattern with three worker nodes. My question, or really concern is, is it a good idea to keep an http connection open for so long? are there any implications for doing so? what kind of things should I look out for? Since I'm using NIO for the http call I shouldn't be using up a thread most of the time. I'm use to http calls finishing on the order or milliseconds not minutes. Cheers, Greg -- 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 javascript:. To post to this group, send email to akka...@googlegroups.com javascript:. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout. -- Cheers, Konrad 'ktoso' Malawski hAkker @ Typesafe http://typesafe.com -- 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.
