20 feb 2014 kl. 08:47 skrev dong don...@gmail.com:
Patrik, I think that's doable workaround. Just curious what Martin thinks
regarding automatically unwrap Persistent messages in EventsourcedProcessor,
or at least let application to hand Persistent messages in receiveCommand
instead of
And here is another question regarding channel and command sourcing
Processor.
My understanding is this, when a event is received by Processor:
1) persist the event
2) handle the event
3) call event.confirm()
In case something wrong in step 2, channel will attempt to redeliver the
same message
Thank you for replying.
My previous understanding of Eventsourced processors is that they can 1)
handle commands which conditionally emit events, and 2) bypass
receiveCommand for Persistent messages and invoke receiveRecover directly.
Seems 2) is not true, meaning all messages sent to
20 feb 2014 kl. 09:07 skrev dong don...@gmail.com:
And here is another question regarding channel and command sourcing Processor.
My understanding is this, when a event is received by Processor:
1) persist the event
2) handle the event
3) call event.confirm()
In case something wrong in
Why don't you let M2 handle createOrder and cancelOrder commands and
emit orderCreated and orderCanceled events to M1? This way you could use
EventsourcedProcessor to implement M2 and a Processor to implement M1.
On the other hand, it's a bit difficult to give an advise here without
knowing
You made a fair point, doctor. What do you think regarding the exchange
example I came up with in my previous post? Shall I switch to use Processor
from EventsourcedProcessor and simple use 'deleteMessage' for all commands
whose precondition check fails (so to ignore them for quicker recovery)?
On Thu, Feb 20, 2014 at 1:47 PM, d...@coinport.com wrote:
To create an order, we need to check balance first and if fund is
insufficient, no event will be generated;
To cancel an order, we need to check the order exists and is still pending.
Anyway, my point is, there might be scenarios like
On 20.02.14 14:00, Patrik Nordwall wrote:
On Thu, Feb 20, 2014 at 1:47 PM, d...@coinport.com
mailto:d...@coinport.com wrote:
To create an order, we need to check balance first and if fund is
insufficient, no event will be generated;
To cancel an order, we need to check the
Martin and Patrick, I'll file a ticket so you guys can have a point to
start for further discussion:)
On Thursday, February 20, 2014 9:23:48 PM UTC+8, Martin Krasser wrote:
On 20.02.14 14:00, Patrik Nordwall wrote:
On Thu, Feb 20, 2014 at 1:47 PM, d...@coinport.com javascript: wrote:
https://github.com/akka/akka/issues/2027
--
Read the docs: http://akka.io/docs/
Check the FAQ: http://akka.io/faq/
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
http://doc.akka.io/docs/akka/2.3.0-RC4/project/issue-tracking.html
On Thu, Feb 20, 2014 at 4:30 PM, d...@coinport.com wrote:
https://github.com/akka/akka/issues/2027
--
Read the docs: http://akka.io/docs/
Check the FAQ: http://akka.io/faq/
Search the archives:
On Thursday, February 20, 2014 9:23:48 PM UTC+8, Martin Krasser wrote:
On 20.02.14 14:00, Patrik Nordwall wrote:
On Thu, Feb 20, 2014 at 1:47 PM, d...@coinport.com javascript: wrote:
To create an order, we need to check balance first and if fund is
insufficient, no event will be
will do :) thank you.
On Thursday, February 20, 2014 11:49:46 PM UTC+8, rkuhn wrote:
Hi Daniel,
you might want to re-read that short page a little more carefully ;-)
Regards,
Roland
20 feb 2014 kl. 16:47 skrev d...@coinport.com javascript::
√ , I logged in with my Google account but
I'm been playing with the new Akka persistence module, and have the
following questions that I hope to get answered.
1. The document says If a processor emits more than one outbound
message per inbound Persistent message it *must* use a separate channel
for each outbound message to
Martin, thank you for the quick reply. Great work on AKKA persistence, we
are very likely to use it in production. So more questions might come to
you later.
1 -
What do you mean Eventsourced processors do not support command sourcing.
? In my case, I have two Eventsourced processors
On Thu, Feb 20, 2014 at 8:03 AM, Martin Krasser krass...@googlemail.comwrote:
On 20.02.14 07:25, dong wrote:
Martin, thank you for the quick reply. Great work on AKKA persistence,
Thanks.
we are very likely to use it in production.
Glad to hear that.
So more questions might come
Patrik, I think that's doable workaround. Just curious what Martin thinks
regarding automatically unwrap Persistent messages in
EventsourcedProcessor, or at least let application to hand Persistent
messages in receiveCommand instead of throwing errors.
On Thursday, February 20, 2014 3:32:34
17 matches
Mail list logo
