| Author |
Message
|
| hotshot |
 Posted: Mon Dec 07, 2015 5:26 pm Post subject: Exception handling and JavaComputeNode behaviour |
 |
|
Novice
Joined: 04 Jan 2013
Posts: 20
|
Hi guys,
I would like to get some advice on how you've done error investigation and error handling for flows which mix both java and esql code.
Here's my scenario. I have a message flow with the following structure:
| Code: |
| MQInput - > Compute Node -> Java Compute Node -> Compute Node -> MQOutput |
The MQInput's catch and failure terminals are connected to some generic subflows which perform basic error handling (logging/alerting) and provide basic root cause analysis before writing to log queues/files.
The JCN uses a couple of Java classes (io classes) which might throw exceptions. This requires for me to do some sort of error handling within Java. So I just catch any exception and re-throw the string of the exception further as an user exception.
I am running a test where I can see (from the user trace and debugger) that the flow reaches the second compute node -> MQOutput and throws an exception, but what I get in the actual ExceptionList in the JCN is not very informative: I get a BIPMSG 2230 error which mentions:
| Quote: |
| JNI method: IbmMqOutputNode |
So it basically seems to tell me the MQOutput node is throwing the exception but close to nothing about the cause.
Questions:
What can I do to get the actual error thrown by the MQOutputNode? It seems that the JCN catch gets less information than I would normally get off the MQInput's catch terminal.
Is there a way to bypass the need to perform the JCN error handling? Seems like a stupid question, but I'll ask anyway.
Is there some automated transformation done from the "normal" ExceptionList tree to what I get in the JCN catch?
Environment: WMB 8.0.0.6, WMQ 7.5.0.5 on RHEL 6.5 (Santiago)
Cheers,
B |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Tue Dec 08, 2015 5:30 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Well, you're not hitting a UserException. You may really want to look at what you do with the Exception Tree in that case. One other possibility is to run the flow with user trace level.
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| joebuckeye |
| Posted: Tue Dec 08, 2015 5:59 am Post subject: Re: Exception handling and JavaComputeNode behaviour |
|
|
Partisan
Joined: 24 Aug 2007
Posts: 365
Location: Columbus, OH
|
| hotshot wrote: |
| The JCN uses a couple of Java classes (io classes) which might throw exceptions. |
This is a red flag to me.
Why are you performing I/O operations inside a JCN when the broker has numerous nodes for handling I/O? |
|
| Back to top |
|
|
| mgk |
| Posted: Tue Dec 08, 2015 9:17 am Post subject: |
|
|
Padawan
Joined: 31 Jul 2003
Posts: 1642
|
| Quote: |
| Is there a way to bypass the need to perform the JCN error handling? Seems like a stupid question, but I'll ask anyway |
This is not stupid - it's correct! I would encourage you to put the propagate call outside your try/catch block. That way, you only catch exceptions that happen in your node which are under your control but do not catch exceptions from downstream nodes. This way, broker can handle the exception for you automatically...
Kind regards,
_________________
MGK
The postings I make on this site are my own and don't necessarily represent IBM's positions, strategies or opinions. |
|
| Back to top |
|
|
| hotshot |
| Posted: Tue Dec 08, 2015 4:40 pm Post subject: |
|
|
Novice
Joined: 04 Jan 2013
Posts: 20
|
Thanks for all of your replies.
| Quote: |
| You may really want to look at what you do with the Exception Tree in that case. One other possibility is to run the flow with user trace level. |
Most flows use a common exception handling mechanism which sits in subflows connected to the input nodes' catch/failure terminals. I would prefer avoiding going through the exception tree as much as possible.
I have taken a user trace and it doesn't give out any more details than what I've already shared (JNI method: IbmMqOutput).
| Quote: |
| Why are you performing I/O operations inside a JCN when the broker has numerous nodes for handling I/O? |
I use the process builder class to call an external program and the buffered reader class to read its output. I would prefer to use standard nodes if possible so I'm open to suggestions.
| Quote: |
| I would encourage you to put the propagate call outside your try/catch block. |
I actually tried it but the exception handler caught it anyway. Or maybe I wasn't paying enough attention when stepping with the debugger. Will have another go at it tomorrow to see if this works for me. It seems like a simple enough solution which gives me what I was after. |
|
| Back to top |
|
|
| timber |
| Posted: Wed Dec 09, 2015 12:08 am Post subject: |
|
|
Grand Master
Joined: 25 Aug 2015
Posts: 1292
|
mgk's suggestion is spot-on. I recommend that you follow up on that one. Try disconnecting the debugger; it's just about possible that it is altering the exception handling behaviour of the message flow ( although I think most of those issues were solved back in v6 ).
I agree with joebuckeye's comment about the I/O. But if you want suggestions from the forum then you will need to explain what the flow is actually doing. |
|
| Back to top |
|
|
| hotshot |
| Posted: Wed Dec 09, 2015 4:04 am Post subject: |
|
|
Novice
Joined: 04 Jan 2013
Posts: 20
|
Tried the proposed approach and moving the propagate outside the try-catch block worked. I can now properly see the MQOutput throwing a Parsing error (MQ headers were incorrect).
I actually received another suggestion to catch only InterruptedException and IOException types which is what the java classes can throw. It also worked fine.
Thanks for all of your replies  |
|
| Back to top |
|
|
| timber |
| Posted: Wed Dec 09, 2015 6:12 am Post subject: |
|
|
Grand Master
Joined: 25 Aug 2015
Posts: 1292
|
Glad it's working.
I'm still interested in that JCN calling out to an external program. Presumably, the external program does some difficult stuff and writes a file containing its output. Then you read it back into the message tree. And the entire process happens during the execution of the evaluate() method in the JCN.
Is that roughly correct? |
|
| Back to top |
|
|
| hotshot |
| Posted: Thu Dec 10, 2015 4:17 pm Post subject: |
|
|
Novice
Joined: 04 Jan 2013
Posts: 20
|
That's roughly the picture. I have no actual file being written and read, though:
| Code: |
ProcessBuilder builder = new ProcessBuilder ("some program");
builder.redirectErrorStream(true);
BufferedReader reader = new BufferedReader(new InputStreamReader(proc.getInputStream()));
OutputStream outputStream = proc.getOutputStream();
BufferedWriter writer = new BufferedWriter(new OutputStreamWriter(outputStream));
writer.write("some command to be executed in the program");
|
|
|
| Back to top |
|
|
| smdavies99 |
| Posted: Fri Dec 11, 2015 8:47 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
So you are replicating/reinventing the features/functionality of the Job Control Node support pack then?
See my sig
_________________
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 |
|
|
| hotshot |
| Posted: Sun Dec 13, 2015 6:35 am Post subject: |
|
|
Novice
Joined: 04 Jan 2013
Posts: 20
|
I wholeheartedly agree with your signature. Will have a look at the support pac. I assume you're referring to IA9Z.
Thanks. |
|
| Back to top |
|
|
|
|
