Author |
Message
|
gerco |
Posted: Thu Jan 10, 2008 2:21 am Post subject: Cluster and XA |
|
|
Newbie
Joined: 10 Jan 2008 Posts: 7
|
Hello,
I have the following setup, using WMQ 5.3:
- Queue manager QM1 at Server 1
- Queue manager QM2 at Server 2, hosting queue q2 which is shared in the cluster.
- Cluster with QM1 and QM2
The problem occurs when both channels at QM1 are inactive, for instance after a restart of the queue manager. I have a (Tuxedo) client putting messages in q2 (connecting through QM1) and it runs in a XA transaction. The message however gets stuck in the SYSTEM.CLUSTER.TRANSIT.QUEUE and the cluster channels remain inactive.
When I drop a message in q2 (via QM1) using the MQ Explorer or AMQSPUT sample program, the message is actually delivered at q2, the cluster channel activated and also the Tuxedo message (which was still pending in the TRANSIT queue) is delivered.
So why doesn't the Tuxedo action activate the channels, while the (very simple) sample program does? There are some minor differences in put options (we are currently investigating whether that makes a difference), but it might also be related to the Tuxedo client participating in an XA transaction, while the sample program obviously doesn't.
Any help will be appreciated.
Cheers,
Gerco |
|
Back to top |
|
 |
jefflowrey |
Posted: Thu Jan 10, 2008 4:44 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
Presumably the Tuxedo app is not properly committing the transaction, and so the messages are not committed on the xmitq and thus not available to get, and thus not triggering the channels. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
gerco |
Posted: Thu Jan 10, 2008 4:51 am Post subject: |
|
|
Newbie
Joined: 10 Jan 2008 Posts: 7
|
Hmm, don't think that's the case.
First of all, in that case the Tux client would have got a transaction time out.
Secondly, MQ has accepted the message. After all, as soon as the channels are activated, the message is delivered at the queue. If that message was still part of a pending message, this would never be allowed.
Thanks,
Gerco |
|
Back to top |
|
 |
jefflowrey |
Posted: Thu Jan 10, 2008 5:03 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
Can you browse the tuxedo messages on the xmitq, before they are delivered? _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
gerco |
Posted: Thu Jan 10, 2008 5:12 am Post subject: |
|
|
Newbie
Joined: 10 Jan 2008 Posts: 7
|
Yes, they are visible in the SYSTEM.CLUSTER.TRANSMIT.QUEUE and can be opened.
It seems to me (although I am not an expert) that MQ has accepted the message, has forwarded the message to the QM where the queue actually resides but the message is kept in the 'outbox' as the channels are not activated. And as soon as they are activated, the message is successfully delivered. |
|
Back to top |
|
 |
jefflowrey |
Posted: Thu Jan 10, 2008 5:21 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
If you can open the messages, then yes. That's the case. But... one has to eliminate the easy possibilities first.
Is your channel initiator running? Did someone play around with the properties of SYSTEM.CLUSTER.TRANSMIT.QUEUE? Are there errors in the AMQERR logs? _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
gerco |
Posted: Thu Jan 10, 2008 6:00 am Post subject: |
|
|
Newbie
Joined: 10 Jan 2008 Posts: 7
|
>>Is your channel initiator running?
Channel initiator is running.
>>Did someone play around with the properties of SYSTEM.CLUSTER.TRANSMIT.QUEUE?
No, it is a clean install on clean virtual machines, which we did in order to try to isolate the problem.
>>Are there errors in the AMQERR logs?
No, complete silence. |
|
Back to top |
|
 |
fjb_saper |
Posted: Thu Jan 10, 2008 7:43 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
Can you give us the trigger attributes of the SYSTEM.CLUSTER.TRANSMIT.QUEUE ? _________________ MQ & Broker admin |
|
Back to top |
|
 |
gerco |
Posted: Thu Jan 10, 2008 8:12 am Post subject: |
|
|
Newbie
Joined: 10 Jan 2008 Posts: 7
|
Trigger Control: on
Trigger Type: first
Trigger Depth: 1
Trigger Message Priority: 0
Trigger Data: -
Initiation Queue Name: -
Process Name: - |
|
Back to top |
|
 |
fjb_saper |
Posted: Thu Jan 10, 2008 10:58 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
Looks like everything is right. Open a PMR ( ) _________________ MQ & Broker admin |
|
Back to top |
|
 |
PeterPotkay |
Posted: Fri Jan 11, 2008 8:39 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
I agree. With the details provided the behaviour makes no sense. Please post the resolution once you figure it out. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
gerco |
Posted: Fri Jan 11, 2008 12:50 pm Post subject: |
|
|
Newbie
Joined: 10 Jan 2008 Posts: 7
|
It didn't make sense to me either. Will try to get IBM involved and let you know once we found the problem. |
|
Back to top |
|
 |
Nigelg |
Posted: Sun Jan 13, 2008 10:21 pm Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004 Posts: 1046
|
Quote: |
Can you give us the trigger attributes of the SYSTEM.CLUSTER.TRANSMIT.QUEUE ?
|
This is not relevant to any problem of a cluster channel not starting. Cluster channels are triggered by internal logic in the agent during put processing, not by the triggering mechanism used to start distributed channels. _________________ MQSeries.net helps those who help themselves.. |
|
Back to top |
|
 |
markt |
Posted: Mon Jan 14, 2008 5:06 am Post subject: |
|
|
 Knight
Joined: 14 May 2002 Posts: 508
|
|
Back to top |
|
 |
gerco |
Posted: Mon Jan 14, 2008 8:26 am Post subject: |
|
|
Newbie
Joined: 10 Jan 2008 Posts: 7
|
I think you hit the nail on its head. Apparently a very recent bug fix (sometimes you just have to be lucky).
I tried it at my clean test environment, and their it worked fine. We will try to implement it at the real systems, but I am pretty confident.
More details can be found here: http://www-1.ibm.com/support/docview.wss?rs=171&uid=swg1IY86994
Thanks a lot everyone for providing input. |
|
Back to top |
|
 |
|