You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Connor Poske <co...@onrampwireless.com> on 2013/03/12 19:12:45 UTC
C++ client library Send() timeout
My apologies if this has already been asked.
Why does the C++ client library not implement a timeout for send()?
We are experiencing a problem where a send() call blocks forever when an exchange it is pushing to has a full queue. We are not in control of the northbound receiving queues being created, so we cannot guarantee that the queue will have a ring limit policy. This leads to the possibility that the queue can become full, thus causing subsequent send() calls to the exchange the queue is on to block indefinitely.
The Java and Python client libraries have a timeout parameter for the send() call, why not c++? Would this be difficult to add?
Re: C++ client library Send() timeout
Posted by Gordon Sim <gs...@redhat.com>.
On 03/14/2013 07:03 PM, Virgilio Fornazin wrote:
> You raised a interesting question here Connor: aren't Sender objects
> 'thread-safe' ?
Yes, they are. (However if two threads are using a sender then neither
can rely on the result of getAvailable() remaining unchanged before a
subsequent call to send()).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: C++ client library Send() timeout
Posted by Virgilio Fornazin <vi...@gmail.com>.
You raised a interesting question here Connor: aren't Sender objects
'thread-safe' ?
On Thu, Mar 14, 2013 at 3:17 PM, Gordon Sim <gs...@redhat.com> wrote:
> On 03/14/2013 05:15 PM, Connor Poske wrote:
>
>> Thanks Gordon, I created QPID-4648
>>
>> https://issues.apache.org/**jira/browse/QPID-4648<https://issues.apache.org/jira/browse/QPID-4648>
>>
>> I didn't see how to assign it to someone, maybe I don't have those
>> privileges?
>>
>
> Thanks! I've assigned it to myself.
>
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.**org<us...@qpid.apache.org>
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: C++ client library Send() timeout
Posted by Gordon Sim <gs...@redhat.com>.
On 03/14/2013 05:15 PM, Connor Poske wrote:
> Thanks Gordon, I created QPID-4648
>
> https://issues.apache.org/jira/browse/QPID-4648
>
> I didn't see how to assign it to someone, maybe I don't have those privileges?
Thanks! I've assigned it to myself.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
RE: C++ client library Send() timeout
Posted by Connor Poske <co...@onrampwireless.com>.
Thanks Gordon, I created QPID-4648
https://issues.apache.org/jira/browse/QPID-4648
I didn't see how to assign it to someone, maybe I don't have those privileges?
________________________________________
From: Gordon Sim [gsim@redhat.com]
Sent: Thursday, March 14, 2013 2:29 AM
To: users@qpid.apache.org
Subject: Re: C++ client library Send() timeout
On 03/13/2013 04:55 PM, Connor Poske wrote:
> Thanks Gordon.
>
> We do use the getAvailable() function. The problem is this solution
> is only useful if you have exclusive access to the Sender. If thread
> B pushes a message to the Sender in between Thread A's call to
> getAvailble() and Send(), thread A is now blocked indefinitely,
> assuming there was only 1 slot available on the Sender initially.
>
> A potential work around is essentially a wrapper to Sender that
> provides an exclusive lock to the caller on the underlying Sender,
> and implements a timeout by checking getAvailable() until either
> timeout occurs or there is available space.
Senders are pretty cheap (though there is a roundtrip or two on setup),
so another workaround is to create a distinct Sender object for each
thread. As far as the transfers on the wire go, for 0-10 at least there
will be little difference.
> I would still request the timeout feature be added if I had such
> powers :)
The request doesn't require much in the way of power :) By all means
create a JIRA - assign to me for now so it doesn't get 'lost' and I'll
do my best to get to it, though I can't make any promises regarding
timing yet.
---------------------------------------------------------------------
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
Re: C++ client library Send() timeout
Posted by Gordon Sim <gs...@redhat.com>.
On 03/13/2013 04:55 PM, Connor Poske wrote:
> Thanks Gordon.
>
> We do use the getAvailable() function. The problem is this solution
> is only useful if you have exclusive access to the Sender. If thread
> B pushes a message to the Sender in between Thread A's call to
> getAvailble() and Send(), thread A is now blocked indefinitely,
> assuming there was only 1 slot available on the Sender initially.
>
> A potential work around is essentially a wrapper to Sender that
> provides an exclusive lock to the caller on the underlying Sender,
> and implements a timeout by checking getAvailable() until either
> timeout occurs or there is available space.
Senders are pretty cheap (though there is a roundtrip or two on setup),
so another workaround is to create a distinct Sender object for each
thread. As far as the transfers on the wire go, for 0-10 at least there
will be little difference.
> I would still request the timeout feature be added if I had such
> powers :)
The request doesn't require much in the way of power :) By all means
create a JIRA - assign to me for now so it doesn't get 'lost' and I'll
do my best to get to it, though I can't make any promises regarding
timing yet.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
RE: C++ client library Send() timeout
Posted by Connor Poske <co...@onrampwireless.com>.
Thanks Gordon.
We do use the getAvailable() function. The problem is this solution is only useful if you have exclusive access to the Sender. If thread B pushes a message to the Sender in between Thread A's call to getAvailble() and Send(), thread A is now blocked indefinitely, assuming there was only 1 slot available on the Sender initially.
A potential work around is essentially a wrapper to Sender that provides an exclusive lock to the caller on the underlying Sender, and implements a timeout by checking getAvailable() until either timeout occurs or there is available space.
I would still request the timeout feature be added if I had such powers :)
________________________________________
From: Gordon Sim [gsim@redhat.com]
Sent: Wednesday, March 13, 2013 2:37 AM
To: users@qpid.apache.org
Subject: Re: C++ client library Send() timeout
On 03/12/2013 06:12 PM, Connor Poske wrote:
> My apologies if this has already been asked.
>
> Why does the C++ client library not implement a timeout for send()?
>
> We are experiencing a problem where a send() call blocks forever when an exchange it is pushing to has a full queue. We are not in control of the northbound receiving queues being created, so we cannot guarantee that the queue will have a ring limit policy. This leads to the possibility that the queue can become full, thus causing subsequent send() calls to the exchange the queue is on to block indefinitely.
>
> The Java and Python client libraries have a timeout parameter for the send() call, why not c++? Would this be difficult to add?
It would not be entirely trivial, but neither should it be too
difficult. I agree it would be a useful addition.
One other suggestion however would be to check available capacity before
sending. If sender.available() returns 0 then you will block; if it
returns a non-zero result you will not. In some ways that leaves you in
a more predictable state. You don't timeout waiting for the status of a
sent message, you simply avoid sending it and take some other action.
---------------------------------------------------------------------
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
Re: C++ client library Send() timeout
Posted by Gordon Sim <gs...@redhat.com>.
On 03/12/2013 06:12 PM, Connor Poske wrote:
> My apologies if this has already been asked.
>
> Why does the C++ client library not implement a timeout for send()?
>
> We are experiencing a problem where a send() call blocks forever when an exchange it is pushing to has a full queue. We are not in control of the northbound receiving queues being created, so we cannot guarantee that the queue will have a ring limit policy. This leads to the possibility that the queue can become full, thus causing subsequent send() calls to the exchange the queue is on to block indefinitely.
>
> The Java and Python client libraries have a timeout parameter for the send() call, why not c++? Would this be difficult to add?
It would not be entirely trivial, but neither should it be too
difficult. I agree it would be a useful addition.
One other suggestion however would be to check available capacity before
sending. If sender.available() returns 0 then you will block; if it
returns a non-zero result you will not. In some ways that leaves you in
a more predictable state. You don't timeout waiting for the status of a
sent message, you simply avoid sending it and take some other action.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org