Re: [akka-user] Akka architecture pattern vs typed actors
Hi Muki, I have skimmed through the template and added a few comments. Since you have mentioned that the main pro of this pattern is ease of use and typesafety I think that Akka Typed Actors http://doc.akka.io/docs/akka/2.3.4/scala/typed-actors.html provide just that. Have you considered using them? If so, what did you like or found hard about them to roll your own solution? On Thu, Jul 31, 2014 at 1:06 AM, Muki nepomuk.sei...@gmail.com wrote: Hi, I created a small sample app for a little architecture pattern for akka applications. The idea can be terribly wrong, but I wanted to get some feedback on it: https://github.com/muuki88/akka-architecture The README explains the pattern and how to apply it. It's more or less a way around typed actors. cheers, Muki -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout. -- Martynas Mickevičius Typesafe http://typesafe.com/ – Reactive http://www.reactivemanifesto.org/ Apps on the JVM -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
[akka-user] Re: Akka architecture pattern vs typed actors
Hi Muki, I like the pattern. In details I would use it a bit different though. I do not like that some of the logic is hidden in the trait, I would prefer only to pass the messages to typed receive methods in greetingReceive. It does not add any real typesafety though, as there is no way to ensure that the actor passed into your consumer actually meets the contract, therefore I would not really see it as an alternative to typed actors, but as a way to document and enforce the contracts between two actors. The wiring of the actors still can go wrong and is not enforced in any way. Still, I think this is a worthwhile pattern especially when facing developers new to Akka or very complex actor wiring. I would love to see an Activator Template with a more complex example using this pattern. Cheers, Michael Am Donnerstag, 31. Juli 2014 00:06:02 UTC+2 schrieb Muki: Hi, I created a small sample app for a little architecture pattern for akka applications. The idea can be terribly wrong, but I wanted to get some feedback on it: https://github.com/muuki88/akka-architecture The README explains the pattern and how to apply it. It's more or less a way around typed actors. cheers, Muki -- 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] combining Akka Persistence with Akka Scheduling
Hi Greg, just dropping this in case you have not seen that it is possible to use quartz https://github.com/akka/akka/blob/9dae0ad525a92ebf8b0f5f42878a10628ac24aae/akka-samples/akka-sample-camel-scala/src/main/scala/sample/camel/QuartzExample.scala through akka-camel. On Fri, Jul 25, 2014 at 5:46 PM, Greg Flanagan ventis...@gmail.com wrote: Endre, Seems reasonable to keep the scheduler light weight and performant. My plans were to build something around it. Thanks. Greg On Friday, July 25, 2014 7:40:39 AM UTC-7, Akka Team wrote: Hi Greg, On Fri, Jul 25, 2014 at 4:20 PM, Greg Flanagan vent...@gmail.com wrote: Hey Konrad, I wasn't planning on making it as powerful as quartz but simply making what's available in the scheduler persistent, so that work that is deferred (i.e. scheduled) will not be lost on jvm shutdown. my use case doesn't require Quartz (i.e. run at 4:50 am on Tuesday), but I do need the deferred jobs to persisted through jvm restarts. The Akka scheduler has been designed for high-volume low-resolution timing tasks, typically timeouts -- all with the requirement of high performance. While you can combine persistence and the Akka scheduler to achieve what you want, we will keep the scheduler simple -- since this is a highly performance sensitive module we do not want to add features there. You can definitely build something around it though. -Endre cheers, Greg On Friday, July 25, 2014 1:18:47 AM UTC-7, Konrad Malawski wrote: Hello Greg, short question - do you aim to provide something as powerful as quartz using this? I mean on monday at 13:02 etc. Because that's not really what our scheduler is designed to do - we only work with in X amount of time. Instead maybe you'd simply like to integrate quartz with akka, as this extension does: https://github.com/typesafehub/akka-quartz-scheduler And let it do it's job :-) On Fri, Jul 25, 2014 at 1:05 AM, Greg Flanagan vent...@gmail.com wrote: I'm interested in combining Akka persistence which Akka Scheduling and wanted to know if there was an interest out there for something like this? I basically need a scheduler that doesn't loose state after a vm crash. I've used Quartz before and it's too much framework for what I want. Any requests of features people would like to see in this type of module? Has it already been done and I just haven't searched google enough? Cheers, Greg -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/c urrent/additional/faq.html Search the archives: https://groups.google.com/grou p/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+...@googlegroups.com. To post to this group, send email to akka...@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout. -- Cheers, Konrad 'ktoso' Malawski hAkker @ Typesafe http://typesafe.com -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/ current/additional/faq.html Search the archives: https://groups.google.com/ group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+...@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. -- Martynas Mickevičius Typesafe http://typesafe.com/ – Reactive http://www.reactivemanifesto.org/ Apps on the JVM -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this
[akka-user] Re: Using Akka to access multiple databases
Please look this before you decide to roll you own. I've being using this for a while and it stable, async and works well. https://github.com/etaty/rediscala there are other open source Redis Akka based drivers available as well. On Wednesday, July 30, 2014 11:48:18 AM UTC-4, Luis Medina wrote: Hi everyone, My company is planning to use Akka for a new feature that we're working on and we want to run our design by a few set of eyes from the Akka community just to make sure that what we're doing makes sense and also to get some feedback and see if perhaps there are other ways of doing things. The new service that we're building will involve accessing 3 different Redis databases to both persist and retrieve data. We can call these 3 databases: TopicDB - holds topics that are added/removed. StatusDB - holds the current status of a topic. Every topic is added to this db for tracking its status. Topics are added/updated but never removed. RequestDB - holds a request queue. Every topic generates a request in this db, that can also be removed. Basically additions or removals to the TopicDB are driven by an external application which must then direct the updates to the other 2 dbs as appropriate. We're planning on having a setup such that for each db there will be what we call a RedisSyncActor which, as the name implies, will sync up with the particular database that it corresponds to. In order to do this syncing, each of these RedisSyncActors will have at most 2 children, a RedisPersisterActor and a RedisListenerActor which will persist data into Redis and will receive data from Redis respectively. https://lh4.googleusercontent.com/-coQA-XEkgJw/U9kTQiTcPMI/AI4/jB4mhcMNehw/s1600/image1.png Now, earlier I said at most because in reality, every Redis database will not necessarily make use of both of each children. Based on our requirements, the setup will look like this where the RequestDB is the only one with both a RedisPersisterActor and a RedisListenerActor while the TopicDB only has a RedisListenerActor and the StatusDB only has a RedisPersisterActor. https://lh3.googleusercontent.com/-AyDu7Pf7w1Q/U9kTWDp9BBI/AJA/s7aIYLgDmco/s1600/image2.png Now, in terms of the data flow and interactions between the actors, this will look something like this: https://lh5.googleusercontent.com/-eIJNHIc3EEs/U9kTaxgILsI/AJI/50Z1o6ABHgs/s1600/image3.png 1. Whenever the TopicDB is changed by adding or removing what we call topics, the TopicRedisListenerActor will pick up on these changes by using the pub/sub feature that Redis provides. 2. Once the TopicRedisListenerActor receives these changes it will send them in 2 directions: a. Regardless of what type of topic change it received (ie. a topic that was added, a topic that was removed, etc), the TopicRedisListenerActor will send it back to its TopicRedisSyncActor parent who will in turn send it off to the StatusRedisSyncActor that handles the StatusDB. This StatusRedisSyncActor will then forward the topic changes to its StatusRedisPersisterActor child so that the change can be persisted to the StatusDB. b. Secondly, if the topic change indicates that a topic was removed from the TopicDB, the TopicRedisListenerActor will send a RemoveTopic message to the TopicRedisSyncActor. This TopicRedisSyncActor will then forward the change to the RequestRedisSyncActor so that the RequestDB can remove the topic as well. 3. Depending on whether or not StatusDB already knows about the id of the topic changes that it receives, this will cause particular updates to happen in the database. If the topic change reflected the creation of a new topic, then a new entry will be added to the StatusDB and the StatusRedisPersisterActor will send back a reply to its StatusRedisSyncActor parent containing the topic and informing it of this action. 4. If the StatusRedisSyncActor receives a notification from its StatusRedisPersisterActor that a new entry was added to the StatusDB then it will send off this topic to ConverterActor which will convert the topic into what we call a request. 5. Afterwards the ConverterActor will send this newly converted request off to the RequestRedisSyncActor. This RequestRedisSyncActor will then send the request to its RequestRedisPersisterActor child so that it can be persisted into the RequestDB. 6. The RequestRedisSyncActor also has a RequestRedisListenerActor which listens for changes that occur in the RequestDB. In this case, it will pick up the fact that a new request was added to the RequestDB by the RequestRedisPersisterActor in step 5 and it will send if off to other parts of the service for further processing. As you can see there is quite a lot going on so we want to be sure we're on the right track. A question that we had is: Are we creating too many Redis-related actors, and is
[akka-user] Re: Using Akka to access multiple databases
Soumya, Thanks for your response. I work with Luis on this. We are currently using Java, and have used Jedis for redis access. Do you have any suggestions for Java-based redis clients that work well for Akka? lakshmi On Wednesday, July 30, 2014 8:48:18 AM UTC-7, Luis Medina wrote: Hi everyone, My company is planning to use Akka for a new feature that we're working on and we want to run our design by a few set of eyes from the Akka community just to make sure that what we're doing makes sense and also to get some feedback and see if perhaps there are other ways of doing things. The new service that we're building will involve accessing 3 different Redis databases to both persist and retrieve data. We can call these 3 databases: TopicDB - holds topics that are added/removed. StatusDB - holds the current status of a topic. Every topic is added to this db for tracking its status. Topics are added/updated but never removed. RequestDB - holds a request queue. Every topic generates a request in this db, that can also be removed. Basically additions or removals to the TopicDB are driven by an external application which must then direct the updates to the other 2 dbs as appropriate. We're planning on having a setup such that for each db there will be what we call a RedisSyncActor which, as the name implies, will sync up with the particular database that it corresponds to. In order to do this syncing, each of these RedisSyncActors will have at most 2 children, a RedisPersisterActor and a RedisListenerActor which will persist data into Redis and will receive data from Redis respectively. https://lh4.googleusercontent.com/-coQA-XEkgJw/U9kTQiTcPMI/AI4/jB4mhcMNehw/s1600/image1.png Now, earlier I said at most because in reality, every Redis database will not necessarily make use of both of each children. Based on our requirements, the setup will look like this where the RequestDB is the only one with both a RedisPersisterActor and a RedisListenerActor while the TopicDB only has a RedisListenerActor and the StatusDB only has a RedisPersisterActor. https://lh3.googleusercontent.com/-AyDu7Pf7w1Q/U9kTWDp9BBI/AJA/s7aIYLgDmco/s1600/image2.png Now, in terms of the data flow and interactions between the actors, this will look something like this: https://lh5.googleusercontent.com/-eIJNHIc3EEs/U9kTaxgILsI/AJI/50Z1o6ABHgs/s1600/image3.png 1. Whenever the TopicDB is changed by adding or removing what we call topics, the TopicRedisListenerActor will pick up on these changes by using the pub/sub feature that Redis provides. 2. Once the TopicRedisListenerActor receives these changes it will send them in 2 directions: a. Regardless of what type of topic change it received (ie. a topic that was added, a topic that was removed, etc), the TopicRedisListenerActor will send it back to its TopicRedisSyncActor parent who will in turn send it off to the StatusRedisSyncActor that handles the StatusDB. This StatusRedisSyncActor will then forward the topic changes to its StatusRedisPersisterActor child so that the change can be persisted to the StatusDB. b. Secondly, if the topic change indicates that a topic was removed from the TopicDB, the TopicRedisListenerActor will send a RemoveTopic message to the TopicRedisSyncActor. This TopicRedisSyncActor will then forward the change to the RequestRedisSyncActor so that the RequestDB can remove the topic as well. 3. Depending on whether or not StatusDB already knows about the id of the topic changes that it receives, this will cause particular updates to happen in the database. If the topic change reflected the creation of a new topic, then a new entry will be added to the StatusDB and the StatusRedisPersisterActor will send back a reply to its StatusRedisSyncActor parent containing the topic and informing it of this action. 4. If the StatusRedisSyncActor receives a notification from its StatusRedisPersisterActor that a new entry was added to the StatusDB then it will send off this topic to ConverterActor which will convert the topic into what we call a request. 5. Afterwards the ConverterActor will send this newly converted request off to the RequestRedisSyncActor. This RequestRedisSyncActor will then send the request to its RequestRedisPersisterActor child so that it can be persisted into the RequestDB. 6. The RequestRedisSyncActor also has a RequestRedisListenerActor which listens for changes that occur in the RequestDB. In this case, it will pick up the fact that a new request was added to the RequestDB by the RequestRedisPersisterActor in step 5 and it will send if off to other parts of the service for further processing. As you can see there is quite a lot going on so we want to be sure we're on the right track. A question that we had is: Are we creating too many Redis-related actors, and is there a more
[akka-user] Re: Akka architecture pattern vs typed actors
Hi Michael, Martynas, Thanks for all the feedback. I added a second example and will add a third soon. Of course you can design the methods in the trait as you like. Sometimes you may want to hide the message, sometimes not. I think this depends on the use case. And yes, you are absolutely right regarding typesafety on the implementation side. On the consumerside you have typed methods, which makes it easier. However you have to provide the correct actorRef, which is a problem this pattern doesn't try to solve. My biggest fear is, that using this pattern will escalate in overengineering stuff you actually can solve a lot easier. Maybe it's a nice starter for beginners as you mentioned. thanks again, Muki PS: Yeah, I'll try to pull an activator out of this Am Donnerstag, 31. Juli 2014 09:52:34 UTC+2 schrieb Michael Pisula: Hi Muki, I like the pattern. In details I would use it a bit different though. I do not like that some of the logic is hidden in the trait, I would prefer only to pass the messages to typed receive methods in greetingReceive. It does not add any real typesafety though, as there is no way to ensure that the actor passed into your consumer actually meets the contract, therefore I would not really see it as an alternative to typed actors, but as a way to document and enforce the contracts between two actors. The wiring of the actors still can go wrong and is not enforced in any way. Still, I think this is a worthwhile pattern especially when facing developers new to Akka or very complex actor wiring. I would love to see an Activator Template with a more complex example using this pattern. Cheers, Michael Am Donnerstag, 31. Juli 2014 00:06:02 UTC+2 schrieb Muki: Hi, I created a small sample app for a little architecture pattern for akka applications. The idea can be terribly wrong, but I wanted to get some feedback on it: https://github.com/muuki88/akka-architecture The README explains the pattern and how to apply it. It's more or less a way around typed actors. cheers, Muki -- 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] reddis based job queue framework in akka? similiar to reque?
Hi, what is your use-case? Why do you want reddis? You can easily build a persistent job queue with akka-persistence. On Tue, Jul 29, 2014 at 8:22 PM, gitted sahmed1...@gmail.com wrote: Hello! Is there a akka based job/queue framework out there in the open source world? I'm looking for something similiar to https://github.com/resque/resque. Basically a queue that is built on top of redis. Resque also then has a base class where you build your custom worker processes that will process the messages off redis queue. -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout. -- Martynas Mickevičius Typesafe http://typesafe.com/ – Reactive http://www.reactivemanifesto.org/ Apps on the JVM -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
[akka-user] Pleasure doing business with event processor
We are currently in the process of writing ES CQRS system using akka
persistence. Lately one of the aspects of the akka persistence
architecture became hotly debated topic of our design discussions - namely
- where are the business rules supposed to be applied in PersistenActor
handling of a command.
Martin Krasser states in his blog that Event sourced processors do not
persist commands. Instead they allow application code to derive events from
a command and atomically persist these events. After persistence, they are
applied to current state. It would help to get some clarification what
does the event derivation process entail in general. Is it purely
transforming incoming event to one or more events and perhaps tagging on
some additional contextual information? Or, does this process also entail
running necessary business logic to create the events, which will
eventually update the state?
Sample implementation of the PersistentActor included with akka persistence
documentation (http://doc.akka.io/docs/akka/snapshot/scala/persistence.html)
shows how the command handler could be implemented:
1. val receiveCommand: Receive = {
2. case Cmd(data) =
3. persist(Evt(s${data}-${numEvents}))(updateState)
4. persist(Evt(s${data}-${numEvents + 1})) { event =
5. updateState(event)
6. context.system.eventStream.publish(event)
7. }
8. case snap = saveSnapshot(state)
9. case print = println(state)
10. }
This however is a very simplistic example, which does not answer my
question: where are the business rules applied? updateState handler
could be interpreted as such place. On the other hand perhaps it's the
constructor of the event (Evt) that symbolizes application of business
rules by creating an event from command content.
Implications of either interpretation are important to us especially when
taking into account state recovery process. Here is what the sample
PersistenActor code has for state recovery:
1. val receiveRecover: Receive = {
2. case evt: Evt = updateState(evt)
3. case SnapshotOffer(_, snapshot: ExampleState) = state = snapshot
4. }
5.
Is updateState handler's responsibility limited to making changes to state
based on events, or is it to apply business rules to the state based on
change event? In the latter case that would mean that business rules are
also invoked during reply of events while state is being restored. Such
interpretation would allow applying business logic fixes retroactively to
state, but would also introduce code versioning issues.
Any help with understanding of this aspect of the akka persistence
architecture would be greatly appreciated. Thanks in advance!
--
Read the docs: http://akka.io/docs/
Check the FAQ:
http://doc.akka.io/docs/akka/current/additional/faq.html
Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups Akka
User List group.
To unsubscribe from this group and stop receiving emails from it, send an email
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Pleasure doing business with event processor
Hi George! I’ll start with the infameous “it depends”, but let’s get into a more constructive answer :-) As updateState is not really something akka forces you to do - it’s simply a pattern we’ve found to be useful. The core of it is “a method which you can call from both `receiveCommand` and `receiveRecover`”. I’d split methods in terms of “does interactions with outside world and should not be triggered on recovery” and “does not trigger interactions with outside world”. But for example if you create child actors as part of your domain logic, you will want to trigger this during replay - to be ready for an incoming request which needs them etc. I for one would not put much logic into events. I tend to keep them as simple as markers that “stuff happened” - when actions need to be made, I’d use actors to do them. Putting a require() or two in there may be ok, but I wouldn’t put more complicated stuff into an event - it’s some actor that would “perform” the work. As for commenting Martin’s quote, by Command he means “incoming message” (as does our PersistentActor#receiveCommand), and by Event he means “the event that the Persistent Actor has persisted, as effect of that incoming command”. This means: command comes in, apply some logic to it, store “result” of that logic as event (SignedUp / UserNameTaken etc.), and act upon this event (once it’s persisted safely). So the logic leads to storing of events. I hope this helps, feel free to ask more or give examples of what you’d need :-) Happy hakking! -- Konrad 'ktoso' Malawski hAkker @ typesafe http://akka.io -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Re: Tackling the ask pattern and `timeout hell`
I though you should also have a look at different patterns one can use to
implement waiting for something,
this has been discussed nicely in this thread: Waiting on multiple Akka
messages
https://groups.google.com/forum/#!searchin/akka-user/multiple$20fsm$20messages/akka-user/KqePSVbaQEM/7L_cM9TNKAsJ
.
On Thu, Jul 31, 2014 at 4:08 PM, Adam adamho...@gmail.com wrote:
I was facing a similar decision a few weeks ago.
For now, I've went with the actor per request approach that Martynas
mentions.
The actor basically looks like a series of receive methods and I use
become to switch between them.
Each switch is done whenever I need to wait for an asynchronous call
(usually when accessing the database).
I also tried the approach of using futures (via the ask pattern), but this
indeed was harder to work with mainly because it was hard to troubleshoot
based on error messages and becuase I kept having to disable or lengthen
these timeouts while debugging.
Note that I don't copy context data between become calls, I use private
members in the Actor (the blog post also mentions this).
On Monday, July 28, 2014 12:49:31 AM UTC+3, Bartłomiej Szczepanik wrote:
Dear Hakkers,
In my current project I have experienced that ask pattern is a kind of
awkward solution. I really like it for its elegance and readability but
besides not very efficient implementation (spawning actor per each request)
it introduces a phenomenon which I call `timeout hell`. It is really hard
to introduce a consistent timeout for a user request when you use several
ask requests in your pipeline.
I have also seen that many people discourage from using that pattern and
encourage to replace it with actor per request pattern. Personally I don't
see any difference with the ask implementation with a new actor spawned
each time. It would be great if someone convince me why it is different and
better.
I'm guessing the cause of this problem is not about the usage of the ask
pattern itself but due to crappy, not reactive design of the system. I
agree that the best is not to wait or block for anything. But currently I
cannot use fully reactive pipeline with pushing events to GUI and so on.
However, I'd like to block user only on HTTP request and be fully reactive
in the rest of the pipeline. But still there is a problem. Let me describe
it on a simple example.
Let's say the backend can handle ChangeColorOfItem command. In the
old-style application we probably would write something like (pseudocode):
on(ChangeColorOfItem cmd) {
item = itemRepository.getById(cmd.itemId)
item.changeColorTo(cmd.getColor)
itemRepository.save(item)
}
It's easy for me to translate it to akka using ask pattern. But as I
said, I would like to avoid it. I came up with several possible solutions:
Fire and forget solution
The idea is to move all but first steps to recipients of respective
messages. For example the repository command retrieves the requested item
and sends message to the retrieved item basing on the passed context. I
don't like the idea because of scattering of business logic and hindering
the reusability of components.
Create an actor and split the business logic on multiple steps
Something more sophisticated. Here's some sample of code:
Receive = {
match msg @ ChangeColorOfItem(itemId, color) = {
itemRepository ! GetById(itemId, Context(sender, msg))
}
match RepositoryResponse(item: ActorRef, context) = {
item ! ChangeColorTo(context.msg.color, context)
}
match event @ ColorChanged(itemId, color, context) = {
itemRepository ! SaveEvent(event)
}
match ItemSaved(context) = {
context.sender ! ColorSuccessfullyChanged(context.msg.id,
context.msg.color)
}
}
Advantages (comparing to ask pattern):
- The entire use case logic is still in one place (one actor)
- Timeouts handling moved on a higher level (e.g. REST interface
level) what enables easy timeout management per entire use case
- No problem with resource leaks when there is a timeout or heavy
load (no stale future objects in memory, only lightweight message)
Disadvantages:
- Need to pass context explicitly all the time
- Logic is harder to read due to steps introduction (a little similar
to use of callbacks)
- Exclusive processing of steps that in fact don't need that
Different ideas
I was thinking about leveraging Futures for similar idea as above. I
wanted to pass some kind of callback with the message and it's context to
the next recipient. That allows me to keep code in one place (unfortunately
in callbacks but still). However I think it is impossible to send a lambda
in a message to the actor. Is that any workaround? If so, would you find
this approach useful?
Generally I would prefer to use a solution that keeps the idea of
application/use case service which orchestrates the
Re: [akka-user] Pleasure doing business with event processor
I'll try to answer your questions with an example (omitting the updateState
pattern):
1.
val receiveCommand: Receive = {
case ChargeCreditCard(payload) = {
// Enforce business rules, constraints, etc.
if (isNotEnough(payload.amount)) sender ! Can I haz more?
// Some rule violations might trigger their own events
if (looksFake(payload.creditCard)) {
persist(PossibleFakeCardEncountered(...)) { _ = fraudSuspected = true}
sender ! Please stay where you are, local authorities will be there any
minute.
}
// If everything's okay do the actual work
var charged = Try(paymentGateway ! charge(payload.creditCard,
payload.amount, ...))
// Once the work is done, change state (if nesessary) and persist the
event(s)
charged match {
case Success(_) = persist(CreditCardCharged(...)) { _ = paid = true }
case Failure(e) = {
persist(PaymentProviderMessedThingsUpAgain())
sender ! There was an issue, please send a check.
}
}
}
val receiveRecover: Receive = {
case CreditCardCharged = paid = true
case PaymentProviderMessedThingsUpAgain = // no state change needed
case PossibleFakeCardEncountered = fraudSuspected = true
}
The important thing here is that the command handler (receiveCommand)
guards against invalid input, checks business rules, enforces constraints,
does the actual work and emits events. The event handler (receiveRecover)
does nothing but change state according to the received events. You
wouldn't want to charge a credit card every time you rehydrate the actor
from the event store.
Hope this helps,
Dennis
On Thu, Jul 31, 2014 at 9:19 PM, Konrad 'ktoso' Malawski
konrad.malaw...@typesafe.com wrote:
Hi George!
I’ll start with the infameous “it depends”, but let’s get into a more
constructive answer :-)
As updateState is not really something akka forces you to do - it’s simply
a pattern we’ve found to be useful.
The core of it is “a method which you can call from both `receiveCommand`
and `receiveRecover`”.
I’d split methods in terms of “does interactions with outside world and
should not be triggered on recovery” and “does not trigger interactions
with outside world”.
But for example if you create child actors as part of your domain logic,
you will want to trigger this during replay - to be ready for an incoming
request which needs them etc.
I for one would not put much logic into events. I tend to keep them as
simple as markers that “stuff happened” - when actions need to be made, I’d
use actors to do them. Putting a require() or two in there may be ok, but I
wouldn’t put more complicated stuff into an event - it’s some actor that
would “perform” the work.
As for commenting Martin’s quote, by Command he means “incoming message”
(as does our PersistentActor#receiveCommand), and by Event he means “the
event that the Persistent Actor has persisted, as effect of that incoming
command”. This means: command comes in, apply some logic to it, store
“result” of that logic as event (SignedUp / UserNameTaken etc.), and act
upon this event (once it’s persisted safely). So the logic leads to storing
of events.
I hope this helps, feel free to ask more or give examples of what you’d
need :-)
Happy hakking!
--
Konrad 'ktoso' Malawski
hAkker @ typesafe
http://akka.io
--
Read the docs: http://akka.io/docs/
Check the FAQ:
http://doc.akka.io/docs/akka/current/additional/faq.html
Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups
Akka User List group.
To unsubscribe from this group and stop receiving emails from it, send an
email to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
--
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.
