[akka-user] Akka Persistence View
Hello, Im new to Akka/Akka Persistence.. Though the documentation seem to provide information on the Akka View -- Im looking for use cases of the same. Is it for supporting High Availability -- wherein if the Processor is running on one node and Akka View can be on another node and provide HA in case the processor dies. Correct me if I got it wrong on the use case of Akka View. Thx, Syed [ I had posted a variant of this topic earlier and didn't see it hence posting again ] -- 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 View -- as a hot/warm standby replica
Hello Syed, yes / no. yes - it's possible to spin up a View for the same processorId on a different node in the cluster. It can be used as a read-model. no - it can not change into becoming a processor if the main processor goes down. A view is a view. The View's use-case is to be able to have a read-model. That is, the processor instance does all the processing and storing - so it does more work, and the View only replays the events and creates some view on the data. You can easily imagine an NumbersProcessor which creates events like Number(...), and an AverageNumberView which gets all the Number events, but it's state is completely different from the processor - it only exposes the average (the processor does more things with them for example). I hope this helps! On Wed, May 21, 2014 at 7:24 PM, Syed Ahmed sbua2...@gmail.com wrote: Hello, Im new to Akka and was interested in trying out the Akka Persistence. I ready about Akka View. Looks like their usage intention is to create a replica of the Processor data? . Please correct me. From that perspective can we use them for High Availability as a Primary/StandBy system. To elaborate, I will use one Processor to capture the messages on one node (say node 1) View of that processor as a Standby on another node (say node2) ( I hope its possible?). If its possible - can the view become the new Primary processor (on Node2) and process messages when the current Processor goes down on the system (Node1). If the above is not possible with Akka View then Im missing the use case of Akka View -- Please explain. Thx, -Syed -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout. -- Cheers, Konrad 'ktoso' Malawski hAkker - Typesafe, Inc http://scaladays.org -- 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] Empty Snapshot files causes EOFException
Hi Björn,
today I found out that the root cause seems to be the length of the fully
qualified class name of the snapshot class. If the length (pacakge+class
name) exceeds 60 characters an EOFException is thrown instead of calling
fromBinary.
Here's my reference.conf:
akka {
actor {
serializers {
customSerializer = com.handler.util.CommonSerializer
}
serialization-bindings {
com.handler.common.dispatcher.xxx.MySnapshot =
customSerializer
}
}
}
Here's the scala file where I define the MySnapshot class:
package com.handler.common.dispatcher.xxx
@SerialVersionUID(1L)
case class MySnapshot(id: String)
Here's the common serializer:
package com.handler.util
class CommonSerializer extends Serializer {
def includeManifest: Boolean = true
def identifier = 5177
def toBinary(obj: AnyRef): Array[Byte] = {
val outputStream = new ByteArrayOutputStream()
outputStream.toByteArray
}
def fromBinary(bytes: Array[Byte],
clazz: Option[Class[_]]): AnyRef = {
None
}
}
If I make the package name shorter it works without throwing an
EOFException - fromBinary is called then.
--
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] Cluster failure in single JVM
Can anyone point in the right direction with this one, probably something obvious I'm missing! I'm trying to debug a strange Cluster issue… I have 3 actor systems in a cluster (all in the same JVM) communicating via the distributed bus. (It's just a test app at the moment, and in production will run with each actor system in its own JVM on different servers). Akka v2.3.0 It works fine on my local machine, and on the dev server. On the test server, it works fine until put under load. At that point actor system 2 seems to disappear – it suddenly doesn’t send or receive any heartbeats and is quickly marked as unreachable (I'm basing this on the log output switched on by log-remote-lifecycle-events) No idea why! I was expecting to see this in networked setup (say on EC2) but not within a single app. I've tried changing the failure detection config settings based on blindly copying in config from other posts here, but it doesn’t affect the problem. Can anyone offer 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] Re: Akka 2.2.x - 2.3.y upgrade problem
On Wed, 2014-05-21 at 11:02 -0700, Alanlit wrote: On Wednesday, May 21, 2014 8:43:56 AM UTC-7, Patrik Nordwall wrote: Verify that you have protobuf version 2.5.0 in your classpath. /Patrik Good call !! I found that a third party library has (of course) an old version of protobuf tucked inside it. Removing that for now fixed everything. Just a warning (because I went this route before you) that proto files compiled to java with protobuf 2.4.1 are not compatible with the protobuf 2.5.0 runtime library. In my case our own application is very dependent on protobuf and I had to recompile some of our dependencies that were using protobuf compiled files with 2.4.1. -- Brice Figureau My Blog: http://www.masterzen.fr/ -- 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 failure in single JVM
Hello James, could you first try the latest Akka which is 2.3.3? There has been multiple issues fixed in three maintenance releases since Akka 2.3.0. On Thu, May 22, 2014 at 4:42 PM, James Bunch james.x.bu...@gmail.comwrote: Can anyone point in the right direction with this one, probably something obvious I'm missing! I'm trying to debug a strange Cluster issue… I have 3 actor systems in a cluster (all in the same JVM) communicating via the distributed bus. (It's just a test app at the moment, and in production will run with each actor system in its own JVM on different servers). Akka v2.3.0 It works fine on my local machine, and on the dev server. On the test server, it works fine until put under load. At that point actor system 2 seems to disappear – it suddenly doesn’t send or receive any heartbeats and is quickly marked as unreachable (I'm basing this on the log output switched on by log-remote-lifecycle-events) No idea why! I was expecting to see this in networked setup (say on EC2) but not within a single app. I've tried changing the failure detection config settings based on blindly copying in config from other posts here, but it doesn’t affect the problem. Can anyone offer 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. -- Martynas Mickevičius Typesafe http://typesafe.com/ – Reactivehttp://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.
Re: [akka-user] Re: Some questions about clustering
I meant to say that ClusterClient is only one way. You can use Send/SendToAll/Publish to talk to the cluster from the outside. However ClusterClient is not suitable when trying to talk to outside from within the cluster. On Wed, May 21, 2014 at 5:56 PM, Luis Medina lu4...@gmail.com wrote: Thank you Martynas. This is not currently supported. As a side node, it could be used the other way around. In fact ClusterReceptionist that ClusterClient talks to, is itself built on PubSub. When you say that it could be the other way around, do you mean having the ClusterClient subscribe to the distributed PubSub that is used within the cluster so that if a message is published to it by someone in the cluster then the client on the outside receives that message too? Or do you mean having the ClusterClient use the Send/SendToAll/Publish methods to send messages to the other actors in the cluster? -- 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/ – Reactivehttp://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.
Re: [akka-user] Akka View -- as a hot/warm standby replica
Thx to both! -- This was helpful! -Syed On Thursday, May 22, 2014 3:03:57 AM UTC-7, Patrik Nordwall wrote: What you are looking for has previously been tracked as https://github.com/akka/akka/issues/13938 /Patrik On Thu, May 22, 2014 at 10:26 AM, Konrad Malawski kt...@typesafe.comjavascript: wrote: Hello Syed, yes / no. yes - it's possible to spin up a View for the same processorId on a different node in the cluster. It can be used as a read-model. no - it can not change into becoming a processor if the main processor goes down. A view is a view. The View's use-case is to be able to have a read-model. That is, the processor instance does all the processing and storing - so it does more work, and the View only replays the events and creates some view on the data. You can easily imagine an NumbersProcessor which creates events like Number(...), and an AverageNumberView which gets all the Number events, but it's state is completely different from the processor - it only exposes the average (the processor does more things with them for example). I hope this helps! On Wed, May 21, 2014 at 7:24 PM, Syed Ahmed sbua...@gmail.comjavascript: wrote: Hello, Im new to Akka and was interested in trying out the Akka Persistence. I ready about Akka View. Looks like their usage intention is to create a replica of the Processor data? . Please correct me. From that perspective can we use them for High Availability as a Primary/StandBy system. To elaborate, I will use one Processor to capture the messages on one node (say node 1) View of that processor as a Standby on another node (say node2) ( I hope its possible?). If its possible - can the view become the new Primary processor (on Node2) and process messages when the current Processor goes down on the system (Node1). If the above is not possible with Akka View then Im missing the use case of Akka View -- Please explain. Thx, -Syed -- 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.comjavascript: . 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, Inc http://scaladays.org -- 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.comjavascript: . 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: Cluster Sharding Questions
Hi Luis,
On Thu, May 22, 2014 at 9:19 PM, Luis Medina lu4...@gmail.com wrote:
Hi Martynas,
Thank you so much for answering my questions. I know it was quite a
lengthy read. Just got a few follow-up comments/question:
I think I understand sharding now. In doing something like:
ClusterSharding.get(system).start(Worker, Props.create(Worker.class),
messageExtractor);
you're essentially telling the cluster that you're going to be sharding
the Worker actor. This doesn't mean that there will be 1 instance of the
entry running in the cluster because the number of entries of this type is
determined by the entryId() method in the messageExtractor.
No, that would be wrong usage. Martynas found earlier today that we had not
documented that specific thing and therefore created ticket:
https://github.com/akka/akka/issues/15273
The purpose with cluster sharding is that at any point in time there will
only be one entry actor instance for a specific identifier. You send
messages to this identifier, without knowing where it is currently located.
Shards are only groups of entries. A way for the infrastructure to manage a
large number of entries.
Can you please describe what you are trying to solve? I get the feeling
that you might be using the wrong tool.
Cheers,
Patrik
The number of entries (for a particular entry type) that are run in the
cluster, depending on how entryId() is specified, will likely be dynamic.
Similarly, the range of values that the shardId() method returns will
determine the number of shards that are created in the cluster. So in that
sense, different shards can potentially contain an instance of the same
entry and thus, an entry doesn't really have a single shard to call its
home. Also, the maximum instances of the same entry type that can ever be
running on the cluster will be equal to the number of shards that it has.
Now based on my understanding, let me give a slightly different example:
Say I have 4 nodes in my cluster. As you confirmed, I should ideally have
40 shards in the cluster.
In order for my entries to be spread out uniformly throughout my cluster,
the shardId() method for each entry type should produce the same ~40 unique
id values (else I risk going past the ideal number of shards for my
cluster). Given this, do you think that a good setup would be something
like:
public static class Message {
public int entryId;
public int shardId;
public Object data;
public Message(Object data) {
this.data = data;
shardId = Random.nextInt();
entryId = Random.nextInt();
}
}
ShardRegion.MessageExtractor messageExtractor = new
ShardRegion.MessageExtractor() {
@Override
public String entryId(Object message) {
if (message instanceof Message)
return Integer.toString(message.entryId);
else
return null;
}
@Override
public Object entryMessage(Object message) {
if (message instanceof Message)
return message.data;
else
return null;
}
@Override
public String shardId(Object message) {
if (message instanceof Message)
return Integer.toString(message.shardId % 40); // note the value
40 here
else
return null;
}
}
a) If the values produced by the shardId() method in the MessageExtractor
are too random,is there a risk in creating too many entries that remain
idle? I'm guessing this is where Passivation would come into play.
b) Same question as above but this time say that the entry doesn't
actually receive message but actually pulls them from somewhere
(essentially using the pulling pattern). Since Passivation only works based
on messages that are sent to an entry, how might idle entries be handled in
this case?
c) So from what you said, sending a message to an entry is done through a
ShardRegion only if you don't know where it is. Otherwise, if you have its
ActorRef, you can send a message to it using .tell(...) without having to
go through the ShardRegion.
d) Do the id values for the entries themselves matter since at most there
would be 1 entry of that type per shard?
e) Is it possible to have a scenario where all of the shards have an entry
of a particular type running and you send a message to said entry type with
an entryId that doesn't match any of the ids of the entries that are
currently running (ie. There are 10 shards, each one running an entry with
an id value that ranges between 1-10, and you send a message with an id
value of 11)? What would happen? Should the entryId() also return id values
that fall in the same range as the number of shards (so in the example
above I would do mod 40 of the entryId)?
--
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
[akka-user] Re: Cluster Sharding Questions
Hi Patrik, You are absolutely correct. I don't know what was going through my mind when I said that there are multiple instances of an entry running. Haven't been getting much sleep lately :/ As for my use-case, I'm trying to build a pipeline that takes in a data stream and processes it in different ways. Since the stream has to be running uninterrupted (and has to be able to recover on its own) I'm thinking of doing by using a singleton (to avoid automatic re-balancing and losing the data flow) or by using sharding but with my own implementation of a ShardAllocationStrategy like Martynas suggested. After the stream come what I'll call the worker actors. Each worker is responsible for doing some change to each message (ie. finding sentiment, the author's gender, etc) in the data stream and passing it on. The workers will be using the pulling pattern and will be implemented as Processor. Each worker will contain a router pool of routees that do the actual processing while the worker itself serves as a coordinator. I'm going to be using RabbitMQ as the data-store that the stream writes to and the workers pull off of, process, and put back into different queues within Rabbit. For the workers, I was thinking of using sharding to be able to scale the system (as described in my first post where the routers would re-size themselves after the entry gets restarted from re-balancing) and for the high-availability that it offers. I considered using singletons except that they would probably create a bottleneck in my cluster since they would all be created on the oldest node of the cluster. Using roles wouldn't help that much because then that would limit what nodes the workers can run on which means that if all the nodes of a certain role go down, then I would lose that particular type of worker which in turn causes issues with RabbitMQ. Does that help? -- 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: TestKit and absolute actor path path
I'd love to hear the answer to this too! I've solved the problem by injecting actorRefs but it does seem to lose the point of actor supervision. The other technique I've tried in one spot is to use the TestActorRef to get the underlyingActor and then set the actorRef on that. This means that actor construction can do things normally - and then I override it. Cheers, Edward On Thursday, May 22, 2014 3:30:10 AM UTC-7, Filippo De Luca wrote: Hi Guys, I am wondering if is it possible to use a probe to test an actor that reference the other actor by actor path. For example it can use actorFor(/user/foo/bar) or actorFor(../my-sibling-actor) is there a way to inject a probe inside the actor-system. This bring to my mind another question, is it a good practice to reference an actor by the path, or is better to pass the actorRef as parameter when possible? Thanks for your help. -- *Filippo De Luca* - WWW: http://filippodeluca.com IM: filosg...@gmail.com javascript: -- 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: TestKit and absolute actor path path
Well, in my case, I'm creating TestProbes and passing them into the actor
under test so that I can verify what it does with them.
For example, I have one class which communicates with 3 other actors and I
mock out all of them with TestProbes.
However, it does feel like a lot of work which is a clue I may be not doing
this the best way.
Cheers,
Edward
On Thu, May 22, 2014 at 2:48 PM, Filippo De Luca m...@filippodeluca.comwrote:
Hi Edward,
In that case it is easy: When an actor need to start a child, I'll pass a
Props instance for that actor. So that the actor will be supervised by the
parent but the dependencies of the constructor for the child are hidden.
ex:
class ParentActor(childProps: Props) {
val child = context.actorOf(childProps.withRouter(...), child)
...
}
object ParentActor {
def props(childProps: Props) = Props(classOf[ParentActor], childProps)
}
class ChildActor(mailServer: MailServer, ) {
}
object ChildActor {
def props(mailServer: MailServer, ) = Props(classOf[ChildActor],
mailServer, )
}
val childProps = ChildActor.props(mailServer, )
val toTest = system.actorOf(ParentActor.props(childProps), parent)
On 22 May 2014 21:48, Edward Sargisson ejsa...@gmail.com wrote:
I'd love to hear the answer to this too!
I've solved the problem by injecting actorRefs but it does seem to lose
the point of actor supervision.
The other technique I've tried in one spot is to use the TestActorRef to
get the underlyingActor and then set the actorRef on that. This means that
actor construction can do things normally - and then I override it.
Cheers,
Edward
On Thursday, May 22, 2014 3:30:10 AM UTC-7, Filippo De Luca wrote:
Hi Guys,
I am wondering if is it possible to use a probe to test an actor that
reference the other actor by actor path.
For example it can use actorFor(/user/foo/bar) or
actorFor(../my-sibling-actor) is there a way to inject a probe inside
the actor-system.
This bring to my mind another question, is it a good practice to
reference an actor by the path, or is better to pass the actorRef as
parameter when possible?
Thanks for your help.
--
*Filippo De Luca*
-
WWW: http://filippodeluca.com
IM: filosg...@gmail.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.
--
*Filippo De Luca*
-
WWW: http://filippodeluca.com
IM: filosgang...@gmail.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 a topic in the
Google Groups Akka User List group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/akka-user/v0SZ6C9l4uQ/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.
