Restarting FSMs , and avoiding undesired side-effects

[Spencer Judge]

Hello all,

I haven't used Akka before, and I'm considering using it to replace some code my team recently wrote that we're finding is too complex to understand well, and I'd like us to use a more formal structure. Akka fits our use case very well (I'd use Erlang, but we depend on too many Java libraries) but there is one question I'm left with after spending some time today reading through documentation.

To make a simple example, our system would be doing side-effect performing work at the leaf nodes of a supervision tree, who would be (or be supervised by) FSM actors. A concrete example is an FSM whose job is to start, send an HTTP request somewhere, poll for the status of the sent request repeatedly until some condition is reached, and then terminate.

Let's say that FSM dies while in the polling state. I don't want to send the initial request again (because presumably the job is still in progress somewhere), I want to go straight to the polling state and start polling again.

From my reading of the docs, persisted actors are restarted by replaying all messages back to the actor which is perfect if you're not performing side effects, but seems problematic in this case. After googling around I have some vague ideas that you're able to inspect replay messages, and maybe I could somehow know to throw out the ones I don't want to do, but I'm not sure if that's idiomatic.

I've got to imagine this is a pretty common issue, but I couldn't find anything that really rang true as the "canonical" way to handle this sort of case.

Your responses are appreciated,
Spencer

[Akka Team]

Hi Spencer,

This sounds like it could work with a supervision strategy that does not restart the actor but rather lets it resume on a failure.

If that is not possible you would have to move the information that the FSM actor has been previously started somewhere outside of it. Could be to another actor, in which case you would have to query that actor about it when the FSM actor starts, with an not-quite-initialized state and then going to different actual initial states when the reply arrives.

If you would want it to behave the same across JVM crashes as well you would have to persist the information, this could for example be done using Akka persistence (take a look at PersistentFSM) but it could also be done in a multitude other ways depending on your needs (file on disk, save to database etc).

--

Johan

[Spencer Judge]

Thanks for the info Johan! I'll take a look at the suggestions. I also think I have an alternate design where I may be able to avoid the problem entirely. I've convinced my team to at least start a prototype with Akka and I'm looking forward to it.

One other question - I've seen the Typsafe Console while doing research and that looks really valuable, but also appears to have been renamed/discontinued. Is that functionality still around? Is it usable without the entire Lightbend platform?

Thanks

[Konrad Malawski]

Thanks for the info Johan! I'll take a look at the suggestions. I also think I have an alternate design where I may be able to avoid the problem entirely. I've convinced my team to at least start a prototype with Akka and I'm looking forward to it.

One other question - I've seen the Typsafe Console while doing research and that looks really valuable, but also appears to have been renamed/discontinued. Is that functionality still around? Is it usable without the entire Lightbend platform?

Right, it's been discontinued (about 3 years ago I think), reason was that we could not spend the time/resources to work so much on a very UI heavy component (among other things).

The effort has been recently reborn though, with some of the original monitoring team taking the lead on it again :-)

You can read about it here: http://resources.typesafe.com/monitoring/docs/ and it's available as part of our commercial offering (feel free to contact con...@lightbend.com) to get in touch about that. 

-- 

Cheers,

Konrad 'ktoso’ Malawski
Akka @ Lightbend