You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Andreas Welchlin <an...@welchlin.de> on 2015/07/21 10:15:10 UTC

C++ Messaging API: Reading from two different message brokers

Hello,

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?

Regards,
Andreas


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


Re: C++ Messaging API: Reading from two different message brokers (now thread safety)

Posted by Gordon Sim <gs...@redhat.com>.
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: 
https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;a=shortlog;h=refs/heads/cjansen-cpp-client


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


Re: C++ Messaging API: Reading from two different message brokers (now thread safety)

Posted by Andreas Welchlin <an...@welchlin.de>.
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()?

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

Do you see any problems there?

Regards,
Andreas



On 07/21/2015 10:15 AM, Andreas Welchlin wrote:
> Hello,
>
> 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?
>
> Regards,
> Andreas
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>



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