Re: [akka-user] ClusterClient and getting response from cluster
On Sat, May 31, 2014 at 4:56 AM, Eugene Dzhurinsky jdeve...@gmail.com wrote: Hello! I have a cluster with set of FSM actors deployed there. I also have a *ClusterClient* configured to send a message to the dedicated actor service, which then processes the passed data and now it has to *respond to the sender*. Like, actor *Client* sends a message to the cluster, which is routed through the *ClusterClient* and is delivered to the *WorkerFSM*, now the *WorkerFSM* processes the message and has to send the result back to the *Client*. But the *sender()* method in *WorkerFSM* will return the reference to *ClusterClient* - not *Client.* That is surprising. The ClusterClient is using forward so the original sender is passed on to the ClusterReceptionist, which creates a response tunnel actor. Your WorkerFSM should see that response tunnel as sender. It has the same name as the client actor, but is a child of the ClusterReceptionist. When you reply to that sender the message will be routed back to that response tunnel, and then back to the client. The reason for this is to avoid inbound connections from other cluster nodes to the client. Are you using Akka version 2.3.3? /Patrik How do I know which actor has been sending the message to the cluster? 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 http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout. -- Patrik Nordwall Typesafe http://typesafe.com/ - Reactive apps on the JVM Twitter: @patriknw http://typesafe.com/go-reactive-activator-contest -- 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: Rebalancing shard entries of different types
Shard rebalancing, as everything else, is managed for each entry type name independently of other entry type names. There is one ShardCoordinator per type name. /Patrik On Sat, May 31, 2014 at 11:45 PM, Luis Medina lu4...@gmail.com wrote: Oops, in the second example I meant to say that Shard 1 has 3 entries running... not 4. -- 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 http://typesafe.com/ - Reactive apps on the JVM Twitter: @patriknw http://typesafe.com/go-reactive-activator-contest -- 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: Rebalancing shard entries of different types
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 http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Re: Rebalancing shard entries of different types
Given that fact, I went ahead and implemented a ShardAllocationStrategy that
takes into account different entry types for figuring out what nodes to
create new entries in. First, I just want to describe the use-case that led
to me implementing this.
I'm working on a pipeline that will ingest real-time social media data and
do processing on it. This pipeline will be getting this data from different
streams (ie. one for Twitter, one for Facebook, etc). As such, I wanted to
take advantage of the high availability and scalability features that
Akka's clustering feature provides. I considered using singletons for this
except that this would create a single point of failure in that if my
eldest node goes down I lose all of my data streams until they're able to
start up on a different node. Using singletons would have also created a
resource bottleneck on the eldest node. As such, I decided to make use of
sharding in order to distribute all of my different streams throughout my
cluster. While sharding provides the distribution that singletons lack, it
only works when sharding the same entry type (as you Patrik pointed out and
I came to find out). This presented a problem since in my case an entry
corresponded to a stream and no 2 streams were really the same. I did try
doing something like this:
ClusterSharding.get(system).start(Feed, StreamActor.props(), new
MessageExtractor());
where instead of initializing the stream through its constructor, I would
initialize it by passing in the necessary arguments through a series of
message using .tell(). This appeared to be promising at first until I
reached a point where regardless of how generic I made my interfaces there
was always something that a 3rd party library required that couldn't be
abstracted from the Objects that Akka receives which left me with a bunch
of unchecked cast warnings (which for me are a no no for me). This led
to my only other option which was to implement my own
ShardingAllocationStrategy that could work across different entry types.
This looks like this:
public class FeedShardAllocationStrategy implements
ShardCoordinator.ShardAllocationStrategy {
private HashMapString, Long shardCount;
public FeedShardAllocationStrategy(HashMapString, Long shardCount) {
Validate.notNull(shardCount, shardCount must not be null.);
this.shardCount = shardCount;
}
@Override
public ActorRef allocateShard(ActorRef actorRef, String s,
MapActorRef, IndexedSeqString actorRefIndexedSeqMap) {
synchronized (this) {
IteratorActorRef shardRegions =
actorRefIndexedSeqMap.keysIterator();
ActorRef leastPopulatedShardRegion = new
ShardCoordinator.LeastShardAllocationStrategy(1, 3).allocateShard(actorRef,
s, actorRefIndexedSeqMap);
long leastPopulatedShardCount = Long.MAX_VALUE;
while (shardRegions.hasNext()) {
ActorRef shardRegion = shardRegions.next();
String address = shardRegion.path().address().toString();
if (shardCount.get(address) == null) {
leastPopulatedShardCount = 0;
leastPopulatedShardRegion = shardRegion;
} else {
long shardCount = this.shardCount.get(address);
if (shardCount leastPopulatedShardCount) {
leastPopulatedShardCount = shardCount;
leastPopulatedShardRegion = shardRegion;
}
}
}
shardCount.put(leastPopulatedShardRegion.path().address().toString(),
leastPopulatedShardCount + 1);
return leastPopulatedShardRegion;
}
}
@Override
public SetString rebalance(scala.collection.immutable.MapActorRef,
scala.collection.immutable.IndexedSeqString actorRefIndexedSeqMap,
SetString stringSet) {
return new HashSet();
}
}
As you can see in the allocateShard method, I use a HashMap to keep track
of the number of shards that have been created using their address. By
default I assign my leastPopulatedShardRegion to be whatever ShardRegion
the LeastShardAllocationStrategy provides. For the rebalance method,
since I don't want to have my streams stop in a re-balance, I return an
empty Set in order to prevent this. This actually works quite well with my
requirements as long as each stream shard implements the same instance of
the ShardAllocationStrategy. For example doing:
ShardCoordinator.ShardAllocationStrategy shardAllocationStrategy = new
FeedShardAllocationStrategy(new HashMap());
ClusterSharding.get(system).start(TwitterStream, StreamActor.props(new
TwitterStreamManager()), new MessageExtractor(), shardAllocationStrategy);
ClusterSharding.get(system).start(FacebookStream, StreamActor.props(new
FacebookStreamManager()), new MessageExtractor(), shardAllocationStrategy);
ClusterSharding.get(system).start(GooglePlusStream,
Re: [akka-user] Cluster, sharding and roles
Hi Eduardo, The ClusterSharding extension supports configuration of one role to use a subset of nodes, but that is not what you are looking for. Instead of using the ClusterSharding extension you may start the actors yourself and thereby specify the roles. See: ShardCoordinatorSupervisor.props ShardCoordinator.props ShardRegion.props Note that the ShardCoordinatorSupervisor is supposed be started with a ClusterSingletonManager. See here: https://github.com/akka/akka/blob/v2.3.3/akka-contrib/src/main/scala/akka/contrib/pattern/ClusterSharding.scala#L360 Cheers, Patrik On Fri, May 30, 2014 at 1:20 PM, Eduardo Fernandes edu...@gmail.com wrote: Hi all. Probably this is a silly question but I couldn't find any clear answer in the group or docs. Suppose I have a cluster with 4 nodes with 2 roles (2 node instances per role). How could I create two shardings, each one sending messages to the nodes belonging to a particular role? The idea is add a new node with a particular role and let the cluster sharding distribute the work among all nodes belonging to that role. I suppose I could create two sharding regions, one per role, and assign the sharding to a role in some way? I'm using Java and Akka 2.3.3. Many thanks for your help. Eduardo. -- 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 http://typesafe.com/ - Reactive apps on the JVM Twitter: @patriknw http://typesafe.com/go-reactive-activator-contest -- 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] Encapsulating very long running processes that must be cancellable
I am running Scala Play 2.2.2 as the front end of for Java library. Certain calls into the java library are extremely long running (order of hours). I am looking for some mechanism to be able to run these calls asynchronously but to also be able to cancel them once they have started, essentially killing the thread that is running them. Akka actors don't seem to fit the bill as as soon as I make the service call, the actor mailbox queue will block until the call is over leaving it unresponsive to Kill messages. I have been looking for an implementation of cancellable futures, but have not found anything that will deterministically kill the Future. The closest that I have come is a gist written by Viktor some time ago (https://gist.github.com/viktorklang/5409467) but I am unable to figure out how to use it correctly. The (Future[A] - A) in the type is completely throwing me off and I have no idea how to pass in my actual workload. Can anyone offer any advice for this situation? I would prefer to be able to use some kind of high level primitive rather than having to fall back to using Callable[T]. -- 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 connection refused
I was clearly miss-configured.
I tried it again from the akka-sample-cluster-java activator template and
this has worked so I modified my configuration based on the word count
example.
And now things work.
Thanks
2014-05-29 8:12 GMT+01:00 Martynas Mickevičius
martynas.mickevic...@typesafe.com:
You have seed-nodes setting pointing to other node in the cluster. So
naturally when you first start either node it tries to connect to the other
one which has not been started yet. Thus the log message: Reason:
Connection refused: /10.xxx.xxx.xxx:15672
You can choose which node you want to start first and have its own address
in the seed-node list. This way the first node will start the cluster with
itself.
Then when you start the second node, it will try to connect to the first
one and will successfully join the cluster.
On Wed, May 28, 2014 at 6:03 PM, Johan Dindaine jojolapin...@gmail.com
wrote:
Hi,
I'm trying to connect two nodes together using akka-cluster and even if I
thought they were setup correctly, while trying to launch the application I
ran into connection problems.
[info] [WARN] [05/28/2014 16:50:09.017]
[ClusterSystem-akka.remote.default-remote-dispatcher-66] [Remoting] Tried
to associate with unreachable remote address
[akka.tcp://clustersys...@10.xxx.xxx.xxx:15672]. Address is now gated
for 5000 ms, all messages to this address will be delivered to dead
letters. Reason: Connection refused: /10.xxx.xxx.xxx:15672
I have got two nodes and they are configured to talk to each other
despite the connection problem:
On node A:
akka {
actor {
provider = akka.cluster.ClusterActorRefProvider
}
remote {
[*]
netty.tcp {
hostname = 10.yyy.yyy.yyy
port = 15699
}
}
cluster {
seed-nodes = [akka.tcp://clustersys...@10.xxx.xxx.xxx:15672]
}
}
And on node B
akka {
actor {
provider = akka.cluster.ClusterActorRefProvider
}
remote {
[*]
netty.tcp {
hostname = 10.xxx.xxx.xxx
port = 15672
}
}
cluster {
seed-nodes = [akka.tcp://clustersys...@10.yyy.yyy.yyy: 15699]
}
}
--
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.
--
Martynas Mickevičius
Typesafe http://typesafe.com/ – Reactive
http://www.reactivemanifesto.org/ Apps on the JVM
--
Read the docs: http://akka.io/docs/
Check the FAQ:
http://doc.akka.io/docs/akka/current/additional/faq.html
Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups
Akka User List group.
To unsubscribe from this group and stop receiving emails from it, send an
email to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
--
Read the docs: http://akka.io/docs/
Check the FAQ:
http://doc.akka.io/docs/akka/current/additional/faq.html
Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups Akka
User List group.
To unsubscribe from this group and stop receiving emails from it, send an email
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Cluster, sharding and roles
Many Thanks Patrik. I'm afraid that if I manage the actors directly I'll lose all the cluster benefits, include spreading out the mapping objectId - physical node. I think that I can reduce the problem to a case where I could avoid the creation of new actors in a particular node in the cluster and then, after all actors are virtually inactive, turn the node down. I don't know where is the mapping of entryId - physical node. Could I override the distribution logical somehow so I could control in which physical node the actor will be instantiated in the cluster? That would be perfect. I'd overridden the mapping using the sharding policy with AbstractShardAllocationStrategy inheriting from LeastShardAllocationStrategy but I couldn't find where adjust the way the cluster assign physical nodes to the particular sharding entry. Many thanks, Patrik, for your help. Regards. El lunes, 2 de junio de 2014 10:24:34 UTC+2, Patrik Nordwall escribió: Hi Eduardo, The ClusterSharding extension supports configuration of one role to use a subset of nodes, but that is not what you are looking for. Instead of using the ClusterSharding extension you may start the actors yourself and thereby specify the roles. See: ShardCoordinatorSupervisor.props ShardCoordinator.props ShardRegion.props Note that the ShardCoordinatorSupervisor is supposed be started with a ClusterSingletonManager. See here: https://github.com/akka/akka/blob/v2.3.3/akka-contrib/src/main/scala/akka/contrib/pattern/ClusterSharding.scala#L360 Cheers, Patrik -- 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: supervisor hierarchies
I strongly suggest reading through Effective Akka by Jamie Allen. He has nice example of front-end to back-end design. W dniu środa, 28 maja 2014 22:22:54 UTC+2 użytkownik Jabbar Azam napisał: Hello, I'm a bit confused with supervisor hierarchies. I've read the akka documentation and other books but hierarchy design is still not sinking in :( A simple, made up, example. I have a web front end with business logic and a database. converting this to akka I would create a web front end actor(a child of the user guardian), the business logic actor(a child of the front end actor), and a database actor( a child of the logic actor). I would add one more actor, a database supervisor between the database actor and the busniess logic actor. I keep thinking this is wrong. I have the urge to make the database supervisor actor a child of the user guardian. I'm not sure which approach is best. Does anybody have any suggestions? -- 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] Cluster, sharding and roles
On Mon, Jun 2, 2014 at 1:10 PM, Eduardo Fernandes edu...@gmail.com wrote: Many Thanks Patrik. I'm afraid that if I manage the actors directly I'll lose all the cluster benefits, include spreading out the mapping objectId - physical node. That would not change. The ClusterSharding extension is only creating exactly the same actors for you, in a convenient way. I understand that you think it is overwhelming to create these actors yourself, but it is possible (and the reason why the props methods are public). I think that I can reduce the problem to a case where I could avoid the creation of new actors in a particular node in the cluster and then, after all actors are virtually inactive, turn the node down. I don't know where is the mapping of entryId - physical node. Could I override the distribution logical somehow so I could control in which physical node the actor will be instantiated in the cluster? That would be perfect. I'd overridden the mapping using the sharding policy with AbstractShardAllocationStrategy inheriting from LeastShardAllocationStrategy but I couldn't find where adjust the way the cluster assign physical nodes to the particular sharding entry. Yes, that is done by the information returned by the AbstractShardAllocationStrategy. The passed in currentShardAllocations contains the ActorRefs of the ShardRegion actors, and you could use the addresses of these to decide which nodes to use. You must somehow correlate those addresses with the addresses of the cluster members if you want to use the cluster role information. The AbstractShardAllocationStrategy does not allocate locations for individual entries. That is always done on a group of entries, a.k.a. shard. You define the mapping between entry ids (messages) and shards in the MessageExtractor. /Patrik Many thanks, Patrik, for your help. Regards. El lunes, 2 de junio de 2014 10:24:34 UTC+2, Patrik Nordwall escribió: Hi Eduardo, The ClusterSharding extension supports configuration of one role to use a subset of nodes, but that is not what you are looking for. Instead of using the ClusterSharding extension you may start the actors yourself and thereby specify the roles. See: ShardCoordinatorSupervisor.props ShardCoordinator.props ShardRegion.props Note that the ShardCoordinatorSupervisor is supposed be started with a ClusterSingletonManager. See here: https://github.com/akka/ akka/blob/v2.3.3/akka-contrib/src/main/scala/akka/contrib/ pattern/ClusterSharding.scala#L360 Cheers, Patrik -- 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 http://typesafe.com/ - Reactive apps on the JVM Twitter: @patriknw http://typesafe.com/go-reactive-activator-contest -- 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] Cluster, sharding and roles
Many Thanks Patrik for your time! I'll check the addresses and let you know. With this info I could, theoretically, implements a smooth node shutdown. Best regards! On Mon, Jun 2, 2014 at 3:12 PM, Patrik Nordwall patrik.nordw...@gmail.com wrote: On Mon, Jun 2, 2014 at 1:10 PM, Eduardo Fernandes edu...@gmail.com wrote: Many Thanks Patrik. I'm afraid that if I manage the actors directly I'll lose all the cluster benefits, include spreading out the mapping objectId - physical node. That would not change. The ClusterSharding extension is only creating exactly the same actors for you, in a convenient way. I understand that you think it is overwhelming to create these actors yourself, but it is possible (and the reason why the props methods are public). I think that I can reduce the problem to a case where I could avoid the creation of new actors in a particular node in the cluster and then, after all actors are virtually inactive, turn the node down. I don't know where is the mapping of entryId - physical node. Could I override the distribution logical somehow so I could control in which physical node the actor will be instantiated in the cluster? That would be perfect. I'd overridden the mapping using the sharding policy with AbstractShardAllocationStrategy inheriting from LeastShardAllocationStrategy but I couldn't find where adjust the way the cluster assign physical nodes to the particular sharding entry. Yes, that is done by the information returned by the AbstractShardAllocationStrategy. The passed in currentShardAllocations contains the ActorRefs of the ShardRegion actors, and you could use the addresses of these to decide which nodes to use. You must somehow correlate those addresses with the addresses of the cluster members if you want to use the cluster role information. The AbstractShardAllocationStrategy does not allocate locations for individual entries. That is always done on a group of entries, a.k.a. shard. You define the mapping between entry ids (messages) and shards in the MessageExtractor. /Patrik Many thanks, Patrik, for your help. Regards. El lunes, 2 de junio de 2014 10:24:34 UTC+2, Patrik Nordwall escribió: Hi Eduardo, The ClusterSharding extension supports configuration of one role to use a subset of nodes, but that is not what you are looking for. Instead of using the ClusterSharding extension you may start the actors yourself and thereby specify the roles. See: ShardCoordinatorSupervisor.props ShardCoordinator.props ShardRegion.props Note that the ShardCoordinatorSupervisor is supposed be started with a ClusterSingletonManager. See here: https://github.com/akka/ akka/blob/v2.3.3/akka-contrib/src/main/scala/akka/contrib/ pattern/ClusterSharding.scala#L360 Cheers, Patrik -- 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 http://typesafe.com/ - Reactive apps on the JVM Twitter: @patriknw http://typesafe.com/go-reactive-activator-contest -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to a topic in the Google Groups Akka User List group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/akka-user/iP-w0OqBbHg/unsubscribe. To unsubscribe from this group and all its topics, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout. -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
[akka-user] Akka Microservice platform
Hey guys, I would like to run an idea by the fine Akka community - which is to discuss what it would take to turn Akka into a platform for building a network of microservices: each one independently redeployable and easy to change, yet through a common platform, take advantage of the distributed supervision, messaging and other goodies from Akka. Here are some characteristics of such a platform: - Service discovery - Supporting different kinds of data flow topologies - request response, as well as streaming data; pub-sub, etc. - Provide common abstractions for efficient data serialization - Support backpressure and flow control, to rate limit requests - Support easy scaling of each component, including routing of messages or requests to multiple instances - Enable easy testing of multiple services (for example, see Akka’s sbt-multi-jvm plugin) - A common platform for application metrics - Distributed message or request tracing, to help with visibility and debugging - Support polyglot development - it should be possible to develop services in different languages I think many of these are already provided by Akka, but I wanted to run through each one in more detail: *Service Discovery* Right now every actor talks to another actor location-transparently; however, when looking up an external ActorRef, one does have to know the mechanism, ie is it looking up in cluster, or remote, etc is it another actorsystem etc... (this could have changed in 2.2 and 2.3, but I'm not up to date :-p) What I'm looking for is a mechanism-independent way of looking up actors, remote or not. IE, I should just need to do this: val downstreamActorRef = System.lookupByName(service = tradingSystem, actor = masterTrader, ) Under the hood this looks up the actorRef using one of configurable mechanisms: - Akka Cluster is certainly one way to go, with nodes - At work we use Zookeeper and Curator. It would be great to make this platform support multiple discovery types *Data Flow Topology* - Akka is pretty good at this already, supporting many types of data flow. The only concern I see is that you have to define the flow via the like of routers and such, which are defined in the code on each node, rather than externally via say a message queue (see ZMQ, NSQ etc). This can be mitigated through DI and configuration and things like that, of course. *Data Serialization* If we are using native Akka protocol to talk over the wire, this is already really good. One defines case classes, and Akka transparently serializes them over the network if the actor is remote. This is one thing about Akka that really appeals to me. So the question is can we make this work for Play / Akka HTTP transparently as well? *Related - Polyglot support* How would a Ruby/Python/etc process talk to an Akka network? My thoughts: - Easiest way would be to have a way to automagically generate HTTP endpoints that includes case class serialization to/from JSON. Type classes to handle special data types. - Did you guys define the Akka binary protocol and keep it stable? Client libraries could then be written for different langauges, but this doesn't solve the problem of message format -- Java serialization and Chill/Kryo won't work. *Backpressure and Flow Control* Reactive streams looks really promising here. How it ties into routing, topologies, etc. I'd like to find out more about. Also, reactive streams won't work for request/response protocols. *Application Metrics and Tracing* Microservices means it becomes more and more important to figure out what's going on across many services. Fortunately there's a lot of work in this area; multiple third party libs to provide automatic metrics; somebody wrote an Akka integration with Twitter's Dapper-like tracing system, and I have written a tracing/graphing system as well. *Hot Reloads* I didn't include this in the list above, because the assumption is that with lots of independent small services, they will be naturally easier to redeploy. Some will argue that the JVM is heavyweight (actually I think a lightly loaded JVM app is under 50MB, which is very reasonable), and will want Erlang-style hot reloads of individual actors. This is really tricky area though. Anyways, I'd love to get the thoughts of the community about this idea of using Akka as a microservice platform. Thanks! Evan -- 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
[akka-user] Actor creation changes in Akka 2.3
So 2.3 introduced changes that wreck havoc with those of us using Akka from languages like Jruby. Namely being forced to pass java classes to props instead of being able to pass instances. stack overflow has a question about this that illustrates the problem: http://stackoverflow.com/questions/23373819/subclassing-a-java-class-in-jruby-with-generics-information I'm playing around with using IndirectActorProducer, although it looks like actorClass might be a problem there. I'm hoping someone has an idea on how to solve this. This is for an existing project with a large codebase, so I will go to dark places to solve this if I absolutely have to, I just don't want to do that:) Chris -- 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] Cluster, sharding and roles
It worked perfectly! Many thanks for your help! Regards. El lunes, 2 de junio de 2014 15:24:58 UTC+2, Eduardo Fernandes escribió: Many Thanks Patrik for your time! I'll check the addresses and let you know. With this info I could, theoretically, implements a smooth node shutdown. Best regards! -- 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: Persistent Queue using Akka (without Durable Mailboxes)
Hi Martin, I'm a little confused by your explanation. First you mention that ...the affected database records are entity-specific... and no indexes are touched. Hence, executing many Bookings in parallel causes no considerable performance issues. But then you say that All of the bookings are written to the same table in the database and when dozens of actors are trying to do so in parallel, this naturally causes locking issues on the database indexes and completely destroys performance. Are you saying that the first set of operations of updating an account with bookings is less intensive than your second operation of storing the bookings themselves? If so, how would splitting the work into 2 different actors help if they're both still accessing the database somewhat simultaneously (one actor updates the account information using the bookings and the other actor maintains the bookings themselves)? Regardless, I don't see anything wrong to using persistence the way that you intend. Essentially, the first actor sends the booking to a second actor which persists it. Once this second actor has successfully maintained the database (I'm assuming the database sends some sort of ok message), then you go ahead and delete said booking from the actor's journal before moving on to the next one. Seems like a pretty good use-case for persistence actually. -- 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: Cluster, sharding and roles
Hi Eduardo, I recently implemented my own version of a ShardAllocationStrategy and made use of the ShardRegion's addresses. I made a post about it here: https://groups.google.com/forum/#!topic/akka-user/7p_fkEFJqHw It doesn't solve your exact problem but maybe it will give you some ideas. Also, the code is in Java so if you're using Scala you might have to do a bit of translating. -- 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: Cluster, sharding and roles
Nice post! I'll use your concepts to implement the progressive scaling down. Many thanks for your info! On Mon, Jun 2, 2014 at 10:49 PM, Luis Medina lu4...@gmail.com wrote: Hi Eduardo, I recently implemented my own version of a ShardAllocationStrategy and made use of the ShardRegion's addresses. I made a post about it here: https://groups.google.com/forum/#!topic/akka-user/7p_fkEFJqHw It doesn't solve your exact problem but maybe it will give you some ideas. Also, the code is in Java so if you're using Scala you might have to do a bit of translating. -- 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] udp throughput
Hi,
I'm writing a very simple UDP server that echos messages back to a sender.
The sender tries to spam the server. When I run the client, I get a lot of
`Send(ByteString(..), NoAk(null))` responses. The UDP server literally
just echos the content back. It isn't doing any blocking compute.
Any ideas what I can do to get rid of these send failures? Code below.
Matthew
*import *java.net.InetSocketAddress*import *akka.actor.{Props,
ActorSystem, ActorRef, Actor}*import *akka.io.{UdpConnected, IO,
Udp}*import *akka.util.ByteString*import
*scala.collection.immutable.Queue*object *Client { *def *main(args:
Array[*String*]): Unit = {*println*(*Client starting up*)
*val **Array*(host, port) = args*val *system =
*ActorSystem*(*boo*)*val *ss = system.actorOf(*Props*(*new
*SendStuffConnected(*new *InetSocketAddress(host, port.toInt
*println*(*Client started*)*this *synchronized { *this
*wait 1000}*println*(*Sending messages*)*for*(i - 1 to
1) { ss ! *f**$*i*: Hi Mum
* ss ! *f**$*i*: Yo Dad
*}*println*(*Client sent message*) }}*case class
*SendStuffConnected(address: InetSocketAddress) *extends *Actor {
*import **context*.system *IO*(UdpConnected) !
UdpConnected.*Connect*(*self*, address) *def *receive: *Receive *=
awaitReady()*def *awaitReady(msgs: Queue[*String*] =
Queue.*empty*): *Receive *= {*case *UdpConnected.Connected =
*println*(*fClient awaiting ready with messages: **$*msgs**)
*context *become ready(sender()) msgs foreach (*self *! _)
*case *msg: *String *= *println*(*fClient stashing message:
**$*msg**) *context *become awaitReady(msgs enqueue msg) }
*def *ready(connection: ActorRef): *Receive *= {*case *msg:
*String *= *println*(*fClient sending message: **$*msg**)
connection ! UdpConnected.*Send*(*ByteString*(msg))*case
*UdpConnected.*Received*(data) = *println*(*fClient received
message **$*{data.utf8String}**)*case *d @
UdpConnected.Disconnect = connection ! d*case
*UdpConnected.Disconnected = *context *stop *self
**case *UdpConnected.*CommandFailed*(cmd) = cmd *match *{
*case *UdpConnected.*Send*(msg, ack) =
*println*(*fFailed sending : **$*{msg.utf8String}**)*case *_
= *println*(*fFailed with: **$*cmd**) }
*println*(*fFailed command: **$*cmd**)*case *unexpected =
*println*(*fClient got unexpected message: **$*unexpected**) } }
*import *java.net.InetSocketAddress*import *akka.actor.{Props,
ActorRef, ActorSystem, Actor}*import *akka.io.{Udp, IO}*object *Server
{ *def *main(args: Array[*String*]): Unit = {*println*(*Server
starting up*)*val **Array*(host, port) = args*val *system =
*ActorSystem*(*boo*)*val *rs = system.actorOf(*Props*(*new
*ReceiveStuff(*new *InetSocketAddress(host, port.toInt
*println*(*Server started*) }}*class *ReceiveStuff(address:
InetSocketAddress) *extends *Actor { *import **context*.system
*IO*(Udp) ! Udp.*Bind*(*self*, address) *override def *receive:
*Receive *= {*case *Udp.*Bound*(local) = *println*(*fServer
bound to **$*local**) *context *become ready(sender())*case
*unhandled = *println*(*fServer received unhandled message:
**$*unhandled**) } *def *ready(socket: ActorRef): *Receive *= {
*case *Udp.*Received*(data, remote) =*// println(fServer
received message: ${data.utf8String} from ${remote})
* socket ! Udp.*Send*(data, remote) *// echo
**case *Udp.Unbind = socket ! Udp.Unbind*case
*Udp.Unbound = *context *stop *self
**case *unhandled = *println*(*fServer received unhandled
message: **$*unhandled**) }}
--
Dr Matthew Pocock
Turing ate my hamster LTD
mailto: turingatemyhams...@gmail.com
Integrative Bioinformatics Group, School of Computing Science, Newcastle
University
mailto: matthew.poc...@ncl.ac.uk
gchat: turingatemyhams...@gmail.com
msn: matthew_poc...@yahoo.co.uk
irc.freenode.net: drdozer
skype: matthew.pocock
tel: (0191) 2566550
mob: +447535664143
--
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: Actor creation changes in Akka 2.3
On Monday, June 2, 2014 1:03:18 PM UTC-7, Chris Ochs wrote: So 2.3 introduced changes that wreck havoc with those of us using Akka from languages like Jruby. Namely being forced to pass java classes to props instead of being able to pass instances. stack overflow has a question about this that illustrates the problem: http://stackoverflow.com/questions/23373819/subclassing-a-java-class-in-jruby-with-generics-information I'm playing around with using IndirectActorProducer, although it looks like actorClass might be a problem there. I'm hoping someone has an idea on how to solve this. This is for an existing project with a large codebase, so I will go to dark places to solve this if I absolutely have to, I just don't want to do that:) Chris So I have something that runs. I basically created a class in java that implements IndirectActorProducer and passed it the factory object I have been using up till now. Then with an additional java interface I can call the ruby factory object to get my actor. But actorClass is an issue. What are the implications of the return value of actorClass not matching the actor's class? Currently I am returning the java class that the ruby classes inherit from, which usually UntypedActor. Chris -- 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 Microservice platform
Hey Evan, I'll bite... I guess my first question would be to ask for a more clear definition of what you mean by a microservice platform. It feels like this is trying to tackle too many different pieces of the ecosystem when some are already well-solved, while others just might not be appropriate to replace with something necessarily Akka-fied. Don't get me wrong, I love Akka, but a lot of this doesn't make a lot of sense to me. For example, why would you try to invent create a whole solution for handling polyglot environments when the microservice approach already handles this rather well using RESTful endpoints and/or queue-based solutions. Akka fits in very well with both of these, so trying to find some magic bullet to support it beyond this seems like a losing proposition. Can you try to clarify what you are envisioning? ~thomas On Monday, June 2, 2014 8:51:06 AM UTC-7, Evan Chan wrote: Hey guys, I would like to run an idea by the fine Akka community - which is to discuss what it would take to turn Akka into a platform for building a network of microservices: each one independently redeployable and easy to change, yet through a common platform, take advantage of the distributed supervision, messaging and other goodies from Akka. Here are some characteristics of such a platform: - Service discovery - Supporting different kinds of data flow topologies - request response, as well as streaming data; pub-sub, etc. - Provide common abstractions for efficient data serialization - Support backpressure and flow control, to rate limit requests - Support easy scaling of each component, including routing of messages or requests to multiple instances - Enable easy testing of multiple services (for example, see Akka’s sbt-multi-jvm plugin) - A common platform for application metrics - Distributed message or request tracing, to help with visibility and debugging - Support polyglot development - it should be possible to develop services in different languages I think many of these are already provided by Akka, but I wanted to run through each one in more detail: *Service Discovery* Right now every actor talks to another actor location-transparently; however, when looking up an external ActorRef, one does have to know the mechanism, ie is it looking up in cluster, or remote, etc is it another actorsystem etc... (this could have changed in 2.2 and 2.3, but I'm not up to date :-p) What I'm looking for is a mechanism-independent way of looking up actors, remote or not. IE, I should just need to do this: val downstreamActorRef = System.lookupByName(service = tradingSystem, actor = masterTrader, ) Under the hood this looks up the actorRef using one of configurable mechanisms: - Akka Cluster is certainly one way to go, with nodes - At work we use Zookeeper and Curator. It would be great to make this platform support multiple discovery types *Data Flow Topology* - Akka is pretty good at this already, supporting many types of data flow. The only concern I see is that you have to define the flow via the like of routers and such, which are defined in the code on each node, rather than externally via say a message queue (see ZMQ, NSQ etc). This can be mitigated through DI and configuration and things like that, of course. *Data Serialization* If we are using native Akka protocol to talk over the wire, this is already really good. One defines case classes, and Akka transparently serializes them over the network if the actor is remote. This is one thing about Akka that really appeals to me. So the question is can we make this work for Play / Akka HTTP transparently as well? *Related - Polyglot support* How would a Ruby/Python/etc process talk to an Akka network? My thoughts: - Easiest way would be to have a way to automagically generate HTTP endpoints that includes case class serialization to/from JSON. Type classes to handle special data types. - Did you guys define the Akka binary protocol and keep it stable? Client libraries could then be written for different langauges, but this doesn't solve the problem of message format -- Java serialization and Chill/Kryo won't work. *Backpressure and Flow Control* Reactive streams looks really promising here. How it ties into routing, topologies, etc. I'd like to find out more about. Also, reactive streams won't work for request/response protocols. *Application Metrics and Tracing* Microservices means it becomes more and more important to figure out what's going on across many services. Fortunately there's a lot of work in this area; multiple third party libs to provide automatic metrics; somebody wrote an Akka integration with Twitter's Dapper-like tracing system, and I
Re: [akka-user] [akka-stream] how to handle Future
Hi Benoit, in the upcoming 0.3 release there is a .mapFuture combinator that lets you transform elements asynchronously. Concerning the ActorSystem shutdown I do not understand your question, can you rephrase? Regards, Roland 27 maj 2014 kl. 21:27 skrev benq benoit.quart...@gmail.com: Hi, How should Future be handled in akka-stream? For example, if one step of a Flow is an http request, when and where should the ActorSystem be shutdown? benq -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout. Dr. Roland Kuhn Akka Tech Lead Typesafe – Reactive apps on the JVM. twitter: @rolandkuhn -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] akka-remote (non-clustered) quarantines and general best practices
Hi Steven, thanks for this write-up, your analysis is thorough and correct on all counts. Remoting needs to use a simplistic approach to the coroner problem (i.e. when to declare another system “dead”—and zombies are not tolerated), which is mostly just a timeout that you should set high enough to avoid false positives given your expected outages (network and GC). Using a dedicated (minimal) ActorSystem for the remoting should be the optimal solution for your use-case, the overhead is a few hundred milliseconds for starting it up plus its default dispatcher (which then should run the remoting etc.), saving the remoting dispatcher on the heavy local ActorSystem behind it. The added benefit you note is that you can then reconfigure the remoting part of the application at runtime. One thing to watch out for is that you don’t accidentally share an ActorRef from the local system in or with a remote message—including sender()—because that can of course not work if the originating system does not have remoting enabled. The symptom would be dropped messages. Regards, Roland 23 maj 2014 kl. 20:27 skrev Steven Scott ste...@codemettle.com: I've been slowly migrating an application to Akka since scala 2.10 came out and pushed me away from scala actors; sorry for any stupid questions as I'm always learning. As a general picture, the application consists of multiple long-lived JVMs communicating over ActiveMQ. The standard deployment is to a single machine, but with multiple services communicating over AMQ for the ability to move specific pieces of functionality to other boxes. As the migration and component rewrites have progressed, I'm solely left with actors communicating with each other over AMQ using akka-camel. The natural next step was to explore akka-remote. My questions started out as is this an abuse/unintended usage of akka-remote? Is akka-remote meant to be used outside of akka-cluster? Is it useful for communicating to local JVMs? What about network hiccups for remote JVMs? I did as much reading as I could and found that Victor Klang has said it's useful for transient networks: http://stackoverflow.com/questions/6401500/is-akka-suitable-for-systems-with-transient-network-coverage, and the smoking gun for same-machine inter-JVM communication being an expected use-case was Dr. Kuhn's comment here: http://stackoverflow.com/questions/10268613/whats-the-equivalent-of-akka/11787971#comment13246146_10268748 I went ahead and implemented a decent amount of code for using akka-remote to talk to one of the services after bumping our akka version to 2.3.3, and have to say I'm pleased, especially when comparing to ActiveMQ. Local machine communication is flawless, but once I started testing with remote machines and doing ifdown eth0; sleep 20; ifup eth0 network disruption tests, I'm left with questions about how to handle quarantines. I looked at reference.conf and heeded the admonition to NOT change the quarantine timeout from 5 days - restarting one of the actor systems is the only alternative. So - what're the best practices concerning restarting the ActorSystem? - I'm not clustering - these are a few long-lived heavy services, not just nodes spinning up to do small processing tasks - Our general deployment is not HA, we don't usually have standbys waiting - Restarting the JVM isn't optimal * since the services are fairly substantial and there's a non-trivial amount of initialization including database hits to pre-fill caches, restarting the JVM is a possibility (less time than the remoting gate time), but isn't the first route I'd choose * we (very rarely) run on non-linux platforms and so tend to try to keep stuff in the JVM instead of relying on upstart/launchd/windows services/etc My only other thought is to run an additional ActorSystem for remoting. - allows programmatic configuration (our runtime configuration system could change remoting settings and restart the remoting ActorSystem with the new settings) - a quarantine situation would just require the remoting ActorSystem to be recreated, not a restart of the whole JVM However, one of the very earliest entries in the Akka documentation states An ActorSystem is a heavyweight structure that will allocate 1…N Threads, so create one per logical application. I know creating multiple dispatchers in the same ActorSystem is fine, and sometimes (at least historically) a dedicated dispatcher was recommended for some remoting cases; I also know starting a new ActorSystem takes some amount of time to create dispatchers, parse configs, etc; so I'm thinking that the big yellow warning in the documentation is a general guideline for getting started with Akka, not a hard and fast rule. Sorry for the long post, can anybody give me some guidance on the situation? -- Read the docs: http://akka.io/docs/ Check the FAQ:
Re: [akka-user] Distributed worker and AdaptiveLoadBalancingPool
Hi Adriano, how do you determine the node’s capabilities? Can they change at runtime? Regards, Roland 30 maj 2014 kl. 15:49 skrev Adriano Machado adriano.mach...@gmail.com: Hi. My question is based on the Activator template akka distributed workers. I have started with it and implemented the needed logic based on my needs, it's working fine. Now I'm trying to design a solution that based on the node's capabilities, automatically increase and/or decrease the number of workers running on it. I have read the docs and found AdaptiveLoadBalancingPool, but I don't know how to fit it with the work pulling model presented by the template. How could I do it? Any help would be appreciated. -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout. Dr. Roland Kuhn Akka Tech Lead Typesafe – Reactive apps on the JVM. twitter: @rolandkuhn -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
[akka-user] How to Create And Send Message to a Timer Actor
Hey,
I want to create a Timer Actor that tracks the progress of the entire
program (and also estimate remaining execution time). Since the timer actor
will have to hold mutable variable aka current progress, I think it
should be constructed under the highest supervisor instead of being spawned
by lower actors. So I created this:
object Entry extends App {
val system: ActorSystem = ActorSystem(Twitter)
val sup = system.actorOf(Props[Supervisor])
sup ! Sentence(.)
}
class Supervisor extends Actor {
def receive = {
case sen: Sentence =
val timer = context.actorOf(Props[Timer])
val pcfg = context.actorOf(Props[PCFGParser])
pcfg ! sen.copy()
}
}
Then I have this lower actor that does all the actions:
class PCFGParser extends Actor{
def receive = {
case sen: Sentence =
//business logic
val ps = context.actorOf(Props[PatternSearch]) //create another
actor
ps ! sen.copy(tree = Some(tree))
context.actorSelection(../timer) ! PCFGAddOne
}
}
So at this point, I think it should send messages back to that Timer Actor.
BUT HOW!? I tried actorSelection, but all I got were dead letter errors.
The message was not delivered. And it also seems like this PCFGParser actor
failed to send messages to both its child actor and Timer Actor:
[INFO] [06/03/2014 01:35:25.290] [Twitter-akka.actor.default-dispatcher-4]
[akka://Twitter/user/$a/$h/$a] Message
[TwitterProject.PCFGParserMsg$Sentence] from
Actor[akka://Twitter/user/$a/$h#11
90256968] to Actor[akka://Twitter/user/$a/$h/$a#-1918790382] was not
delivered. [6] dead letters encountered.
[INFO] [06/03/2014 01:35:25.291] [Twitter-akka.actor.default-dispatcher-17]
[akka://Twitter/user/$a/$d/../timer] Message
[TwitterProject.TimerMsg$PCFGAddOne$] from Actor[akka://Twitter/user/$a/
$d#-1685001108] to Actor[akka://Twitter/user/$a/$d/../timer] was not
delivered. [7] dead letters encountered.
First, I admit there could be some error that's inside the business logic
of this actor that caused this error (or really?? Could a dead actor
triggers message not delivered error?) Second, what's the right way for
this PCFGParser actor to send message to a distant actor?
Thank you!
--
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] reactive streams uses ack based write throttling?
Hi Kenneth, the current state of Akka Streams is that we want to get the functionality implemented in a correct fashion first and optimize later. You are right that optimistic write-through would be more performant, but the implementation of that scheme requires a lot more care because on the other side the Reactive Stream input needs to signal the “right” amount of demand, taking into account the possibility of receiving a NACK later. In effect this will lead to yet another buffer between the stream and the socket, which is certainly not ideal, so we will need to spend some effort in minimizing that while retaining the throughput advantage. If you want to experiment with different schemes and contribute measurements or even alternate implementations you would be most welcome! Regards, Roland 2 jun 2014 kl. 01:58 skrev Kenneth Owens kowens0...@gmail.com: My questions pertain to the choice of ack based write throttling in the reactive streams implementation using Akka. I currently have multiple, Akka based, Protocol Buffers via TCP services running in production at my company, and, like the group at spray, I tend to prefer nack based write throttling with read suspension back pressure (Empirically, I've found this method to be much more performant). From review of the source, it seems that the writePump will buffer all incoming data prior to demand being established and any outstanding writes being complete, concatenate the buffered data into a single ByteString, and then send the data to the underlying TCP actor managing the NIO selector for the connection. Is my understanding correct? If so why has this method been selected instead of optimistic write through? Am I missing some implication of this method with respect to dynamic back pressure control? It seems that better performance might be gained by writing to the NIC optimistically until CommandFailed occurs, and that, as the back pressure here is applied by the kernel TCP buffers and I/O device, it should not affect downstream remote subscribers or affect the back pressure balance between remote hosts Thanks you in advance for you reply, -K -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout. Dr. Roland Kuhn Akka Tech Lead Typesafe – Reactive apps on the JVM. twitter: @rolandkuhn -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
