| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Dymanically Setting Queue Name in MQGet Node |
« View previous topic :: View next topic » |
| Author |
Message
|
| sarathmattam |
 Posted: Tue Jul 15, 2014 12:53 am Post subject: Dymanically Setting Queue Name in MQGet Node |
 |
|
Voyager
Joined: 05 Sep 2008
Posts: 94
|
Dear All,
I am stuck with an issue with MQGet Node. Am using WMB 8.0.0.3 and MQ 7.5.
I have a message flow as below
MQ Input --> Timer Control node
Timer Notification --> MQ Header --> Compute-1 Node --> MQGet Node -->Compute-2 node --> MQ Output Node
I am setting the queue name in OutputLocalEnvironment in Compute-1 node and set the Compute mode property of the compute-1 node to LocalEnvironment and Message. But, when trying to read message from the queue, am getting an exception. I have gone through the previous posts here, and many of them points to the approach that I followed. I am copying the error part of the user trace below
| Quote: |
2014-07-15 12:49:18.007714 76064 UserTrace BIP4016I: Message propagated to terminal ''out'' of node 'com.emaratech.common.purge.queue.PurgeQueueMsgFlow.Get_Trans_Details_From_DB' with the following message trees: 'OutputLocalEnvironment, OutputRoot, InputExceptionList'.
2014-07-15 12:49:18.007854 76064 UserTrace BIP4635I: The MQ Get node 'com.emaratech.common.purge.queue.PurgeQueueMsgFlow.Purge_Profile_Msg' failed to navigate to the default location ''InputLocalEnvironment.MQ.GET.MQGMO'' for ''Input MQGMO Location (derived from Input MQ Parameters Location)''.
Location ''InputLocalEnvironment.MQ.GET.MQGMO'' is the default value for ''Input MQGMO Location (derived from Input MQ Parameters Location)'' and it was not found. It is assumed that this ''Input MQGMO Location (derived from Input MQ Parameters Location)'' node property is not needed in this case and, therefore, the issue is ignored.
Ignore this message (and the previous user trace message regarding this navigation, if there is one) if this ''Input MQGMO Location (derived from Input MQ Parameters Location)'' node property is not needed; Otherwise, make sure the location is available or correct the location specification.
2014-07-15 12:49:18.009124 76064 UserTrace BIP2231E: Error detected whilst processing a message in node 'com.emaratech.common.purge.queue.PurgeQueueMsgFlow.TimeoutNotification'.
The message broker detected an error whilst processing a message in node 'com.emaratech.common.purge.queue.PurgeQueueMsgFlow.TimeoutNotification'. The message has been augmented with an exception list and has been propagated to the node's failure terminal for further processing.
See the following messages for details of the error.
2014-07-15 12:49:18.009150 76064 RecoverableException BIP2230E: Error detected whilst processing a message in node 'com.emaratech.common.purge.queue.PurgeQueueMsgFlow.Get_Trans_Details_From_DB'.
The message broker detected an error whilst processing a message in node 'com.emaratech.common.purge.queue.PurgeQueueMsgFlow.Get_Trans_Details_From_DB'. An exception has been thrown to cut short the processing of the message.
See the following messages for details of the error.
2014-07-15 12:49:18.009162 76064 RecoverableException BIP2488E: ('com.emaratech.common.purge.queue.PurgeQueueMsgFlow_Get_Trans_Details_From_DB.Main', '35.6') Error detected whilst executing the SQL statement ''PROPAGATE TO TERMINAL 'out' FINALIZE DEFAULT DELETE DEFAULT;''.
The message broker detected an error whilst executing the given statement. An exception has been thrown to cut short the SQL program.
See the following messages for details of the error.
2014-07-15 12:49:18.009176 76064 RecoverableException BIP2230E: Error detected whilst processing a message in node 'com.emaratech.common.purge.queue.PurgeQueueMsgFlow.Purge_Profile_Msg'.
The message broker detected an error whilst processing a message in node 'com.emaratech.common.purge.queue.PurgeQueueMsgFlow.Purge_Profile_Msg'. An exception has been thrown to cut short the processing of the message.
See the following messages for details of the error.
2014-07-15 12:49:18.009188 76064 RecoverableException BIP4633E: An error occurred whilst performing an MQGet node operation.
N/A.
See the following messages for information pertaining to this error.
2014-07-15 12:49:18.009198 76064 RecoverableException BIP2110E: Message broker internal program error.
An internal software error has occurred in the message broker. Further messages will indicate the effect of this error on the broker's transactions. There is no diagnostic information associated with this message
Shutdown and restart the message broker. If the problem continues to occur, then restart the system. If the problem still continues to occur contact your IBM support center.
2014-07-15 12:49:18.009536 76064 UserTrace BIP2638I: The MQ output node 'com.emaratech.common.purge.queue.PurgeQueueMsgFlow.MQ Output' attempted to write a message to queue ''VSN.QMGR.DLQ'' connected to queue manager ''''. The MQCC was '0' and the MQRC was '0'.
2014-07-15 12:49:18.009562 76064 UserTrace BIP2622I: Message successfully output by output node 'com.emaratech.common.purge.queue.PurgeQueueMsgFlow.MQ Output' to queue ''VSN.QMGR.DLQ'' on queue manager ''''. |
Regards,
Sarath |
|
| Back to top |
|
 |
