You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by theipavlu <th...@gmail.com> on 2016/04/11 23:24:33 UTC

QPID Threading model?

Hi,

how does it works behind scenes in QPID?
I got some idea, that each connection has own thread or thread from pool, to
handle incoming/outgoing messages. But is it only one for transmission and
reception as well?
Where the threads are created?

I got through code in C++, and have to admit, that I have not found it...
I would like to know more about the threading model QPID has implemented.

Thanks.

ip




--
View this message in context: http://qpid.2158936.n2.nabble.com/QPID-Threading-model-tp7641734.html
Sent from the Apache Qpid developers mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org


Re: QPID Threading model?

Posted by Alan Conway <ac...@redhat.com>.
On Mon, 2016-04-11 at 14:24 -0700, theipavlu wrote:
> Hi,
> 
> how does it works behind scenes in QPID?
> I got some idea, that each connection has own thread or thread from
> pool, to
> handle incoming/outgoing messages. But is it only one for
> transmission and
> reception as well?
> Where the threads are created?
> 
> I got through code in C++, and have to admit, that I have not found
> it...
> I would like to know more about the threading model QPID has
> implemented.

The model is fixed-size thread pool, work is serialized per-connection. 
Different threads may process a connection over its lifetime but no two
threads will ever process the same connection concurrently, which
reduces the need for locking on per-connection state.

Threads are started when the broker starts. When a connection becomes
readable or writable, some thread wakes up to process it. No other
thread is allowed to touch that connection till that thread is
finished. The worker threads uses non-blocking or asynchronous IO to do
only the work that is immediately available on the connection, then
they go back to sleep and put the connection back in the poller where
any thread can wake up to process it when it is ready to process again.

This is a common model for scalable servers. The number of threads in
the pool should be tuned to the number of real hardware cores, not the
number of expected connections. That reduces unproductive context
switching overhead that occurs when you have far more threads that
cores.

> 
> Thanks.
> 
> ip
> 
> 
> 
> 
> --
> View this message in context: http://qpid.2158936.n2.nabble.com/QPID-
> Threading-model-tp7641734.html
> Sent from the Apache Qpid developers mailing list archive at
> Nabble.com.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org