PinnedDispatcher with SingleConsumerOnlyUnboundedMailbox behaviour

[Guido Medina]

Quick question: If my default mailbox is a SingleConsumerOnlyUnboundedMailbox and my dispatcher a PinnedDispatcher, does the thread pool -in this case a single thread- de-queue tasks from it or is it there an intermediary Java blocking queue?

I'm assuming dispatchers in Akka are not necessary a copy of Fork-Join and Thread Pool executors from Java which for SingleConsumerOnlyUnboundedMailbox and PinnedDispatcher would be a waste of performance, I'm assuming it is de-queuing tasks directly from the mailbox, are my assumptions correct?

Best regards,

Guido.

[Guido Medina]

Sorry I mixed oranges with apples here, I just looked deeper the code and no, my assumptions are not correct, the mailbox is one thing but the task-queue is a different story, it would be nice at the ThreadPoolExecutorConfigurator Scala class to have an option for single thread dispatchers aka PinnedDispatcher so that it is not a full blown blocking queue due to the fact there is only one thread executing tasks, I'm guessing there is one or more threads on the Akka system "loop" that can queue tasks into the PinnedDispatcher's queue which in this case it will always have a single task consumer -The PinnedDispatcher only thread-

[Guido Medina]

In fact, even more could be done here, I'm assuming there is a reason why mailboxes in general are not just blocking queues from Java, designers' decision to provide a faster queue, so, why not reuse the same logic for dispatchers?

[Viktor Klang]

Hi Guido,

the good news is that the ExecutorService for the Dispatcher is pluggable so you can provide your own, optimized version.

Would love to hear how much of a difference it could make (JMH bench would be superb).

On Tue, May 26, 2015 at 6:35 PM, Guido Medina <oxy...@gmail.com> wrote:

In fact, even more could be done here, I'm assuming there is a reason why mailboxes in general are not just blocking queues from Java, designers' decision to provide a faster queue, so, why not reuse the same logic for dispatchers?

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

√

[Guido Medina]

It would only require a quick & dirty hack, but I'm still in the process of learning/developing a new project using Akka/Java 8 on a new job so time is not much on my side -you know, the first 6 months of every new job-

There is no need to change the dispatcher but the Scala configurator should provide one of your lovely queues which I know are extremely optimized compared to ArrayBlockingQueue, LinkedBlocking and ConcurrentLinkedQueue Java counter parts, right?

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/Q_sgvACG8Nw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to akka-user+...@googlegroups.com.

[Guido Medina]

Sorry I replied directly to you, my mistake, pasting message here:

[Viktor Klang]

Fair enough :)

I have some longer term plans providing more interesting execution engines (not based on ExecutorService),

we'll see what the future holds. For all intents and purposes the invitation to provide alternate implementations still stands :)