That also works, yes.
I was unsure if sending the client your failure was OK for you.
On 8 August 2014 at 14:16:34, Lawrence Wagerfield (lawre...@dmz.wagerfield.com)
wrote:
Hi Konrad,
Many thanks for humouring my paranoia! Greatly appreciated.
I have since implemented another approach that I
It's not the exact code, but the notion is the client receives either a
success or failure message, not both. In reality I log the exception
alongside a hash of its message, and then forward that hash to the client.
It provides us with a way of cross-referencing errors without giving away
Haha no worries - it's Friday after all :)
Thank you for all your help.
On Friday, August 8, 2014 1:24:44 PM UTC+1, Konrad Malawski wrote:
Argh, ignore my last was unsure sentence, mixed up emails :-)
Yes, the scheme you propose will work correctly, and is definitely harder
to mess up than
I have problem that involves synchronising outbound messages from a parent
actor and its child actor. This particular problem is with regards to
forwarding failure messages to clients.
Here is the example:
I have a service actor that receives a request from a client actor*.*
The service
Hi Lawrence,
In general, exactly one entity in a distributed system should be
responsible for deciding about success / failure,
otherwise there always will be a race of some kind.
In your case though, the problem arrises because the service actor does not
know if the transaction actor has
Are you suggesting the default decider combined with a one-for-one strategy
with a max retry attempt of 1, combined with the following code?:
override def preRestart(exception)
client ! exception
context stop self
On Thursday, August 7, 2014 12:29:05 PM UTC+1, Konrad Malawski wrote:
What I'm playing at is:
Assumptions:
I'm assuming we're talking about all these actors in the same JVM, nothing
you wrote is hinting a clustered env.
Execution:
If your actor reaches the point in the code where it `client ! result` and
does *nothing *(bold italic nothing, as in stopping :-))
It certainly makes sense. I wouldn't expect the send/stop operation to fail
any more than I would expect the whole supervision framework to fail.
What I'm trying to defend against ultimately comes down to programmer
error. Its quite likely that I'm being irrational in my perception of how
