Re: [akka-user] Design Help: Async Listener
Yes it is definitely possible, if you use akka-remote and akka-cluster then it works seamlessly (in fact that is one of the main features of those -- to maintain location transparency of ActorRefs). -Endre On Tue, Jan 21, 2014 at 12:28 AM, Rob Withers reefed...@gmail.com wrote: On Jan 20, 2014, at 3:57 PM, Rob Withers reefed...@gmail.com wrote: [crop] Akka will do nicely here, perhaps by passing the ActorRef to Actor-B in the original send. Is this even possible, to pass an ActorRef remotely? - charlie -- Read the docs: http://akka.io/docs/ Check the FAQ: http://akka.io/faq/ 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/groups/opt_out. -- 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://akka.io/faq/ 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/groups/opt_out.
Re: [akka-user] [Java] Registering Actors with Guice
Hi Chanan,
Nice to see that you were able to solve what you wanted.
I have one concern, please correct me if I have misunderstood the
implementation. This solution encourage creating lots of top level actors
without proper supervisor hierarchy. ActorScanner creates top level actors
for all UntypedActor classes it finds. That might be what you want, and can
be fine for a few entry points, but I think it should be clearly stated in
the documentationhttps://github.com/chanan/AkkaGuice/blob/master/README.md
that
this is not the Akka way of forming supervision
hierarchieshttp://doc.akka.io/docs/akka/2.2.3/java/fault-tolerance.htmlto
handle failures.
Regards,
Patrik
On Fri, Jan 17, 2014 at 8:14 AM, Patrik Nordwall
patrik.nordw...@gmail.comwrote:
Thanks for sharing. I will take a closer look next week.
/Patrik
On Thu, Jan 16, 2014 at 2:15 PM, Chanan Braunstein chan...@gmail.comwrote:
Hi Patrik, Roland anyone else that wants to take a look,
I created a Play module (with a sample project) register actor
automatically with Guice: https://github.com/chanan/AkkaGuice
Would you mind taking a look and giving feedback?
Thanks,
Chanan.
On Saturday, January 11, 2014 4:22:47 PM UTC-5, Chanan Braunstein wrote:
Hi Patrik,
There are a few reasons why I don't want the actors defined and
instantiated inside the controller. For example, for testing purposes, I
would like to pass in to the controller a probe so we can write good unit
tests.
Thanks for the link to the Spring-Java Activator. I think something
like: https://github.com/typesafehub/activator-akka-
java-spring/blob/master/src/main/java/sample/SpringExtension.java for
Guice is what I am looking for. Does anyone have one already? If not, I
will attempt to write one.
Chanan.
On Saturday, January 11, 2014 9:48:41 AM UTC-5, Patrik Nordwall wrote:
Hi Chanan,
On Fri, Jan 10, 2014 at 7:24 PM, Chanan Braunstein cha...@gmail.comwrote:
Hi Roland,
Thanks for your reponse. I do think what I am trying to do is correct.
The purpose of what I am asking for is not to inject ActorRef's into
Actors. It is to inject ActorRef's into Play Controllers.
Why is it important to inject the the ActorRefs into Play Controllers?
Why not create the actors there (using IndirectActorProducer) or in an Akka
extension http://doc.akka.io/docs/akka/2.2.3/java/extending-akka.html
?
Have you looked at the Typesafe Activator Akka Spring
templatehttp://typesafe.com/activator/template/akka-java-spring
?
Regards,
Patrik
We already do so by Manually Creating the provider functions in the
GuiceModule. However this problematic since we cannot
use IndirectActorProducer if we do that.
So here is the code example:
public class GuiceModule extends AbstractModule {
@Override
protected void configure() {
//bind code goes here
}
@Provides @Named(NewAppActor)
ActorRef getNewAppActor() {
return Akka.system().actorOf(NewAppActor.Props(), NewAppActor);
//This should be using IndirectActorProducer but it cannot since the
injector does not exist yet
}
}
And a Play controller:
public class Application extends Controller {
private final ActorRef newAppActor;
@Inject
public Application(@Named(NewAppActor) ActorRef newAppActor) {
this.newAppActor = newAppActor;
}
...
}
So to sum up, there is one actual problem and one nice to have
(although solving the nice to have would actually solve the problem as
well):
1. Problem: Inside GuiceModule, I do not have access to Injector, so
we cannot use IndirectActorProducer to create the ActorRef, so we
cannot use injection in that Actor.
2. Nice to have: It would be nice if we can scan our code, find all
the actors and register them in GuiceModule. This can use
IndirectActorProducer if the scanning happens after the injector is
created.
I already have code that scans the code for certain actors that are
marked as needing scheduling and starts them via the scheduler, so I was
wondering if someone already solved this same issue I am facing. There was
that mention on stackoverflow as I said, but I couldn't find the code they
mentioned.
On Friday, January 10, 2014 4:46:37 AM UTC-5, rkuhn wrote:
Hi Chanan,
I’ll leave more specific points to Patrik, but I’d like to remark on
the general strategy. Injecting resources into Actors for their use is a
very reasonable thing to do, which is why IndirectActorProducer exists.
Creating actors, however, is something which inherently must always be
done
by another actor in order to properly define the supervision hierarchy.
Guice cannot really do that, because an ActorSystem is its own
encapsulated
container and apart from the unfortunate exception of `system.actorOf()`
Guice cannot drive the creation—it can only be involved by the parent
actor
as you are doing it. As a side note, I dream of a world where
system.actorOf() is deprecated and eventually removed, simply because it
is
such a gross and
Re: [akka-user] Why AKKA clusters
Hi! On Tue, Jan 21, 2014 at 8:19 AM, d...@coinport.com wrote: I've been following AKKA for quite some time, but I'm confused what's the purpose of a cluster, in what aspect does it differ form the remote model. In the very beginning, I thought in one cluster there will only be one Akka system whose single actor tree will be partitioned magically into different nodes, but later I found it's not the case. It seems to me each node may have one or more actor systems and they don't interfere with each other nor with actor systems of the same name on other nodes. Yes that is correct, and the reason why we dropped the idea of a unified actor tree is exactly that word: magic. We discussed it quite extensively and we found that it is not as useful as it seems, and not the right abstraction level (and would be a _very_ leaky abstraction anyway). So the question again, why akka Cluster and what problems can it solve? Akka clustering provides distributed membership of the participant actor systems and manages their lifecylce (joining, detecting unreachable nodes, removing nodes, etc, all without a dedicated master node). In pure remoting you have to know somehow the systems that are part of the large compound, and you have to manage these addresses manually (which is hard to do reliably). Clustering, just like remoting abstracts away location of ActorRefs, so all actors look the same independently whether they are local or on another member of the cluster. On top of membership there are various useful tools: - cluster aware routers that can add or remove routees as nodes join or leave - cluster singletons that are guaranteed to be unique in a cluster and started up on a new node if the node containing the singleton fail - various tools on top of persistence+cluster like sharding, which distributes a set of stateful entities across cluster members and manages their failover. -Endre -- Read the docs: http://akka.io/docs/ Check the FAQ: http://akka.io/faq/ 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/groups/opt_out. -- 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://akka.io/faq/ 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/groups/opt_out.
Re: [akka-user] Remote DeathWatch and comms failure
At some point you just have to move on... On Jan 21, 2014 9:44 AM, Akka Team akka.offic...@gmail.com wrote: Hi Alistair, On Tue, Jan 21, 2014 at 8:38 AM, Alistair George alistairgeor...@gmail.com wrote: Hi Akka, Thanks for the reply. One question: if (in 2.3) a remote actor system becomes permanently quarantined, what do I have to do to re-establish communication once the comms problem is fixed? First of all, quarantining is a state where it is not considered just a communications problem but the remote system is declared dead (it is declared, not proven since all we know that it does not reply). Short communication failures do not trigger quarantine (what is considered short is configurable). Do I have to restart the remote actor system? Or the local one? Or both? From the remoting viewpoint it does not matter which one you restart. Obviously if one of the systems genuinely crashed then that is the one to be restarted, otherwise it is application specific. -Endre Cheers Alistair On Monday, January 20, 2014 12:41:25 PM UTC, Akka Team wrote: Hi Alistair, On Thu, Jan 16, 2014 at 9:30 AM, Alistair George alistai...@gmail.comwrote: If I set up a watch on a remote actor (one on a remote actor system) and the network between me and the remote system fails, I get a Terminated message almost immediately. In fact, the remote actor hasn't terminated, That does not matter. If you use remote DeathWatch, and one of the systems gets unreachable for enough time it will eventually fire Terminated for all the watched actors on the remote system and then quarantines that system so it never comes back again. The deathwatch failure detector (akka.remote.watch-failure-detector) settings controls how sensitive is this decision. If you think that a 1 hour unreachability should be not considered terminal, then you should configure those settings correspondingly. and I can still use the ActorRef to send messages to it once comms are restored. (However, if comms fail a second time I don't get a second Terminated message.) This is because we made the mistakes in 2.2.x: - we made quarantine times configurable - we set it to a low value, 60 seconds After the quarantine elapses the systems can communicate again, regardless of the Terminated message, probably this is what you observed -- and this is exactly why quarantine in 2.3 is permanent. Terminated and lost contact are rather different states, and may need different handling. Does anyone know of a reliable way I can distinguish these? DeathWatch sends Terminated in the case the remote system is in lost contact state for a long time. How long is that time is configurable by the DeathWatch failure detector. lost contact events are generated as remote lifecycle events, but I don't recommend using those directly. Message send supposed to be lossy, you can track reachability in your user layer by some heartbeating mechanism if you want it. Btw, there is another failure detector (akka.remote.transport-failure-detector) that monitors the health of network connections, but it does not generate Terminated events, only reconnect attempts. In 2.3 clustering will differentiate between UNREACHABLE events (which can heal) from removals. You probably want to use those features instead of plain remoting. Thanks Alistair -- Read the docs: http://akka.io/docs/ Check the FAQ: http://akka.io/faq/ 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/groups/opt_out. -- 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://akka.io/faq/ 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/groups/opt_out. -- 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://akka.io/faq/ Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups
[akka-user] Actor selection wildcard
What is actually matched when using a wildcard such as * ? Is it the actors that match the pattern _now_ , or is it the actors that match the pattern _over time_. that is, is it a snapshot of actors at the time when the selection was applied, or does it mean a concurrent mutating child collection //Roger -- Read the docs: http://akka.io/docs/ Check the FAQ: http://akka.io/faq/ 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/groups/opt_out.
[akka-user] Re: ANNOUNCE: Akka 2.3.0-RC1 (RELEASE CANDIDATE)
So 2.3.0 will be released without IO at all. Have I missed something? -- Read the docs: http://akka.io/docs/ Check the FAQ: http://akka.io/faq/ 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/groups/opt_out.
Re: [akka-user] Actor selection wildcard
It's always when it is applied, it's not a temporal query. On Tue, Jan 21, 2014 at 10:54 AM, Roger Alsing rogerals...@gmail.comwrote: What is actually matched when using a wildcard such as * ? Is it the actors that match the pattern _now_ , or is it the actors that match the pattern _over time_. that is, is it a snapshot of actors at the time when the selection was applied, or does it mean a concurrent mutating child collection //Roger -- Read the docs: http://akka.io/docs/ Check the FAQ: http://akka.io/faq/ 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/groups/opt_out. -- Cheers, √ *———**Viktor Klang* *Chief Architect - **Typesafe http://www.typesafe.com/* Twitter: @viktorklang -- Read the docs: http://akka.io/docs/ Check the FAQ: http://akka.io/faq/ 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/groups/opt_out.
Re: [akka-user] Remote DeathWatch and comms failure
On Tuesday, January 21, 2014 8:44:17 AM UTC, Akka Team wrote: Hi Alistair, On Tue, Jan 21, 2014 at 8:38 AM, Alistair George alistai...@gmail.comjavascript: wrote: Hi Akka, Thanks for the reply. One question: if (in 2.3) a remote actor system becomes permanently quarantined, what do I have to do to re-establish communication once the comms problem is fixed? First of all, quarantining is a state where it is not considered just a communications problem but the remote system is declared dead (it is declared, not proven since all we know that it does not reply). Short communication failures do not trigger quarantine (what is considered short is configurable). Do I have to restart the remote actor system? Or the local one? Or both? From the remoting viewpoint it does not matter which one you restart. Obviously if one of the systems genuinely crashed then that is the one to be restarted, otherwise it is application specific. I'm not sure this is desirable behaviour. I shouldn't have to restart a process just to recover from a comms failure. After all, nothing in the process has failed, and it may be providing services to other clients that have not suffered any comms failure. They shouldn't have to take the impact of a restart. One of the strengths of Akka is that it doesn't pretend to do things that can't be done in a distributed context - this is essential for transparent distribution. One of this things you can't do distributed is give reliable, timely notification of a remote event, such as actor termination, and I don't think Akka should try. What I'd prefer is this: - Reconnect attempts should continue indefinitely. - The DeathWatch protocol should be extended to include (possibly multiple) Reachable/Unreachable events. - Terminate should only be delivered when the remote actor system is reachable and asserts that the watched actor does not exist. This might never happen: an actor might stay in an unreachable state forever. I realise I can emulate this by setting the timeout before quarantine to be effectively infinite, and adding my own facility to detect reachability and termination, but this isn't trivial. I'd prefer this behaviour to be available out of the box, for both practical and conceptual reasons. Just my $.02 Cheers Alistair -Endre Cheers Alistair On Monday, January 20, 2014 12:41:25 PM UTC, Akka Team wrote: Hi Alistair, On Thu, Jan 16, 2014 at 9:30 AM, Alistair George alistai...@gmail.comwrote: If I set up a watch on a remote actor (one on a remote actor system) and the network between me and the remote system fails, I get a Terminated message almost immediately. In fact, the remote actor hasn't terminated, That does not matter. If you use remote DeathWatch, and one of the systems gets unreachable for enough time it will eventually fire Terminated for all the watched actors on the remote system and then quarantines that system so it never comes back again. The deathwatch failure detector (akka.remote.watch-failure-detector) settings controls how sensitive is this decision. If you think that a 1 hour unreachability should be not considered terminal, then you should configure those settings correspondingly. and I can still use the ActorRef to send messages to it once comms are restored. (However, if comms fail a second time I don't get a second Terminated message.) This is because we made the mistakes in 2.2.x: - we made quarantine times configurable - we set it to a low value, 60 seconds After the quarantine elapses the systems can communicate again, regardless of the Terminated message, probably this is what you observed -- and this is exactly why quarantine in 2.3 is permanent. Terminated and lost contact are rather different states, and may need different handling. Does anyone know of a reliable way I can distinguish these? DeathWatch sends Terminated in the case the remote system is in lost contact state for a long time. How long is that time is configurable by the DeathWatch failure detector. lost contact events are generated as remote lifecycle events, but I don't recommend using those directly. Message send supposed to be lossy, you can track reachability in your user layer by some heartbeating mechanism if you want it. Btw, there is another failure detector (akka.remote.transport-failure-detector) that monitors the health of network connections, but it does not generate Terminated events, only reconnect attempts. In 2.3 clustering will differentiate between UNREACHABLE events (which can heal) from removals. You probably want to use those features instead of plain remoting. Thanks Alistair -- Read the docs: http://akka.io/docs/ Check the FAQ: http://akka.io/faq/ Search the archives: https://groups.google.com/ group/akka-user --- You received this message because you are
[akka-user] Akka.2.2.3 : Is there any way to mark a node from unreachable state to reachable in order to make it cluster member again.
Hi All, We are using akka cluster 2.2.3 in our project. During a highly memory intensive operation cluster nodes start seeing each other as unreachable. We perform a memory intensive operation across cluster which takes time as well as garbage collection occurs on each node. Is there any way to mark a node from unreachable state to reachable in order to make it cluster member again. Can it be done using configuration or programmatically. Thanks in advance. -- Read the docs: http://akka.io/docs/ Check the FAQ: http://akka.io/faq/ 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/groups/opt_out.
Re: [akka-user] Remote DeathWatch and comms failure
We respectfully disagree then. Akka's design in this regard is highly deliberate. On Jan 21, 2014 12:35 PM, Alistair George alistairgeor...@gmail.com wrote: On Tuesday, January 21, 2014 8:44:17 AM UTC, Akka Team wrote: Hi Alistair, On Tue, Jan 21, 2014 at 8:38 AM, Alistair George alistai...@gmail.comwrote: Hi Akka, Thanks for the reply. One question: if (in 2.3) a remote actor system becomes permanently quarantined, what do I have to do to re-establish communication once the comms problem is fixed? First of all, quarantining is a state where it is not considered just a communications problem but the remote system is declared dead (it is declared, not proven since all we know that it does not reply). Short communication failures do not trigger quarantine (what is considered short is configurable). Do I have to restart the remote actor system? Or the local one? Or both? From the remoting viewpoint it does not matter which one you restart. Obviously if one of the systems genuinely crashed then that is the one to be restarted, otherwise it is application specific. I'm not sure this is desirable behaviour. I shouldn't have to restart a process just to recover from a comms failure. After all, nothing in the process has failed, and it may be providing services to other clients that have not suffered any comms failure. They shouldn't have to take the impact of a restart. One of the strengths of Akka is that it doesn't pretend to do things that can't be done in a distributed context - this is essential for transparent distribution. One of this things you can't do distributed is give reliable, timely notification of a remote event, such as actor termination, and I don't think Akka should try. What I'd prefer is this: - Reconnect attempts should continue indefinitely. - The DeathWatch protocol should be extended to include (possibly multiple) Reachable/Unreachable events. - Terminate should only be delivered when the remote actor system is reachable and asserts that the watched actor does not exist. This might never happen: an actor might stay in an unreachable state forever. I realise I can emulate this by setting the timeout before quarantine to be effectively infinite, and adding my own facility to detect reachability and termination, but this isn't trivial. I'd prefer this behaviour to be available out of the box, for both practical and conceptual reasons. Just my $.02 Cheers Alistair -Endre Cheers Alistair On Monday, January 20, 2014 12:41:25 PM UTC, Akka Team wrote: Hi Alistair, On Thu, Jan 16, 2014 at 9:30 AM, Alistair George alistai...@gmail.comwrote: If I set up a watch on a remote actor (one on a remote actor system) and the network between me and the remote system fails, I get a Terminated message almost immediately. In fact, the remote actor hasn't terminated, That does not matter. If you use remote DeathWatch, and one of the systems gets unreachable for enough time it will eventually fire Terminated for all the watched actors on the remote system and then quarantines that system so it never comes back again. The deathwatch failure detector (akka.remote.watch-failure-detector) settings controls how sensitive is this decision. If you think that a 1 hour unreachability should be not considered terminal, then you should configure those settings correspondingly. and I can still use the ActorRef to send messages to it once comms are restored. (However, if comms fail a second time I don't get a second Terminated message.) This is because we made the mistakes in 2.2.x: - we made quarantine times configurable - we set it to a low value, 60 seconds After the quarantine elapses the systems can communicate again, regardless of the Terminated message, probably this is what you observed -- and this is exactly why quarantine in 2.3 is permanent. Terminated and lost contact are rather different states, and may need different handling. Does anyone know of a reliable way I can distinguish these? DeathWatch sends Terminated in the case the remote system is in lost contact state for a long time. How long is that time is configurable by the DeathWatch failure detector. lost contact events are generated as remote lifecycle events, but I don't recommend using those directly. Message send supposed to be lossy, you can track reachability in your user layer by some heartbeating mechanism if you want it. Btw, there is another failure detector (akka.remote.transport-failure-detector) that monitors the health of network connections, but it does not generate Terminated events, only reconnect attempts. In 2.3 clustering will differentiate between UNREACHABLE events (which can heal) from removals. You probably want to use those features instead of plain remoting. Thanks Alistair -- Read the docs: http://akka.io/docs/ Check the FAQ: http://akka.io/faq/ Search the
Re: [akka-user] Play, Spray, ...
Charlie, doing DB calls in Spray has nothing special or different from what you would do with plain Akka, Play or any other toolkit. Certainly, there is a preference for using async and non-blocking drivers, but that is not a requisite. What really matters in case you are doing blocking calls to a database (using JDBC, for example) is that you set up a dedicated dispatcher (like a thread-pool) to be used by those blocking tasks. That way the blocking part of your app wont eat all the threads and starve the rest of the components. With regards to managing and monitoring, of course the first option would be the Typesafe Console [1], built by the same people working in Akka/Play. Also, there is a project we are working on right now [2], focused in Akka and Spray (Play support might arrive in the future).. we are in the process of tidying up the basic set of features and writing docs for our first public release which will get out very soon. Last, but not least, there is the monitor [3] tool for Akka created by the Cake Solutions team (correct me if I'm wrong!) which is also open source. Hope this info helps! best regards!. [1] http://typesafe.com/platform/runtime/console [2] http://kamon.io [3] https://github.com/eigengo/monitor On Tue, Jan 21, 2014 at 11:27 AM, Pascal Voitot Dev pascal.voitot@gmail.com wrote: I'm not an expert in Spray in prod (more Play experience) but there are a few articles you can find on Google on how to monitor an Akka app... You've got Typesafe Console naturally which is specifically dedicated to this and a few tools to add on top of Akka! Other people might have far better advices than mine on this point! Pascal On Tue, Jan 21, 2014 at 3:18 PM, charlie robert reefed...@gmail.comwrote: Oh, yes, could you also mention about management and monitoring with Spray, as well? - charlie On Jan 21, 2014, at 7:15 AM, charlie robert reefed...@gmail.com wrote: Hi pascal, This sounds promising. However, our kafka consumers need to do some DB calls, but in a high volume sort of way. Could you say a few words about database interactions in Spray? thanks, charlie On Jan 21, 2014, at 1:03 AM, Pascal Voitot Dev pascal.voitot@gmail.com wrote: Yes clearly you can get rid of servlet stuff and go to frameworks like Play or Spray! Spray is more low-level and is better if you want pure REST (more is possible too but it's more manual than Play). It's also 100% actor based with akka.io Play is full-stack and can help if you want more than just REST (it provides everything to build web apps)... It uses Netty for now as network layer (spray will be integrated later) and doesn't rely on actors for network part (you can use actors in your application) Both are performant. In terms of connection pooling, you won't manage it anymore as with servlets as you'll enter the world of stateless/non-blocking/async where you have a very few threads switching very quickly instead of a big pool like servlets. So you have to stop thinking about sticky sessions, stateful sessions and blocking code etc... But it brings real benefits, you'll see ;) pascal On Tue, Jan 21, 2014 at 3:28 AM, Robert Withers reefed...@gmail.comwrote: Which Akka-based REST servers include support for connection pooling, without a Servlet 3.0 container? It may be fun to ditch Tomcat. We had an issue where multiple jars were stomping on each other and the WAR was exiting with no information. 2 weeks of team investigation finally identified the setting that needed to change…turn off string-encodings in wily. If Play or Spray can match performance, connection pooling and log configuration, it would be an option for a proof-of-concept. Any recommendations? Thanks, - charlie - robert -- Read the docs: http://akka.io/docs/ Check the FAQ: http://akka.io/faq/ 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/groups/opt_out. -- Read the docs: http://akka.io/docs/ Check the FAQ: http://akka.io/faq/ 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/groups/opt_out. -- Read the docs:
[akka-user] What happend to the IO stack between 2.3M2 and 2.3RC1 ???
Hello, I've started to migrate from 2.3.M2 API to the RC1 and I have some very bad surprises on the IO API side. It looks like you've removed a LOT of things here is a list of classes that are missing between M2 and RC1 : akka.io.AbstractSymmetricPipePair; akka.io.PipePairFactory; akka.io.SymmetricPipePair; akka.io.SymmetricPipelineStage; akka.io.BackpressureBuffer.*; akka.io.PipelineStage; akka.io.TcpPipelineHandler.*; akka.io.TcpReadWriteAdapter; We have build a lots of things around theses classes with your new IO stack. Do I have to understand that we have to trash weeks of work and rewrite everything or do you have a package that still supports these classes ? Regards C.Munger -- Read the docs: http://akka.io/docs/ Check the FAQ: http://akka.io/faq/ 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/groups/opt_out.
Re: [akka-user] Debug akka code in intellij (Java)
Hey Viktor, Just for the sake of clarity, If I send a byte[], Akka wont call any serializer and just send the message as is, but if its an Object then it would call the serializer class and serialize the message before sending it right. Best Vj On Monday, January 20, 2014 3:37:32 PM UTC-8, √ wrote: Hi Vijay, What seems to be the problem? Cheers, V On Jan 20, 2014 11:27 PM, vijay krishna vijaycapr...@gmail.comjavascript: wrote: Hello, I am trying to debug Akka code to see how the tell() function works. Any recommendation on how I can do that? I am working with Java Thanks, Vijay -- Read the docs: http://akka.io/docs/ Check the FAQ: http://akka.io/faq/ 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/groups/opt_out. -- Read the docs: http://akka.io/docs/ Check the FAQ: http://akka.io/faq/ 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/groups/opt_out.
[akka-user] unhandled messages in akka 2.0.5
Hi all, I'm constrained to Scala 2.9.2 and Akka 2.0.5 on my project and I am confused how unhandled messages are intended to be logged. It seems that in order to get any form of logging, the receive method must use the LoggingReceive wrapper. This then shows handled and unhandled messages in the logs thanks to akka.actor.debug.receive. This is a bit of a pain as I'd rather not have to use a wrapper in the code to enable logging, I'd expect it to be a purely configuration setting. But even without the LoggingReceive, the unhandled messages are being sent to context.system.eventStream.publish(UnhandledMessage(message, sender, self)) from the Actor's default unhandled body. But this never seems to be logged? Changing akka.actor.debug.unhandled does nothing (maybe this was added in 2.1?) nor does changing akka.actor.debug.event-stream. Given that catching unhandled messages is a critical part of the dev / test cycle, I'm really very keen to be able to log these messages. I've resorted to overriding the unhandled method and using the SLF4J logger in there, but what is the correct way to do this? Best regards, Sam -- Read the docs: http://akka.io/docs/ Check the FAQ: http://akka.io/faq/ 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/groups/opt_out.
Re: [akka-user] Akka Development Setup
Any update on this? On Monday, 11 July 2011 06:52:40 UTC+1, Eugene Vigdorchik wrote: Hi Reuben, Deploying to EC2 instances is already implemented in Atmos, which is Akka commercial offering. The deployment is done by publishing to S3 first, and EC2 instances downloading from there. Amazon Elastic Beanstalk is in our plans for future versions. Cheers, Eugene. On Sun, Jul 10, 2011 at 11:17 PM, reuben doetsch reuben@gmail.com javascript: wrote: Hey guys, I currently have an application with a backend API, and then various thin front clients. I am using Akka for some sync backend API processing which does not have to happen in real time and can be paralelized. I want to ask how to best accomplish the following: Right Now I am using Amazon Elastic Beanstalk for the API server and the lift website. Both of these will scale and are nice. What is the best way (using Amazon AWS) to deploy Akka. How can I embed akka into a tomcat instance for elastic beanstalk. Perhaps this is not a good idea because I have a server load balancer and Akka's load balancers. What is the best solution using Akka with Amazon (either Amazon Elastic Bean stalk or multiple EC2 instances)? Am I missing something obvious and very simple? Reuben -- 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.comjavascript: . To unsubscribe from this group, send email to akka-user+...@googlegroups.com javascript:. For more options, visit this group at http://groups.google.com/group/akka-user?hl=en. -- Read the docs: http://akka.io/docs/ Check the FAQ: http://akka.io/faq/ 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/groups/opt_out.
Re: [akka-user] Remote DeathWatch and comms failure
My plan for this was to have a proxy for NodeB watch state in NodeA. In normal (connected) operation it just remembers the current watch states (Actor Ax is/isn't watching Actor By) and passes the messages on to NodeB. If disconnected it just remembers the watch state. On reconnect, it sends a snapshot of the state to NodeB. Because it's remembering state rather than messages it stays bounded. Need to make sure that isn't watching states get pruned, but that's just the usual sequence number/ack stuff (if disconnected, we can prune them immediately, because they don't form part of the snapshot). Cheers Alistair On Tuesday, January 21, 2014 5:57:36 PM UTC, √ wrote: NodeA NodeB are communicating NodeB disappears (not acking) NodeA still has things it needs to propagate to NodeB (watching actors on that node etc), so they need to be buffered, also, if there are ordering requirements it means that other things may not be transmitted/received before other things, so more thing get buffered. At which point does NodeA either A) drop the buffer or B) throw OOME? Cheers, √ On Tue, Jan 21, 2014 at 6:46 PM, Alistair George alistai...@gmail.comjavascript: wrote: I don't see where the unbounded buffer is needed. I'd be grateful for a bit of explanation, especially since it looks like I'm going to have to implement this stuff :) On Tuesday, January 21, 2014 12:40:19 PM UTC, √ wrote: And it also introduces the need for unbounded buffering, i.e. memory leaks. On Tue, Jan 21, 2014 at 1:01 PM, Akka Team akka.o...@gmail.com wrote: Hi Alistair, I'm not sure this is desirable behaviour. I shouldn't have to restart a process just to recover from a comms failure. After all, nothing in the process has failed, and it may be providing services to other clients that have not suffered any comms failure. They shouldn't have to take the impact of a restart. No, restart is not needed to recover from a communications failure, it is needed to recover from the quarantined state. One of the strengths of Akka is that it doesn't pretend to do things that can't be done in a distributed context - this is essential for transparent distribution. One of this things you can't do distributed is give reliable, timely notification of a remote event, such as actor termination, and I don't think Akka should try. What I'd prefer is this: - Reconnect attempts should continue indefinitely. This is actually what happens. Quarantining only happens if you use remote DeathWatch. If this is not the feature you want, you should not use remote deathwatch. The contract of remote DeathWatch is that it eventually produces a Terminated message if the remote actor is dead, at the cost of false positives (i.e. actor is live but remote system was not responding for a long time). You can tune the false positive rate by setting the watch failure detector. You can even set it to trigger after one year. - The DeathWatch protocol should be extended to include (possibly multiple) Reachable/Unreachable events. This is not the purpose of DeathWatch, but you can implement such a thing on your own by sending heartbeats between the related actors. In clustering there is support for Unreachable/Reachable events. - Terminate should only be delivered when the remote actor system is reachable and asserts that the watched actor does not exist. This might never happen: an actor might stay in an unreachable state forever. While that is a useful feature, it is not the purpose of DeathWatch. Clustering has the feature you want, and in general, clustering is recommended over plain remoting. I realise I can emulate this by setting the timeout before quarantine to be effectively infinite, and adding my own facility to detect reachability and termination, but this isn't trivial. I'd prefer this behaviour to be available out of the box, for both practical and conceptual reasons. There is always the akka-contrib area for contributions :) In general, I understand your use case, but DeathWatch does not support it. Many users would be surprised when they watch a remote actor, and kill the node running the system, but no Terminated messages would be generated. And they would argue that is wrong for practical and conceptual reasons :) -Endre Just my $.02 Cheers Alistair -Endre Cheers Alistair On Monday, January 20, 2014 12:41:25 PM UTC, Akka Team wrote: Hi Alistair, On Thu, Jan 16, 2014 at 9:30 AM, Alistair George alistai...@gmail.com wrote: If I set up a watch on a remote actor (one on a remote actor system) and the network between me and the remote system fails, I get a Terminated message almost immediately. In fact, the remote actor hasn't terminated, That does not matter. If you use remote DeathWatch, and one of the systems gets unreachable for enough time it
Re: [akka-user] Remote DeathWatch and comms failure
On Tue, Jan 21, 2014 at 7:50 PM, Alistair George alistairgeor...@gmail.com
wrote:
My plan for this was to have a proxy for NodeB watch state in NodeA. In
normal (connected) operation it just remembers the current watch states
(Actor Ax is/isn't watching Actor By) and passes the messages on to NodeB.
If disconnected it just remembers the watch state. On reconnect, it sends a
snapshot of the state to NodeB.
You still need to keep track of who watches (or wants to watch) who forever
(in the case of a perpetually lost node)
Because it's remembering state rather than messages it stays bounded. Need
to make sure that isn't watching states get pruned, but that's just the
usual sequence number/ack stuff (if disconnected, we can prune them
immediately, because they don't form part of the snapshot).
It's not unbounded: extrapolate over time as Nodes{N} join and then become
silent, all watches need to be kept indefinitely = leak.
Cheers,
√
Cheers
Alistair
On Tuesday, January 21, 2014 5:57:36 PM UTC, √ wrote:
NodeA NodeB are communicating
NodeB disappears (not acking)
NodeA still has things it needs to propagate to NodeB (watching actors on
that node etc), so they need to be buffered, also, if there are ordering
requirements it means that other things may not be transmitted/received
before other things, so more thing get buffered. At which point does NodeA
either A) drop the buffer or B) throw OOME?
Cheers,
√
On Tue, Jan 21, 2014 at 6:46 PM, Alistair George alistai...@gmail.comwrote:
I don't see where the unbounded buffer is needed. I'd be grateful for a
bit of explanation, especially since it looks like I'm going to have to
implement this stuff :)
On Tuesday, January 21, 2014 12:40:19 PM UTC, √ wrote:
And it also introduces the need for unbounded buffering, i.e. memory
leaks.
On Tue, Jan 21, 2014 at 1:01 PM, Akka Team akka.o...@gmail.com wrote:
Hi Alistair,
I'm not sure this is desirable behaviour. I shouldn't have to
restart a process just to recover from a comms failure. After all,
nothing
in the process has failed, and it may be providing services to other
clients that have not suffered any comms failure. They shouldn't have to
take the impact of a restart.
No, restart is not needed to recover from a communications failure, it
is needed to recover from the quarantined state.
One of the strengths of Akka is that it doesn't pretend to do things
that can't be done in a distributed context - this is essential for
transparent distribution. One of this things you can't do distributed is
give reliable, timely notification of a remote event, such as actor
termination, and I don't think Akka should try.
What I'd prefer is this:
- Reconnect attempts should continue indefinitely.
This is actually what happens. Quarantining only happens if you use
remote DeathWatch. If this is not the feature you want, you should not use
remote deathwatch. The contract of remote DeathWatch is that it eventually
produces a Terminated message if the remote actor is dead, at the cost of
false positives (i.e. actor is live but remote system was not responding
for a long time). You can tune the false positive rate by setting the
watch
failure detector. You can even set it to trigger after one year.
- The DeathWatch protocol should be extended to include (possibly
multiple) Reachable/Unreachable events.
This is not the purpose of DeathWatch, but you can implement such a
thing on your own by sending heartbeats between the related actors. In
clustering there is support for Unreachable/Reachable events.
- Terminate should only be delivered when the remote actor system
is reachable and asserts that the watched actor does not exist. This
might
never happen: an actor might stay in an unreachable state forever.
While that is a useful feature, it is not the purpose of DeathWatch.
Clustering has the feature you want, and in general, clustering is
recommended over plain remoting.
I realise I can emulate this by setting the timeout before quarantine
to be effectively infinite, and adding my own facility to detect
reachability and termination, but this isn't trivial. I'd prefer this
behaviour to be available out of the box, for both practical and
conceptual
reasons.
There is always the akka-contrib area for contributions :)
In general, I understand your use case, but DeathWatch does not
support it. Many users would be surprised when they watch a remote actor,
and kill the node running the system, but no Terminated messages would be
generated. And they would argue that is wrong for practical and conceptual
reasons :)
-Endre
Just my $.02
Cheers
Alistair
-Endre
Cheers
Alistair
On Monday, January 20, 2014 12:41:25 PM UTC, Akka Team wrote:
Hi Alistair,
On Thu, Jan 16, 2014 at 9:30 AM, Alistair George
alistai...@gmail.com wrote:
If I set up a watch on a remote actor (one on a remote actor
Re: [akka-user] Debug akka code in intellij (Java)
Oh ok is there a secret flag that you use internally to make it work synchronously ;-) just to validate the functionality. On Tuesday, January 21, 2014 11:31:06 AM UTC-8, √ wrote: Ok, I suspect that a step-through-debugger won't be super-duper helpful since the code-path very likely is async :) However, we have tests :) On Tue, Jan 21, 2014 at 7:21 PM, vijay krishna vijaycapr...@gmail.comjavascript: wrote: Thanks Viktor I will got through the documentation :-). Actually thats promptly why I wanted to step thru a debugger to see what exactly happens when tell() is called. On Tuesday, January 21, 2014 8:49:56 AM UTC-8, √ wrote: Hi Vijay, Sometimes code is worth a thousand words: https://github.com/akka/akka/blob/master/akka-actor/src/ main/resources/reference.conf#L449 https://github.com/akka/akka/blob/master/akka-actor/src/ main/scala/akka/serialization/Serializer.scala#L157 Cheers, √ On Tue, Jan 21, 2014 at 5:14 PM, vijay krishna vijaycapr...@gmail.comwrote: Hey Viktor, Just for the sake of clarity, If I send a byte[], Akka wont call any serializer and just send the message as is, but if its an Object then it would call the serializer class and serialize the message before sending it right. Best Vj On Monday, January 20, 2014 3:37:32 PM UTC-8, √ wrote: Hi Vijay, What seems to be the problem? Cheers, V On Jan 20, 2014 11:27 PM, vijay krishna vijaycapr...@gmail.com wrote: Hello, I am trying to debug Akka code to see how the tell() function works. Any recommendation on how I can do that? I am working with Java Thanks, Vijay -- 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 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/groups/opt_out. -- Read the docs: http://akka.io/docs/ Check the FAQ: http://akka.io/faq/ 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/groups/opt_out. -- Cheers, √ * ——— **Viktor Klang* *Chief Architect - **Typesafe http://www.typesafe.com/* Twitter: @viktorklang -- Read the docs: http://akka.io/docs/ Check the FAQ: http://akka.io/faq/ 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/groups/opt_out. -- Cheers, √ * ——— **Viktor Klang* *Chief Architect - **Typesafe http://www.typesafe.com/* Twitter: @viktorklang -- Read the docs: http://akka.io/docs/ Check the FAQ: http://akka.io/faq/ 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/groups/opt_out.
Re: [akka-user] Design Help: Async Listener
And I meant hack in the best sense, if you were wondering! So I should say hAkk! On Jan 21, 2014, at 7:09 AM, charlie robert reefed...@gmail.com wrote: Ok, they are on the list. I was looking at the network code… I don’t know what to say yet, as I don’t fully understand the flow of control of a functional programming language, but it looks tight. It’s a hack. There are a lot of surrounding capability, but I see in Netty some listener logic and then there is the FSM. DeathWatch and heartbeat, staged teardown. In comparison to pauwau’s net code…damn! I am licking my lips, but my list is growing quickly and they are not a couple of hour items..days..as I can’t just read docs, or read code; I’ll have to do both and see it running in the debugger. Old Smalltalk habits die hard. - charlie On Jan 21, 2014, at 1:52 AM, Akka Team akka.offic...@gmail.com wrote: Yes it is definitely possible, if you use akka-remote and akka-cluster then it works seamlessly (in fact that is one of the main features of those -- to maintain location transparency of ActorRefs). -Endre On Tue, Jan 21, 2014 at 12:28 AM, Rob Withers reefed...@gmail.com wrote: On Jan 20, 2014, at 3:57 PM, Rob Withers reefed...@gmail.com wrote: [crop] Akka will do nicely here, perhaps by passing the ActorRef to Actor-B in the original send. Is this even possible, to pass an ActorRef remotely? - charlie -- Read the docs: http://akka.io/docs/ Check the FAQ: http://akka.io/faq/ 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/groups/opt_out. -- 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://akka.io/faq/ 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/groups/opt_out. - robert - robert -- Read the docs: http://akka.io/docs/ Check the FAQ: http://akka.io/faq/ 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/groups/opt_out.
[akka-user] Re: Debug akka code in intellij (Java)
There was a podcast about async scala debugger in Eclipse: http://skillsmatter.com/podcast/scala/iulian-dragos -- Read the docs: http://akka.io/docs/ Check the FAQ: http://akka.io/faq/ 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/groups/opt_out.
