| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Is blocking send() on full JMS queue possible in WMQ? |
« View previous topic :: View next topic » |
| Author |
Message
|
| mqsnbmp1 |
 Posted: Tue Oct 18, 2005 6:31 am Post subject: Is blocking send() on full JMS queue possible in WMQ? |
 |
|
Apprentice
Joined: 18 Oct 2005
Posts: 25
|
| Normally, when a Websphere MQ queue reaches its maximum queue depth, any subsequent send() operation will fail (JMSException) due to queue full condition. Other JMS providers (Weblogic, etc) allow queue settings that would cause a send() call to a full queue to block (either indefinitely or with a timeout) -- a behavior similar to how synchronous receive() would block on an empty queue. Is there a way (some setting) in Websphere MQ to make send() call block on a full queue, rather than throw an exception? -- Thanks |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Tue Oct 18, 2005 6:46 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
No.
But you could easily wrap an infinite loop around your send, and have it keep trying until the exception does not indicate a full queue.
But man I hope there isn't a user on the other side of this operation.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| mqsnbmp1 |
| Posted: Tue Oct 18, 2005 7:23 am Post subject: |
|
|
Apprentice
Joined: 18 Oct 2005
Posts: 25
|
Thanks for reply. The problem with this approach is that you would have to rely on IBM-specific error codes from LinkedException. This defeats the purpose of having a provider-independent JMS+JNDI code to access message queues (JMSException on the full queue is non-specific, so retries based on just JMS exceptions would be non-sensical).
I am new to Websphere MQ, but not to MOM in general. Anything that I have worked with so far (System V IPC, POSIX queues, JMS via other providers) does give you the option for configurable timeout on a send() operation. This is quite surprising that IBM makes the decision to return an error immediately.
So from what I gather, the only option with IBM is to size up the queue for the worst possible scenario. This is pretty weak in my view, since a simple configuration mistake can cause a disaster. On the other hand, messages could be buffered up somewhere else -- but why do this if a message queue can already serve as a persistent FIFO?
Can someone point out where I might be missing the point?
Thanks. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
