qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From gcutuli <giuseppe.cut...@numonyx.com>
Subject Multi-Threading
Date Fri, 26 Nov 2010 10:43:46 GMT

Dear all,
I'm moving toward the implementation of a multithreading application based
on QPID Messaging 0.7, and I experienced strange behaviors.
This is the background:
- subscription of N subjects with N different receivers (all of them under
the same session)
- running N different "diaspatching threads" for each receiver 
Basically, each "dispatcher" executes an infinite loop where messages are
fetched from the related queue:
for (;;)
    msg = receiver.fetch(Duration::Forever);
After a random number of incoming messages, the library crashes (exactly on
the "fetch" method) with one of the following exceptions:
qpid::messaging::NoMessageAvailable or  qpid::messaging::SessionError
My suspect is that the native qpid session object is not designed to be used
in a multi-threading scenario (in other words this object is not
I also tryed to create a different session for each receiver and, in this
case, the application works fine without any exception.
Is all ok? Not at all !!!
With N indipendent sessions, is not possible to create and share the same
queue if the exclusive flag is set to true.
In fact, It happens that the first receiver creates and binds the queue,
while the others receive an exception trying to "bind" the same queue.
This is because the "exclusiveness" of a queue, is referred to the session
where it has been declared.
In other words, the "exclusive" flag is temporary: when the session where
the "exclusive" queue has been created is closed,  the flag is reset to
allowing another session to "acquire" that queue.
Furthermore, please consider the following rules:
if (exclusive=True and autoDelete=True)
    the queue is deleted once the session where it has been created, is
if (exclusive=false and autoDelete=True)
    the queue is deleted once all the consumers (sessions) are close.
I'm applying this second rule in my application keeping in mind that a
non-exclusive queue is anything but "private" (apart its name - that is
guaranteed to be 
unique and randomly generated) and any client can, potentially, read
messages from it.
Any comments from your side?

View this message in context: http://apache-qpid-users.2158936.n2.nabble.com/Multi-Threading-tp5776758p5776758.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.

Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org

View raw message