Author |
Message
|
infotainment |
Posted: Wed Aug 24, 2016 5:58 am Post subject: IBMIntegrationBus: MQ Message Processing in Transaction Mode |
|
|
Apprentice
Joined: 18 Apr 2016 Posts: 41
|
Dear Team,
We are facing a problem regarding IBM MQ Messages Processing under Transaction Mode in IIB.
We have one Message Flow in which IBM Message Flow is having MQ Input and MQ Output Node.
MQ Input Node’s Transaction Property is “Yes”.
MQ Output Node’s Transaction Property is “Automatic”.
When process runs, its MQ Output node (which is final node of message flow) Puts message on Persistent Message Queue on IBM MQ but the process which is needs to consume this message is NOT able to read this message.
Please note that Output Count in MQ Explorer keeps showing as 1 though it should be zero as soon as message is PUT on MQ Queue, looks like somehow commit is not working or so.
Need help, if we run same process with Transaction Mode set to "NO", only then its runs fine |
|
Back to top |
|
 |
smdavies99 |
Posted: Wed Aug 24, 2016 6:37 am Post subject: |
|
|
 Jedi Council
Joined: 10 Feb 2003 Posts: 6076 Location: Somewhere over the Rainbow this side of Never-never land.
|
So if you :-
1) Stop the reader of the output message from running
2) Enable user trace on the EG and/or the Flow
3) Send a message through the Flow
4) Read and format the User trace
5) Look at the usertrace log and see what the MQRC returned from the MQOutput Node is
Repeat the above with the Transaction mode set to No.
What is different from in the traces.
Also, it would really help to let us know what version of IIB including the FixPAck level, the platform (windows etc) and if you are using IIB 10 if the Queue Manager used for the MQInput and MQOutput is local (using the QMGR assicoated with the Broker) or a remote QMGR
IF the latter, does the flow show the same problems when you are using a queue on the local (to the broker) queue Manager. _________________ WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
Back to top |
|
 |
zpat |
Posted: Wed Aug 24, 2016 7:39 am Post subject: |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5866 Location: UK
|
The MQOutput node will acquire an open output handle to the queue - I believe the broker has a pool of these handles, and that it keeps the output handles open for about 20 minutes (or was it 20 seconds) in case of re-use.
So it is not true that the output queue handle will be dropped immediately after the message is put.
Make sure nothing is reading the queue and watch for the message, check if the queue has any uncommitted messages or not (QSTATUS). _________________ Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
Back to top |
|
 |
infotainment |
Posted: Wed Aug 24, 2016 7:45 am Post subject: |
|
|
Apprentice
Joined: 18 Apr 2016 Posts: 41
|
Thanks.
I will get back to you with updates on this |
|
Back to top |
|
 |
adubya |
Posted: Wed Aug 24, 2016 10:35 am Post subject: |
|
|
Partisan
Joined: 25 Aug 2011 Posts: 377 Location: GU12, UK
|
Is your message flow stuck in a loop ? With your transaction settings then the output message should be available to downstream consumers when the input message has been successfully processed.
Are you propagating multiple message and/or looping in your flow ? _________________ Independent Middleware Consultant
andy@knownentity.com |
|
Back to top |
|
 |
