| Author |
Message
|
| Broady |
 Posted: Tue May 03, 2005 8:20 am Post subject: Migrated Message Flow(s) not playing ball |
 |
|
Novice
Joined: 16 Apr 2004
Posts: 23
Location: Halifax, West Yorkshire, England
|
We have migrated a large number of message flows from WMQI to WBIMB V5(CSD04) and are experiencing a number of problems. I have narrowed it down to the following scenario. I was wondering if other had seen this themselves and there is a simple solution.
If not, we will raise a PMR.
The Broker is running on AIX(V5.1) and the broker DB is Oracle9i.
The top level flow reasd the incoming message from as queue and based upon its contents does a route to label for further context specific processing. All so far is hunk-dory.
The label the message is routed to calls a number of sub flows in order. The problem lies i the processing within the first sub flow.
The input node is wired to a TryCatch with the catch terminal directed to the failure terminal of the subflow. The catch terminal is wired to a trace node which is wired to the input terminal of a compute node. The output terminal of the compute node is wired to a subflow followed by another subflow and thence to the output terminal. This is all pretty simple and straighforward. The main flow handles anout 10 different message types. All have the same processing methodology. The unique point is the processing within the compute node.
The processing on some message types work but other fail for a common reason. The relevant part of the trace log is shown below. This is pretty self explanatory.
The trace node 'PLUGGH_Trace' has output the specified
trace data.
This is an information message provided by the message flow designer.
The user response will be determined by the local environment.
2005-05-03 16:24:07.439926 6427 UserTrace BIP4067I: Message propagated to output terminal for trace no
de 'PLUGGH_Trace'.
The trace node 'PLUGGH_Trace' has received a message an
d is propagating it to any nodes connected to its output terminal.
No user action required.
2005-05-03 16:24:07.440391 6427 UserTrace BIP4124I: Message propagated to 'out' terminal of compute no
de 'ZORRO_xvert_XML_to_CC'.
{PLUGGH & ZORRO were chosen to make the nodes easy to find with grep}
The output of the trace node is passed to the output terminal of the compute node thus bypassing the processing within. This is NOT what is expected.
Any Ideas? or is it PMR time?
_________________
Alan Broadbent |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Tue May 03, 2005 8:25 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I'm missing what the problem is.
Trace nodes always complete successfully... (well, I guess if you are writing to a file and that file is not writeable it might throw an error).
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Broady |
| Posted: Tue May 03, 2005 8:41 am Post subject: The problem is... |
|
|
Novice
Joined: 16 Apr 2004
Posts: 23
Location: Halifax, West Yorkshire, England
|
The Trace node is wired to the input terminal of the compute node
BUT
The trace output says that the message is propagated from the out terminal of the compute node to the out terminal of the compute node thus bypassing the processing of the message within the compute node. The flow then blows up in the subsequent processing as things like the messageSet name etc have not been setup. The error we see is as follows:-
May 3 17:01:24 zaphod MQSIv500[1974428]: (AIXBRKR_Services_01a)[6427]BIP2232E: Error detected whilst handling a previous error in node 'Seller_Update.DestinationList'. : AIXBRKR.0f21d7a2-0301-0000-0080-ca320b751785: /build/S500_P/src/DataFlowEngine/ImbDataFlowNode.cpp: 387: ImbDataFlowNode::logExceptionList: ComIbmMQOutputNode: Seller_Update#FCMComposite_1_49.SYS_PROC_FLOW_SEND_ERR_TO_TERM_PT_SUB#FCMComposite_1_2
May 3 17:01:24 zaphod MQSIv500[1974428]: (AIXBRKR.ZZ_Services_01a)[6427]BIP2230E: Error detected whilst processing a message in node 'Seller_Update.PASS_THRU.OUT'. : AIXBRKR.0f21d7a2-0301-0000-0080-ca320b751785: /build/S500_P/src/DataFlowEngine/ImbDataFlowNode.cpp: 558: ImbDataFlowNode::createExceptionList: ComIbmMQOutputNode: Seller_Update#FCMComposite_1_51
May 3 17:01:24 zaphod MQSIv500[1974428]: (AIXBRKR.ZZ_Services_01a)[6427]BIP5304E: Resource Manager: Dictionary not found for message set NULL. : AIXBRKR.0f21d7a2-0301-0000-0080-ca320b751785: /build/S500_P/src/MTI/MTIforBroker/MtiImbParser2/MtiImbRMErrorMap.cpp: 163: MtiImbRMErrorMap::checkRC: :
_________________
Alan Broadbent |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue May 03, 2005 9:17 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
A trace node has no impact on any nodes downstream of it - except in the rare case where it throws an error.
I strongly suspect that you have a logic flaw in the compute node, if it is going to the output where it shouldn't be.
Also, your original flow description is a little muddled. Everything appears to come off of the catch terminal of the try/catch node - where I suspect that the trace node et al are off the Try terminal.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Broady |
| Posted: Wed May 04, 2005 4:27 am Post subject: Next Attempt |
|
|
Novice
Joined: 16 Apr 2004
Posts: 23
Location: Halifax, West Yorkshire, England
|
We modified the ESQL to just copy the whole message flow in the way that WBIMB dows it. Everything was commented out. Still the message is propagated from the out terminal of the trace node to the out terminal of the compute node. So, IMHO there is something else going wrong.
A PMR will be raised today.
_________________
Alan Broadbent |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed May 04, 2005 4:35 am Post subject: Re: Next Attempt |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Okay.
I think I understand what you're saying now.
Try deleting the compute node and re adding it.
I still suspect you have something wrong in your .esql file - that is causing the compute node to short circuit.
What happens when you right click on the node and say "Show ESQL", or whatever it's called?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Broady |
| Posted: Wed May 04, 2005 10:52 pm Post subject: Been there done that |
|
|
Novice
Joined: 16 Apr 2004
Posts: 23
Location: Halifax, West Yorkshire, England
|
Jeff,
We have tried that one. Opening the ESQL file via the compute node works fine. I have even tried shortening the name in case that was a problem.
I have even replaced the whole subflow that contains the errant compute node with one developed totally under WBIMB. Still the same results.
I even enabled usertrace and then deployed the flow. At the top it showed how the broker was wiring up the nodes. This all matches the connections detailed in the xml of the message flow.
Very Strange behaviour.
The PMR has been submitted.
_________________
Alan Broadbent |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu May 05, 2005 3:04 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Did you check the ESQL for bad line endings and non-printable characters? Are you *sure* it's not a logic flaw?
Well.
At least keep us posted on the PMR.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Broady |
| Posted: Sun May 08, 2005 11:39 am Post subject: An Update |
|
|
Novice
Joined: 16 Apr 2004
Posts: 23
Location: Halifax, West Yorkshire, England
|
It is possible that there are/were some rogue characters in the esql module. The GUI bar file creator did not object to them however some other work we were doing with command line bar file creation has brought to light that some modules (that did work by the way) had non visible characters in the esql files.
The mqsicreatebar command seemingly objects to esql files with these non printable characters.
I examined the files with ultraedit and it seem there is a ctrl/M at the end of most lines in thes files.
After removing them, the command line bar file creation was able to work properly. This may or may not be a red herring though as even with the files edited, the project rebuilt and bar file deployed, the actual processing propagates from the out terminal of the trace node to the out terminal of the compute node.
The esql file contains two modules. One for the compute node and the other for a filter node. Selecting "Open Esql" from the flow designer takes the gui to the correct part of the esql file so the linkage is correct.
So far we are no further forward in finding why the flow processing skips the compute node.
_________________
Alan Broadbent |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sun May 08, 2005 2:49 pm Post subject: Re: An Update |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Broady wrote: |
....
I examined the files with ultraedit and it seem there is a ctrl/M at the end of most lines in thes files.
... |
Looks to me like a CR/LF in ASCII that's being displayed in a Unix Environment after a binary file transfer.
I never saw it as any problem in jar files containing source code when I had to view the source code in debug...
Enjoy  |
|
| Back to top |
|
|
| Broady |
| Posted: Fri Jun 03, 2005 3:07 am Post subject: Bypassing compute node |
|
|
Novice
Joined: 16 Apr 2004
Posts: 23
Location: Halifax, West Yorkshire, England
|
We have an answer.
This has occurred whenever a flow name and the node name produce a module name in the eclipse tool that has reached a certain limit. Not sure what that limit is, but 50 bytes seems to cause this problem.
During migration the default for module names is this simple concatenation, but of course if one develops from scratch then one can choose an abbreviated name for the module.
The module name though too long is still displayed fully. It is only at run time that it was deemed a problem.
We shortened the name of the flow in this case and then it worked.
Thanks everyone for your help.
_________________
Alan Broadbent |
|
| Back to top |
|
|
| JT |
| Posted: Fri Jun 03, 2005 7:46 am Post subject: |
|
|
Padawan
Joined: 27 Mar 2003
Posts: 1564
Location: Hartford, CT.
|
| Quote: |
| This has occurred whenever a flow name and the node name produce a module name in the eclipse tool that has reached a certain limit. Not sure what that limit is, but 50 bytes seems to cause this problem. |
It's actually a combination of the ESQL file path, ESQL module names, and procedure names that must total less than 256 (the size limitation Windows imposes for file names).
In addition to reducing the length of the module and procedure names, you can change the size of the ESQL file path, i.e. C:/MYESQL rather than C:\Program Files\IBM\WebSphere Business Integration Message Brokers\eclipse |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Jun 03, 2005 7:52 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
This is one reason I always install in c:\IBM\WBIMB.
And also one reason why I always use the -data to change my workspace to somewhere other than <install_dir>/eclipse/workspace.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
|
|
