| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| MQ consumption stalling when one Weblogic server fails |
« View previous topic :: View next topic » |
| Author |
Message
|
| BBM |
 Posted: Thu Sep 20, 2012 3:04 am Post subject: MQ consumption stalling when one Weblogic server fails |
 |
|
Master
Joined: 10 Nov 2005
Posts: 217
Location: London, UK
|
Hi everyone,
I wanted to find out if anyone knows the expected behaviour of MQ in the following circumstance:
We have four Weblogic managed servers (J2EE application servers), that are consuming from the same queue. Each managed server has 16 MDB connections to the queue totalling 64 connections.
We have found that when one managed server goes into a indeterminate state and partially hangs message consumption stops completely. The connection count remains at 64 but no messages are being consumed suggesting that the hung server is preventing further consumption by the remaining three managed servers.
The queue is set to FIFO (default). We are thinking that as MQ has not finished allowing the hung managed server to get the message, ie the commitment of the GET has not been completed it will not allow further consumption as this would upset the FIFO order.
Is this assumption correct, or are we completely on the wrong track? The managed servers are opening the queue for shared input so I'd be surprised if MQ allows one app to block all other but this is what appears to be happening.
Any pointers would be greatly appreciated.
Thanks
BBM |
|
| Back to top |
|
 |
| Vitor |
| Posted: Thu Sep 20, 2012 5:05 am Post subject: Re: MQ consumption stalling when one Weblogic server fails |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| BBM wrote: |
| We are thinking that as MQ has not finished allowing the hung managed server to get the message, ie the commitment of the GET has not been completed it will not allow further consumption as this would upset the FIFO order. |
I'd hope that each MDB would have a different queue handle and hence the fact that 1 get not being completed would still allow the next message to be retrieved. Remember that having the queue as FIFO (rather than priority) controls how the messages are presented, not the order of delivery. The next get request (wherever it comes from) should be given the next available message in FIFO order. So the first message (or 1st 16) might sit because they're hung up but the rest should go.
Unless there's something in your set up enforcing sequence.
My hopes & theories are no substitute for a PMR here.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| BBM |
| Posted: Thu Sep 20, 2012 7:06 am Post subject: |
|
|
Master
Joined: 10 Nov 2005
Posts: 217
Location: London, UK
|
| Thanks - that's very interesting, I hadn't realised that specifying FIFO only affected the presentation I thought GET order was enforced. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Sep 20, 2012 9:31 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| BBM wrote: |
| Thanks - that's very interesting, I hadn't realised that specifying FIFO only affected the presentation I thought GET order was enforced. |
Unless you're using something like message sequence or order, hence my point above.
Effectively specifying FIFO just causes the queue manager to ignore the priority in a message's MQMD.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| 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
|
|
|
|
