Multi-Threading

[gcutuli <gi...@numonyx.com>]

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
thread-safe).
 
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
false,
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
close
}
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?
 
Regards

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

Re: Multi-Threading

[Gordon Sim <gs...@redhat.com>]

On 11/26/2010 10:43 AM, gcutuli wrote:
>
> 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

Is there any more detail logged for the session errors, either on the 
client or the broker? I suspect that may be the root cause of the issue.

> 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
> thread-safe).

It is supposed to be threadsafe (that doesn't of course rule out a bug 
making it unsafe).

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