qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: C++ Messaging API: Reading from two different message brokers (now thread safety)
Date Mon, 27 Jul 2015 11:10:41 GMT
On 07/23/2015 12:58 PM, Andreas Welchlin wrote:
> Hello,
> since there seems to be no method in the C++ messaging API to listen on
> two different message brokers at the same time I will do this using two
> additional threads. So I ask myself how threadsafe the messaging API is
> or more concrete: how threadsafe the method
> "qpid::messaging::Session::nextReceiver()" is.
> My plan is to use the main thread to read and send messages from/to both
> of the brokers.
> For waiting on incoming messages I start two additional threads. Each of
> them calls Session::nextReceiver(). If a message is available the main
> thread will be informed and call fetch() on the receiver which woke up.
> My question is: Would it be a problem if one thread calls
> session.nextReceiver() and at the same time another thread calls
> receiver.fetch()?

The Session::nextReceiver() method returns the next receiver on which a 
fetch would be successful. If you call this again concurrently with 
actually calling the Receiver::fetch(), there is a race. The 
nextReceiver call may get the same receiver again simply because it gets 
in before the fetch.

> It could also be possible that the main thread calls sender.send() while
> the other thread is waiting in session.nextReceiver()?

This should cause no problems.

> On 07/21/2015 10:15 AM, Andreas Welchlin wrote:
>> I wrote an application which reads from two different message brokers.
>> So I used two connections and therefore I got also two sessions.
>> When I have just one session I can just call
>> "qpid::messaging::Session::nextReceiver()". But this is not possible
>> with two sessions. I could call nextReceiver for both sessions in two
>> differnt threads but this is not so nice.
>> Do you have an idea how I could solve this in an easy way?

This is a gap/failing of the qpid::messaging API. Though I did spend 
some time investigating changes to eliminate it, my own view at present 
is that the emerging proton based reactive API in c++[1]  is probably 
the better solution. Alan has created some nice documentation for that: 
http://people.apache.org/~aconway/proton/index.html (it is AMQP 1.0 only 
as well, I should note).

[1] currently still on a branch but ready I believe to be meregd as soon 
as 0.10 is released: 

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

View raw message