| Author |
Message
|
| lancelotlinc |
 Posted: Wed Feb 13, 2013 8:15 am Post subject: |
 |
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| sree4vit wrote: |
| lancelotlinc wrote: |
| sree4vit wrote: |
| mqjeff wrote: |
and what does the -t flag mean?
It means "service trace". |
Apologies for mentioning the trace as user trace.
Now, Whichever trace it is, what's causing the broker write those lines? |
Each time ImbXMLNSCSyntaxElement::deleteXMLNSCValue() function is called, broker writes these lines in the file. |
And why would broker call ImbXMLNSCSyntaxElement::deleteXMLNSCValue() function each time? |
Because it is processing your messages.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Wed Feb 13, 2013 8:17 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| sree4vit wrote: |
| lancelotlinc wrote: |
| sree4vit wrote: |
| mqjeff wrote: |
and what does the -t flag mean?
It means "service trace". |
Apologies for mentioning the trace as user trace.
Now, Whichever trace it is, what's causing the broker write those lines? |
Each time ImbXMLNSCSyntaxElement::deleteXMLNSCValue() function is called, broker writes these lines in the file. |
And why would broker call ImbXMLNSCSyntaxElement::deleteXMLNSCValue() function each time? |
Because it deleted an XMLNSC value in some thread.
This is why you shouldn't read service trace. Because 95% of it is entirely meaningless to anyone outside of the lab.
I'll tell you something useful, though.
That number '4852' is the *thread* that is performing the action.
If that *thread* is not the same thread as your message flow is using.... IGNORE IT. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Feb 13, 2013 8:23 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
| This is why you shouldn't read service trace. Because 95% of it is entirely meaningless to anyone outside of the lab. |
| mqjeff wrote: |
| If that *thread* is not the same thread as your message flow is using.... IGNORE IT. |
Here's another question - what prompted you to issue an mqsichangetrace command? What issue are you trying to solve? What brought you to the conclusion a service trace was the option you needed?
Maybe there's a better way we can offer. Over and above suggesting user trace not service trace.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| kimbert |
| Posted: Wed Feb 13, 2013 8:39 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| This is why you shouldn't read service trace. Because 95% of it is entirely meaningless to anyone outside of the lab. |
I could not agree more.
IBM provides user trace as a high-level diagnostic tool for end users
IBM provides service trace as a low-level diagnostic tool for IBM service |
|
| Back to top |
|
|
| sree4vit |
| Posted: Thu Feb 14, 2013 2:35 am Post subject: |
|
|
Novice
Joined: 05 Aug 2010
Posts: 21
|
| mqjeff wrote: |
| sree4vit wrote: |
| lancelotlinc wrote: |
| sree4vit wrote: |
| mqjeff wrote: |
and what does the -t flag mean?
It means "service trace". |
Apologies for mentioning the trace as user trace.
Now, Whichever trace it is, what's causing the broker write those lines? |
Each time ImbXMLNSCSyntaxElement::deleteXMLNSCValue() function is called, broker writes these lines in the file. |
And why would broker call ImbXMLNSCSyntaxElement::deleteXMLNSCValue() function each time? |
Because it deleted an XMLNSC value in some thread.
This is why you shouldn't read service trace. Because 95% of it is entirely meaningless to anyone outside of the lab.
I'll tell you something useful, though.
That number '4852' is the *thread* that is performing the action.
If that *thread* is not the same thread as your message flow is using.... IGNORE IT. |
Some useful information indeed. Thanks Very much. |
|
| Back to top |
|
|
| sree4vit |
| Posted: Thu Feb 14, 2013 2:41 am Post subject: |
|
|
Novice
Joined: 05 Aug 2010
Posts: 21
|
| Vitor wrote: |
| mqjeff wrote: |
| This is why you shouldn't read service trace. Because 95% of it is entirely meaningless to anyone outside of the lab. |
| mqjeff wrote: |
| If that *thread* is not the same thread as your message flow is using.... IGNORE IT. |
Here's another question - what prompted you to issue an mqsichangetrace command? What issue are you trying to solve? What brought you to the conclusion a service trace was the option you needed?
Maybe there's a better way we can offer. Over and above suggesting user trace not service trace. |
Broker was creating abend files follwed by an EG shutdown while processing a huge XML data of around 10 Megs. Since my service had lot of Webservice calls and DB hits It was quite untraceble for me to find what/where it went wrong, So I had to go for Service trace. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Feb 14, 2013 4:17 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| sree4vit wrote: |
| Broker was creating abend files follwed by an EG shutdown while processing a huge XML data of around 10 Megs. Since my service had lot of Webservice calls and DB hits It was quite untraceble for me to find what/where it went wrong, So I had to go for Service trace. |
AHA.
Again, to the best of my knowledge, what you see represents the EG doing garbage collection on an XMLNSC tree.
I'd go further backwards in time from where you were in the trace output. See if you can correlate the time in the very earliest abend with an entry in the service trace, and then look backwards from there for some idea.
I'd also isolate the flow in question to it's own EG, and use the -c option on mqsichangetrace to be a very large number.
But also, this should have already been discussed with your IBM support representative through a PMR... |
|
| Back to top |
|
|
| kimbert |
| Posted: Thu Feb 14, 2013 4:49 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| Since my service had lot of Webservice calls and DB hits It was quite untraceble for me to find what/where it went wrong, So I had to go for Service trace. |
Did you actually try user trace? It should give you all the information that you ( as a user ) need. If it does not, then that's a valid reason for opening a PMR in itself.
But regardless of that, if your EG crashes without good diagnostics then IBM wants to know, so that we can fix it. Please open a PMR if you have not already done so. |
|
| Back to top |
|
|
|
|
