Am 31.01.2014 15:31 schrieb "Vadim Bobrov" :
>
>
> On Friday, January 31, 2014 2:02:34 AM UTC-5, Martin Krasser wrote:
>>
>>
>> On 30.01.14 23:22, Vadim Bobrov wrote:
>>>
>>> That is what I meant, yes. Leaving messages on the JMS queue wouldn't
work for me because I have other actors (like retrievi
On Friday, January 31, 2014 2:02:34 AM UTC-5, Martin Krasser wrote:
>
>
> On 30.01.14 23:22, Vadim Bobrov wrote:
>
> That is what I meant, yes. Leaving messages on the JMS queue wouldn't work
> for me because I have other actors (like retrieving info over REST) whose
> event stream I also ne
On 30.01.14 23:22, Vadim Bobrov wrote:
That is what I meant, yes. Leaving messages on the JMS queue wouldn't
work for me because I have other actors (like retrieving info over
REST) whose event stream I also need to preserve.
I'm not getting this argument. Why can't you use JMS persistence fo
On 30.01.14 16:44, Vadim Bobrov wrote:
> It seems to me that the Processor is based on the assumption that it
must preserve the sequence of Messages it received...
Oleg, thanks. I'll give it a thought. However:
if the Processor is based on the assumption that it basically cannot
do any proce
That is what I meant, yes. Leaving messages on the JMS queue wouldn't work
for me because I have other actors (like retrieving info over REST) whose
event stream I also need to preserve. Thanks!
On Thursday, January 30, 2014 2:56:32 PM UTC-5, Oleg Zhurakousky wrote:
>
> I see. . .
> So, your FSM
I see. . .
So, your FSM actor in question is a JMS listener.
Side question. If you are using JMS, why not just rely on its own
persistence/transaction mechanism. This way unprocessed (uncommitted)
messages will remain on its queue, so you can avoid Persistence all
together.
Having said that I am go
> Are you coupling too much responsibility into a single component?
here is a birds-eye overview of what my system is. I am picking up messages
from ActiveMQ, do some processing and save to HBase. All principal actors
are FSM, I found it convenient to orchestrate their cooperative behaviour
by
While this would work for your use case, it may present more confusion when
you look at it in more general perspective.
The Processor and Recovery mechanism is based on a well known pattern
MessageStore - http://www.eaipatterns.com/MessageStore.html ( i think its
the 4th time I bring it up in the l
> It seems to me that the Processor is based on the assumption that it must
preserve the sequence of Messages it received...
Oleg, thanks. I'll give it a thought. However:
if the Processor is based on the assumption that it basically cannot do any
processing until after the recovery is done, th
On 30.01.14 14:10, Oleg Zhurakousky wrote:
Vadim
I was thinking about it some more, so let me share some thoughts
Processor type actor designed for recovery-first use case where a
Message that didn't get a chance to process at the time of actor
termination (e.g., system crash) would need to b
Vadim
I was thinking about it some more, so let me share some thoughts
Processor type actor designed for recovery-first use case where a Message
that didn't get a chance to process at the time of actor termination (e.g.,
system crash) would need to be recovered, processed and only then all other
m
Oleg, Martin, thanks
I did not realize everything is stashed by Processor until after the
recovery ends, regardless customized or not. My idea was to run a
controlled recovery after my FSM actors are in a certain "ready" state
(which involves coordinating several actors). But since a Processor
On 29.01.14 03:53, Oleg Zhurakousky wrote:
Using Processor actor implies that there may be some initial state, so
its preStart() method sends a Recover message to facilitate the
recovery before anything else happens.
The important part is that until the Recovery message is received by
Processo
Using Processor actor implies that there may be some initial state, so its
preStart() method sends a Recover message to facilitate the recovery before
anything else happens.
The important part is that until the Recovery message is received by
Processor everything else sent to the Processor actor wi
Thanks, Oleg,
If you make FsmActor in your example inherit from Processor (from
akka-persistence) you'll see the effect
(class FsmActor extends Processor with FSM[State, Data] {)
Vadim
--
>> Read the docs: http://akka.io/docs/
>> Check the FAQ: http://akka.io/faq/
>>
Can you share some code. I just tried to reproduce it based on your
explanation and it all works for me (see code below), but may be I am
missing something.
Cheers
Oleg
=
import akka.actor.Actor
import akka.actor.ActorSystem
import akka.actor.FSM
import akka.actor.FSM.SubscribeTransiti
Hi,
I ran into this problem: when preStart is overriden (empty) for an FSM
actor it stops sending CurrentState in response
to SubscribeTransitionCallBack. Tried putting
startWith
initialize
into preStart, still not getting CurrentState. What is the correct solution
in this case? I am disabli
17 matches
Mail list logo
