[akka-user] Master Slave Batch (or how am I reinventing the wheel)?
Hey there, We current run a spring-batch+spring-integration solution to do batch processing in large scale through remote-chunking technique which makes communication using request and replies queues. We're currently studying akka and scala and we saw a few implementation ideas from box (http://www.slideshare.net/vignesh41/silicon-valley-code-camp-2012) and also Akka Essentials Indian Blog (http://www.akkaessentials.in/2012/03/implementing-master-slave-grid.html) and came up with the following: https://lh5.googleusercontent.com/-hhDgjeGfeoU/U888y3hS9aI/buw/ayX9L9Dt2KE/s1600/Master-Slave-Proposal+-+New+Page.jpeg My questions at the moment are: - Should I have a JobSupervisorActor after the scheduler one? So after a schedule message a supervisor takes place and awakes a predef number of workers for a job. Wouldn't that be a spof? - The jobDone notification should be handled as a msg to another bunch os NotificationActors since it can vary as SMS/e-mail/AppPush? - If the slave call to a server is io-blocking that means that cpu is free to another actor to take place? My concern is that today we use a lot of two/four cores to house a bunch of slaves, so what's the best spec to hold hundreds of actors doing ws blocking calls? I guess more questions related to design, logging and things like that will come while we develop that, but that's a good place to start. Thanks for the patience guys, D. -- 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] Changing socket options from the Java API of Akka IO
Hi, Is there a way to change socket options such as send receive buffers from the Java API? All I can find is the set of Scala case classes (e.g. http://doc.akka.io/api/akka/snapshot/index.html#akka.io.Inet$$SO$$SendBufferSize), but to the best of my knowledge there is no way to use case classes from Java, so I'm wondering if I must create Scala wrappers that can be called from Java to achieve this. -- 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] Changing socket options from the Java API of Akka IO
Hi Adam, The Java API for that is here: http://doc.akka.io/japi/akka/2.3.4/?_ga=1.146627261.86713299.1405931132 Cheers, V On Jul 23, 2014 10:24 AM, Adam adamho...@gmail.com wrote: Hi, Is there a way to change socket options such as send receive buffers from the Java API? All I can find is the set of Scala case classes (e.g. http://doc.akka.io/api/akka/snapshot/index.html#akka.io.Inet$$SO$$SendBufferSize), but to the best of my knowledge there is no way to use case classes from Java, so I'm wondering if I must create Scala wrappers that can be called from Java to achieve this. -- 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] Changing socket options from the Java API of Akka IO
Hi Adam, Scala’s case classes are normal classes, they just come with a few auto-generated methods (like productIterator() and static apply()). Nothing stands in the way of using them just like any other Java class. Regards, Roland 23 jul 2014 kl. 10:24 skrev Adam adamho...@gmail.com: Hi, Is there a way to change socket options such as send receive buffers from the Java API? All I can find is the set of Scala case classes (e.g. http://doc.akka.io/api/akka/snapshot/index.html#akka.io.Inet$$SO$$SendBufferSize), but to the best of my knowledge there is no way to use case classes from Java, so I'm wondering if I must create Scala wrappers that can be called from Java to achieve this. -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout. Dr. Roland Kuhn Akka Tech Lead Typesafe – Reactive apps on the JVM. twitter: @rolandkuhn -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Waiting on multiple Akka messages
Hi Paul, I think attaching an ID field is a very good practice anyway. In my personal experience many patterns need a distinguishing field eventually, there were several times in Akka internals even when we had to introduce various IDs (ActorSystem instance IDs, ActorRef IDs, etc.). So I would say it is a pretty common thing to do and you save some future hassle by having them early. -Endre On Tue, Jul 22, 2014 at 5:20 PM, Paul Kinsky pkin...@gmail.com wrote: Thanks for the detailed reply on SO! We're almost certainly going with your recommended method of tagging requests and responses with an id field, but I thought a wider discussion could be interesting. On Tuesday, July 22, 2014 10:59:41 AM UTC-4, Konrad Malawski wrote: You're welcome :-) Happy hakking! On Tue, Jul 22, 2014 at 4:53 PM, Paul Kinsky pki...@gmail.com wrote: I recently posted this question on Stack Overflow, as Waiting on multiple Akka FSM messages https://stackoverflow.com/questions/24872342/waiting-on-multiple-akka-fsm-messages. I got one great answer (reproduced below) from Konrad 'ktoso' Malawski. I'm reposting it on this list just in case there are any other methods for distinguishing between responses. My question: I have an Akka FSM actor that runs the following pseudocode after receiving a message while in ReadyState lookupA ! Wrapper(Lookup(A)) lookupB ! Wrapper(Lookup(B)) lookupC ! Wrapper(Lookup(C)) goto(LookingUpDataState) using DataFound(a = None, b = None, c = None) The actor then waits for responses which can be either FullResult[T] ( extending ServiceResult[T]) or Empty (extending ServiceResult[Nothing]). Successful lookup results are used to populate the DataFound instance's fields and Empty lookup results result in a logged error message and the termination of the actor. My question is this: how can I determine which lookup failed, so that I can log the failure or fallback to a default value? All I can think of is examining the sender's ActorRef (hacky) or adding a unique ID field to all messages (high overhead). This is a simple problem to solve using Ask's and Futures. Does an idiomatic Akka solution exist? Konrad's answer: There's a few patterns you could use here. You will have to resort to one of these options listed below. They all have some trade off (and benchmarking is king anyway), but I've listed them in order of bad to good, - performing the queries in-order, so send A, wait for A response, send B ... But that's *horrible* - as in needlessly sequential. - use the ask pattern, so you'll spin up (internally that's how ask works) 3 actors, and they'll complete their own future. So this also has some cost on the sender because it has to start these special purpose actors (smaller than a normal actor, but still). - Yes, you'll need to tag these messages somehow. So you'd send some ID and the response must contain the same ID, then you know it's oh it's the response for A etc. I would argue that this is the recommended way to go here. - there's a *contrib* pattern available in Akka called the Aggregator, which is designed for this use case, so you might want to check it out: http://doc.akka.io/docs/akka/2.3.4/contrib/aggregator.htmlHowever if you like it or not is very much a matter of personal taste I guess. My personal favourite (we tend to avoid ask in general) would be tagging the requests in an Envelope(id, payload) so the responses can also be wrapped in such Envelope(id, response). If you decide to call these simply envelope or more with domain terminology is up to you. Hope this helps. -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/ current/additional/faq.html Search the archives: https://groups.google.com/ group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+...@googlegroups.com. 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. -- Cheers, Konrad 'ktoso' Malawski hAkker @ Typesafe http://typesafe.com -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout. -- Akka Team Typesafe - The
Re: [akka-user] Akka Cluster 2.3.4 does not mark died nodes Unreachable
Hi Alexander,
On Tue, Jul 22, 2014 at 7:51 PM, Alexander Smirnov alsmirn...@gmail.com
wrote:
I run cluster of Actor nodes on AWS Autoscaling groups.
Before migration to version 2.3.4, cluster discovery worked just fine: new
instances join cluster, terminated machines switched to Unreachable and
Down state.
After switching to 2.3.4, I see that terminated instances never leave a
cluster.
I see a lot of remoting errors, but node status never changed.
There were changes between 2.2.x and 2.3.x how unreachability events were
handled. In 2.2.x there was no way for the cluster to heal from scenarios
when there were temporary communication failures between two live hosts
(since one marked the other unreachable, downed and quarantined it).
You should look at the migration guide:
http://doc.akka.io/docs/akka/2.3.4/project/migration-guide-2.2.x-2.3.x.html#Changed_cluster_auto-down_configuration
akka.cluster.auto-down setting has been replaced by
akka.cluster.auto-down-unreachable-after, which instructs the cluster to
automatically mark unreachable nodes as DOWN after this configured time of
unreachability. This feature is disabled by default, as it also was in
2.2.x.
During the deprecation phase akka.cluster.auto-down=on is interpreted at as
instant auto-down.
As your cluster status snippets show below, instances *are* marked as
unreachable. The difference now that unreachability is considered a
temporary event and nodes can come back from this state. This behavior is
controlled by the akka.cluster.auto-down-unreachable-after setting which
instructs the cluster how long it expects nodes to come back from this
state.
Cluster status reported by Mbean. It's interesting that nodes from
unreachable section reported as Up:
There is nothing wrong with that. A cluster member can go back and forth
between UP-REACHABLE and UP-UNREACHABLE. You can either decide to
programmatically DOWN these instances in your application according to some
condition, or use the setting I mentioned above.
Once the node has be DOWNed though, it becomes quarantined -- DOWNing is a
permanent action and the same ActorSystem instance can never join again but
has to be restarted. Also, DOWN events trigger remote DeathWatch (unlike
unreachability).
-Endre
{
self-address: akka.tcp://
loadtes...@ec2-107-20-67-78.compute-1.amazonaws.com:2552,
members: [
{
address: akka.tcp://
loadtes...@ec2-107-20-67-78.compute-1.amazonaws.com:2552,
status: Up
},
{
address: akka.tcp://
loadtes...@ec2-50-16-180-25.compute-1.amazonaws.com:2552,
status: Up
},
{
address: akka.tcp://
loadtes...@ec2-54-204-110-59.compute-1.amazonaws.com:2552,
status: Up
},
{
address: akka.tcp://
loadtes...@ec2-54-211-16-150.compute-1.amazonaws.com:2552,
status: Up
},
{
address: akka.tcp://
loadtes...@ec2-54-225-3-180.compute-1.amazonaws.com:2552,
status: Up
},
{
address: akka.tcp://
loadtes...@ec2-54-80-144-23.compute-1.amazonaws.com:2552,
status: Up
},
{
address: akka.tcp://
loadtes...@ec2-54-89-171-156.compute-1.amazonaws.com:2552,
status: Up
},
{
address: akka.tcp://
loadtes...@ec2-75-101-210-243.compute-1.amazonaws.com:2552,
status: Up
}
],
unreachable: [
{
node: akka.tcp://
loadtes...@ec2-50-16-180-25.compute-1.amazonaws.com:2552,
observed-by: [
akka.tcp://
loadtes...@ec2-54-204-110-59.compute-1.amazonaws.com:2552,
akka.tcp://
loadtes...@ec2-54-89-171-156.compute-1.amazonaws.com:2552
]
},
{
node: akka.tcp://
loadtes...@ec2-54-211-16-150.compute-1.amazonaws.com:2552,
observed-by: [
akka.tcp://
loadtes...@ec2-107-20-67-78.compute-1.amazonaws.com:2552,
akka.tcp://
loadtes...@ec2-54-89-171-156.compute-1.amazonaws.com:2552,
akka.tcp://
loadtes...@ec2-75-101-210-243.compute-1.amazonaws.com:2552
]
},
{
node: akka.tcp://
loadtes...@ec2-54-225-3-180.compute-1.amazonaws.com:2552,
observed-by: [
akka.tcp://
loadtes...@ec2-107-20-67-78.compute-1.amazonaws.com:2552,
akka.tcp://
loadtes...@ec2-54-204-110-59.compute-1.amazonaws.com:2552,
akka.tcp://
loadtes...@ec2-54-89-171-156.compute-1.amazonaws.com:2552,
akka.tcp://
loadtes...@ec2-75-101-210-243.compute-1.amazonaws.com:2552
]
},
{
node: akka.tcp://
loadtes...@ec2-54-80-144-23.compute-1.amazonaws.com:2552,
observed-by: [
akka.tcp://
loadtes...@ec2-107-20-67-78.compute-1.amazonaws.com:2552,
akka.tcp://
loadtes...@ec2-54-89-171-156.compute-1.amazonaws.com:2552,
akka.tcp://
loadtes...@ec2-75-101-210-243.compute-1.amazonaws.com:2552
]
}
]
}
--
Read the docs: http://akka.io/docs/
Check the FAQ:
Re: [akka-user] [2.2.4] Lots of AssociationErrors in the logs during testing
Hi Ryan, On Tue, Jul 22, 2014 at 8:06 PM, Ryan Tanner ryan.tan...@gmail.com wrote: This is an issue I've been dealing with for a while now. I was hoping that the fix for log-remote-lifecycle-events = off in 2.2.4 would've fixed it but it hasn't. During multi-JVM cluster testing, we remove and re-add a node to test failure handling: testConductor.exit(BackendConfig.analytics, 0).await This leads to hundreds (if not thousands) of these statements in our logs: These are genuine ERROR events. Remoting only observes the following facts: - there are messages to be sent remotely, so it should retry - there has been no directives issued to remoting that it should not retry: - clustering has not indicated removal of that host - no DeathWatch timeouts has been triggered It reports dutifully that these attempts fail and all pending buffered messages were dropped, and also any new messages will be dropped until the gate elapses (5 seconds by default). If this would not be logged it would be really hard to know why messages end up in the void Is there any way to shut that actor up? It stops once that node is quarantined at least. You can mute those events in your test: system.eventStream.publish(TestEvent.Mute(EventFilter.error(start = AssociationError)) -Endre -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout. -- Akka Team Typesafe - The software stack for applications that scale Blog: letitcrash.com Twitter: @akkateam -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Master Slave Batch (or how am I reinventing the wheel)?
Hi Diego, This question is a bit too broadly scoped for us to answer (although the community might help), these kind of questions are handled through our professional services: developer subscriptions (http://typesafe.com/how/subscription) or consulting (http://typesafe.com/how/consulting). -Endre On Wed, Jul 23, 2014 at 6:52 AM, Diego Magalhães dgome...@gmail.com wrote: Hey there, We current run a spring-batch+spring-integration solution to do batch processing in large scale through remote-chunking technique which makes communication using request and replies queues. We're currently studying akka and scala and we saw a few implementation ideas from box ( http://www.slideshare.net/vignesh41/silicon-valley-code-camp-2012) and also Akka Essentials Indian Blog ( http://www.akkaessentials.in/2012/03/implementing-master-slave-grid.html) and came up with the following: https://lh5.googleusercontent.com/-hhDgjeGfeoU/U888y3hS9aI/buw/ayX9L9Dt2KE/s1600/Master-Slave-Proposal+-+New+Page.jpeg My questions at the moment are: - Should I have a JobSupervisorActor after the scheduler one? So after a schedule message a supervisor takes place and awakes a predef number of workers for a job. Wouldn't that be a spof? - The jobDone notification should be handled as a msg to another bunch os NotificationActors since it can vary as SMS/e-mail/AppPush? - If the slave call to a server is io-blocking that means that cpu is free to another actor to take place? My concern is that today we use a lot of two/four cores to house a bunch of slaves, so what's the best spec to hold hundreds of actors doing ws blocking calls? I guess more questions related to design, logging and things like that will come while we develop that, but that's a good place to start. Thanks for the patience guys, D. -- 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] Changing socket options from the Java API of Akka IO
Hi, Thanks, this indeed works. However, just for the record, the way to reference these classes is not exactly as the average Java programmer would expect. I had to decompile the Akka classes in order to understand what to do. Because these are nested classes I initially expected the call to the constructor to look like this: import akka.io.Inet; ... final Inet.SocketOption sendBufferSize = new Inet.SO.SendBufferSize(1234); But actually this will fail compilation. The correct way to make the call is this: import akka.io.Inet; ... final Inet.SocketOption sendBufferSize = new akka.io.Inet$SO$SendBufferSize( 1234); Which, at least in Eclipse, has the nasty side effect of marking the case class in red(The nested type akka.io.Inet$SO$SendBufferSize cannot be referenced using its binary name). Anyway, red marker aside, this works. On Wednesday, July 23, 2014 12:24:45 PM UTC+3, rkuhn wrote: Hi Adam, Scala’s case classes are normal classes, they just come with a few auto-generated methods (like productIterator() and static apply()). Nothing stands in the way of using them just like any other Java class. Regards, Roland 23 jul 2014 kl. 10:24 skrev Adam adam...@gmail.com javascript:: Hi, Is there a way to change socket options such as send receive buffers from the Java API? All I can find is the set of Scala case classes (e.g. http://doc.akka.io/api/akka/snapshot/index.html#akka.io.Inet$$SO$$SendBufferSize), but to the best of my knowledge there is no way to use case classes from Java, so I'm wondering if I must create Scala wrappers that can be called from Java to achieve this. -- 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. *Dr. Roland Kuhn* *Akka Tech Lead* Typesafe http://typesafe.com/ – Reactive apps on the JVM. twitter: @rolandkuhn http://twitter.com/#!/rolandkuhn -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Changing socket options from the Java API of Akka IO
23 jul 2014 kl. 12:39 skrev Adam adamho...@gmail.com: Hi, Thanks, this indeed works. However, just for the record, the way to reference these classes is not exactly as the average Java programmer would expect. I had to decompile the Akka classes in order to understand what to do. Because these are nested classes I initially expected the call to the constructor to look like this: import akka.io.Inet; ... final Inet.SocketOption sendBufferSize = new Inet.SO.SendBufferSize(1234); But actually this will fail compilation. The correct way to make the call is this: import akka.io.Inet; ... final Inet.SocketOption sendBufferSize = new akka.io.Inet$SO$SendBufferSize(1234); Which is why Viktor pointed you to the JavaDoc: you can also write akka.io.Inet.SoJavaFactories.sendBufferSize(1234). You can statically import SoJavaFactories to make your code look nicer. Regards, Roland Which, at least in Eclipse, has the nasty side effect of marking the case class in red(The nested type akka.io.Inet$SO$SendBufferSize cannot be referenced using its binary name). Anyway, red marker aside, this works. On Wednesday, July 23, 2014 12:24:45 PM UTC+3, rkuhn wrote: Hi Adam, Scala’s case classes are normal classes, they just come with a few auto-generated methods (like productIterator() and static apply()). Nothing stands in the way of using them just like any other Java class. Regards, Roland 23 jul 2014 kl. 10:24 skrev Adam adam...@gmail.com: Hi, Is there a way to change socket options such as send receive buffers from the Java API? All I can find is the set of Scala case classes (e.g. http://doc.akka.io/api/akka/snapshot/index.html#akka.io.Inet$$SO$$SendBufferSize), but to the best of my knowledge there is no way to use case classes from Java, so I'm wondering if I must create Scala wrappers that can be called from Java to achieve this. -- 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. Dr. Roland Kuhn Akka Tech Lead Typesafe – Reactive apps on the JVM. twitter: @rolandkuhn -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout. Dr. Roland Kuhn Akka Tech Lead Typesafe – Reactive apps on the JVM. twitter: @rolandkuhn -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Changing socket options from the Java API of Akka IO
Wait... As long as I'm looking at decompiled code, maybe this is just a documentation issue. Isn't this really the correct way to do this from Java code: final Inet.SocketOption sendBufferSize = TcpSO.receiveBufferSize(1234); It doesn't appear in the javadocs of 2.3.4, but the factory methods are there in the class. On Wednesday, July 23, 2014 1:39:48 PM UTC+3, Adam wrote: Hi, Thanks, this indeed works. However, just for the record, the way to reference these classes is not exactly as the average Java programmer would expect. I had to decompile the Akka classes in order to understand what to do. Because these are nested classes I initially expected the call to the constructor to look like this: import akka.io.Inet; ... final Inet.SocketOption sendBufferSize = new Inet.SO.SendBufferSize(1234); But actually this will fail compilation. The correct way to make the call is this: import akka.io.Inet; ... final Inet.SocketOption sendBufferSize = new akka.io. Inet$SO$SendBufferSize(1234); Which, at least in Eclipse, has the nasty side effect of marking the case class in red(The nested type akka.io.Inet$SO$SendBufferSize cannot be referenced using its binary name). Anyway, red marker aside, this works. On Wednesday, July 23, 2014 12:24:45 PM UTC+3, rkuhn wrote: Hi Adam, Scala’s case classes are normal classes, they just come with a few auto-generated methods (like productIterator() and static apply()). Nothing stands in the way of using them just like any other Java class. Regards, Roland 23 jul 2014 kl. 10:24 skrev Adam adam...@gmail.com: Hi, Is there a way to change socket options such as send receive buffers from the Java API? All I can find is the set of Scala case classes (e.g. http://doc.akka.io/api/akka/snapshot/index.html#akka.io.Inet$$SO$$SendBufferSize), but to the best of my knowledge there is no way to use case classes from Java, so I'm wondering if I must create Scala wrappers that can be called from Java to achieve this. -- 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. *Dr. Roland Kuhn* *Akka Tech Lead* Typesafe http://typesafe.com/ – Reactive apps on the JVM. twitter: @rolandkuhn http://twitter.com/#!/rolandkuhn -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Changing socket options from the Java API of Akka IO
Ah, right, that is the more direct route. This is in the JavaDoc by way of “implemented super-interfaces”. Regards, Roland 23 jul 2014 kl. 12:49 skrev Adam adamho...@gmail.com: Wait... As long as I'm looking at decompiled code, maybe this is just a documentation issue. Isn't this really the correct way to do this from Java code: final Inet.SocketOption sendBufferSize = TcpSO.receiveBufferSize(1234); It doesn't appear in the javadocs of 2.3.4, but the factory methods are there in the class. On Wednesday, July 23, 2014 1:39:48 PM UTC+3, Adam wrote: Hi, Thanks, this indeed works. However, just for the record, the way to reference these classes is not exactly as the average Java programmer would expect. I had to decompile the Akka classes in order to understand what to do. Because these are nested classes I initially expected the call to the constructor to look like this: import akka.io.Inet; ... final Inet.SocketOption sendBufferSize = new Inet.SO.SendBufferSize(1234); But actually this will fail compilation. The correct way to make the call is this: import akka.io.Inet; ... final Inet.SocketOption sendBufferSize = new akka.io.Inet$SO$SendBufferSize(1234); Which, at least in Eclipse, has the nasty side effect of marking the case class in red(The nested type akka.io.Inet$SO$SendBufferSize cannot be referenced using its binary name). Anyway, red marker aside, this works. On Wednesday, July 23, 2014 12:24:45 PM UTC+3, rkuhn wrote: Hi Adam, Scala’s case classes are normal classes, they just come with a few auto-generated methods (like productIterator() and static apply()). Nothing stands in the way of using them just like any other Java class. Regards, Roland 23 jul 2014 kl. 10:24 skrev Adam adam...@gmail.com: Hi, Is there a way to change socket options such as send receive buffers from the Java API? All I can find is the set of Scala case classes (e.g. http://doc.akka.io/api/akka/snapshot/index.html#akka.io.Inet$$SO$$SendBufferSize), but to the best of my knowledge there is no way to use case classes from Java, so I'm wondering if I must create Scala wrappers that can be called from Java to achieve this. -- 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. Dr. Roland Kuhn Akka Tech Lead Typesafe – Reactive apps on the JVM. twitter: @rolandkuhn -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout. Dr. Roland Kuhn Akka Tech Lead Typesafe – Reactive apps on the JVM. twitter: @rolandkuhn -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Changing socket options from the Java API of Akka IO
OK. Thanks a lot. On Wednesday, July 23, 2014 1:52:57 PM UTC+3, rkuhn wrote: Ah, right, that is the more direct route. This is in the JavaDoc by way of “implemented super-interfaces”. Regards, Roland 23 jul 2014 kl. 12:49 skrev Adam adam...@gmail.com javascript:: Wait... As long as I'm looking at decompiled code, maybe this is just a documentation issue. Isn't this really the correct way to do this from Java code: final Inet.SocketOption sendBufferSize = TcpSO.receiveBufferSize(1234); It doesn't appear in the javadocs of 2.3.4, but the factory methods are there in the class. On Wednesday, July 23, 2014 1:39:48 PM UTC+3, Adam wrote: Hi, Thanks, this indeed works. However, just for the record, the way to reference these classes is not exactly as the average Java programmer would expect. I had to decompile the Akka classes in order to understand what to do. Because these are nested classes I initially expected the call to the constructor to look like this: import akka.io.Inet; ... final Inet.SocketOption sendBufferSize = new Inet.SO.SendBufferSize(1234 ); But actually this will fail compilation. The correct way to make the call is this: import akka.io.Inet; ... final Inet.SocketOption sendBufferSize = new akka.io. Inet$SO$SendBufferSize(1234); Which, at least in Eclipse, has the nasty side effect of marking the case class in red(The nested type akka.io.Inet$SO$SendBufferSize cannot be referenced using its binary name). Anyway, red marker aside, this works. On Wednesday, July 23, 2014 12:24:45 PM UTC+3, rkuhn wrote: Hi Adam, Scala’s case classes are normal classes, they just come with a few auto-generated methods (like productIterator() and static apply()). Nothing stands in the way of using them just like any other Java class. Regards, Roland 23 jul 2014 kl. 10:24 skrev Adam adam...@gmail.com: Hi, Is there a way to change socket options such as send receive buffers from the Java API? All I can find is the set of Scala case classes (e.g. http://doc.akka.io/api/akka/snapshot/index.html#akka.io.Inet$$SO$$SendBufferSize), but to the best of my knowledge there is no way to use case classes from Java, so I'm wondering if I must create Scala wrappers that can be called from Java to achieve this. -- 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. *Dr. Roland Kuhn* *Akka Tech Lead* Typesafe http://typesafe.com/ – Reactive apps on the JVM. twitter: @rolandkuhn http://twitter.com/#!/rolandkuhn -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+...@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. *Dr. Roland Kuhn* *Akka Tech Lead* Typesafe http://typesafe.com/ – Reactive apps on the JVM. twitter: @rolandkuhn http://twitter.com/#!/rolandkuhn -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Master Slave Batch (or how am I reinventing the wheel)?
Thanks for the promptly response, Endre! On Wednesday, July 23, 2014 6:51:27 AM UTC-3, Akka Team wrote: Hi Diego, This question is a bit too broadly scoped for us to answer (although the community might help), these kind of questions are handled through our professional services: developer subscriptions (http://typesafe.com/how/subscription) or consulting (http://typesafe.com/how/consulting). -Endre On Wed, Jul 23, 2014 at 6:52 AM, Diego Magalhães dgom...@gmail.com javascript: wrote: Hey there, We current run a spring-batch+spring-integration solution to do batch processing in large scale through remote-chunking technique which makes communication using request and replies queues. We're currently studying akka and scala and we saw a few implementation ideas from box ( http://www.slideshare.net/vignesh41/silicon-valley-code-camp-2012) and also Akka Essentials Indian Blog ( http://www.akkaessentials.in/2012/03/implementing-master-slave-grid.html) and came up with the following: https://lh5.googleusercontent.com/-hhDgjeGfeoU/U888y3hS9aI/buw/ayX9L9Dt2KE/s1600/Master-Slave-Proposal+-+New+Page.jpeg My questions at the moment are: - Should I have a JobSupervisorActor after the scheduler one? So after a schedule message a supervisor takes place and awakes a predef number of workers for a job. Wouldn't that be a spof? - The jobDone notification should be handled as a msg to another bunch os NotificationActors since it can vary as SMS/e-mail/AppPush? - If the slave call to a server is io-blocking that means that cpu is free to another actor to take place? My concern is that today we use a lot of two/four cores to house a bunch of slaves, so what's the best spec to hold hundreds of actors doing ws blocking calls? I guess more questions related to design, logging and things like that will come while we develop that, but that's a good place to start. Thanks for the patience guys, D. -- 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. -- Akka Team Typesafe - The software stack for applications that scale Blog: letitcrash.com Twitter: @akkateam -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Akka cluster: stopping actor doesn't remove sharding entry
Many thanks for your help Endre. Completely understood from shard perspective. I'll check if the entry disappear if the actor is stopped (which is not the case for the sharding). Regards. El miércoles, 23 de julio de 2014 11:13:46 UTC+2, Akka Team escribió: Hi Eduardo, Shards are assumed to be a fixed and relatively few in numbers (like a few hundreds). They are the unit of rebalancing and do not get removed even if there are no active entries in them at a certain time. This is usually not a problem if the number of shards are a few, but if you map all your entries with shardId == entryId then obviously all entries will live on a separate shard -- this use case is not optimized so far. -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.
Re: [akka-user] Remote: cascade disconnections when more than 10 clients connecting to same system
Hi,
I also tried scenario establish remote connection without sending any
application specific messages...without any success.
Finally I solved problem with protobuf dependency in our app and upgraded
to Akka 2.3.4
Everything works as expected (tried with 43 Tomcats).
On Tuesday, July 22, 2014 11:03:00 AM UTC+3, Akka Team wrote:
Hi Vitaliy,
Do you send large messages or send messages without backpressure? Since
2.2.x does not prioritize internal heartbeat messages over user messages it
can accumulate delay. You should try throttling or backpressuring your
remote sends first to see if it is the problem.
-Endre
On Mon, Jul 21, 2014 at 7:06 PM, Vitaliy Morarian vmor...@gmail.com
javascript: wrote:
Hi Konrad,
Master is m1.xlarge instance. I checked CPU load: about 5-10%
Unfortunately we can't upgrade to 2.3.x due protobuf dependency (I tried,
but faced with some reflection exceptions during Tomcat startup)
On Friday, July 18, 2014 1:04:33 PM UTC+3, Konrad Malawski wrote:
Hi Vitaliy,
It seems the master is overloaded.
Do you have jvm monitoring in place to see if it's not in state of agony?
In other news, 2.3.4 prioritises hearbeats so missing hearbeat messages
(thus causing false positives on failure detection) because of overloaded
machine is less likely,
I would recommend trying to upgrade (maybe you can upgrade your proto
dependency somehow?).
You can also tweak the failure detector's timeout, but if it's the case
that the master is barely keeping up anyway that's not really a solution.
On Mon, Jul 14, 2014 at 5:53 PM, Vitaliy Morarian vmor...@gmail.com
wrote:
Hi,
We have MonitoringMaster actor system and N Metrics actor systems.
They are deployed in AWS, and to make it working we are substituting
public-ip in runtime.
Akka version: 2.2.4 (can't upgrade to 2.3.x due protobuf dependency)
Config file:
akka {
loglevel = INFO
log-config-on-start = on
debug {
receive = on
lifecyle = off
}
actor {
provider = akka.remote.RemoteActorRefProvider
}
remote {
enabled-transports = [akka.remote.netty.tcp]
log-remote-lifecycle-events = INFO
netty.tcp {
hostname = 127.0.0.1 //but we substitute a real IP in runtime
}
secure-cookie = #
require-cookie = on
}
}
remote {
untrusted-mode = on
log-received-messages = off
}
So everything works ok when we have less than 10 clients. Problem
starts to occur when more than 10 clients are connecting to master
(sometimes 11, sometimes 15, ...).
In this case we observing cascade of exceptions (and it affects all
Metrics systems):
*MonitoringMaster*:
[INFO] [07/14/2014 15:02:06.386]
[MonitoringMaster-akka.actor.default-dispatcher-3]
[akka://MonitoringMaster/user/master] Added producer Actor[akka.tcp://
metr...@ec2-54-88-77-195.compute-1.amazonaws.com:2552/user/
metric-producer#-1020796025] with meta InstanceMeta(InstanceGlobalId(
us-east-1,i-14ffd83e),)
[WARN] [07/14/2014 15:03:03.023]
[MonitoringMaster-akka.actor.default-dispatcher-19]
[akka://MonitoringMaster/system/remote-watcher] Detected unreachable:
[akka.tcp://metr...@ec2-54-88-77-195.compute-1.amazonaws.com:2552]
[INFO] [07/14/2014 15:03:03.048]
[MonitoringMaster-akka.actor.default-dispatcher-3]
[Remoting] Address [akka.tcp://Metrics@ec2-54-88-
77-195.compute-1.amazonaws.com:2552] is now quarantined, all messages
to this address will be delivered to dead letters.
WARN] [07/14/2014 15:03:03.060]
[MonitoringMaster-akka.actor.default-dispatcher-3]
[akka://MonitoringMaster/system/endpointManager/
reliableEndpointWriter-akka.tcp%3A%2F%2FMetrics%40ec2-54-
88-77-195.compute-1.amazonaws.com%3A2552-1866/endpointWriter]
AssociationError [akka.tcp://MonitoringMaster@ec2-54-82-6-7.compute-1.
amazonaws.com:2551] - [akka.tcp://Metrics@ec2-54-88-
77-195.compute-1.amazonaws.com:2552]: Error [Invalid address:
akka.tcp://metr...@ec2-54-88-77-195.compute-1.amazonaws.com:2552] [
akka.remote.InvalidAssociation: Invalid address: akka.tcp://
metr...@ec2-54-88-77-195.compute-1.amazonaws.com:2552
Caused by: akka.remote.transport.Transport$InvalidAssociationException:
The remote system has a UID that has been quarantined. Association aborted.
]
[WARN] [07/14/2014 15:03:03.061]
[MonitoringMaster-akka.actor.default-dispatcher-3]
[Remoting] Tried to associate with unreachable remote address [akka.tcp://
metr...@ec2-54-88-77-195.compute-1.amazonaws.com:2552]. Address is now
gated for 6 ms, all messages to this address will be delivered to dead
letters. Reason: The remote system has a UID that has been quarantined.
Association aborted.
[ERROR] [07/14/2014 15:03:06.205]
[MonitoringMaster-akka.actor.default-dispatcher-19]
[akka://MonitoringMaster/system/endpointManager/
endpointWriter-akka.tcp%3A%2F%2FMetrics%40ec2-54-88-77-195.
compute-1.amazonaws.com%3A2552-1867] AssociationError [akka.tcp://
Re: [akka-user] Best practices using Akka Persistence with long-running projects?
First of all, thank you very much for the elaborate reply. I guess I'll get hacking away at some prototypes soon and so some performance testing close to our use-case. Looking forward to it, too :-) One question remains: Am Montag, 21. Juli 2014 13:28:27 UTC+2 schrieb Konrad Malawski: The other method I like *more *personally is promoting events. So an event comes in it's in version 2. You're running your app on version 5 events. You have promotions ready in your system and can promote an v2 event to v3, then to v4, then to v5, and after promoting it to your current runtime's version, you can give it to your actors. What's the wins? You don't keep the old implementations around and you and you can hook in the promotions into the custom serialiser in akka. Read in old events, promote them, return them to be used. So what you suggest is that the serializer first deserializes a stored event forgivingly, without throwing an exception for for example dropping removed field and initializing new fields with 0/null/default values, and then I compare the version and apply additional conversion logic? Or do you mean something more complex like storing a dehydrated version of the event and re-hydrating it every time an event is loaded from storage, promoting it to the latest version in this process? -- 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] [2.2.4] Lots of AssociationErrors in the logs during testing
Thanks so much! That EventFilter.mute was precisely what I needed. We had so much log output from remoting that CircleCI was truncating our logs so we weren't actually able to figure out which tests failed. On Wednesday, July 23, 2014 3:48:02 AM UTC-6, Akka Team wrote: Hi Ryan, On Tue, Jul 22, 2014 at 8:06 PM, Ryan Tanner ryan@gmail.com javascript: wrote: This is an issue I've been dealing with for a while now. I was hoping that the fix for log-remote-lifecycle-events = off in 2.2.4 would've fixed it but it hasn't. During multi-JVM cluster testing, we remove and re-add a node to test failure handling: testConductor.exit(BackendConfig.analytics, 0).await This leads to hundreds (if not thousands) of these statements in our logs: These are genuine ERROR events. Remoting only observes the following facts: - there are messages to be sent remotely, so it should retry - there has been no directives issued to remoting that it should not retry: - clustering has not indicated removal of that host - no DeathWatch timeouts has been triggered It reports dutifully that these attempts fail and all pending buffered messages were dropped, and also any new messages will be dropped until the gate elapses (5 seconds by default). If this would not be logged it would be really hard to know why messages end up in the void Is there any way to shut that actor up? It stops once that node is quarantined at least. You can mute those events in your test: system.eventStream.publish(TestEvent.Mute(EventFilter.error(start = AssociationError)) -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+...@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. -- Akka Team Typesafe - The software stack for applications that scale Blog: letitcrash.com Twitter: @akkateam -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Akka cluster: stopping actor doesn't remove sharding entry
Ok. Entries are managed as expected. After looking at the code I understand what you mean. Thanks a lot for your help. Regards. El miércoles, 23 de julio de 2014 15:41:00 UTC+2, Eduardo Fernandes escribió: Many thanks for your help Endre. Completely understood from shard perspective. I'll check if the entry disappear if the actor is stopped (which is not the case for the sharding). Regards. -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
[akka-user] Side effect stream combinator
Hi guys:
Something that would be useful is a side effecting combinator. For
example, like doOnEach from RxJava. This would be particularly useful in
the actor world to insert an actor tell into the flow.
def doOnEach(f: = Unit): Flow[T]
For example:
flow.doOnEach { msg = if (msg.isSomething) actor ! msg }.map()...
This can be done with a Transformer but it's not really transforming.
Will there be a way to create Flow subtypes so that people can invent their
own combinators?
Thanks,
--
Read the docs: http://akka.io/docs/
Check the FAQ:
http://doc.akka.io/docs/akka/current/additional/faq.html
Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups Akka
User List group.
To unsubscribe from this group and stop receiving emails from it, send an email
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
