onsibility.
>
> On Thu, Jul 21, 2016 at 3:33 AM, Nader Aeinehchi
> wrote:
>
>> I have a classic question: how to fork some work and then join the
>> results.
>>
>> Let me explain the problem:
>>
>> There is a security manager that asks several secur
I have a classic question: how to fork some work and then join the results.
Let me explain the problem:
There is a security manager that asks several security providers (e.g.
Active Directory, Tivoli, Mainframe) if a given call is authorized. If all
the security providers say "yes", the call i
Hi
Thanks a lot to Leonidb for the response.
In this example, the issue itself - as a state machine and its underlying
state - is stored in an IssueTracking database (event sourcing). On the
other hand, the "name", say John, is written to another database, say
NameRegistrationDatabase. There
I am currently modeling a PersistentFSM actor and humbly ask for guidance.
Suppose, we write a name to a database in the state "InProcess". Having
successfully committed to the database, we would like the state machine to
change its state to "Closed".
What if we manage to write to the database,
of it).
> In fact I've seen a ticketing system in the wild implemented like that and
> they've enjoyed it as far as I could tell :-)
>
> Take a deep dive into persistence docs:
> http://doc.akka.io/docs/akka/snapshot/scala/persistence.html
>
> On Mon, Jul 27, 2015 at 4:
Hello everyone
I find PersistentFSMActor to be a very interesting concept.
I intend to use PersistentFSMActor as part of an automatic issue
management. I wonder if there is an example of its usage?
My hypothesis:
1. Each issue is represented as an PersistentFSMActor.
2. Each issue is "born" w
+1, rkuhn wrote:
> Hi Nader,
>
> 12 feb 2014 kl. 12:39 skrev Nader Aeinehchi
> >:
>
> Hi Roland
>
> "sounds fishy, because actors do not expose methods, they only communicate
> via message passing"
> Agree. That is why I brought up this question
s along with what Roland stated earlier)
>
> Perhaps you could actually try to explain what exactly you are trying to
> accomplish as a business use case since it seems like you may be making
> things (architecture and design) more complex then they have to be.
>
> Cheers
> Oleg
e outside is the
> ActorRef, which supports nothing besides the `tell` operation (which `ask`
> is a variant of).
>
> Regards,
>
> Roland
>
> 12 feb 2014 kl. 09:08 skrev Nader Aeinehchi
> >:
>
> Hi again
>
> Let me explain it better. There are two optio
r, using “context.actorOf(……, name)”. Child actors
> enjoy the same kind of encapsulation from all others—including from their
> parent—so you will need to send messages to communicate with them.
>
> Regards,
>
> Roland
>
>
>
> On Mon, Feb 10, 2014 at 10:24 PM, Nader Aeine
Hi
How can a child actor (which itself implements FSM) be created and added as
a child to the context of a FSM actor?
Suppose the following pseudocode:
trait WorkerFSM[S, D] extends FSM[S, D]
trait ManagerFSM[S, D] extends FSM[S, D] {
// Does not work
// Create some WorkerFSM actor and ad
hen(new StartingState)(
>
> (s:AbstractState) => new StoppingState
>
> )
>
> // // won't compile
>
> // when(new StartingState)(
>
> //(s:AbstractState) => new IdleState
>
> // )
>
> when(new StartedState)(
>
> (s:Abstrac
is should make it impossible to transition from Idle to Idle, or from
> Idle to Buffering, because only Idle.Next would be allowed, of which the
> only subtype is Active.
>
> Regards,
>
> Roland
>
> 13 dec 2013 kl. 13:58 skrev Nader Aeinehchi
> >:
>
> Hi Rol
Hi again
Last night, I posted to a wrong thread. Sorry for duplicate.
--
Here is a suggestion for a trait that can be used to define legal state
transitions. It also guards against illegal state transitions in runtime.
I am also interested in how this can implemented in compile-t
Hi again
Here is a suggestion for a trait that can be used to define legal state
transitions. It also guards against illegal state transitions:
/**
* A simple extension of Akka's FSM. In this class, state
transitions can be defined with the
* from state and to state constructs. For
insta
15 matches
Mail list logo