Re: [akka-user] Re: Pulling Pattern vs Durable Mailboxes
On 06.05.14 06:56, Matthew Howard wrote: Our design is still a bit young, but we're going with a work pulling pattern right now... which is something that has worked well for me in the past (this is my first Akka impl though). In terms of the overall approach of using a queue/datastore effectively as a replacement for a mailbox (or implementing your own mailbox backed by a data store) it seems like a valid design to me if you need durable messaging (or just need messaging across heterogeneous systems). It obviously adds the communication/serialization overhead to every message, but really any durable message is going to have the same overhead, so in terms of it being too heavyweight I don't think I'd worry unless very high throughput was a real priority. In that case though there are no great options if you also want the durability... but that is where distributed data stores or queues can help - if you can scale out your datastore and consumers then you can get throughput even on durable messages. I wouldn't be surprised if there were also some good options using Akka alone. On top of my large queue concerns with Rabbit I didn't particularly feel like adding another component into the mix if I didn't need to. I wouldn't be shocked if you could do something pretty cleanly with just akka persistence. I haven't looked into the new akka streams but that provides some pretty nice looking flow control you might be able to use. You may be interested in this pull request https://github.com/akka/akka/pull/15036 that enables reading from akka-persistence journals via reactive-stream producers. I'd be interested to hear some Akka-oriented options from the crew out there. -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com 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.
[akka-user] Reactive applications with CQRS and Akka Persistence?
I thought reactive applications were all event-based and, in particular, events could be generated and flow through an application from GUI back to GUI. Does the way Akka Persistence Views work prevent this (since they are, if I understand correctly, essentially polling for events)? Can a reactive path be constructed in another way with Akka Persistence that can be used in distributed applications? Are reactive applications compatible with the eventual consistency of CQRS? Please excuse my ignorance if this question doesn't make sense and I am not criticising anything, just trying to understand. 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 wouldn't be surprised if there were also some good options using Akka alone. On top of my large queue concerns with Rabbit I didn't particularly feel like adding another component into the mix if I didn't need to. I wouldn't be shocked if you could do something pretty cleanly with just akka persistence. I haven't looked into the new akka streams but that provides some pretty nice looking flow control you might be able to use. I'd be interested to hear some Akka-oriented options from the crew out there. I was also in the same mindset that you have in terms of just wanting a pure Akka solution with a pulling pattern. The only issue that I found there was in the scenario where your master actors (the one's that hold the work that other actors pull from) go down. In this case, you're losing all of the data that the master actors held unless you have some sort of safe-guard in place (not really sure what this might look like). Something like Persistence might work except for a (probably rare but still plausible) case where the majority of your Akka system goes down, including the mechanisms responsible for Persistence. It also doesn't help when you're working with a data-stream that never stops coming; there's no easy way to catch up when failures happen. I've also been reading about Akka streams and I also checked out the Typesafe activator module that they have with examples. It definitely looks very promising. Unfortunately it seems like it's something that will be released closer to the end of the year. If only it could get here sooner! -- 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] Views for many entities?
On 06.05.14 08:18, Ashley Aitken wrote: Hi Martin, Thank you for your response to my questions. On Tuesday, 6 May 2014 13:13:46 UTC+8, Martin Krasser wrote: 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? Each processor has its own logical journal, although journal plugins maintain them in a single physical backend store (replicated or not). This is not a requirement but all plugins follow this pattern so far. So, from a physical viewpoint there's a single big message store but this doesn't mean that there is a global ordering of messages. An ordering of messages is only defined within a processor (i.e. logical journal). Messages from different processors are seen as unrelated by akka-persistence. This is an interesting twist (IMHO), with regards to Eventsourcing with Akka Persistence. I was under the (perhaps naive) impression that in ES there would logically be some sort of event log that kept all events and that components could subscribe to such events. This event log is per processor (optionally with n views as subscribers). The reason that there's no global log (with a global ordering of messages) is write scalability: processors can reside on different nodes and having a global counter for all would limit scalability. An interesting alternative could be information about causal ordering of messages between processors (not implemented (yet)) and this could be implemented in a scalable way. AP seems to be taking a different tack with per processor logical journals that are polled (in some sense, please correct me if I am wrong). Polling, as done by views, is an implementation detail. Later version of akka-persistence may provide a push-based approach as well. Processors only write to the journal during normal operation (and read from it only during recovery). I guess the proposed change / ticket will at least allow a View to follow all events. 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). Yes, views are there to maintain read models. They may also keep state in memory (and take snapshots) since it can be recovered by replaying messages (optionally starting from a snapshot). Good so I am on the write track. I am confused a little about the Views keeping stage in memory and with snapshots. What state would this be? Surely the read model itself is maintaining most of the state, e.g. in a database. Could the Views themselves sometimes be the read model that were queried by the client? Is that meant to be the primary approach or not? Yes, this is meant to be the primary approach. Views that track updates from many processors make absolutely sense and have already been requested several times (see ticket). Ok, this is good, I just thought perhaps I was not understanding the design of Akka Persistence and the way it should be used for CQRS/ES, for example. I have read the discussions and thanks for pointing out the ticket. I won't ask when we can hope for a solution but I will ask (not necessarily you but anyone reading) what are people doing until then? There are several options, some are - Let the backend store (Cassandra, MongoDB or whatever) update custom views (e.g. database tables) whenever a new message is added to the journal (using triggers). - Let processors update a database directly to create a view (via channels to avoid duplicates during replay). - ... Thanks again for answering my newbie questions. I am really impressed with the elegance and simplicity of Akka Persistence and it's CQRS/ES components. Cheers, Ashley. -- 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.
[akka-user] Re: Reactive applications with CQRS and Akka Persistence?
I believe Martin may have kindly answered, at least part of, this question in another thread. If I may paraphrase him: the way Akka Persistence Views work currently (polling) is an implementation detail and later versions of Akka Persistence may provide a push-based approach as well. If journal replication is still used as the means of distribution then perhaps Views will just subscribe to a Processor (effectively the Processors's journal) and get pushed events in messages (without the Processor even running locally). Not exactly totally reactive - I assume it depends upon how the journals are replicated - but it could work. Of course, it's very likely that I am completely confused ;-) -- 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: Reactive applications with CQRS and Akka Persistence?
On 06.05.14 08:59, Ashley Aitken wrote: I believe Martin may have kindly answered, at least part of, this question in another thread. If I may paraphrase him: the way Akka Persistence Views work currently (polling) is an implementation detail and later versions of Akka Persistence may provide a push-based approach as well. If journal replication is still used as the means of distribution then perhaps Views will just subscribe to a Processor (effectively the Processors's journal) and get pushed events in messages (without the Processor even running locally). Not exactly totally reactive - I assume it depends upon how the journals are replicated - but it could work. Of course, it's very likely that I am completely confused ;-) The availability of (new) events in the journal is also an event. Whether a view is actively notified about their availability (= push) or if the view tries to find out itself (= pull) is rather a technical detail. A pull-based view even allows to decouple a processor from its view(s) in the dimension of lifetime. Why do you see this in conflict with being reactive? -- 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] Re: Reactive applications with CQRS and Akka Persistence?
On Tuesday, 6 May 2014 15:18:29 UTC+8, Martin Krasser wrote: The availability of (new) events in the journal is also an event. Whether a view is actively notified about their availability (= push) or if the view tries to find out itself (= pull) is rather a technical detail. A pull-based view even allows to decouple a processor from its view(s) in the dimension of lifetime. Why do you see this in conflict with being reactive? Reactive I take to mean push, the events are driving action in the system, from GUI to GUI. With the current way Views work I don't see them as supporting a reactive system (not a criticism), but as you mentioned this is a technical detail that may change in a later version of Akka Persistence. I am confused though, about how the whole eventual consistency of CQRS fits in with reactive systems, it seems like a sort of lazy reactivity, i.e. we'll get around to reacting to the event sometime soon ;-) Of course, CQRS is proving to me that eventual consistency is fine for most (if not nearly all) situations but I wouldn't call it reactive (personally), and I would like to know what to do when we really need reactivity. With regards to Akka Persistence this may mean the Views (or another read model maintained by the Views) having some sort of open connection to the client to forward on read model events (if there are such things?). Thanks Martin. Cheers, 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] Unexpected result on resolveOne (send ActorIdentify) (Akka 2.3.2)
I'm doing some testing on remote lookup and dead watch. Therefore I use an
actor (see below) which simple resolves a given address and in the case we
got an actor-path back we start to watch them.
When writting the sample I made a type and forgot the @ between the IP
address and the akka-system name.
.. val lookupActor = client.actorOf(Props(new LookupActor(
*akka.tcp://server127.0.0.1:2567/user/DummyActor*)), LookupActor)
Surprisingly this not existing actor could be resolved! The DeadLetters
actor seem to reply on my Identy. Is this an expected behavior?
*Log:*
[info] Found Server Actor..lets watch
akka.tasfcp://sasdferver127.0.0.1:2567/user/DummyActor his lifecycle
akka://clientSystem/deadLetters true
*Sample Actor*
class LookupActor(path: String) extends Actor {
sendIdentifyRequest()
/* same behaviour as below */
// def sendIdentifyRequest(): Unit = context.actorSelection(path) !
Identify(path)
def sendIdentifyRequest(): Unit =
context.actorSelection(path).resolveOne(Duration(5,seconds)).map { ref =
println(found actor identity: + ref)
ActorIdentity(path, Some(ref))
}.pipeTo(self)
def receive = {
case ActorIdentity(`path`, Some(actor)) =println(Found Server
Actor..lets watch +`path`+ his lifecycle + actor.path+
+actor.isTerminated)
context.watch(actor)
case ActorIdentity(`path`, None)= println(sRemote actor
not availible: $path)
case ReceiveTimeout = sendIdentifyRequest()
case Terminated(ref) =println(Remote actor
died..lets stop myself)
context.stop(self)
case _= println(Unhandeld msg
received)
}
}
--
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: Reactive applications with CQRS and Akka Persistence?
On 06.05.14 09:31, Ashley Aitken wrote: On Tuesday, 6 May 2014 15:18:29 UTC+8, Martin Krasser wrote: The availability of (new) events in the journal is also an event. Whether a view is actively notified about their availability (= push) or if the view tries to find out itself (= pull) is rather a technical detail. A pull-based view even allows to decouple a processor from its view(s) in the dimension of lifetime. Why do you see this in conflict with being reactive? Reactive I take to mean push, the events are driving action in the system, from GUI to GUI. With the current way Views work I don't see them as supporting a reactive system (not a criticism), but as you mentioned this is a technical detail that may change in a later version of Akka Persistence. From a user's (= API) perspective, a View will always receive Persistent messages (regardless whether it is working internally with a pull or push mechanism) i.e. a View always *reacts* to Persistent messages. It's this perspective that counts. An upcoming feature in Akka will also allow the creation of reactive stream producers from messages written by a processor, see also this pull request https://github.com/akka/akka/pull/15036. The rate at which the journal is polled for new messages depends on the downstream consumers demand. Here again, it is a technical detail whether this producer is internally polling for new messages or not. I am confused though, about how the whole eventual consistency of CQRS fits in with reactive systems, it seems like a sort of lazy reactivity, i.e. we'll get around to reacting to the event sometime soon ;-) Can you explain further why you think it doesn't fit? Of course, CQRS is proving to me that eventual consistency is fine for most (if not nearly all) situations but I wouldn't call it reactive (personally), and I would like to know what to do when we really need reactivity. With regards to Akka Persistence this may mean the Views (or another read model maintained by the Views) having some sort of open connection to the client to forward on read model events (if there are such things?). There are numerous implementation options to notify clients about events occuring on server side. For these notification to work, there must be some sort of connection between the client and the server. For example, long-polling is one option for a web client to *react* to server-generated events. I don't understand why you think this contradicts reactivity? Thanks Martin. Cheers, Ashley. -- 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.
[akka-user] Mystery log message from Akka
Hello, I am seeing this log message from akka. 2014-05-06 10:42:20 akka.actor.OneForOneStrategy SEVERE : Some(null) (of class scala.Some) I am using *Akka 2.2.3* and no, I can't upgrade. It's not my decision. I also can't show the code. Sorry. I have some clue about which actor is involved, but I have no clue as to how I can proceed with the debugging. I have had a brief look at the source for *OneForOneStrategy* but I got no clues from that. It might be due to my own ineptitude, but... The error happens after the completion of *preStart()* in the suspect actor and it the get stuck in a restart - error - restart ... loop. Any pointers to what I can do next is appreciated. Thanks. /Ulf A. -- 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] Configuration approach for Akka in OSGi
Hello Hakkers, today I am interested how you usually configure your bundles inside an OSGi container. I can easily access the application.conf provided with Akka itself to get to all the default values. I can also provide bundle specific configuration in separate files and my bundle would pick up those. However, I have just done some experimenting with Spray in OSGi and the problem is as follows: Several spray bundles contain resource.conf files with default values that make sense to configure spray. On top of that the user has to provide some additional values to make his route work. The ActorSystem that lives in some bundle not knowing about spray does not see the resource.conf files provided by spray and the user-bundle should only contain the values it wishes to add or override. I have seen examples to do some classloader tweaking (e.g. [1]) to bring the resource.conf files into scope when the ActorSystem is initialized. From my (probably limited) understanding that would kind of defeat the purpose of OSGi. The ActorSystem shouldn't know about the bundles that are installed and may contribute to the configuration. My current solution is to replicate the spray settings in my bundle's conf file, but that somehow doesn't feel right either. I was wondering whether someone has thought about / tried to implement some kind of whiteboard pattern ? - I am thinking along the lines of an Akka config service that starts with the default application.conf. The extender would merge resource.conf files as akka bundles are installed remove the settings again when the bundle is uninstalled. Does the Config API provide such functionality ? Well, I just wanted to hear some thoughts before diving into such an extender [1] https://groups.google.com/forum/#!topic/spray-user/lmcdBsxNzdQ Thanks and best regards Andreas -- 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, I am Nicola (not Christian), I created a github repo for you: https://github.com/pic/akkaTheHutt you have three classes: FiniteStateMachine ( no persistence, extends Actor ) AlmostPersistentFSM ( extends Processor but no use of Persistent ) PersistentFSM ( persistence ) The only difference between FiniteStateMachine and AlmostPersistentFSM is that the first extends Actor, the second extends Processor, the only difference between AlmostPersistentFSM and PersistentFSM is that the second actually uses Persistent messages. You have tests for the three classes (FiniteStateMachineSpec, ...) which are practically the same. If you try to run the tests you will see that: FiniteStateMachineSpes - OK AlmostPersistentFSMSpec - red PersistentFSMSpec - red - Also I have a new problem. I write it here but maybe a new thread would be more appropriate. There are also three objects that you can run FiniteStateMachineSpes - Main AlmostPersistentFSMSpec - AlmostPersistentMain PersistentFSMSpec - PersistentMain If you try to run PersistentMain the first time, it looks OK, journal is written, etc., etc. Then you kill the process, and you run it a second time. akka-persistence is not able to restore the state because PersistentImpl messages are sent (instead of Persistent). You see in the log: [DEBUG] [05/06/2014 13:15:42.274] [default-akka.actor.default-dispatcher-7] [akka://default/user/persistentUnderTest] processing Event(PersistentImpl(Done(List(゜⋓想춌鋋)),1,/user/persistentUnderTest,false,List(),Actor[akka://default/user/persistentUnderTest#161253413]),List()) from Actor[akka://default/user/persistentUnderTest#161253413] [WARN] [05/06/2014 13:15:42.275] [default-akka.actor.default-dispatcher-7] [akka://default/user/persistentUnderTest] unhandled event PersistentImpl(Done(List(゜⋓想춌鋋)),1,/user/persistentUnderTest,false,List(),Actor[akka://default/user/persistentUnderTest#161253413]) in state waiting [DEBUG] [05/06/2014 13:15:42.275] [default-akka.actor.default-dispatcher-7] [akka://default/user/persistentUnderTest] processing Event(PersistentImpl(Done(List(ꍎ穽ᮯ适ࡣ, ゜⋓想춌鋋)),2,/user/persistentUnderTest,false,List(),Actor[akka://default/user/persistentUnderTest#161253413]),List()) from Actor[akka://default/user/persistentUnderTest#161253413] [WARN] [05/06/2014 13:15:42.275] [default-akka.actor.default-dispatcher-7] [akka://default/user/persistentUnderTest] unhandled event PersistentImpl(Done(List(ꍎ穽ᮯ适ࡣ, ゜⋓想춌鋋)),2,/user/persistentUnderTest,false,List(),Actor[akka://default/user/persistentUnderTest#161253413]) in state waiting ... What am I doing wrong here? Thanks, Nicola On Monday, May 5, 2014 10:24:31 AM UTC+2, Akka Team wrote: 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 picc...@gmail.comjavascript: wrote: 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]
Re: [akka-user] Re: Broadcast a message with cluster sharding
Hello Endre, What about one actor from each node joining the DistributedPubSubMediator and this actor could register with a node local Akka eventbus? The sharded actors could register with the local Akka event bus for messages. So a message published to a topic, on the DistributedPubSubMediator would be received by the local actor joined to DistributedPubSubMediator which would then publish the message to the local Akka eventbus. I think this would work. I'm assuming I'll have 10,000 actors per node, but don't know until the rest of the system is in place. Each actor will be storing GPS coordinates for a rectangular region and will be used as an index into Cassandra tables. On Monday, 5 May 2014 09:19:52 UTC+1, Akka Team wrote: 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.comjavascript: 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+...@googlegroups.com javascript:. To post to this group, send email to akka...@googlegroups.comjavascript: . Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout. -- 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, We were thinking of that same design. If you implement before we do, please share your experiences with that design and we will do the same. Chanan -- 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: Akka OSGI renewed
Hello Hakkers, following this discussion, I have made some progress in getting an actor based API around the OSGI framework going. For those interested, the project is located at [1]. There is some documentation at [2] - [4]. [1] https://github.com/woq/de.woq.osgi.java [2] https://github.com/woq/de.woq.osgi.java/wiki/Building [3] https://github.com/woq/de.woq.osgi.java/wiki/AkkaIntegration [4] https://github.com/woq/de.woq.osgi.java/wiki/AkkaApiExample Happy for any feedback - good or bad Andreas -- 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
Hello Chanan, This is an evening project for me so you might get it done before me. Although I got the cluster sharding, with cassandra, working last night. On Tuesday, 6 May 2014 14:14:19 UTC+1, Chanan Braunstein wrote: Hi Jabbar, We were thinking of that same design. If you implement before we do, please share your experiences with that design and we will do the same. Chanan -- 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'm the author of the blog post from Conspire you referenced. In our case, losing the supervisor isn't a problem because all work is generated from a SQL database. If the supervisor crashes, we can just start over. Our worker nodes subscribe to cluster event notifications and will queue their messages to the supervisor if its node goes down so we also don't lose any in-progress work. In addition, our workers are responsible for their own persistence, we only send instructions and status updates between nodes so there's little concern about losing work in-flight. When we tried to take our first implementation of this system into production (using Akka but with lots of actor+future combos), it crashed *horribly*. Nodes would get marked unreachable within a minute of starting the cluster because worker actors immediately spun their work out to a future and started on the next item, saturating our puny EC2 nodes which prevented Akka's internal cluster/remoting actors from ever getting any CPU time. In our refactor we focused on building a very defensive system which can lose any given node without breaking down—a key to this was pulling work rather than pushing it (plus ditching the futures except when dealing with IO). Since that refactor, we've quadrupled the load on our Akka cluster and had zero issues. We can trivially add and remove workers if we can a burst of load and if a worker does crash, its work is re-dispatched to another work from its last known save point (not really a term we use but I don't want to get into the weeds on what's really a domain-specific concern). On Tuesday, May 6, 2014 12:29:33 AM UTC-6, massivedynamic wrote: I wouldn't be surprised if there were also some good options using Akka alone. On top of my large queue concerns with Rabbit I didn't particularly feel like adding another component into the mix if I didn't need to. I wouldn't be shocked if you could do something pretty cleanly with just akka persistence. I haven't looked into the new akka streams but that provides some pretty nice looking flow control you might be able to use. I'd be interested to hear some Akka-oriented options from the crew out there. I was also in the same mindset that you have in terms of just wanting a pure Akka solution with a pulling pattern. The only issue that I found there was in the scenario where your master actors (the one's that hold the work that other actors pull from) go down. In this case, you're losing all of the data that the master actors held unless you have some sort of safe-guard in place (not really sure what this might look like). Something like Persistence might work except for a (probably rare but still plausible) case where the majority of your Akka system goes down, including the mechanisms responsible for Persistence. It also doesn't help when you're working with a data-stream that never stops coming; there's no easy way to catch up when failures happen. I've also been reading about Akka streams and I also checked out the Typesafe activator module that they have with examples. It definitely looks very promising. Unfortunately it seems like it's something that will be released closer to the end of the year. If only it could get here sooner! -- 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: Pulling Pattern vs Durable Mailboxes
6 maj 2014 kl. 17:38 skrev Ryan Tanner ryan.tan...@gmail.com: I'm the author of the blog post from Conspire you referenced. In our case, losing the supervisor isn't a problem because all work is generated from a SQL database. If the supervisor crashes, we can just start over. Our worker nodes subscribe to cluster event notifications and will queue their messages to the supervisor if its node goes down so we also don't lose any in-progress work. In addition, our workers are responsible for their own persistence, we only send instructions and status updates between nodes so there's little concern about losing work in-flight. When we tried to take our first implementation of this system into production (using Akka but with lots of actor+future combos), it crashed *horribly*. Nodes would get marked unreachable within a minute of starting the cluster because worker actors immediately spun their work out to a future and started on the next item, saturating our puny EC2 nodes which prevented Akka's internal cluster/remoting actors from ever getting any CPU time. In our refactor we focused on building a very defensive system which can lose any given node without breaking down—a key to this was pulling work rather than pushing it (plus ditching the futures except when dealing with IO). Since that refactor, we've quadrupled the load on our Akka cluster and had zero issues. Glad to hear that!!! /Patrik We can trivially add and remove workers if we can a burst of load and if a worker does crash, its work is re-dispatched to another work from its last known save point (not really a term we use but I don't want to get into the weeds on what's really a domain-specific concern). On Tuesday, May 6, 2014 12:29:33 AM UTC-6, massivedynamic wrote: I wouldn't be surprised if there were also some good options using Akka alone. On top of my large queue concerns with Rabbit I didn't particularly feel like adding another component into the mix if I didn't need to. I wouldn't be shocked if you could do something pretty cleanly with just akka persistence. I haven't looked into the new akka streams but that provides some pretty nice looking flow control you might be able to use. I'd be interested to hear some Akka-oriented options from the crew out there. I was also in the same mindset that you have in terms of just wanting a pure Akka solution with a pulling pattern. The only issue that I found there was in the scenario where your master actors (the one's that hold the work that other actors pull from) go down. In this case, you're losing all of the data that the master actors held unless you have some sort of safe-guard in place (not really sure what this might look like). Something like Persistence might work except for a (probably rare but still plausible) case where the majority of your Akka system goes down, including the mechanisms responsible for Persistence. It also doesn't help when you're working with a data-stream that never stops coming; there's no easy way to catch up when failures happen. I've also been reading about Akka streams and I also checked out the Typesafe activator module that they have with examples. It definitely looks very promising. Unfortunately it seems like it's something that will be released closer to the end of the year. If only it could get here sooner! -- 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] Views for many entities?
Thanks again Martin. On Tuesday, 6 May 2014 14:37:48 UTC+8, Martin Krasser wrote: Good so I am on the write track. I am confused a little about the Views keeping stage in memory and with snapshots. What state would this be? Surely the read model itself is maintaining most of the state, e.g. in a database. Could the Views themselves sometimes be the read model that were queried by the client? Is that meant to be the primary approach or not? Yes, this is meant to be the primary approach. So, please correct me if I am wrong, the View(s) are a front for the read model, which is stored either 1) inside each View object's state or 2) in a hidden backend store? Which one of those is most common? Or something else? Views that track updates from many processors make absolutely sense and have already been requested several times (see ticket). I won't ask when we can hope for a solution but I will ask (not necessarily you but anyone reading) what are people doing until then? There are several options, some are - Let the backend store (Cassandra, MongoDB or whatever) update custom views (e.g. database tables) whenever a new message is added to the journal (using triggers). Are you talking about the backend store for the journal (for which LevelDB is the default)? And that when a new event is added to the backend store / journal a trigger fires that updates custom denormalised entries for the read model? - Let processors update a database directly to create a view (via channels to avoid duplicates during replay). I'm not so sure I understand this one. Let the Processor update the domain model AND the read model backend store? I guess that's possible if it is on the same node. And use a Channel to ensure the read model doesn't get redundantly updated. Processor =Channel= Actor (which is the read model or updates the backend store)? Cheers, 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.
Re: [akka-user] Re: Reactive applications with CQRS and Akka Persistence?
Thanks Martin. On Tuesday, 6 May 2014 15:53:28 UTC+8, Martin Krasser wrote: On 06.05.14 09:31, Ashley Aitken wrote: Reactive I take to mean push, the events are driving action in the system, from GUI to GUI. From a user's (= API) perspective, a View will always receive Persistent messages (regardless whether it is working internally with a pull or push mechanism) i.e. a View always *reacts* to Persistent messages. It's this perspective that counts. I am confused though, about how the whole eventual consistency of CQRS fits in with reactive systems, it seems like a sort of lazy reactivity, i.e. we'll get around to reacting to the event sometime soon ;-) Can you explain further why you think it doesn't fit? I guess you have a slightly weaker interpretation of reactive than mine. I feel reactive needs to be event-based and thus push. As an analogy, a Web application in which a user had to refresh the page to see any changes wouldn't be reactive (IMHO). That said, a regular enough pull can approximate a push. With regards to Akka Persistence this may mean the Views (or another read model maintained by the Views) having some sort of open connection to the client to forward on read model events (if there are such things?). There are numerous implementation options to notify clients about events occuring on server side. For these notification to work, there must be some sort of connection between the client and the server. For example, long-polling is one option for a web client to *react* to server-generated events. I don't understand why you think this contradicts reactivity? Sorry, if I was not clear. I see this as the way to reactivity, e.g. commands from the client may become domain events on the server that may result in changes to the read model that may produce view events that are transmitted to the client which requests any updated view data it needs. No polling. That would seem to me to be a necessary aspect of any CQRS implementation desiring a reactive client. Interestingly (to me at least ;-), the Meteor JS framework has latency compensation so that views in the client are updated immediately to reflect changes without waiting for the server but later if the server produces different results (e.g. denies the changes) the client's view is patched to show the true result. I guess that's for a limited type of applications though and the patching could be somewhat disconcerting for the user. Cheers, 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] Visualisation of running system
Which tools do you use to visualise your running Akka system? I know that the Typesafe Console can be used, but is that still being developed? -- 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] Visualisation of running system
Hello there, The Console is in deed EndOfLife-ing. The Typesafe Activator is on it’s way to support more and more actor tracing etc. Currently it does a little bit already, though it’s currently not a production solution. Thanks to EOLing the console multiple community projects have appeared around tracing, I’m aware of Kamon: http://kamon.io and AkkaTracing: https://github.com/levkhomich/akka-tracing // Was not able to try them out yet. I hope that helps (a bit) :-) -- Konrad 'ktoso' Malawski hAkker - Typesafe, Inc -- 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] Visualisation of running system
I'm using Kamon in production with the docker image kamon/grafana-graphite. You should check http://kamon.io/teamblog/2014/04/27/get-started-quicker-with-our-docker-image/ Cheers, Sergio Magnacco Despegar.com El martes, 6 de mayo de 2014 15:52:36 UTC-3, Konrad Malawski escribió: Hello there, The Console is in deed EndOfLife-ing. The Typesafe Activator is on it’s way to support more and more actor tracing etc. Currently it does a little bit already, though it’s *currently* not a production solution. Thanks to EOLing the console multiple community projects have appeared around tracing, I’m aware of Kamon: http://kamon.io and AkkaTracing: https://github.com/levkhomich/akka-tracing *// Was not able to try them out yet.* I hope that helps (a bit) :-) -- Konrad 'ktoso' Malawski hAkker - Typesafe, Inc http://www.scaladays.org/ -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Re: Reactive applications with CQRS and Akka Persistence?
Why not use a business-level identity as a correlation id that travels
through the processing and view compositions that you describe? In the end
you could use an EventBus to tell a given presentation that its newly
composed view is available. You might find your answers using something
like this:
class PresentationEventBus extends EventBus with SubchannelClassification {
... }
On Tuesday, May 6, 2014 11:10:46 AM UTC-6, Ashley Aitken wrote:
Thanks Martin.
On Tuesday, 6 May 2014 15:53:28 UTC+8, Martin Krasser wrote:
On 06.05.14 09:31, Ashley Aitken wrote:
Reactive I take to mean push, the events are driving action in the
system, from GUI to GUI.
From a user's (= API) perspective, a View will always receive
Persistent messages (regardless whether it is working internally with a
pull or push mechanism) i.e. a View always *reacts* to Persistent messages.
It's this perspective that counts.
I am confused though, about how the whole eventual consistency of CQRS
fits in with reactive systems, it seems like a sort of lazy reactivity,
i.e. we'll get around to reacting to the event sometime soon ;-)
Can you explain further why you think it doesn't fit?
I guess you have a slightly weaker interpretation of reactive than mine.
I feel reactive needs to be event-based and thus push. As an analogy, a
Web application in which a user had to refresh the page to see any changes
wouldn't be reactive (IMHO). That said, a regular enough pull can
approximate a push.
With regards to Akka Persistence this may mean the Views (or another read
model maintained by the Views) having some sort of open connection to the
client to forward on read model events (if there are such things?).
There are numerous implementation options to notify clients about events
occuring on server side. For these notification to work, there must be some
sort of connection between the client and the server. For example,
long-polling is one option for a web client to *react* to server-generated
events. I don't understand why you think this contradicts reactivity?
Sorry, if I was not clear. I see this as the way to reactivity, e.g.
commands from the client may become domain events on the server that may
result in changes to the read model that may produce view events that are
transmitted to the client which requests any updated view data it needs.
No polling.
That would seem to me to be a necessary aspect of any CQRS implementation
desiring a reactive client.
Interestingly (to me at least ;-), the Meteor JS framework has latency
compensation so that views in the client are updated immediately to
reflect changes without waiting for the server but later if the server
produces different results (e.g. denies the changes) the client's view is
patched to show the true result.
I guess that's for a limited type of applications though and the patching
could be somewhat disconcerting for the user.
Cheers,
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: Visualisation of running system
Thanks for the input! I will have a look at both tools. Den tirsdag den 6. maj 2014 20.41.40 UTC+2 skrev Anders Bech Mellson: Which tools do you use to visualise your running Akka system? I know that the Typesafe Console can be used, but is that still being developed? -- 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] new hash based router
Hi I was trying to implement an router which could router a message to an specified routee via the message's key.just as the ConsistentHashRouter. when I look at the selected method ,the comes out routees are in an immutable seq,but not a mapString,Routee,so if I want to selected one of the routee I should iterate the routee in the seq? or I should use my one implement? I have checked the ConsistentHashRouter's logic,it has an inner map and an transform the data in the seq to map,and selected on the map if the passed in seq has not changed otherwise will rebuild the map. So ,I was wondering,If I want to implement on hash based one should I use the concorrentHashMap for the treadsafe? and how about the actorRef.getContext().child(name)? should it be O(1),is it based on hash in the inner implement? all in all, 1,if I want to implement an hash based router ,in the logic implement i must transform the seq to hashmap right? 2,the child(name:String) to selecte an child of an parent Actor is O(1)? -- 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: Reactive applications with CQRS and Akka Persistence?
On 06.05.14 19:10, Ashley Aitken wrote: Thanks Martin. On Tuesday, 6 May 2014 15:53:28 UTC+8, Martin Krasser wrote: On 06.05.14 09:31, Ashley Aitken wrote: Reactive I take to mean push, the events are driving action in the system, from GUI to GUI. From a user's (= API) perspective, a View will always receive Persistent messages (regardless whether it is working internally with a pull or push mechanism) i.e. a View always *reacts* to Persistent messages. It's this perspective that counts. I am confused though, about how the whole eventual consistency of CQRS fits in with reactive systems, it seems like a sort of lazy reactivity, i.e. we'll get around to reacting to the event sometime soon ;-) Can you explain further why you think it doesn't fit? I guess you have a slightly weaker interpretation of reactive than mine. I feel reactive needs to be event-based and thus push. As an analogy, a Web application in which a user had to refresh the page to see any changes wouldn't be reactive (IMHO). That said, a regular enough pull can approximate a push. No, we have the same understanding that reactive means event-based and thus push. Of course, requiring a user to manually refresh a web page is *not* reactive. Long polling (mentioned below) is just a technology to *emulate* a server push to clients over HTTP (see also Comet http://en.wikipedia.org/wiki/Comet_%28programming%29, but I'm pretty sure you're familiar with that). Although (long) polling is used under the hood, the user experience is that events are pushed to the client. Similar arguments apply to pull/push when using views (although the underlying technology is different). Hope that clarifies things. With regards to Akka Persistence this may mean the Views (or another read model maintained by the Views) having some sort of open connection to the client to forward on read model events (if there are such things?). There are numerous implementation options to notify clients about events occuring on server side. For these notification to work, there must be some sort of connection between the client and the server. For example, long-polling is one option for a web client to *react* to server-generated events. I don't understand why you think this contradicts reactivity? Sorry, if I was not clear. I see this as the way to reactivity, e.g. commands from the client may become domain events on the server that may result in changes to the read model that may produce view events that are transmitted to the client which requests any updated view data it needs. No polling. As explained above. Push from a user's perspective and a Comet http://en.wikipedia.org/wiki/Comet_%28programming%29 (or web socket or whatever ...) under the hood to push these changes to the web client (no *explicit* polling/refresh by the user). That would seem to me to be a necessary aspect of any CQRS implementation desiring a reactive client. Interestingly (to me at least ;-), the Meteor JS framework has latency compensation so that views in the client are updated immediately to reflect changes without waiting for the server but later if the server produces different results (e.g. denies the changes) the client's view is patched to show the true result. I guess that's for a limited type of applications though and the patching could be somewhat disconcerting for the user. Cheers, Ashley. -- 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] Views for many entities?
On 06.05.14 18:21, Ashley Aitken wrote: Thanks again Martin. On Tuesday, 6 May 2014 14:37:48 UTC+8, Martin Krasser wrote: Good so I am on the write track. I am confused a little about the Views keeping stage in memory and with snapshots. What state would this be? Surely the read model itself is maintaining most of the state, e.g. in a database. Could the Views themselves sometimes be the read model that were queried by the client? Is that meant to be the primary approach or not? Yes, this is meant to be the primary approach. So, please correct me if I am wrong, the View(s) are a front for the read model, which is stored either 1) inside each View object's state or 2) in a hidden backend store? Which one of those is most common? Or something else? Most common is 1, because state is automatically re-created when the view is (re)started. Views could also use channels to update a backend store (2) if you want but it's usually more efficient if processors do that directly (see below). Views that track updates from many processors make absolutely sense and have already been requested several times (see ticket). I won't ask when we can hope for a solution but I will ask (not necessarily you but anyone reading) what are people doing until then? There are several options, some are - Let the backend store (Cassandra, MongoDB or whatever) update custom views (e.g. database tables) whenever a new message is added to the journal (using triggers). Are you talking about the backend store for the journal (for which LevelDB is the default)? And that when a new event is added to the backend store / journal a trigger fires that updates custom denormalised entries for the read model? Yes. - Let processors update a database directly to create a view (via channels to avoid duplicates during replay). I'm not so sure I understand this one. Let the Processor update the domain model AND the read model backend store? I guess that's possible if it is on the same node. No, there's no need to have the read model backend store on the same node: - either use a local channel destination with a remote connection to the read model backend store - or a remote channel destination that connects to the read model backend store. And use a Channel to ensure the read model doesn't get redundantly updated. Yes (and channels additionally provide at-least-once delivery semantics). Processor =Channel= Actor (which is the read model or updates the backend store)? See above. Cheers, Ashley. -- 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 20:52, Vaughn Vernon wrote: Thanks. I still think that the docs need to be strengthened to state that the Processor will not work unless it receives a Recover message, and that the Recover message could take several forms depending on the recovery goals. I agree. Do you want to make a pull request with the changes you'd like to see in the docs? Thanks, Martin On Monday, May 5, 2014 11:40:59 PM UTC-6, Martin Krasser wrote: 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 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 http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user 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 http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout 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.
Re: [akka-user] Re: Pulling Pattern vs Durable Mailboxes
On 06.05.14 21:13, Matthew Howard wrote: On Tuesday, May 6, 2014 2:06:16 AM UTC-4, Martin Krasser wrote: You may be interested in this pull request https://github.com/akka/akka/pull/15036 that enables reading from akka-persistence journals via reactive-stream producers. Yea, actually that looks much like what I had in mind. On Tuesday, May 6, 2014 2:29:33 AM UTC-4, massivedynamic wrote: I was also in the same mindset that you have in terms of just wanting a pure Akka solution with a pulling pattern. The only issue that I found there was in the scenario where your master actors (the one's that hold the work that other actors pull from) go down. In this case, you're losing all of the data that the master actors held unless you have some sort of safe-guard in place (not really sure what this might look like). I am in the same boat as Ryan mentions below - I'm enriching and processing data that already resides in a database, so if a failure occurs I can just reprocess from the start. That is generally the direction I was thinking with a pure Akka implementation based on persistence. If you had a (persistent) Processor(s) just accumulating Tweet events, then a View(s) could subscribe to that processor and emit the events to downstream workers for processing. In that case the View acts as the coordinator and the Processor is the durable mailbox effectively, if either goes down you have the ability to recreate it and effectively pick up where you left off. You'd need to play with the snapshots, replay and recovery a bit to get proper flow control while reading the journal... Based on a quick read of Martin's PR above I think that is where streams would be helpful (a replacement of the View in my scenario). A PersistentChannel might be an easier option now that I think about it... then your workers can confirm when done - providing you automatic replay for anything missed if coordinator/worker dies. Please not that the primary use case for persistent channels is to deal with slow and/or temporarily available consumers/destinations. It is not optimized for high throughput (yet). More detailed, a persistent channel usually has a very high write rate (with up to 100k msgs/sec, provided by a Processor it uses internally) but only a moderate message delivery rate to consumers. If you need a persistent queue with a high message throughput, consider using a 3rd party messaging product. I'm not sure in your case how you might protect yourself if the coordinator dies, although if that is likely there should be some way to minimize the job and state of the coordinator to minimize it's role. So for example if the coordinator is responsible for a) pulling data from the Twitter stream, and b) supervising workers to consume that data, and c) acting on the response from workers and maintaining some state... then perhaps that really is best done with 3 actors. I could see a) and c) possibly being done with actors behind a router to provide some fault-tolerance (in which case a couldn't really be a Processor, but I think it could use a PersistentChannel). In my case I had lots of niggling reasons not to introduce another architectural component - but I think some MQ/DB option is perfectly reasonable. On another note - Ryan, I have been reading your blog also... very helpful, thanks. -- 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.
