| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| SYSTEM.CLUSTER.TRANSMIT.QUEUE is piling messages |
« View previous topic :: View next topic » |
| Author |
Message
|
| faiz |
 Posted: Fri Nov 15, 2002 8:49 am Post subject: SYSTEM.CLUSTER.TRANSMIT.QUEUE is piling messages |
 |
|
Newbie
Joined: 15 Nov 2002
Posts: 2
Location: Chicago
|
Hi,
I have a basic question about how clustering and syncpoint works.
I have two Queue Managers QM1 and QM2 and they are both part of a cluster. I have defined a Queue Q2 which is local to QM2 and part of the cluster. I have another Queue Q1 which is a local queue to QM1.
Here is my scenario.
When I put messages to Q1 and Q2 as part of the same unit of work everything works fine. When I put disable Q2 on QM2. My application is still able to put messages to Q1 and Q2 as part of the same unit of work. I noticed since I have put disabled Q2 the unit of work did not rollback. Also the message intended for Q2 is sitting in the SYSTEM.CLUSTER.TRANSMIT.QUEUE.
Now when I put enable Q2 on QM2 the message is still sitting on the SYSTEM.CLUSTER.TRASMIT.QUEUE and any further messages to Q1 and Q2 are being sent correctly as part of the same unit of work.
I have two questions now
1) When I put disabled Q2 on QM2 shoudln't the unit of work rollback.
2) When I put enabled Q2 on QM2 shouldn't the piled up messages on SYSTEM.CLUSTER.TRANSMIT.QUEUE be delivered to Q2 on QM2
Thanks |
|
| Back to top |
|
 |
| mqonnet |
| Posted: Fri Nov 15, 2002 9:06 am Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
Here are your answers.
1) Why do you think that the UOW should be rolled back if you put disabled a queue. Consider the same scenario on a local queue. When you put to a local queue with syncpoint under a UOW, and the queue is put disabled. Then it is the put that fails with 2051. It has nothing to do with the UOW the application started to do this put. UOW is backed out only if there is some thing wrong with the transaction or transaction manager. But since the PUT itself failed, the message would not land up on the local queue. Coming back to your scenario of clustering. You would expect the earlier result in this case too. And which is, NO message anywhere. But you have to bear in mind that clustering tries to use the algorithm to try and put the message first to the local instance of a queue, if available. If there is not, or there is an error, it would try to put it onto the next available anywhere within the cluster. And since it tried but did not find any such reference, it stayed in the CLUSTER.TRANSMIT.QUEUE. My 2 cents of reasoning.
2) The message that stays on CLUSTER.TRANSMIT.QUEUE reached that queue because of an error, as per my previous explaination. And hence it stays there forever and never gets transmitted. As it does not know where Q2 is present other than the local qm.
Hope this helps.
Cheers.
kumar
_________________
IBM Certified WebSphere MQ V5.3 Developer
IBM Certified WebSphere MQ V5.3 Solution Designer
IBM Certified WebSphere MQ V5.3 System Administrator |
|
| Back to top |
|
|
| faiz |
| Posted: Mon Nov 18, 2002 10:01 am Post subject: |
|
|
Newbie
Joined: 15 Nov 2002
Posts: 2
Location: Chicago
|
Thanks for you response.
Isnt there any retry logic for messages stuck in SYSTEM.CLUSTER.TRANSMIT.QUEUE
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
|
|
|
|
