Yes, i understand, but still being safe about actor own state consistency
is what we need from actors.
On Wednesday, August 6, 2014 2:01:30 PM UTC+7, √ wrote:
>
> Its thread safe but I wouldn't call it safe-it could process other
> messages in between the different executable ones.
> On Aug 6, 2
Yes, i understand, but still being "single threaded" inside the actor code
is what usually expected.
On Wednesday, August 6, 2014 2:01:30 PM UTC+7, √ wrote:
>
> Its thread safe but I wouldn't call it safe-it could process other
> messages in between the different executable ones.
> On Aug 6, 201
Its thread safe but I wouldn't call it safe-it could process other messages
in between the different executable ones.
On Aug 6, 2014 5:42 AM, "Oleg Galako" wrote:
> Here is a code example for what i meant by
>
> "splitting async processing into several message steps (which requires
> naming messa
Here is a code example for what i meant by
"splitting async processing into several message steps (which requires
naming messages, passing context in them, etc)"
// Some external services, actors, something asynchronous
object ExternalStuff {
def step1(par
If you want to send the result of a Future to an actor (can be self),
simply use the pipe pattern:
http://doc.akka.io/docs/akka/snapshot/scala/futures.html#use-with-actors
import akka.pattern.pipe
Future { 42 } pipeTo self
// short email as my laptop is dying right :-)
On Tue, Aug 5, 2014 at 7:
Hi Konrad,
Thanks for the reply.
Here's a quote from Akka docs on Actors:
-
Warning
When using future callbacks, such as onComplete, onSuccess, and onFailure,
inside actors you need to carefully avoid closing over the containing
actor’s reference, i.e. do not call methods or access
Hi Oleg,
This is a bit confusing – why would you need this?
What is this supposed to be helping with?
The simplest way to get an execution context for a Future to run on is
`import context.dispatcher` which makes it run on the same dispatcher as
the Actor.
Of course, that's not always what you wan
Greetings!
Looks like Futures inside actors are better than splitting async processing
into several message steps (which requires naming messages, passing context
in them, etc).
Is there something wrong with this code or maybe something like that
already implemented in a better way?
case clas
