| Author |
Message
|
| Armageddon123 |
 Posted: Tue Jul 14, 2015 8:53 am Post subject: Any method to perform trace on only one compute node in IIB. |
 |
|
Acolyte
Joined: 11 Feb 2014
Posts: 61
|
Hi
We have a large IIB9.0.0.2 flow. It is failing to retrieve values in middle of flow in one compute node . When i run the user trace or service trace, it is coming as very large file and unable to identify the issue.
Is there any option in trace command by which we can mention that the trace is needed only in one particular compute node so that we can see the trace for that part only?
Could not find any such option for mqsichangetrace command.
Thanks |
|
| Back to top |
|
 |
| Vitor |
| Posted: Tue Jul 14, 2015 9:21 am Post subject: Re: Any method to perform trace on only one compute node in |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Armageddon123 wrote: |
| Is there any option in trace command by which we can mention that the trace is needed only in one particular compute node so that we can see the trace for that part only? |
No.
I would put it to you that if the user trace is too large to be manageable for a single input, your flow is too big and could manage being subdivided. Not only will this make debugging easier, you might well see performance improvements from not having the entire process for one input single threaded. As a minimum, it's not best IBM advice:
| Quote: |
| The number and length of message flows have implications for performance, and it is important to keep the number of nodes to a minimum. |
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Jul 14, 2015 9:24 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Sorry, that link was IIBv10. This is the IIBv9 one.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| McueMart |
| Posted: Tue Jul 14, 2015 10:20 am Post subject: |
|
|
Chevalier
Joined: 29 Nov 2011
Posts: 490
Location: UK...somewhere
|
Either spend more time studying the UserTrace to track down your problem, or use the interactive debugger to pin-point the issue.
The UserTrace contains the compute node it is tracing as part of the output so surely it cant be *that* hard to find the issue? |
|
| Back to top |
|
|
| kimbert |
| Posted: Tue Jul 14, 2015 12:21 pm Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
I see no reason for any message flow developer to take a service trace, unless they have first tried user trace. It's not meant for users, it's for IBM service. User trace, on the other hand, is meant for users.
I agree that user trace is often far too verbose ( even if the flow is well designed ) but if you have a half-decent text editor that should not be a problem.
_________________
Before you criticize someone, walk a mile in their shoes. That way you're a mile away, and you have their shoes too. |
|
| Back to top |
|
|
| ganesh |
| Posted: Tue Jul 14, 2015 1:45 pm Post subject: |
|
|
Master
Joined: 18 Jul 2010
Posts: 294
|
| kimbert wrote: |
I see no reason for any message flow developer to take a service trace, unless they have first tried user trace. It's not meant for users, it's for IBM service. User trace, on the other hand, is meant for users.
|
I agree if you are debugging your code user trace will suffice but if you are troubleshooting issues related to authentication of user's then you would find such information in service trace.
Developers do have to troubleshoot authentication and other environment issues at times and they look at the service trace during troubleshooting. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Tue Jul 14, 2015 10:16 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| kimbert wrote: |
| but if you have a half-decent text editor that should not be a problem. |
This does not include Windows Notepad which should have been consigned to the rubbish bin years ago.
My editors of choice are Notepad++ (free) and UltraEdit (not free)
These have the advantage of detecting if the underlying file has been overwritten. so you can leave your usertrace file open in the application and when you run trace again it is easy to load the new output into the editor.
It may help you to insert some marker lines into the ESQL to help you locate the problem quicker. By this I mean something like this
| Code: |
declare cMarker1 CHAR '111111111111111111111111';
|
and then later
| Code: |
declare cMarker2 CHAR '222222222222222222222222';
|
Then you might find it quicker to 'zoom' into suspect areas in the usertrace output.
don't forget to remove them when done.
there are also some common BIP messages that could be used as search pointers. A little persistence on your part and I am sure that you will find the issue.
_________________
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 |
|
|
| Armageddon123 |
| Posted: Wed Jul 15, 2015 7:26 am Post subject: |
|
|
Acolyte
Joined: 11 Feb 2014
Posts: 61
|
|
| Back to top |
|
|
| ruimadaleno |
| Posted: Thu Jul 16, 2015 6:32 am Post subject: |
|
|
Master
Joined: 08 May 2014
Posts: 274
|
Can you modify the message flow ?
if yes, you can use trace nodes to debug the problem.
Use two trace nodes. Place one trace node before the "problematic" node and another trace node after the "problematic" node.
configure both trace nodes to write $root and inspect the values before and after the "problematic" node.
_________________
Best regards
Rui Madaleno |
|
| Back to top |
|
|
| kimbert |
| Posted: Thu Jul 16, 2015 11:26 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| if you are debugging your code user trace will suffice but if you are troubleshooting issues related to authentication of user's then you would find such information in service trace. |
I believe you. But that's a bug, not a reason for using service trace all the time.
_________________
Before you criticize someone, walk a mile in their shoes. That way you're a mile away, and you have their shoes too. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Jul 16, 2015 12:01 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| ganesh wrote: |
| I agree if you are debugging your code user trace will suffice but if you are troubleshooting issues related to authentication of user's then you would find such information in service trace. |
Under what circumstances? If there is a problem with (for example) database or web service (WS-Security) authentication then that shows up in the user trace. What kind of authentication problem is only visible in the service trace?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Jul 16, 2015 12:41 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Vitor wrote: |
| ganesh wrote: |
| I agree if you are debugging your code user trace will suffice but if you are troubleshooting issues related to authentication of user's then you would find such information in service trace. |
Under what circumstances? If there is a problem with (for example) database or web service (WS-Security) authentication then that shows up in the user trace. What kind of authentication problem is only visible in the service trace? |
I would think password used?
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Jul 16, 2015 1:30 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| fjb_saper wrote: |
| Vitor wrote: |
| ganesh wrote: |
| I agree if you are debugging your code user trace will suffice but if you are troubleshooting issues related to authentication of user's then you would find such information in service trace. |
Under what circumstances? If there is a problem with (for example) database or web service (WS-Security) authentication then that shows up in the user trace. What kind of authentication problem is only visible in the service trace? |
I would think password used? |
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| ganesh |
| Posted: Mon Jul 20, 2015 2:33 pm Post subject: |
|
|
Master
Joined: 18 Jul 2010
Posts: 294
|
| Vitor wrote: |
Under what circumstances? If there is a problem with (for example) database or web service (WS-Security) authentication then that shows up in the user trace. What kind of authentication problem is only visible in the service trace? |
User trace does not have much details about kerberos authentication issues, service trace has more. More information related to issues with keystore and truststore can be found in service trace and not in user trace. |
|
| Back to top |
|
|
| kimbert |
| Posted: Fri Jul 24, 2015 3:30 pm Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
My general point stands - don't use service trace for normal message flow debugging. User trace is designed for that. If user trace is not adequate for debugging authentication problems then that's a product defect, in my opinion.
_________________
Before you criticize someone, walk a mile in their shoes. That way you're a mile away, and you have their shoes too. |
|
| Back to top |
|
|
|
|
