Re: [akka-user] Is it possible to execute Actors in a pre-defined order?

[√iktor Ҡlang]

Hi!

What problem are you trying to solve?

Cheers,
V

On Nov 18, 2012 8:57 AM, "Sachin" <shirv...@gmail.com> wrote:

Hi All,

I would like to execute actors (which have messages in mailboxes and are eligible to execute) in a definite order. I am aware that a particular actor may process its messages in some prioritized manner, but my goal is different. If we have (say) 10 actors ready to execute, can we define the order in which they will be executed? I tried to search through the documentation, but I could not find relevant information. I will appreciate if someone can either comment on this scenario's possibility or at least point me to a relevant document.

Thanks

Sachin

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

[Samira Tasharofi]

Do you think having a solution like Setak: http://mir.cs.illinois.edu/setac/

would help you?

[Evan Chan]

That link is broken by the way.

--

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

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

[√iktor Ҡlang]

So you don't have any use case?

Cheers,
V

On Nov 20, 2012 8:38 AM, "Sachin" <shirv...@gmail.com> wrote:

Hi Viktor,

I am still learning akka and after looking at message priority example, I was wondering that whether doing the same with actors is possible or not. By the way, I also do not understand how the actors are picked from the actor pool and run by threads. I mean what part of akka source code does that. Is it done by dispatcher? And do the actors wait in global queue before getting processed by running threads? 

Your help is highly appreciated as before.

Thanks
Sachin

[√iktor Ҡlang]

I'd love to help out, I just want to understand the use case first, so I am convinced that we're attempting the most appropriate solution.

Cheers,

√

On Fri, Dec 28, 2012 at 12:03 AM, Sachin <shirv...@gmail.com> wrote:

Hi,

I am trying to prioritize actors so that all actors are scheduled according to their attached priority. A direct equivalent is a real-time application where threads have priorities and they get scheduled according to them. One drawback of this implementation will be that SystemMessages of a lower priority actor may not get processed till all higher priority actors get executed.

As the first step, I am looking to execute actors with their respective message priority. In this way message priorities become applicable system wide. For example if there are three actors A, B and C with ordered priority mailbox as A={2,4}, B={1,4}, and C={3,5} (Here the mailboxes of A, B and C are ordered due to existing akka message priority support). Then I would like to see execution pattern of

B(1)..A(2)..C(3)..B(4)..A(4)..C(5).....

I looked into the akka code (2.0.4) and figured out that the actors are pushed into a <Runnable> queue using executor interface when a message for the actor is sent. Assuming a thread-pool executor, actor's Runnable will be queued in linkedBlockingQueue and whenever a thread is free it will pick the head element from the queue and execute it.

To implement the target scenario, I believe that I should have a priority queue for Runnables, but there is no priority information (from message) available at that level. Can someone suggest me a possible way out? Should I modify existing queue to a priority queue which contains tuple of <Runnable, priority> and then threads should execute the runnable when they get free? Any help in this is highly appreciated.

Thanks,
Sachin

--
Viktor Klang

Director of Engineering

Typesafe - The software stack for applications that scale

Twitter: @viktorklang

[Rich Dougherty]

Hi Sachin

It's probably useful to know specifically why you'd like to have actors with different priorities. Depending on what you want to do other solutions might be possible (or not).

For example, have you considered using messages to represent the work that needs doing, and dispatching the messages to a pool of workers? You could probably do some clever things with message priorities to control which work gets executed first. But it's easier to offer suggestions if there's a concrete problem to think about.

Cheers

Rich

On Fri, Dec 28, 2012 at 3:22 PM, Sachin <shirv...@gmail.com> wrote:

Hi Viktor,

Thank you for the reply. Can you elaborate what you mean by use case? Do you mean the application which will run or something else? If you mean application, then there are many real-time systems applications which have multiple periodic threads with different priorities (static/dynamic). For example, an industrial control system where threads controlling the valves and assembly line have higher priority as compared to threads displaying the status/information on operator panel.

Please let me know if I have answered your question or not. Otherwise I will try to clarify the scenario further.

Thanks
Sachin

[√iktor Ҡlang]

What problem (use-case) is best solved by introducing a global ordering, that is my question.

It's definitely doable, it will just have crap performance and 0 scalability.

Cheers,

√

[Paulo "JCranky" Siqueira]

@Sachin

Perhaps if you try to think about workers in general, and about what they have to do, and forget that threads even exists (akka will take care of that), it could help with the design.

@Viktor et al

I have a scenario that might come close to something Sachin is asking, so I'll amend it here. I have a few actors, lets call them A, B, C and D.

A is the kick-starter. It sends a message to B.
B them sends a message to both C and D.
D them also sends a message to C.

Is there any way to guarantee that B's message arrive at C before D's? I already know the messages were sent in the proper order, but it doesn't guarantee the delivery order, correct?

[]s,

2012/12/28 √iktor Ҡlang <viktor...@gmail.com>

--
Paulo "JCranky" Siqueira
http://www.jcranky.com/
http://lojinha.paulosiqueira.com.br/

[√iktor Ҡlang]

Hi Paulo,

have you read the 2.1.0 version of the message ordering documentation?

http://doc.akka.io/docs/akka/2.1.0/general/message-delivery-guarantees.html

Cheers,

√

[Paulo "JCranky" Siqueira]

I read 2.0's. Any big changes in this respect?

I know there is no guarantees in this case, so my question really is how should I design around this. Perhaps from inside C? Is it correct to say that this is C's responsibility?

[√iktor Ҡlang]

Hi Paulo,

yes, the 2.1 version is much more fleshed out.

One solution is to create an intermediate actor that all sends go though, this actor can enforce that A's messages are delivered before C's, but the real question is how you know that B received A's messages at all?

Cheers,

√

[Paulo "JCranky" Siqueira]

I don't, and this is something I'm going to work on yet - if the message is not received, I'll have to re-send it.

[Roland Kuhn]

And the logical consequence is that you will need to have the logic to handle that within D anyway, making the “requirement” a moot point.

But if you read the 2.1 docs on this, you’ll find that your “no guarantees” statement might not be true in all cases. Please have a look and tell us if it helps.

Regards,

Roland

Dr. Roland Kuhn
Akka Tech Lead
Typesafe – The software stack for applications that scale.
twitter: @rolandkuhn

[Paulo "JCranky" Siqueira]

Just read the 2.1 version. Indeed, it is much nicer then before. Since I'm at it, a small typo there, in the "Reliability of Local Message Sends" session: "meaning that the we actually do apply". There's an additional 'the' here, right? =)

Now, to the technical points. First, I wasn't fully aware of the extra considerations of the local messaging, although they make a lot of sense. In a way, I was assuming something like that, but I felt better asking.

What I said before makes sense from the general guidelines point of view, but we can be a little bit relaxed locally. This is what I'm going to do in the short term then, with design improvements in mind to take into account the general rules.

Does all this make sense?

PS.: happy new year for everybody!!

[]s,

2012/12/28 Roland Kuhn <goo...@rkuhn.info>