Behavior of Akka when you sleep in an actor

[Evan Chan]

Dear Hakkers,

We profiled our Akka actors (running on 2.0.4) using CodaHale metrics, and the running time of the receive function would go up substantially when we inserted Thread sleeps in our code.   

When there is a "Thread sleep 50" in the receive loop, for example, we would observe occasional running times of receive() in the seconds.  

Note that the "Thread sleep" is actually in a trait which is mixed into the Actor class, if that makes a difference.

We are thinking that perhaps when you Thread sleep in an actor, then Akka will switch out the actor to another one, or some other magic happens, such that the sleep duration is more than the 50 ms.    Does that make sense at all?   Otherwise we are not able to explain the behavior.

thanks,

Evan

[Jonas Bonér]

It is not that surprising. It depends on what our system is doing in
the meanwhile and the number of cores you have available, and how you
have configured the system.
Akka is not doing anything at all with regards to this, it is all in
the hands of the FJ ThreadPool in conjunction with the OS scheduler to
let another thread use the hardware. It finds better things to do.
A thread sleep/yield and with a followed thread parking/unparking is
expensive. Instead of sleeping, hold on to the thread by doing some
artificial work for a while.

> --
>>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>>> Check the FAQ: http://akka.io/faq/
>>>>>>>>>>> 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 post to this group, send email to akka...@googlegroups.com.
> To unsubscribe from this group, send email to
> akka-user+...@googlegroups.com.
> Visit this group at http://groups.google.com/group/akka-user?hl=en.
>
>



--
Jonas Bonér
Phone: +46 733 777 123
Home: http://jonasboner.com
Twitter: @jboner

[G J]

This raises an interesting question.  What is the best way for an actor to sleep for a specified/interval?

One alternative would be to create an inline anonymous actor (see docs) whose only job is to time out at the required interval.  I have not tried this, but I'm scared of the actor creation and stopping overhead.

Another is to have a dedicated actor whose job is to also not process any messages except the ReceiveTimeout message. This is what I use for a fixed sleep interval of 1sec.  A START message sets the receive timeout parameter, which is reset on the ReceiveTimeout message.

I know that the latter has significant overhead for my application. A 1 sec sleep interval has an overhead of 1sec.

Any better ideas?

Thanks.

Best Regards.

[Ryan LeCompte]

I'd suggest taking a look at this recent stack overflow question for inspiration (specifically, Roland Kuhn's answer):

http://stackoverflow.com/questions/13896638/is-it-possible-to-use-the-akka-scheduler-inside-an-actor

Ryan

[Rich Dougherty]

The Scheduler (Java, Scala) can be used to schedule future operations. It can be used to simulate sleeping without actually holding a thread. You can arrange either a callback to be called or a message to be sent after a certain time has elapsed.

There are examples in the documentation showing how to send a message after a delay of 50ms:

Java:

system.scheduler().scheduleOnce(Duration.create(50, TimeUnit.MILLISECONDS), testActor, "foo");

Scala:

system.scheduler.scheduleOnce(50 milliseconds, testActor, "foo")

Cheers

Rich

[G J]

Thanks for the excellent suggestions. Very much appreciated.

btw: Under the hoods, the scheduleOnce alternative is quite different from the become/unbecome - where the latter, I presume, would unbecome on ReceiveTimeout.

Thanks.

Best Regards.

[Rich Dougherty]

On Mon, Jan 14, 2013 at 5:33 PM, G J <oda...@gmail.com> wrote:

Thanks for the excellent suggestions. Very much appreciated.

btw: Under the hoods, the scheduleOnce alternative is quite different from the become/unbecome - where the latter, I presume, would unbecome on ReceiveTimeout.

Hi

You're welcome. :)

By the way, I don't think of scheduleOnce and become/unbecome as separate alternatives. Roland Kuhn's example (if you look carefully) actually combines both scheduleOnce and become/unbecome in a single program. Let me explain what I mean:

1. The actor uses scheduleOnce to schedule a WakeUp message.

2. It then uses become to change its behaviour. Its new behaviour is that it waits for a WakeUp message.

3. Once the WakeUp message is receveived it uses unbecome to return the actor to its previous behaviour. The WakeUp message is sent by the scheduler.

Notice also that the unbecome is triggered by the scheduled message. I don't think it is a ReceiveTimeout that triggers the unbecome.

Cheers

Rich

