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 [[email protected]] Sent: Wednesday, March 13, 2013 2:37 AM To: [email protected] 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: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
