Re: [akka-user] ThreadLocal not being cleaned up?
Take a look at this discussion: https://groups.google.com/d/msg/akka-user/a8GcX2qEm6g/OIbFTtPaSRoJ /Patrik On Tue, Sep 30, 2014 at 9:48 PM, Daniel Davies davi...@att.net wrote: Thanks for the hint. I had trouble getting the router and children to use a different dispatcher. However, I was able to change the default dispatcher. That got rid all of the messages except one. SEVERE: The web application [/pois] created a ThreadLocal with key of type [scala.concurrent.forkjoin.ThreadLocalRandom$1] (value [scala.concurrent.forkjoin.ThreadLocalRandom$1@6c64cb25]) and a value of type [scala.concurrent.forkjoin.ThreadLocalRandom] (value [scala.concurrent.forkjoin.ThreadLocalRandom@6ae5aa72]) but failed to remove it when the web application was stopped. This is very likely to create a memory leak. Daniel Davies On Tuesday, September 30, 2014 1:58:33 AM UTC-6, Akka Team wrote: Hi Daniel, Have you tried using a different dispatcher than the fork-join one like a thread-pool-executor? If the problem goes away after changing the dispatcher then this is a bug in the ForkJoinPool. -Endre On Fri, Sep 26, 2014 at 4:38 AM, Daniel Davies dav...@att.net wrote: Sorry, I was interrupted while posting this and did not notice I had not completed the versions. AKKA 2.3.6 Scala 2.11 Java 8 Not sure what you need for shutdown. I have given the sequence. You execute the shutdown script for Tomcat Spring has Application Listeners and I have one that listens for the ContextClosedEvent - which means the application is quitting This listener calls system.stop on my top level actors. It then calls system.shutdown Lastly, it calls system.awaitTermination blocking until complete system is an ActorSystem The top level Actors are routers that have a varying number of child actors using resizer. It seems like the number error messages corresponds to the number of child actors, but I can't be sure since I don't know how many actors are running at any time. On Thursday, September 25, 2014 3:38:03 PM UTC-6, √ wrote: Hi Daniel, In order to be able to understand how that happens, a couple of questions come to mind: how are you shutting down your system and what version of Akka are you using? (there is no version named 2.11 that I know of) On Thu, Sep 25, 2014 at 11:26 PM, Daniel Davies dav...@att.net wrote: I am running Tomcat 6 AKKA 2.11 I am using Spring Webservices. I have an Application listener that listens for a ContextClosedEvent. This calls system.stop on top level actors , then system.shutdown and then an awaitTermination. After these run I get a series of errors like: SEVERE: The web application [/pois] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@79e2c065]) and a value of type [scala.concurrent.forkjoin.ForkJoinPool.Submitter] (value [scala.concurrent.forkjoin.ForkJoinPool$Submitter@7e07db1f]) but failed to remove it when the web application was stopped. This is very likely to create a memory leak. This is just one of several error messages. These posts indicate that it is fixed, but it does not appear to be fixed. On Thursday, September 20, 2012 7:52:15 AM UTC-6, √ wrote: Shouldn't be a problem. https://www.assembla.com/spaces/akka/tickets/2479 Cheers, √ On Thu, Sep 20, 2012 at 3:45 PM, Eirik eiri...@gmail.com wrote: I'm using Akka 2.0.3 on Tomcat 7.0.30 and am facing the same issues on shutdown. I've got a shutdown method that gets called before Tomcats memory-leak-detection algorithm runs. The shutdown method does: actorSystem.shutdown(); actorSystem.awaitTermination(); But Tomcat still complains: SEVERE: The web application [/**] created a ThreadLocal with key of type [akka.jsr166y.ForkJoinPool.ThreadSubmitter] (value [akka.jsr166y.ForkJoinPool$ThreadSubmitter@1e8b404]) and a value of type [akka.jsr166y.ForkJoinPool.Submitter] (value [akka.jsr166y.ForkJoinPool$Submitter@829a91]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak. I haven't dug deep enough at the moment to figure out if I should worry about this or not, but I've written some more shutdown logic just to be safe, that searches through threadlocals to find the ForkJoinPool$Submitter and removes it. This solves the issue, but shouldn't akka already have take care of cleaning up when I called shutdown and awaitTermination? Regards, Eirik -- Read the docs: http://akka.io/docs/ Check the FAQ: http://akka.io/faq/ Search the archives: https://groups.google.com/grou p/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To post to this group, send email to akka...@googlegroups.com. To unsubscribe from this group, send email to akka-user+...@ googlegroups.com. Visit this group at http://groups.google.com/group/akka-user?hl=en. --
[akka-user] Re: Cluster Sharding and dynamically adding actors at runtime across the cluster
Hi Mike,
Did you look at the distributed worker pattern ?
See: http://typesafe.com/activator/template/akka-distributed-workers
That may be a better match looking at your use case.
Kind regards,
Olger
On Tuesday, September 30, 2014 11:41:59 PM UTC+2, Michael Kohout wrote:
Hi Folks-
I've got an application that uses cluster sharding to distribute work across
a cluster and provide failover. But because of a change in scope I need
to change how the work is done to maintain system performance while also
allowing for failover and cluster rebalancing.
At present the system has several actors that are created at application
startup via the ClusterSharding extension. The same actors with the same
behavior and configuration are started across all the nodes in the cluster.
These actors have no state, so they don't use akka persistence. A
singleton exists in the cluster whose purpose is to trigger the sharded
actors to perform work on a schedule(It's a homebrew integration with
Spring's TaskScheduler). Every day, that singleton triggers the actors
that were configured via ClusterSharding, and the sharded actors pull their
work from a DBMS, process each entity, save the results and wait until they
are triggered again.
Now the processing we have to do on each entity is grown in complexity and
time required, so I want to delegate that work to some actor that is
dedicated to each entity.
The simple answer to splitting up this work further seems like it would be
to maintain a list of actors that the sharded actor can delegate work to
then trigger them when the entities they represent need to be processed:
//inside the sharded actors receive:
listOfEntitiesFromDBQuery.each{ entity -
//create the child actor if it doesn't exist
if(!context.getChild(entity.id)){
context.actorOf(Props.create(EntityProcessor.class, entity.id),
entity.id))
}
context.getChild(entity.id).tell(DOWORK)
}
But this design still looks like it would have problems.
1) While the sharded actor would move around the cluster because of
rebalancing, what about the children? They'll be stopped as the parent is
stopped and moved, correct? Is there any chance a child could exist on
both the old node and new node at the same time?
2) The children are processor intensive-so we'd want them to be
distributed across the cluster too and it seems that this won't happen with
this simple design.
It seems to me what I'd *like* to do is chard the processors/children as
well-not just start them as a child of the sharded actor on the actorsystem
it's currently living on. But I'm not sure how to do that since they
aren't known at startup.
Is this a problem anyone else has solved? If this is a common pattern, is
there anything built into akka-contrib that pertains to this?
thanks,
Mike Kohout
--
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] Routing to subset of children
1 okt 2014 kl. 03:45 skrev Richard Rodseth rrods...@gmail.com: Thanks, Konrad. I have a little test working, but I'm puzzled by one thing. If all I want to do is subscribe to individual channel ids (Longs, not Strings), the SubChannelClassification doesn't seem appropriate. But the LookupClassification requires overriding mapSize, which makes me think it's not suitable since I have a large range of possible channelIds. I wouldn’t read too much into the mapSize parameter: the underlying Index uses a ConcurrentHashMap and this parameter defines the number of buckets, which also determines how fine-grained the locking of the hash space is partitioned, so having lots of IDs is not a problem—it is more about how many IDs you expect to register and look up concurrently. Regards, Roland I can certainly synthesize a string classifier like /event/channel-id, but I thought I'd ask. On Mon, Sep 8, 2014 at 12:04 AM, Konrad Malawski kt...@typesafe.com wrote: Hi guys, exactly, I'd go with an Subchannel classification EventBus in this case. This way you can even define hierarchies of these topics the actors are interested in. You may also enjoy this article by Ben Howell which we've featured on letitcrash.com some time ago: http://www.benhowell.net/examples/2014/04/23/scala_and_the_akka_event_bus/ Happy hakking! On Sat, Sep 6, 2014 at 7:18 PM, Richard Rodseth rrods...@gmail.com wrote: Thanks. For those, following along, this is helpful: http://www.kotancode.com/tag/event-bus/ On Sat, Sep 6, 2014 at 1:09 AM, Martynas Mickevičius martynas.mickevic...@typesafe.com wrote: Hello Richard, I think Event Bus can help you there where children can subscribe to an interested channel on a bus. On Fri, Sep 5, 2014 at 11:44 PM, Richard Rodseth rrods...@gmail.com wrote: Suppose I have messages containing a channel id coming to a parent actor. There are many children, each of which is interested in one or more channels. In other words, a channel message needs to be dispatched to a subset of the children. I'm aware of ActorSelection and have looked at the routing docs, but neither seemed to fit. I could maintain a Map in the parent from channelid to list of actor paths, or I could send each message to all children. Am I missing anything? Thanks in advance. -- 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 – Reactive 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. -- Cheers, Konrad 'ktoso' Malawski hAkker @ Typesafe -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout. -- Read the docs: http://akka.io/docs/ Check the FAQ:
Re: [akka-user] Bridging spray router and service actors
Hi Richard,
No, I mean the other complete() method that you call from the Success and
Failure paths of the onComplete block. Why not just use
complete(result.transform(...))?
-Endre
On Wed, Oct 1, 2014 at 2:01 AM, Richard Rodseth rrods...@gmail.com wrote:
Hi Endre
Yes, the one I showed (onComplete()) *is* taking a future. The result of
my ask is a Future[Long].
On Tue, Sep 30, 2014 at 3:58 AM, Akka Team akka.offic...@gmail.com
wrote:
Hi Richard,
The route looks something like this:
post {
val result = (xyzService ?
XYZService.CreateXYZ(xyzAttributes)).mapTo[Long]
onComplete(result) {
case Success(value) = complete(sThe result was $value)
case Failure(ex) = complete(StatusCodes.InternalServerError,
sAn error occurred: ${ex.getMessage})
}
Isn't there a version of complete() that take a Future directly? (maybe
called completeAsynch, but I think there should be one). I am not sure
calling complete() out of the context of the actor works or not.
-Endre
}
In this case the XYZService actor forwards a transformed message to the
DbActor
case msg @ XYZService. CreateXYZ(attributes) = {
dbActor forward DbActor.AddXYZ(attributes) // Interesting that I
can forward a new message
}
If the response needed transforming, presumably an additional ask would
be needed within the XYZService.
The DbActor replies with a result
case AddXYZ(attributes) = db withSession { implicit session =
try {
val result = XYZDAO.add(attributes)
sender() ! result
} catch {
case e: Exception =
sender() ! akka.actor.Status.Failure(e)
throw e
}
}
Does this seem reasonable? Would it be considered better practice to use
per-request actors for every route, to avoid the use of tell, or somehow
pass the request context to the service actor for completion? I've read the
Ian Forsey article, but am a bit unclear on whether to standardize on the
per-request model. I did notice that the route I implemented using
per-request is slow on all but the first request, and I haven't had time to
look into that.
--
Read the docs: http://akka.io/docs/
Check the FAQ:
http://doc.akka.io/docs/akka/current/additional/faq.html
Search the archives:
https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google
Groups Akka User List group.
To unsubscribe from this group and stop receiving emails from it, send
an email to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
--
Akka Team
Typesafe - The software stack for applications that scale
Blog: letitcrash.com
Twitter: @akkateam
--
Read the docs: http://akka.io/docs/
Check the FAQ:
http://doc.akka.io/docs/akka/current/additional/faq.html
Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups
Akka User List group.
To unsubscribe from this group and stop receiving emails from it, send an
email to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
--
Read the docs: http://akka.io/docs/
Check the FAQ:
http://doc.akka.io/docs/akka/current/additional/faq.html
Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups
Akka User List group.
To unsubscribe from this group and stop receiving emails from it, send an
email to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
--
Akka Team
Typesafe - The software stack for applications that scale
Blog: letitcrash.com
Twitter: @akkateam
--
Read the docs: http://akka.io/docs/
Check the FAQ:
http://doc.akka.io/docs/akka/current/additional/faq.html
Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups Akka
User List group.
To unsubscribe from this group and stop receiving emails from it, send an email
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] how to recursive restart remote actors
Hi Sean, On Wed, Oct 1, 2014 at 6:40 AM, Sean Zhong clock...@gmail.com wrote: The hierachy may looks like this: grandpa - parent - child When I restart grandpa(grandpa throws a exception, and its supervisor handle with Restart), I want the whole tree is restarted. parent actor and child actor are remote actors, and their life cycle is not binded to their parents. If the children are remote deployed they work supervision-wise the same as local actors (see: http://doc.akka.io/docs/akka/2.3.6/general/addressing.html#The_Interplay_with_Remote_Deployment). In other words remotely deployed children get restarted if their parent is restarted. -Endre -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout. -- Akka Team Typesafe - The software stack for applications that scale Blog: letitcrash.com Twitter: @akkateam -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
[akka-user] dead letters encountered and timed out replies
hi all, my understanding is that when I have: actorRef ? hi and the future times out, the reply eventually sent back from actorRef goes to dead-letters. That is fine but the log is polluted with messages about dead letters encountered related to those replies. Is there a way to filter out only this kind of messages from the log (but keep other dead letters encountered)? Thanks, Nicola -- 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 singleton, multi-jvm testing and enter barriers
Hi, If anyone has any ideas/suggestions regarding the above issue, that would be great. I can share my test code if it will help. Unfortunately in these kind of integration tests sometimes long timeouts are needed. It is btw good to be aware of these since these timing issues are relevant in production, too. One option though is to tweak timing parameters of clustering, for example you can set up a shorter gossip period for tests. a) If I use runOn(node1), the enclosed code is executed in the corresponding node and its jvm - ok. If in my base spec, there is no other code specified for node1, does this mean that the node will be shut down even if other code is still being executed on other nodes? It is sufficient to put a barrier after the block if you want to ensure that the node exists only after other nodes reached that barrier. As a more specific example, if I have one node acting as my cluster client and other nodes as part of my cluster, do I have to do anything extra to keep them up in the background since I will be using runOn(client) only? Adding a barrier will definitely work. b) Is there any way to make all my test cases dependent on my singleton being started? If I need to implement this myself, how do I go about it? I guess I can listen to the cluster for some event that signifies that the singleton is up, but I still don’t know enough. For example, does the singleton start itself automatically or is it initiated in a lazy manner? The singleton will start up on the oldest member as soon as the oldest member has been found. Which event should I listen for? Looking at the code I couldn't find any explicit events published, what we usually do in tests is sending pings periodically to the singleton until it replies. If more fancy events are needed you might want to use a cluster PubSub topic to publish Singleton events (this might add some delay of course, and now you have an extra subsystem added). c) Is it possible to use enter barriers to control both of the above? Yet, I could not find any documentation at all regarding enter barriers. How do they work? Is there any difference between placing them inside or outside a runOn block? enterBarrier(*barrierName*) calls mean that all nodes reaching that point will: - send a message to the test coordinator that they have reached *barrierName* - they wait until all other nodes have been reported that they have reached *barrierName*, too In other words every code on every node defined before a barrier *barrierName *globally happens before every code on every node after the barrier *barrierName*. -Endre Thanks a lot, Sinan -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout. -- Akka Team Typesafe - The software stack for applications that scale Blog: letitcrash.com Twitter: @akkateam -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Best book(s) on distributed system ?
Hi Jonas Thanks a lot to take the time to answer such question, I really appreciate! I'm a bit surprised though: most of the books/papers you refer are research level, meaning for building solutions. I was kind of thinking/hoping some solutions would already be built On Tue, Sep 30, 2014 at 9:10 PM, Jonas Bonér jo...@jonasboner.com wrote: Here is a list of some of the more recent nice books I’ve read on distributed systems: - This is a nice one IMO. Brings in failure as a first class concept, makes it suitable for the real world: http://www.distributedprogramming.net/ - This one is interesting as well. More theoretical, but eye opening. Written by Gul Agha’s student. http://www.amazon.co.uk/Programming-Distributed-Computing-Systems-Foundational/dp/0262018985 - I’m reading this one right now, too early to judge: http://www.amazon.com/Distributed-Computing-Through-Combinatorial-Topology/dp/0124045782 - This one is the one with interesting algos, but that ignores failure (but most books do that actually): http://www.amazon.com/Distributed-Algorithms-Message-Passing-Systems-Michel/dp/3642381227/ - This is a nice one on multicore programming (related): http://www.amazon.com/Art-Multiprocessor-Programming-Revised-Reprint/dp/0123973376 - Joe Armstrong’s thesis, essential reading for building fault-tolerant systems: http://www.sics.se/~joe/thesis/armstrong_thesis_2003.pdf But I’ve learned most from reading papers. I can recommend all the papers listed in the references section in my talk: www.slideshare.net/jboner/the-road-to-akka-cluster-and-beyond On Tue, Sep 30, 2014 at 2:17 PM, Joseph Pachod joseph.pac...@gmail.com wrote: Hello Our small software shop has recently been bought and now we face the issue of building a distributed system, meaning by that moving from monolithic web based products to a platform with various optional modules. The main characteristics looked for are : - seen as a web app by the users - mostly deployed on premises - mission critical software (health care - emergency services), so downtime and seamless upgrades (most of the time at least) - if possible should allow for multiple languages/stack on the JVM and even beyond (.Net I'm looking at you !). Being a commuter and a big reader, I'm looking for the best resource(s) on the topic, any hints ? Thanks in advance Best Joseph PS: I already tried scala/akka/eventsourced (now akka persistence), but there's quite a step going to a proper distributed systems from there... -- 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. -- *Jonas Bonér* Home: jonasboner.com Twitter: @jboner https://twitter.com/jboner Public Key: keybase.io/jonas -- 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] akka.persistence Deserialization issue from scala 2.10 to 2.11
Hi Christian,
just saw that the SelectedSnapshot issue seems to be related to the
akka.persistence casbah mongodb plugin and was fixed a few days ago. I also
had a look again at the snapshot serializer and saw this:
val header = SnapshotHeader(snapshotSerializer.identifier,
snapshotManifest) val headerSerializer =
*extension.findSerializerFor(header)* val headerBytes = headerSerializer.
toBinary(header)
I haven't found a serializer for the SnapshotHeader only the Snapshot.
Did I just miss it?
Nope, I haven't found one either, this is a bug it seems. I opened a
ticket: https://github.com/akka/akka/issues/16009
-Endre
Regards,
Christian
Am Dienstag, 30. September 2014 17:38:54 UTC+2 schrieb Christian
Kitzmueller:
Hi,
we are using protobuf to serialize our messages - I have to check if we
might have missed one. From your comment I conclude that akka persistence
itself shouldn't be an issue and the internal parts it is saving (like
snapshot headers, manifest, etc ...) are safe ?
Regards,
Christian
Am Dienstag, 30. September 2014 13:00:59 UTC+2 schrieb Akka Team:
Hi Christian,
Are you using Java serialization to save Scala objects? Please note that
these Scala versions are not binary compatible, not even on the
serialization level. It is highly recommended to use a proper serialization
format when using persistence (protobuf, Thrift, etc.) that support
forward-backward compatibility and a stable binary format irregardless of
the platform.
-Endre
On Mon, Sep 29, 2014 at 8:42 AM, Christian Kitzmueller
christian@gmail.com wrote:
Hi,
we are currently using akka 2.3.6 and checking for migration from scala
2.10.4 to 2.11.2. When I tried an update to scala 2.11.2, I noticed
following things:
When I start my application (using a local leveldb) I cannot reload
Snapshots - I get the following exception:
08:12:08.232 ERROR [akka.tcp://x@127.0.0.1:
3552/system/snapshot-store] Error loading snapshot
[SnapshotMetadata(,3,1411970788025)]
java.io.InvalidClassException: scala.Option; local class incompatible:
stream classdesc serialVersionUID = -2062608324514658839, local class
serialVersionUID =
-114498752079829388
I have a similar issue with the akka-persistence-mongo-casbah journal:
07:43:03.534 ERROR [akka.tcp://x@127.0.0.1:
3552/system/snapshot-store] error loading snapshot { _id : { $oid
: 5428f1275fe8f19e6086ec8c}
, persistenceId : xx , sequenceNr : 0 , timestamp :
1411969319306 , snapshot : Binary Data}
java.io.InvalidClassException: akka.persistence.SelectedSnapshot;
local class incompatible: stream classdesc serialVersionUID =
-7413351535605152403, local clas
s serialVersionUID = -8204699298693905400
at java.io.ObjectStreamClass.initNonProxy(Unknown Source)
~[na:1.7.0_45]
I guess the only workaround for this would be touching the serializers?
Regards,
Christian
--
Read the docs: http://akka.io/docs/
Check the FAQ: http://doc.akka.io/docs/akka/
current/additional/faq.html
Search the archives: https://groups.google.com/
group/akka-user
---
You received this message because you are subscribed to the Google
Groups Akka User List group.
To unsubscribe from this group and stop receiving emails from it, send
an email to akka-user+...@googlegroups.com.
To post to this group, send email to akka...@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
--
Akka Team
Typesafe - The software stack for applications that scale
Blog: letitcrash.com
Twitter: @akkateam
--
Read the docs: http://akka.io/docs/
Check the FAQ:
http://doc.akka.io/docs/akka/current/additional/faq.html
Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups
Akka User List group.
To unsubscribe from this group and stop receiving emails from it, send an
email to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
--
Akka Team
Typesafe - The software stack for applications that scale
Blog: letitcrash.com
Twitter: @akkateam
--
Read the docs: http://akka.io/docs/
Check the FAQ:
http://doc.akka.io/docs/akka/current/additional/faq.html
Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups Akka
User List group.
To unsubscribe from this group and stop receiving emails from it, send an email
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] When to create new actors vs. re-use
Sure, but Björn pointed out above that doing it this way prevents me from scaling out to multiple servers. If the end goal is to have at least the leaf nodes of the tree be processed in a distributed manner (in a pool across multiple servers), what's the best way to achieve that? On Tuesday, September 30, 2014 6:23:04 AM UTC+2, atomly wrote: To answer your basic question, Actors are cheap to create and you shouldn't really worry about reusing them. You should use as many of them as is necessary to make your code function properly while being easy to write/maintain. It sounds like an Actor per-Node, as you have implemented, is easiest for you and there is no problem with writing your code that way from an Akka best practices viewpoint, so you might as well continue with it. :: atomly :: [ ato...@atomly.com javascript: : www.atomly.com : http://blog.atomly.com/ ... [ atomiq records : new york city : +1.347.692.8661 ... [ e-mail atomly-new...@atomly.com javascript: for atomly info and updates ... On Thu, Sep 25, 2014 at 1:08 PM, Idris Mokhtarzada idr...@gmail.com javascript: wrote: Hi, I'm just starting to tinker with Akka, so forgive my ignorance. I'm having trouble determining when I should be creating new actors every time vs. re-using actors and maybe running them in round-robin pools or something. Below is my use case.. any advice would be very helpful. This is a Spring MVC webapp, and I'm using Akka to traverse a tree which is associated with some user data. These trees have 4 different node types (including the root), so I have the following actor classes defined: - Root: 1 actor class for the root node.. this basically calls the Children actor below - Children: 1 actor class to process the children of internal nodes - Leaf: 1 actor class to process the leaf nodes As I traverse the tree, each actor is generating some HTML and sending back to the parent. At the Children nodes, these are concatenated together and sent back to the parent. The advantage I'd like to gain with Akka is I'd like to be able to scale processing of the leaf nodes horizontally, to multiple threads, and possibly multiple servers. Currently, at every node in the tree, I'm calling context.actorOf(...) to get the child actors. My question is whether I should be doing that, or whether it's better to call context.actorOf(...) only ONCE per actor TYPE, and then setup a routing pool to scale. More generally, when do you want to create new actors vs. re-use actors from a pool? Any help on this topic would be greatly appreciated. Thanks! Idris -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+...@googlegroups.com javascript:. To post to this group, send email to akka...@googlegroups.com javascript:. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout. -- 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] Routing to subset of children
Excellent.. Thanks. On Wed, Oct 1, 2014 at 1:00 AM, Roland Kuhn goo...@rkuhn.info wrote: 1 okt 2014 kl. 03:45 skrev Richard Rodseth rrods...@gmail.com: Thanks, Konrad. I have a little test working, but I'm puzzled by one thing. If all I want to do is subscribe to individual channel ids (Longs, not Strings), the SubChannelClassification doesn't seem appropriate. But the LookupClassification requires overriding mapSize, which makes me think it's not suitable since I have a large range of possible channelIds. I wouldn’t read too much into the mapSize parameter: the underlying Index uses a ConcurrentHashMap and this parameter defines the number of buckets, which also determines how fine-grained the locking of the hash space is partitioned, so having lots of IDs is not a problem—it is more about how many IDs you expect to register and look up concurrently. Regards, Roland I can certainly synthesize a string classifier like /event/channel-id, but I thought I'd ask. On Mon, Sep 8, 2014 at 12:04 AM, Konrad Malawski kt...@typesafe.com wrote: Hi guys, exactly, I'd go with an Subchannel classification EventBus in this case. This way you can even define hierarchies of these topics the actors are interested in. You may also enjoy this article by Ben Howell which we've featured on letitcrash.com http://letitcrash.com/post/83622461507/publish-subscribe-using-akka-eventbus some time ago: http://www.benhowell.net/examples/2014/04/23/scala_and_the_akka_event_bus/ Happy hakking! On Sat, Sep 6, 2014 at 7:18 PM, Richard Rodseth rrods...@gmail.com wrote: Thanks. For those, following along, this is helpful: http://www.kotancode.com/tag/event-bus/ On Sat, Sep 6, 2014 at 1:09 AM, Martynas Mickevičius martynas.mickevic...@typesafe.com wrote: Hello Richard, I think Event Bus http://doc.akka.io/docs/akka/2.3.6/scala/event-bus.html can help you there where children can subscribe to an interested channel on a bus. On Fri, Sep 5, 2014 at 11:44 PM, Richard Rodseth rrods...@gmail.com wrote: Suppose I have messages containing a channel id coming to a parent actor. There are many children, each of which is interested in one or more channels. In other words, a channel message needs to be dispatched to a subset of the children. I'm aware of ActorSelection and have looked at the routing docs, but neither seemed to fit. I could maintain a Map in the parent from channelid to list of actor paths, or I could send each message to all children. Am I missing anything? Thanks in advance. -- 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. -- Cheers, Konrad 'ktoso' Malawski hAkker @ Typesafe http://typesafe.com/ -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To
Re: [akka-user] Bridging spray router and service actors
Thanks for clarifying. I was using the version of complete I showed in
order to have control over the status code etc, but there are no doubt
other ways to do that in Spray.
My takeaway is that I shouldn't be too hasty about standardizing on
per-request actors.
On Wed, Oct 1, 2014 at 2:13 AM, Akka Team akka.offic...@gmail.com wrote:
Hi Richard,
No, I mean the other complete() method that you call from the Success and
Failure paths of the onComplete block. Why not just use
complete(result.transform(...))?
-Endre
On Wed, Oct 1, 2014 at 2:01 AM, Richard Rodseth rrods...@gmail.com
wrote:
Hi Endre
Yes, the one I showed (onComplete()) *is* taking a future. The result of
my ask is a Future[Long].
On Tue, Sep 30, 2014 at 3:58 AM, Akka Team akka.offic...@gmail.com
wrote:
Hi Richard,
The route looks something like this:
post {
val result = (xyzService ?
XYZService.CreateXYZ(xyzAttributes)).mapTo[Long]
onComplete(result) {
case Success(value) = complete(sThe result was $value)
case Failure(ex) = complete(StatusCodes.InternalServerError,
sAn error occurred: ${ex.getMessage})
}
Isn't there a version of complete() that take a Future directly? (maybe
called completeAsynch, but I think there should be one). I am not sure
calling complete() out of the context of the actor works or not.
-Endre
}
In this case the XYZService actor forwards a transformed message to the
DbActor
case msg @ XYZService. CreateXYZ(attributes) = {
dbActor forward DbActor.AddXYZ(attributes) // Interesting that I
can forward a new message
}
If the response needed transforming, presumably an additional ask would
be needed within the XYZService.
The DbActor replies with a result
case AddXYZ(attributes) = db withSession { implicit session =
try {
val result = XYZDAO.add(attributes)
sender() ! result
} catch {
case e: Exception =
sender() ! akka.actor.Status.Failure(e)
throw e
}
}
Does this seem reasonable? Would it be considered better practice to
use per-request actors for every route, to avoid the use of tell, or
somehow pass the request context to the service actor for completion? I've
read the Ian Forsey article, but am a bit unclear on whether to standardize
on the per-request model. I did notice that the route I implemented using
per-request is slow on all but the first request, and I haven't had time to
look into that.
--
Read the docs: http://akka.io/docs/
Check the FAQ:
http://doc.akka.io/docs/akka/current/additional/faq.html
Search the archives:
https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google
Groups Akka User List group.
To unsubscribe from this group and stop receiving emails from it, send
an email to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
--
Akka Team
Typesafe - The software stack for applications that scale
Blog: letitcrash.com
Twitter: @akkateam
--
Read the docs: http://akka.io/docs/
Check the FAQ:
http://doc.akka.io/docs/akka/current/additional/faq.html
Search the archives:
https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google
Groups Akka User List group.
To unsubscribe from this group and stop receiving emails from it, send
an email to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
--
Read the docs: http://akka.io/docs/
Check the FAQ:
http://doc.akka.io/docs/akka/current/additional/faq.html
Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups
Akka User List group.
To unsubscribe from this group and stop receiving emails from it, send an
email to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
--
Akka Team
Typesafe - The software stack for applications that scale
Blog: letitcrash.com
Twitter: @akkateam
--
Read the docs: http://akka.io/docs/
Check the FAQ:
http://doc.akka.io/docs/akka/current/additional/faq.html
Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups
Akka User List group.
To unsubscribe from this group and stop receiving emails from it, send an
email to
Re: [akka-user] Bridging spray router and service actors
This looks interesting. Future.collect. Learn something new every day.
http://www.superloopy.io/articles/2013/spray-routing-error-handling.html
On Wed, Oct 1, 2014 at 11:00 AM, Richard Rodseth rrods...@gmail.com wrote:
Thanks for clarifying. I was using the version of complete I showed in
order to have control over the status code etc, but there are no doubt
other ways to do that in Spray.
My takeaway is that I shouldn't be too hasty about standardizing on
per-request actors.
On Wed, Oct 1, 2014 at 2:13 AM, Akka Team akka.offic...@gmail.com wrote:
Hi Richard,
No, I mean the other complete() method that you call from the Success and
Failure paths of the onComplete block. Why not just use
complete(result.transform(...))?
-Endre
On Wed, Oct 1, 2014 at 2:01 AM, Richard Rodseth rrods...@gmail.com
wrote:
Hi Endre
Yes, the one I showed (onComplete()) *is* taking a future. The result of
my ask is a Future[Long].
On Tue, Sep 30, 2014 at 3:58 AM, Akka Team akka.offic...@gmail.com
wrote:
Hi Richard,
The route looks something like this:
post {
val result = (xyzService ?
XYZService.CreateXYZ(xyzAttributes)).mapTo[Long]
onComplete(result) {
case Success(value) = complete(sThe result was $value)
case Failure(ex) = complete(StatusCodes.InternalServerError,
sAn error occurred: ${ex.getMessage})
}
Isn't there a version of complete() that take a Future directly? (maybe
called completeAsynch, but I think there should be one). I am not sure
calling complete() out of the context of the actor works or not.
-Endre
}
In this case the XYZService actor forwards a transformed message to
the DbActor
case msg @ XYZService. CreateXYZ(attributes) = {
dbActor forward DbActor.AddXYZ(attributes) // Interesting that
I can forward a new message
}
If the response needed transforming, presumably an additional ask
would be needed within the XYZService.
The DbActor replies with a result
case AddXYZ(attributes) = db withSession { implicit session =
try {
val result = XYZDAO.add(attributes)
sender() ! result
} catch {
case e: Exception =
sender() ! akka.actor.Status.Failure(e)
throw e
}
}
Does this seem reasonable? Would it be considered better practice to
use per-request actors for every route, to avoid the use of tell, or
somehow pass the request context to the service actor for completion? I've
read the Ian Forsey article, but am a bit unclear on whether to
standardize
on the per-request model. I did notice that the route I implemented using
per-request is slow on all but the first request, and I haven't had time
to
look into that.
--
Read the docs: http://akka.io/docs/
Check the FAQ:
http://doc.akka.io/docs/akka/current/additional/faq.html
Search the archives:
https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google
Groups Akka User List group.
To unsubscribe from this group and stop receiving emails from it, send
an email to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
--
Akka Team
Typesafe - The software stack for applications that scale
Blog: letitcrash.com
Twitter: @akkateam
--
Read the docs: http://akka.io/docs/
Check the FAQ:
http://doc.akka.io/docs/akka/current/additional/faq.html
Search the archives:
https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google
Groups Akka User List group.
To unsubscribe from this group and stop receiving emails from it, send
an email to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
--
Read the docs: http://akka.io/docs/
Check the FAQ:
http://doc.akka.io/docs/akka/current/additional/faq.html
Search the archives:
https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google
Groups Akka User List group.
To unsubscribe from this group and stop receiving emails from it, send
an email to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
--
Akka Team
Typesafe - The software stack for applications that scale
Blog: letitcrash.com
Twitter: @akkateam
--
Read the docs: http://akka.io/docs/
Check the FAQ:
http://doc.akka.io/docs/akka/current/additional/faq.html
Search the archives:
[akka-user] draining daemon system actors' queues on shutdown
How to drain daemon system actors' queues on system exit? -- 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] Running Akka cluster in docker or decouple node identification from host and
Dear all, When running our Akka cluster in docker we need to bind netty to 0.0.0.0 to make it accessible to the outside of the container and binding to the external ip of the docker host is not possible. However, the seed node uri needs to point to the external ip in order to connect to the seed nodes. Consequently, the seed node drops the messages from joining nodes because it thinks they are not meant for him. Is there an existing solution to this issue? One of the solutions would be to use host names and change the ip addresses through the hosts file. This would be very cumbersome for us to maintain. Would it be sensible to include a different variable that is used to configure the identifier of the node such that it is decoupled from the hostname used to bind the network interface? Cheers, Alessandro -- 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: draining daemon system actors' queues on shutdown
I must clarify saying draining I mean giving to all system's actors some duration to process all already sent messages. -- 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] draining daemon system actors' queues on shutdown
Hello Andrew, you might find “the Reaper” pattern of interest to you: http://letitcrash.com/post/30165507578/shutdown-patterns-in-akka-2 -- Konrad 'ktoso' Malawski hAkker @ typesafe http://akka.io -- 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] draining daemon system actors' queues on shutdown
Konrad, great, thanks! - will dig in... -- 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.
