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
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
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
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
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
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
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
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
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
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
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
11 matches
Mail list logo
