code that will block for some time, part of an actor or should I wrap it inside a Feature?

[Kostas kougios]

I have some code that will take some time to execute. This code runs in a few steps with each step "blocking" for some time to store data into files.

I am thinking in creating a new actor which can receive 1 message for each step. Will the block part affect only that actor or will other actors be affected (since threads are reused in the actorsystem)?

[Justin du coeur]

On Mon, Nov 9, 2015 at 5:23 PM, Kostas kougios <kostas....@googlemail.com> wrote:

I have some code that will take some time to execute. This code runs in a few steps with each step "blocking" for some time to store data into files.

I am thinking in creating a new actor which can receive 1 message for each step. Will the block part affect only that actor or will other actors be affected (since threads are reused in the actorsystem)?

The block doesn't necessarily affect any *specific* other Actor -- each Actor is threaded separately.  However, if you do this a lot, especially with multiple Actors doing it, you can easily starve the thread pool: all of the available threads are blocked, so there's nothing left to allocate to other Actors.

The usual recommendation, if you need to do a bunch of blocking, is to assign the blocking Actors to their own dedicated Dispatcher; that will leave the default dispatcher available to deal with non-blocking Actors...

[Guido Medina]

I have actors such like AccountProcessor and AccountPersistor, AccountPersistor is a child of AccountProcessor and at its creation I pass a different dispatcher, assuming your code is in Scala here is better explained:

http://doc.akka.io/docs/akka/snapshot/scala/dispatchers.html

HTH,

Guido.

[Richard Rodseth]

Also see

http://doc.akka.io/docs/akka/snapshot/general/actor-systems.html#Blocking_Needs_Careful_Management

--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups "Akka User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+...@googlegroups.com.
To post to this group, send email to akka...@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[Konstantinos Kougios]

useful advice, thanks everyone.

I wonder why continuations didn't catch up. continuations "blocking" would be of no issue. I/O and even sleep(x) would be possible with no overhead.

You received this message because you are subscribed to a topic in the Google Groups "Akka User List" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/akka-user/u71EOymonvk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to akka-user+...@googlegroups.com.

[Viktor Klang]

On Wed, Nov 11, 2015 at 4:02 PM, 'Konstantinos Kougios' via Akka User List <akka...@googlegroups.com> wrote:

useful advice, thanks everyone.

I wonder why continuations didn't catch up. continuations "blocking" would be of no issue. I/O and even sleep(x) would be possible with no overhead.

That is not *really* true—if you call blocking syscalls then you're calling blocking syscalls.

--

Cheers,

√

[Konstantinos Kougios]

true, a new new-IO would have to be written :) and a lot of libraries to be modified which would not be easy.

But the problem with blocking syscalls is true for actors too. And the developer needs to take extra care anyway.

Maybe rephrase and say that continuations would make parallel code looks as if running serially which seems like a good thing to me. I tend to have serial processes in what I do and tend to simulate it with messages like

actorA send msg X1 to B
actorB do whatever with X1 and send C to actorA
actorA act on C by completing the process

effectively the above is (on actorA)

actorB.do(X1)
... complete the process

[Viktor Klang]

I think that's a matter of taste. Having async code look exactly like sync code means that it's going ot be hard to see in the code whether you're doing something sync or async.

[Konstantinos Kougios]

hmm, I guess it is probably a bigger discussion. Does it matter if the code is async? I think (maybe) this all relates to why typed-actors was deprecated. I can't find the link about the discussion why it was deprecated, anyone has it? I remember seeing something a few months ago.

[Viktor Klang]

Given that tehre a lot of methods that use locks in the implementation, do syscalls etc, it eveyrthing looks like sync calls then all callsites could be a potentially blocking operation. :S

[Konstantinos Kougios]

Hi Viktor, yes I realized that.

I ended up trying to simulate serial execution of code as if there is no parallelization or cluster. I experimented a bit with continuations but I think the state of the jvm doesn't allow something sane to be implemented and perform well. So I ended up experimenting with say something like active objects meets spark on top of akka. I have normal objects impl description of behavior that will be executed by akka. Future {} and actor ! X are implemented via normal service.doSomething() calls and behave as if they execute serially (not using async lib). I am now refactoring my code to use them and will see how it goes. So far testing and writing the code seems easier as it is std object oriented code.