infotainment |
Posted: Thu Aug 25, 2016 4:49 am Post subject: |
|
|
Apprentice
Joined: 18 Apr 2016 Posts: 41
|
Following things are observed.
1- MQOutput node was running in Destination List mode changing it to Queue mode worked fine with Transaction mode set to "Yes" and "Automatic" for MQInput and MQOutput respectively.
2- Setting Transaction mode to "NO" for both nodes and running MQOutput node in Destination List mode resulted in Error trace of the MQOutput node(even though the destination list queue was able to successfully receive the message).
ii) Setting Transaction mode to previous configuration("Yes" and "Automatic" also made it to the error trace but this time listener queue was not able to receive the message.
** In short Destination List mode for MQOutput node is not working in Transaction mode.
Any help would be appreciated. |
|
Back to top |
|
 |
Vitor |
Posted: Thu Aug 25, 2016 4:54 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
infotainment wrote: |
** In short Destination List mode for MQOutput node is not working in Transaction mode.
Any help would be appreciated. |
So raise a PMR and ask for help.
Seriously - what do you expect us to do about a bug in the MQOutput node?
Refer to this thread in the PMR if you think it will help. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
smdavies99 |
Posted: Thu Aug 25, 2016 11:29 am Post subject: |
|
|
 Jedi Council
Joined: 10 Feb 2003 Posts: 6076 Location: Somewhere over the Rainbow this side of Never-never land.
|
What version of MQ and IIB are you using? Including the FixPack
I have a number of flows that use DestinatonLists and TransactionMode=Yes. We are looking at moving to IIB 10 shortly so it would be nice to know what verisons you are having issues with. _________________ WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
Back to top |
|
 |
vishBroker |
Posted: Thu Aug 25, 2016 12:56 pm Post subject: |
|
|
Centurion
Joined: 08 Dec 2010 Posts: 135
|
Quote: |
** In short Destination List mode for MQOutput node is not working in Transaction mode. |
Are you populating localEnvironment tree prior to MQOutput node, correctly?
This is from the help
+++
If you select Destination List, the message is sent to the list of queues that are named in the local environment that is associated with the message. The data that you have provided is used in the DestinationData subtree of the local environment. For more information about the DestinationData subtree.
+++
If you were not setting that up then, it is code issue not a product issue. |
|
Back to top |
|
 |
smdavies99 |
Posted: Thu Aug 25, 2016 9:47 pm Post subject: |
|
|
 Jedi Council
Joined: 10 Feb 2003 Posts: 6076 Location: Somewhere over the Rainbow this side of Never-never land.
|
vishBroker wrote: |
[
Are you populating localEnvironment tree prior to MQOutput node, correctly?
|
That is a very good question. We still don't have any real idea of the underlying problem apart from 'It does not work' and 'it does work'.
The OP has not told us :-
- The MQ Version inc Fixpack
- The IIB Version inc Fixpack
- What MQ Error code if any is returned
- What the Broker runtime level is
- What platform this is all happening on.
As a general observation and not just related to this thread, this lack of detail seems to be becoming more common recently.
It just makes our efforts to help all the harder. _________________ WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
Back to top |
|
 |
infotainment |
Posted: Thu Aug 25, 2016 10:15 pm Post subject: |
|
|
Apprentice
Joined: 18 Apr 2016 Posts: 41
|
Quote: |
The OP has not told us :-
- The MQ Version inc Fixpack
- The IIB Version inc Fixpack
- What MQ Error code if any is returned
- What the Broker runtime level is
- What platform this is all happening on. |
MQ Version is 8.0.0.2
IIB Version is 10.0.0.5
Linux Platform
Connecting MQ via Channel
Platform is LINUX
IIB Error Description: Invalid Destination List (in TXN Mode as well as Non TXN Mode)
Message is placed on MQ while its in Non Transaction Mode But error still comes (Invalid Destination List).
Message is NOT placed on MQ while its in Transaction Mode and error is coming still (Invalid Destination List)
Please note that Destination List Code seems valid as Queue Name is correctly picked from local environment. |
|
Back to top |
|
 |
adubya |
Posted: Thu Aug 25, 2016 10:31 pm Post subject: |
|
|
Partisan
Joined: 25 Aug 2011 Posts: 377 Location: GU12, UK
|
Perhaps you've got a legitimate entry in the destination list and also an invalid entry. When in transactional mode the flow can't write to all the destination list entries and so backs out. Non transactional mode writes to the valid entry and just warns about the invalid entry.
Add a trace node just before the MQ Output, captue ${Root} and paste the results here (in [code] tags). _________________ Independent Middleware Consultant
andy@knownentity.com |
|
Back to top |
|
 |
infotainment |
Posted: Fri Aug 26, 2016 6:15 am Post subject: |
|
|
Apprentice
Joined: 18 Apr 2016 Posts: 41
|
Dear Team,
Thanks for all your feedback.
Issue finally resolved. Root Cause was that:
In ESQL, where we were setting Queue Name in Destination List with Local Environment; propagate statement was causing this issue and after replacing propagate statement with return true statement, it worked.
 |
|
Back to top |
|
 |
fjb_saper |
Posted: Sat Aug 27, 2016 4:58 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
infotainment wrote: |
Dear Team,
Thanks for all your feedback.
Issue finally resolved. Root Cause was that:
In ESQL, where we were setting Queue Name in Destination List with Local Environment; propagate statement was causing this issue and after replacing propagate statement with return true statement, it worked.
 |
I beg to differ. The PROPAGATE statement was not causing the issue. Your use of it was. Look up the propagate statement . You need to add stuff to it if you want it to also pass the local environment to the next node... specially if you forgot to tell the compute node to do so...
Have fun  _________________ MQ & Broker admin |
|
Back to top |
|
 |
infotainment |
Posted: Sun Aug 28, 2016 6:23 am Post subject: |
|
|
Apprentice
Joined: 18 Apr 2016 Posts: 41
|
Quote: |
I beg to differ. The PROPAGATE statement was not causing the issue. Your use of it was. Look up the propagate statement . You need to add stuff to it if you want it to also pass the local environment to the next node... specially if you forgot to tell the compute node to do so... |
Point noted. I will update code and get back to you. |
|
Back to top |
|
 |
|