Re: [akka-user] Re: code that will block for some time, part of an actor or should I wrap it inside a Feature?

'Konstantinos Kougios' via Akka User List Thu, 26 Nov 2015 04:23:03 -0800

Hi Viktor, yes I realized that.

I ended up trying to simulate serial execution of code as if there is noparallelization or cluster. I experimented a bit with continuations butI think the state of the jvm doesn't allow something sane to beimplemented and perform well. So I ended up experimenting with saysomething like active objects meets spark on top of akka. I have normalobjects 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 amnow refactoring my code to use them and will see how it goes. So fartesting and writing the code seems easier as it is std object oriented code.




On 13/11/15 11:06, Viktor Klang wrote:

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

On Wed, Nov 11, 2015 at 5:15 PM, 'Konstantinos Kougios' via Akka UserList <[email protected] <mailto:[email protected]>>wrote:


    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.


    On 11/11/15 16:00, Viktor Klang wrote:

    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.

    On Wed, Nov 11, 2015 at 4:39 PM, 'Konstantinos Kougios' via Akka
    User List <[email protected]
    <mailto:[email protected]>> wrote:

        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



        On 11/11/15 15:16, Viktor Klang wrote:



        On Wed, Nov 11, 2015 at 4:02 PM, 'Konstantinos Kougios' via
        Akka User List <[email protected]
        <mailto:[email protected]>> 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.



            On 11/11/15 14:37, Richard Rodseth wrote:

            Also see

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

            On Tue, Nov 10, 2015 at 2:04 PM, Guido Medina
            <[email protected] <mailto:[email protected]>> wrote:

                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.


                On Monday, November 9, 2015 at 10:23:38 PM UTC,
                Kostas kougios 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)?