| Vitor |
| Posted: Tue Jul 15, 2014 4:42 am Post subject: Re: Dymanically Setting Queue Name in MQGet Node |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sarathmattam wrote: |
| I am setting the queue name in OutputLocalEnvironment in Compute-1 node |
The software appears to disagree with you:
| sarathmattam wrote: |
| 2014-07-15 12:49:18.007854 76064 UserTrace BIP4635I: The MQ Get node 'com.emaratech.common.purge.queue.PurgeQueueMsgFlow.Purge_Profile_Msg' failed to navigate to the default location ''InputLocalEnvironment.MQ.GET.MQGMO'' for ''Input MQGMO Location (derived from Input MQ Parameters Location)''. |
So while you claim to be setting the queue name, and the trace confirms you're passing LocalEnvironment down the line, the MQGet node is not finding it. Time for a Trace node and a game of hunt the fat fingered mistake I think....
Certainly your method is sound & there's no technical reason it shouldn't work.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| sarathmattam |
| Posted: Tue Jul 15, 2014 11:01 pm Post subject: |
|
|
Voyager
Joined: 05 Sep 2008
Posts: 94
|
Hi Vitor, Thanks for your reply
I tried connecting a trace node between Compute-1 node and MQGet and I can see that the value is being passed to the MQGet node.
Also, If am not wrong, the line which you have quoted will appear in trace even if I am setting the queue name on the node level (not using LocalEnvironment). Because, when I tried by setting the queue name at the node, the node still checks the presence of MQGMO and if not found, it discards it. I believe this is expected behaviour. Please correct if my understanding is wrong.
Regards,
Sarath |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jul 16, 2014 5:01 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sarathmattam wrote: |
| I tried connecting a trace node between Compute-1 node and MQGet and I can see that the value is being passed to the MQGet node. |
That's good.
| sarathmattam wrote: |
| Also, If am not wrong, the line which you have quoted will appear in trace even if I am setting the queue name on the node level (not using LocalEnvironment). Because, when I tried by setting the queue name at the node, the node still checks the presence of MQGMO and if not found, it discards it. I believe this is expected behaviour. Please correct if my understanding is wrong. |
Quite correct - my point was that it's not finding it even though you claim (and have now apparently confirmed) that you're sending it. So there are 2 options:
- The queue name you supply is present in the LocalEnvironment but not at the location (which is case sensitive) that the node is looking at.
- There's a bug in the MQGet node.
A few moments reviewing your trace will confirm that the queue name is in exactly the correct path. Or not. From there your course of action will be clear.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| sarathmattam |
| Posted: Sat Jul 19, 2014 11:11 pm Post subject: |
|
|
Voyager
Joined: 05 Sep 2008
Posts: 94
|
| Thanks Vitor. Your option-1 did the trick. It was indeed a case mismatch. |
|
| 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
|
|
|
|
