Indeed. My point was more that one has to both account for potential memory
leakage (Actor gets replaced on restart) as well as the threadsafety of the
logger.
On Aug 8, 2014 10:15 AM, "Christopher Hunt"
wrote:
> …so there you are… there is of course still a danger of closing over the
> wrong thi
…so there you are… there is of course still a danger of closing over the wrong
thing. We should take a copy of the log then before the callback. As stated,
the idea is to minimise the potential for closing over the wrong thing, but of
course the approach doesn't eliminate that possibility.
On 0
In the example you are closing over 'this.log...'
On Aug 8, 2014 9:49 AM, "Christopher Hunt"
wrote:
> IMHO the key is to minimise the potential for closing over state that
> isn't available to a future's callback. This is tricky, and the approach
> I'm going to suggest only diminishes the risk, i
IMHO the key is to minimise the potential for closing over state that isn't
available to a future's callback. This is tricky, and the approach I'm
going to suggest only diminishes the risk, it does not eliminate it.
I see that there are broadly two options: either create a worker actor to
manag
Hello Soumya,
how about maping over the Futures in a for comprehention, like this, and
then sending the result back to the actor so it can set the value (*don't*
modify a var from a Future (not safe – as it's executing on a different
thread, and Actor guarantees don't hold any longer)).
case SetSt
Michael,
Thank you for your response.
Here is what I'm struggling with.
In order to use pipeTo pattern I'll need access to the transaction (tran )and
the FIRST Future (zf) in the actor where I'm piping the Future to because
the SECOND Future depends on the value (z) of FIRST. How can I do t
Sorry, still early. Missed the part where you said that you don't want to
use PipeTo because of the transaction. Not sure if that is a problem at all
though. From what I see you use the transaction to make sure nothing
happens with the values between your zcard and zrange calls, afterwards its
Instead of mutating state from within the future I would use the pipeTo
pattern. Using pipeTo you can send the result of a future to an actor (e.g.
to self). There you can safely change state, as you are in
single-threaded-illusion-land again...
HTH
Cheers,
Michael
Am Donnerstag, 7. August 20
