> I've been looking at Akka today in the perspective of implementing a
> custom scheduler for an Actor-based Web system. I found Scala scheduler
> to be a little bit hairy, and looking at Akka's documentation, I was
> impressed by its clarity and the richness of features.

> So my problem is as follows:

> - I have Actors (type A) that process incoming HTTP requests
> - I have Actors (type B) that log these requests in a Redis DB

> Currently, using Scala Actors, the scheduler does not fully interleave
> execution of A and B. So when you have a burst of requests, the type A
> actors get all busy, and then type B actors get busy, killing the
> response time for the next requests.

> So instead of scheduling like this:

>  A A A A A B B B B B

> I would like to schedule like this:

>  A B A B A B A B A B

> Or even better, be able to decide at each step if it's better to
> execute an A or a B.

> Could anyone point me on how to do this with Akka ?

> Thanks,

>  -- Sébastien

> --

> 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-user@googlegroups.com.
> To unsubscribe from this group, send email to
> akka-user+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/akka-user?hl=en.

> Thanks for your interest in Akka.

> I think it would be hard to enforce what you need with the
> out-of-the-box event-based dispatcher (the default), since it runs on
> a thread pool its impossible to control the actual OS thread
> dispatching (which is done by the OS scheduler).

> The thread-based dispatcher might give you more what you need. Try  
> that.

> One that will give you the exact interleaving is the single-thread
> dispatcher in which each event is ordered and executed one by one on
> the same thread. But this one has no scalability and is dangerous
> since one actor can block all.

> You can also implement your own dispatcher by implementing the
> MessageDispatcher trait.

> Hope it helps, Jonas.

> 2010/1/5 Sébastien Pierre <sebastien.pie...@gmail.com>:
>> Hello,

>> I've been looking at Akka today in the perspective of implementing a
>> custom scheduler for an Actor-based Web system. I found Scala  
>> scheduler
>> to be a little bit hairy, and looking at Akka's documentation, I was
>> impressed by its clarity and the richness of features.

>> So my problem is as follows:

>> - I have Actors (type A) that process incoming HTTP requests
>> - I have Actors (type B) that log these requests in a Redis DB

>> Currently, using Scala Actors, the scheduler does not fully  
>> interleave
>> execution of A and B. So when you have a burst of requests, the  
>> type A
>> actors get all busy, and then type B actors get busy, killing the
>> response time for the next requests.

>> So instead of scheduling like this:

>>  A A A A A B B B B B

>> I would like to schedule like this:

>>  A B A B A B A B A B

>> Or even better, be able to decide at each step if it's better to
>> execute an A or a B.

>> Could anyone point me on how to do this with Akka ?

>> Thanks,

>>  -- Sébastien

>> --

>> 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-user@googlegroups.com.
>> To unsubscribe from this group, send email to
>> akka-user+unsubscribe@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/akka-user?hl=en.

> --
> Jonas Bonér

> twitter: @jboner
> blog:    http://jonasboner.com
> work:   http://scalablesolutions.se
> code:   http://github.com/jboner
> code:   http://akkasource.org
> also:    http://letitcrash.com
> --
> 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-user@googlegroups.com.
> To unsubscribe from this group, send email to akka-user+unsubscribe@googlegroups.com
> .
> For more options, visit this group at http://groups.google.com/group/akka-user?hl=en
> .