[akka-user] quorum-based split brain resolution
I have been hacking on a discovery plugin for elasticsearchhttps://github.com/shikhar/eskka using akka cluster and I wanted to add some automated downing, and the auto-down-unreachable-after is not really an option since it can lead to split brain. So I went with the approach of using a quorum of members to determine whether the unreachable node should be downed. I'm curious to hear what you think of this. see https://github.com/shikhar/eskka/blob/master/src/main/scala/eskka/QuorumBasedPartitionMonitor.scala 1. The VotingMembershttps://github.com/shikhar/eskka/blob/release-0.1/src/main/scala/eskka/VotingMembers.scalapassed in the constructor are the seed nodes. Using seed nodes was just an easy choice since they are specified before-hand. So ideally there should be 3 or more seed nodes. 2. I am using an app-level ping layerhttps://github.com/shikhar/eskka/blob/master/src/main/scala/eskka/Pinger.scalaon top of the UNREACHABLE events. When a ping request to an unreachable node, made via the seed nodes affirmatively times-out (i.e. they must explicitly return a timeout response rather than the ping request timing out, so that we don't consider an unreachable seed-node as a voter!), then we DOWN that unreachable node. Instead of these app-level pings maybe it makes sense to utilize the Akka private[cluster] metadata like Reachability.isReachable(observer, node) but I'm not entirely sure of the semantics. 3. Currently this QuorumBasedPartitionMonitor actor gets started on every seed node. So in case a member becomes unreachable, they'd all end up trying to arrange for a distributed ping to the unreachable node via one another, and possibly downing it. This seems a bit like a thundering herd so not ideal. But on the other hand I don't want to use a cluster-singleton because this partition resolver is trying to be the layer that allows for singleton failover to happen smoothly. I'd love to hear ideas on how to handle this better. 4. Maybe a generic solution for quorum-based partition resolution should be a part of Akka proper/contrib? It seems AutoDown is rarely a good answer. -- 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] Pulling Pattern vs Durable Mailboxes
This is a copy of a post I put up on Stackoverflowhttp://stackoverflow.com/questions/23403335/akka-pulling-pattern-vs-durable-mailboxes . I've been working on a project of mine using Akka to create a real-time processing system which takes in the Twitter stream (for now) and uses actors to process said messages in various ways. I've been reading about similar architectures that others have built using Akka and this particular blog post caught my eye: http://blog.goconspire.com/post/64901258135/akka-at-conspire-part-5-the-importance-of-pulling Here they explain different issues that arise when pushing work (ie. messages) to actors vs. having the actors pull work. To paraphrase the article, by pushing messages there is no built-in way to know which units of work were received by which worker, nor can that be reliably tracked. In addition, if a worker suddenly receives a large number of messages where each message is quite large you might end up overwhelmed and the machine could run out of memory. Or, if the processing is CPU intensive you could render your node unresponsive due to CPU thrashing. Furthermore, if the jvm crashes, you will lose all the messages that the actor(s) had in its mailbox. Pulling messages largely eliminates these problems. Since a specific actor must pull work from a coordinator, the coordinator always knows which unit of work each worker has; if a worker dies, the coordinator knows which unit of work to re-process. Messages also don’t sit in the workers’ mailboxes (since it's pulling a single message and processing it before pulling another one) so the loss of those mailboxes if the actor crashes isn't an issue. Furthermore, since each worker will only request more work once it completes its current task, there are no concerns about a worker receiving or starting more work than it can handle concurrently. Obviously there are also issues with this solution like what happens when the coordinator itself crashes but for now let's assume this is a non-issue. More about this pulling pattern can also be found at the Let It Crash website which the blog references: http://letitcrash.com/post/29044669086/balancing-workload-across-nodes-with-akka-2 This got me thinking about a possible alternative to doing this pulling pattern which is to do pushing but with durable mailboxes. An example I was thinking of was implementing a mailbox that used RabbitMQ (other data stores like Redis, MongoDB, Kafka, etc would also work here) and then having each router of actors (all of which would be used for the same purpose) share the same message queue (or the same DB/collection/etc...depending on the data store used). In other words each router would have its own queue in RabbitMQ serving as a mailbox. This way, if one of the routees goes down, those that are still up can simply keep retrieving from RabbitMQ without too much worry that the queue will overflow since they are no longer using typical in-memory mailboxes. Also since their mailbox isn't implemented in-memory, if a routee crashes, the most messages that it could lose would just be the single one it was processing before the crash. If the whole router goes down then you could expect RabbitMQ (or whatever data store is being used) to handle an increased load until the router is able to recover and start processing messages again. In terms of durable mailboxes, it seems that back in version 2.0, Akka was gravitating towards supporting these more actively since they had implemented a few that could work with MongoDB, ZooKeeper, etc. However, it seems that for whatever reason they abandoned the idea at some point since the latest version (2.3.2 as of the writing of this post) deprecated them. You're still able to implement your own mailbox by implementing the MessageQueue interface which gives you methods like enqueue(), dequeue(), etc... so making one that works with RabbitMQ, MongoDB, Redis, etc wouldn't seem to be a problem. Anyways, just wanted to get your guys' and gals' thoughts on this. Does this seem like a viable alternative to doing pulling? -- 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] Dynamic configuration extension during runtime
Hi Christian, *To nail down the question: is there a way to extend the settings / configuration of an already running ActorSystem during runtime?* No, there is no support for changing the configuration after the system has been started. Is there a technical reason for that or simply a missing requirement :-) In our world configuration is static and do not change after system startup. There are technical reasons for this as well, most parts internally rely on being able to cache various settings or being immutable at least. It would be really hard to safely reconfigure a concurrent system like Akka on-the-fly. -Endre - Christian -Endre *Kind regards,* * Christian* -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/ current/additional/faq.html Search the archives: https://groups.google.com/ group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+...@googlegroups.com. To post to this group, send email to akka...@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout. -- Akka Team Typesafe - The software stack for applications that scale Blog: letitcrash.com Twitter: @akkateam -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout. -- Akka Team Typesafe - The software stack for applications that scale Blog: letitcrash.com Twitter: @akkateam -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Akka (Java) Competing Consumers
Hi, I see that you create a router with a set of workers: // distributing the message processing across a pool of 5 actors ActorRef workRouter = akkaSystem.actorOf(new RoundRobinPool(numOfWorkers).props(Props.create(EventProcessor.class)), workRouter); } } But I don't see any place where you use workRouter. -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] Re: Broadcast a message with cluster sharding
Hi Jabbar, No, you are not missing anything, PubSub is designed for such cases. Just be careful not to broadcast too much data since it does not scale linearily. -Endre On Sat, May 3, 2014 at 1:06 AM, Jabbar Azam aja...@gmail.com wrote: I've just looked at the documentation. I can use the DistributedPubSubMediator and get all the sharded actors listening to a topic. So when I need the contents from a particular sharded actor I can send a message to a topic which will be received by all the sharded actors and the one containing the cache information will respond. Sounds too simple. I must be missing something... On Friday, 2 May 2014 21:25:17 UTC+1, Jabbar Azam wrote: Hello, I want to create a cluster of actors using the cluster sharding module. I want to be able to send a message to all the actors in the cluster. I've read the documentation and seen the typesafe Activator example which shows messages being sent to individual actors. Does anybody know if it's possible to broadcast a message to all the actors using cluster sharding? Basically I'm trying to implement a persistent distributed cache and I want each cache element to respond to a broadcast message which where each cache element(actor) has a resulting response. -- 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] mixing FSM and akka-persistence
Hi Christian, Do you have a small reproducible test case that exposes the problem? If you do, please share so we can look into the possible issue. -Endre On Sun, May 4, 2014 at 2:07 PM, Nicola Piccinini piccin...@gmail.comwrote: Yes, http://doc.akka.io/docs/akka/snapshot/scala/persistence. html#state-machines thank you for the pointer. The problem was that I had overwritten preStart, with something like: super.preStart() self ! Message and that did not play well with Processor. Since it is probably not a good idea, I have refactored my FSM and I am not overwriting #preStart anymore. Now, in normal condition, my Processor-FSM runs fine but I have a new problem. I have some tests for the FSM, I have just updated to last scalatest version to be sure to use the most up to date stuff: com.typesafe.akka %% akka-actor % 2.3.2, com.typesafe.akka %% akka-persistence-experimental % 2.3.2, org.scalatest %% scalatest % 2.1.5 % test, com.typesafe.akka %% akka-testkit % 2.3.2 % test, org.mockito % mockito-core % 1.9.5 % test One test is a mixin between FunSpec and akka TestKit and looks like: - val brain = mock[SchedulerBrain] when(brain.timeoutFor).thenReturn(Map[Symbol, FiniteDuration]().withDefaultValue(50.seconds)) when(brain.schedule(Mock.gate, Map())).thenReturn(Map(123 - /collector/123)) fsmRef = createFsmRef(brain) Thread.sleep(100) assert(fsmRef.stateName === Waiting) assert(fsmRef.stateData === Map(123 - /collector/123)) verify(brain).schedule(Mock.gate, Map()) - When my FSM is an Actor (not a Processor), the test run successfully and this is the log: [DEBUG] [05/04/2014 13:57:35.228] [default-scheduler-1] [akka://default/user/$$a] transition org.peach.moma.schedulers.CollectorsScheduler$Waiting$@7a7d0e26 - org.peach.moma.schedulers.CollectorsScheduler$Scheduling$@62170848 [DEBUG] [05/04/2014 13:57:35.229] [default-scheduler-1] [akka://default/user/$$a] processing Event(Scheduled(Map(123 - /collector/123)),Map()) from TestActor[akka://default/user/$$a] [DEBUG] [05/04/2014 13:57:35.230] [default-scheduler-1] [akka://default/user/$$a] transition org.peach.moma.schedulers.CollectorsScheduler$Scheduling$@62170848 - org.peach.moma.schedulers.CollectorsScheduler$Waiting$@7a7d0e26 When my FSM is a Processor, then I have this assertion error: Map() did not equal Map(123 - /collector/123) and no logs related to the FSM transitions (???). The only difference is about extending Actor or Processor, I am not yet using any Persistent message so the behaviour should not vary, I think. I have another test related to that FSM and also it is green with Actor, red with Processor, so it really seems that persistence is affecting tests in a bad way. Any idea? 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. -- 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] Re: Starting an FSM in a cluster
Hi Eugene,
On Sun, May 4, 2014 at 6:23 PM, Eugene Dzhurinsky jdeve...@gmail.comwrote:
On Sun, May 04, 2014 at 09:46:50AM +0200, Heiko Seeberger wrote:
class MyActor(myParameter: String) extends Actor with FSM { ... }
context.actorOf(Props(new MyActor(myArgument)))
As far as I understand, this will create an actor on the same host/same
JVM,
but I need it to be created in a cluster.
I think you should rather use an initialization message instead of a
constructor. It should preferrably result in a reply (e.g. Initialized) so
the manager knows when the instance is ready for exposure to other parts of
the system.
-Endre
--
Eugene N Dzhurinsky
--
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] Re: Starting an FSM in a cluster
On Sun, May 4, 2014 at 6:23 PM, Eugene Dzhurinsky jdeve...@gmail.comwrote:
On Sun, May 04, 2014 at 09:46:50AM +0200, Heiko Seeberger wrote:
class MyActor(myParameter: String) extends Actor with FSM { ... }
context.actorOf(Props(new MyActor(myArgument)))
As far as I understand, this will create an actor on the same host/same
JVM,
but I need it to be created in a cluster.
Got it. You still can deploy it remotely in the cluster. Just use
`Cluster.state` to get all member nodes which are up, choose one and get
its `address`, then use `Props.withDeploy(Deploy(scope =
RemoteScope(address)))`.
That's a simple approach. You could also start manager actors on member
nodes and ask one of those to create the actors by sending the `Props`. And
you can take a look into cluster sharding.
Heiko
--
Eugene N Dzhurinsky
--
Heiko Seeberger
Twitter: @hseeberger
Blog: blog.heikoseeberger.name
--
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] Dynamic configuration extension during runtime
2014-05-05 10:14 GMT+02:00 Akka Team akka.offic...@gmail.com: Hi Christian, *To nail down the question: is there a way to extend the settings / configuration of an already running ActorSystem during runtime?* No, there is no support for changing the configuration after the system has been started. Is there a technical reason for that or simply a missing requirement :-) In our world configuration is static and do not change after system startup. There are technical reasons for this as well, most parts internally rely on being able to cache various settings or being immutable at least. It would be really hard to safely reconfigure a concurrent system like Akka on-the-fly. Thanks for your reply. It was the kind of answer I was hoping for, although it makes things difficult for me as I have to figure out a different way. Unfortunately it will not allow me to shield away different technical aspects as I have could done with an abstraction layer right on top of the actor represented through a mailbox ;-) -Christian -Endre - Christian -Endre *Kind regards,* * Christian* -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/ current/additional/faq.html Search the archives: https://groups.google.com/ group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+...@googlegroups.com. To post to this group, send email to akka...@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout. -- Akka Team Typesafe - The software stack for applications that scale Blog: letitcrash.com Twitter: @akkateam -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout. -- Akka Team Typesafe - The software stack for applications that scale Blog: letitcrash.com Twitter: @akkateam -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to a topic in the Google Groups Akka User List group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/akka-user/4rvo0h_GcMc/unsubscribe. To unsubscribe from this group and all its topics, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout. -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
[akka-user] Akka cluster failover: hot swaping
Hi all. I'm trying a hot swap between an active processor and a backup one, in line with the thishttps://www.assembla.com/spaces/akka/tickets/3938#/activity/ticket: ticket, to avoid delay while swapping huge actors. I'm thinking about manually sending my commands to two different actors in a active/passive fashion. In case of node failure I'd like to point out to the passive instance, avoiding startup delay. I'm thinking about having two sharding regions and then, after node failure and using a particular sharding strategy, point out to the node where the passive object is. Maybe the hotswap (as decribed herehttp://doc.akka.io/docs/akka/snapshot/java/untyped-actors.html#untypedactor-hotswap) can be used to deviate the commands to passive actor. In the meanwhile the standard Akka persistence scheme is being used to re-initiate the original actor that could be used later after a new node failure. Do you think that this approach is feasible or maybe there is another simpler way to achieve this behavior? Many thanks for your help. Eduardo. -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] How can the sender know that a message has been delivered (confirmed) by a channel?
Of course, but if the channel-internal ACK has already arrived, why should we require another application-level one that might get lost? Heiko On Mon, May 5, 2014 at 4:25 PM, Martin Krasser krass...@googlemail.comwrote: On 05.05.14 14:59, Heiko Seeberger wrote: On the other hand, an application level ACK is an additional message that might get lost ... The same is true for the channel-internal ACK. Heiko On Sun, May 4, 2014 at 8:06 PM, Heiko Seeberger heiko.seeber...@gmail.com wrote: Maybe yes. Heiko On Sun, May 4, 2014 at 12:57 PM, Martin Krasser krass...@googlemail.comwrote: On 04.05.14 11:00, Heiko Seeberger wrote: Not all communication follows the request-response pattern. In my case there's no need for an application level response, its only purpose is the technical ACK. Isn't that a special case of request-response? Heiko On Sun, May 4, 2014 at 10:41 AM, Martin Krasser krass...@googlemail.com wrote: Maybe a confirm(reply: Any) method would make sense, where reply is sent to the sender of the Persistent message. This would also allow for some internal optimizations. On 04.05.14 10:18, Martin Krasser wrote: On 04.05.14 10:07, Heiko Seeberger wrote: On Sun, May 4, 2014 at 9:55 AM, Martin Krasser krass...@googlemail.com wrote: Hi Heiko, On 03.05.14 06:58, Heiko Seeberger wrote: Hi, A short-lived actor A should send a result message to some other actor B before it terminates itself. As it is important that this message gets delivered, I would like to use a channel in order to retry message delivery. In case of permanent delivery failure (redeliverMax exceeded) the short-lived actor A would send the message to some other actor C which would know what to do. This can be implemented using a redeliverFailureListener. My question is: How can the short-lived actor A know that the message has been delivered, i.e. the ConfirmablePersistent message has been confirmed? AFAIK there's no deliverSuccessListener or such. Actor B should send an application-level reply to actor A. Channels preserve sender references. Well, that's how I have already implemented it without channels. I was hoping that channels would make that easier ;-) The purpose of a channel is to make delivery of a message from A - B more reliable (by implementing a retry-ack protocol where the ack is generated by the receiver by calling confirm()) and it shouldn't hide an application-level conversation between actors A and B which also includes the reply from B to A. You'd also send a reply if A sends a message to B without using a channel. Hence, when using a channel, B should confirm delivery *in addition* to sending a reply. Is it possible to add a feature like a deliverSuccessListener in the future? It's not a big deal to add that but I'm not sure if it's a good idea from a design perspective. Curious what others think ... Thanks Heiko -- 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. -- Martin Krasser blog:http://krasserm.blogspot.com code:http://github.com/krasserm twitter: http://twitter.com/mrt1nz -- Martin Krasser blog:http://krasserm.blogspot.com code:http://github.com/krasserm twitter: http://twitter.com/mrt1nz -- 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. -- Heiko Seeberger Twitter: @hseeberger Blog: blog.heikoseeberger.name -- 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] (Java) Using the new Router in 2.3.2
In the new Router documentation for version 2.3.2 (http://doc.akka.io/docs/akka/2.3.2/java/routing.html), I noticed that in their very first example, they use a new Router class. From the example, it seems like they use the Router as a group-router since they first create Worker actors as children of the Master actor before assigning them to the Router as routees. Is it possible to use the Router class to create a pool-router such that routees are children of the Router? Also, is it possible to configure the new Router class through configurations? -- 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] Pulling Pattern vs Durable Mailboxes
On Mon, May 5, 2014 at 3:13 AM, massivedynamic lu4...@gmail.com wrote: Anyways, just wanted to get your guys' and gals' thoughts on this. Does this seem like a viable alternative to doing pulling? Definitely not my area of expertise -- I haven't gotten a system under sufficient load yet to really grok all the issues -- but I would worry about efficiency differences. My impression has been that all implementations of durable mailboxes are quite heavyweight, and can't support anywhere near the throughput of ordinary mailboxes. (Whereas the work-pulling pattern doesn't seem to have anywhere near so much overhead.) Folks who have worked with durable mailboxes, does this match your experience? -- 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] Views for many entities?
Howdy All, This is my first post and I am new to Akka and Scala but very excited about using Akka Persistence and CQRS / ES for a new Web application I am developing. I have been reading a lot about CQRS / ES and playing around with Akka Persistence and have a few questions I hope you can help me with. I am warming to the idea of Views being able to track the journal of a Processor (sort of a compromise pub-sub that will work with replicated journals). I assume Views are meant to build the read model. However, I wonder how I am meant to maintain a View(s) for each EventsourcedProcessor when there may be many Processors? Take the classic example of aggregate root Order, with an EP representing it. How does the View get constructed for each Order, particularly if there are a very large number of Orders? Do I just create one (or more) Views each time an Order is created and let them sit around (and go inactive / idle)? I know Actors don't take up much memory when inactive / idle but if I have a whole lot of Orders do I really need a separate View(s) for each. Wouldn't it be better to have some sort of generic OrderView that can handle event from any Order's journal? It could singularly then manage a denormalised Order store. Similarly, I guess for the domain model. Will my EPs for particular aggregate roots be created each time I need to access them or do they live forever as Actor in the name space / paths? It seems like I have two stores representing the entities (journal for data and Actor name space / path for identity) . Finally, I believe I would like to track all the events that get added to the entire journal (treating it like a combined log). Is that possible? Is it one big log-like thing or are there really separate journals for each Processor? Similarly, what about a View that tracked changes to all Orders and all Receipts? My understanding is that the Views will be used to update the read model (e.g. some denormalised store, like MongoDB optimised for client querying). It seems to me that the handling of such updates would be better done by a few Views rather than one for every aggregate root. Please explain what I am missing. I hope those questions make sense and many thanks in advance for any comments or suggestions. Thanks, Ashley. -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
[akka-user] Re: Pulling Pattern vs Durable Mailboxes
I was considering almost the same thing, but talked myself out of it after reading this: ( http://www.rabbitmq.com/blog/2012/04/25/rabbitmq-performance-measurements-part-2/see section Large Queues). RabbitMQ queues messages in memory, regardless of whether they are durable. The durability only dictates that they are ALSO written to disk... but if you plan for the queue to become fairly large then performance can degrade considerably because at some point it needs to page to disk. I am looking at having large bursts of messages - up to 20 million, and so I felt like allowing the queue to grow that large would probably not work for our use-case. Other MQs might behave differently and I never tested this with RabbitMQ so that might still be a valid approach... I just wanted to minimize the risk and I have the luxury of having control over how the messages are produced. Thanks for the insight! Yeah you're right in that Rabbit's performance degrades the larger its queues become. In my case I don't plan on having the queues hold millions of messages so it's definitely a use-case that I still have to explore. I was also thinking of using something like Kafka (instead of RabbitMQ) which utilizes sequential disk access but I can't say I've looked into it in much depth. When you say you talked yourself out of it, what kind of design did you end up going with if you don't mind me asking? Also in terms of implementing mailboxes to act as wrappers to a data-store's (ie. RabbitMQ, Mongo, etc...) input/output, what's your take on how heavyweight it would make them? -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
[akka-user] Re: How can the sender know that a message has been delivered (confirmed) by a channel?
that what I just want. I am still wondering should there be an deliveryConfirmedListener just as redeliverFailureListener.by this way,I will make my life easier. I don't think the application-level replay should be a answer for that replay could be lost and there have one internal ACK in the channel itself ,why not just use it? for the design ,I think some API may should be symmetrical. 在 2014年5月3日星期六UTC+8下午12时58分18秒，Heiko Seeberger写道： Hi, A short-lived actor A should send a result message to some other actor B before it terminates itself. As it is important that this message gets delivered, I would like to use a channel in order to retry message delivery. In case of permanent delivery failure (redeliverMax exceeded) the short-lived actor A would send the message to some other actor C which would know what to do. This can be implemented using a redeliverFailureListener. My question is: How can the short-lived actor A know that the message has been delivered, i.e. the ConfirmablePersistent message has been confirmed? AFAIK there's no deliverSuccessListener or such. Thanks Heiko -- Heiko Seeberger Twitter: @hseeberger Blog: blog.heikoseeberger.name -- 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] Cassandra Journal v2.0.3?
Hi Matthew, On 05.05.14 21:21, Matthew Howard wrote: Has anyone implemented an akka persistence journal for older versions of Cassandra? I see the current journal is dependent on C* v2.0.3 or higher (https://github.com/krasserm/akka-persistence-cassandra) but my app is currently on 1.1.9 and we are only actively planning to upgrade to v1.2 (just found this out - I thought we were moving to 2). I'm guessing there isn't one already out there, but thought I'd ask before attempting to implement one. Assuming I would need to implement it (probably a question for Martin directly) any warnings or recommendations? At first glance I'd obviously need to tweak the create keyspace/columnfamily commands (and change the driver), but I'm not seeing anything that appears to be too wildly dependent on C* v2.0.3 features. The handling of the partition_nr seems to be the biggest issue - I'm thinking we could just create the rowkey as a concatenation of the processor_id and partition_nr (e.g. myprocessor-0, myprocessor-1, etc... ). But I think/hope? otherwise the composite columns should work the same and I'm not going to get myself into a rabbit hole... The partition_nr is needed to split rows across nodes, otherwise, all messages of a single processor are stored on the same node (given your rowkey design). This shouldn't be a problem with, let's say, 1 billion messages per processor. However, if you want your processors to scale with a larger number of messages, there's no way around row splitting. Hope that helps. Cheers, Martin Thanks in advance, Matt Howard -- 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 mailto:akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com mailto: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. -- Martin Krasser blog:http://krasserm.blogspot.com code:http://github.com/krasserm twitter: http://twitter.com/mrt1nz -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] akka-persistence Processor preStart override problems
On 06.05.14 04:26, Vaughn Vernon wrote: When I override preStart in any way other than invoking super.preStart() my actor is unable to receive any kind of message. It seems to be stashing messages, but never delivering them. The only way I can work around this is by leaving preStart as defaulted, and using the mode variables recoveryRunning or receoveryFinished. (Or I can send Recover myself.) I found this: https://groups.google.com/d/msg/akka-user/EBV0pLttClk/oP_wixqFSw8J By this this it seems to me that the documentation probably requires clarification. In the docs I get the impression that you never need to recover an actor, but from the above link it appears that a Processor must always receive a Recover message from something. Further, it seems that the only way to avoid recovering a given actor is to ignore all messages until receoveryFinished is true. You could also send a Recover message with either toSequenceNr=0L or replayMax=0L. This will enable the processor to process new messages without replaying any messages. -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com mailto:akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com mailto: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. -- Martin Krasser blog:http://krasserm.blogspot.com code:http://github.com/krasserm twitter: http://twitter.com/mrt1nz -- 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.
