| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| What will happen |
« View previous topic :: View next topic » |
| Author |
Message
|
| nyey |
 Posted: Fri Aug 13, 2004 12:46 pm Post subject: What will happen |
 |
|
Acolyte
Joined: 13 Mar 2003
Posts: 57
|
I have a clustered Q mgrs which 2 clustered qs I sent msgs to. Due the receiving side down, we have accumtalute of msgs. we have expiry on the msgs.
Since there will be no get/browser operations to the msgs, then they will fill up the Qs. Then:
what will happen? go to the deadlett Qs?
If deadletter qs also full, waht will be next? |
|
| Back to top |
|
 |
| EddieA |
| Posted: Fri Aug 13, 2004 1:39 pm Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
It's a little unclear from your description where the "accumulation" of messages is taking place.
If the communication between the QMs is down, then the messages will continue to accumulate on the XMITQ. Once this fills up, the sending application will get an error returned to it when it tries to PUT a message.
If the connection is good, but the receiving application is down, messages will continue to build up on the application queue. When that fills, the messages will go to the DLQ instead. When that fills, the channel will "go down" and the messages will start to build up on the sending XMITQ, when the above scenario will eventually happen.
However, the second case only happens like that with persistent messages. If they are not persistent, then it depends on the Channel attribute: NPMSPEED. Look this up in the manuals to see what the effects are.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| Nigelg |
| Posted: Thu Aug 19, 2004 7:52 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
| You could try starting the cluster channels, even if the destination qmgrs are down. This will have the effect of the channel reading the msgs on the cluster xmitq and trying to allocate them to another qmgr in the cluster. If the msgs have reached their expiry time, they will then be removed from the CURDEPTH. This will only work if the msgs were put BIND_NOT_FIXED. |
|
| Back to top |
|
|
| EddieA |
| Posted: Thu Aug 19, 2004 9:01 am Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
| Quote: |
| This will have the effect of the channel reading the msgs on the cluster xmitq and trying to allocate them to another qmgr in the cluster |
No. By the time the message is put into the XMITQ, MQ has already decided which QM to route to. Take a look at the CorrelationID (or is it MessageID) in the header. That's the destination.
If you want to re-route them, you will have to write an application to do it.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| Nigelg |
| Posted: Thu Aug 19, 2004 11:10 pm Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
Sorry EddieA, you are wrong. When a cluster channel stops, the msgs on the channel which were put with BIND_NOT_FIXED are reallocated if there is an alternative destination. See this description I wrote a little while ago:
These messages may be routed to another qmgr when the
channel to that qmgr stops, or the qmgr starts. Note that this will
happen periodically when a channel is in RETRYING SHORTRTY (10) times
at an interval of SHORTTMR (60) seconds, followed by LONGRTY (999..)
times at intervals of LONGTMR (1200) seconds. Note also that by default
LONGRTY is a large number, so should a channel to a running qmgr in a
cluster ever go into RETRYING (for whatever reason) then messages
directed to a cluster queue with multiple instances will then be routed
to each qmgr that has a RETRYING status.
.
The mechanism for rerouting messages in the cluster xmitq is invoked
every time a channel stops (or goes into RETRYING status). This is
done in rrmReallocMsgs, called from rriWriteCompMsg, from rriFreeSess.
The messages on the xmitq with a CorrelId of the channel name are read
and MQPUT again. The same mechanism as above decides the qmgr that the
messages will be routed to. This process stops when all the messages for
that channel have been read. This may result in all the messages being
routed to the same qmgr again, if no other qmgr with a status in the
same class is available.
The same thing is done on qmgr startup as part of the cluster reconcile
process run by the repository manager. |
|
| Back to top |
|
|
| EddieA |
| Posted: Fri Aug 20, 2004 9:46 am Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
Well, as they say: "You learn something new every day". 
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| 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
|
|
|
|