[Roland Kuhn]

On 14 jan 2013, at 09:05, Rich Dougherty <ri...@rd.gen.nz> wrote:

On Mon, Jan 14, 2013 at 5:33 PM, G J <oda...@gmail.com> wrote:

Thanks for the excellent suggestions. Very much appreciated.

btw: Under the hoods, the scheduleOnce alternative is quite different from the become/unbecome - where the latter, I presume, would unbecome on ReceiveTimeout.

Hi

You're welcome. :)

By the way, I don't think of scheduleOnce and become/unbecome as separate alternatives. Roland Kuhn's example (if you look carefully) actually combines both scheduleOnce and become/unbecome in a single program. Let me explain what I mean:

1. The actor uses scheduleOnce to schedule a WakeUp message.

2. It then uses become to change its behaviour. Its new behaviour is that it waits for a WakeUp message.

Minor nitpick: use of the term «wait» should be avoided in this context, it sounds too active. In fact the actor does not wait, it just reacts differently to incoming events during a certain time period. Instead I’d say that it discards or stashes away incoming messages until it receives the WakeUp call. 

Regards,

Roland

3. Once the WakeUp message is receveived it uses unbecome to return the actor to its previous behaviour. The WakeUp message is sent by the scheduler.

Notice also that the unbecome is triggered by the scheduled message. I don't think it is a ReceiveTimeout that triggers the unbecome.

Cheers

Rich

--

[Evan Chan]

By the way, thanks everyone for the hints.   Using the scheduler instead of Thread sleep definitely fixed it.

--
--
Evan Chan
Senior Software Engineer | 
e...@ooyala.com | (650) 996-4600
www.ooyala.com | blog | @ooyala

[Fahimeh Rahemi]

Hi every body!

I have a relative question; 

I want to create some heavy and thread occupier actors by akka; by using thread.sleep(5000) are the threads associated to that actors really occupied?I mean when I use thread.sleep(5000) inside an actor, does the actor occupy the thread for 5 seconds or leaves it to the thread pool for other actors  to use?

an other alternative for making a heavy actor is, for example, using nested 1000000 time loops: for(int i =0; i<1000000; i++); and doing some mathematical operations inside the loops! 

may I know your opinions? 

thanks 

[Viktor Klang]

Thread.sleep's behavior is documented here: https://docs.oracle.com/javase/7/docs/api/java/lang/Thread.html#sleep(long)

--

>>>>>>>>>> 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.

--

Cheers,

√

[Nicholas Sterling]

Fahlmeh, hopefully you are talking about some form of test -- in a production system, you would not want to use thread.sleep.

But to answer your question, yes -- if your actor calls thread.sleep, it really ties up a thread.

Nicholas

[Fahimeh Rahemi]

:) thank you from your answer!

yes, I'm trying to test my actor system with dispatchers, and need both heavy and light weight actors for my test ;

Please let me see if I understand your answer correctly, do you mean that if I use thread.sleep(5000) inside an actor, the actor does not leave it's thread at all? and the thread is idle and jobless for 5 seconds?

:) thanks again

[Konrad Malawski]

On Thu, Oct 15, 2015 at 4:44 AM, Fahimeh Rahemi <fahime...@gmail.com> wrote:

Please let me see if I understand your answer correctly, do you mean that if I use thread.sleep(5000) inside an actor, the actor does not leave it's thread at all? and the thread is idle and jobless for 5 seconds?

Yeah, exactly. It effectively renders that thread useless for around 5 seconds – don't do that ;-)

-- 

Konrad

[Harit Himanshu]

A dumb question. I was in such a situation recently and have been sleeping threads in Java. I got so much used to it that now I had trouble telling Actor what "heavy work" it should do to stay busy. 

My solution was File.createTempFile("someRandom", "txt") couple of thousand time (so Actor was busy doing something I did not care). The problem was it was creating all these files. 

What other ways people have kept their actors busy (pretending they are doing a lot for work)? This is just for tests I am asking for.

[Adam]

I don't understand the purpose of "keeping the actor busy".
Why not use the actor system's scheduler in order to implement the delay?

Do you actually want to use CPU or other resources?

The only thing to pay attention to is that the scheduler, has a certain precision, so the delay may turn out to be slightly larger than aimed for.

For testing purposes, BTW, depending on the situation, I sometimes use a count down latch instead of timed delays. When possible, it makes the tests much faster to execute.