You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@axis.apache.org by ji...@apache.org on 2004/06/17 11:35:09 UTC
[jira] Created: (AXISCPP-100) enable axis c++ (engine) tracing
Message:
A new issue has been created in JIRA.
---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/AXISCPP-100
Here is an overview of the issue:
---------------------------------------------------------------------
Key: AXISCPP-100
Summary: enable axis c++ (engine) tracing
Type: Wish
Status: Unassigned
Priority: Major
Project: Axis-C++
Versions:
future (enh)
Assignee:
Reporter: Aleksander Slominski
Created: Thu, 17 Jun 2004 2:33 AM
Updated: Thu, 17 Jun 2004 2:33 AM
Environment: ALL
Description:
i think it would be good to have some kind of tracing/logging compiled into binary that could be triggered by setting environment variable (for example AXISCPP_TRACE=engine:ALL).
it would be very useful tool when debugging such problems like wrong SOAPAction to see if engine received request and see where did it go and why it was rejected.
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Closed: (AXISCPP-100) enable axis c++ (engine) tracing
Posted by "nadir amra (JIRA)" <ax...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/AXISCPP-100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
nadir amra closed AXISCPP-100.
------------------------------
Resolution: Fixed
Fix Version/s: current (nightly)
OK, finally got this done. Tracing is now integrated in the code so that only one binary is needed when we put out a release. I have also disabled and removed the previous support in which a tool was used to dynamically produce source with a trace points. That was kludgy and introduced complexity when trying to do tracing of the xml parser and transport, and channels. It is much cleaner now. Here is the information on the support.
To enable tracing, simply set one of ClientLogPath or LogPath (for server logging) to the path of the trace file in the axiscpp.conf file. With this support, a new configuration variable, LogFilter, can be set to filter the trace records so you can isolate a component. The filter is a semicolon delimited string of possible filters. Possible filters include:
* stub - show trace records generated by stubs
* engine - show trace records generated by engine
* parser - show trace records generated by parser
* transport - show trace records generated by transport
* noEntryExit - do not show entry/exit trace records
The default filter is "stub;engine;parser;transport". So, for example, if I wanted to enable client trace and show only transport trace records and no entry/exit trace records, then the following would need to be specified:
> enable axis c++ (engine) tracing
> --------------------------------
>
> Key: AXISCPP-100
> URL: https://issues.apache.org/jira/browse/AXISCPP-100
> Project: Axis-C++
> Issue Type: Wish
> Components: Trace Utility
> Affects Versions: future (enh)
> Environment: ALL
> Reporter: Aleksander Slominski
> Fix For: current (nightly)
>
>
> i think it would be good to have some kind of tracing/logging compiled into binary that could be triggered by setting environment variable (for example AXISCPP_TRACE=engine:ALL).
> it would be very useful tool when debugging such problems like wrong SOAPAction to see if engine received request and see where did it go and why it was rejected.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
[jira] Commented: (AXISCPP-100) enable axis c++ (engine) tracing
Posted by "John Hawkins (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXISCPP-100?page=comments#action_58151 ]
John Hawkins commented on AXISCPP-100:
--------------------------------------
We have the trace tooling which adds in entry and exit trace to MOST methods on-the-fly in the build process (ANT build only) (using an AOSD approach where we parse the file looking for entry and exit points). I looked into using C OASD and frankly it wasn't up to the job (July 2004). I got the impression that we'd struggle to compile it on many platforms as well.
We have found this extremely useful in debugging problems. It puts out what methods you are entering and exiting from but also parameter details. If an AxisException is thrown then a lot of information goes into the log too. Thread info is also put out (or will be soon!)
By default this trace is off and needs a compile time flag to turn it on.
The trace is being output (as of tomorrow) in an IBM format that can be viewed with a free viewer from alphaworks http://alphaworks.ibm.com/tech/ta4was However, it is also fairly easy to read by a human without the reader.
However, having said all that. I would like to also do what is called FFDC (First Failure Data Capture) which means that when we catch an exception we output a file for later diagnostics. The advantage being that you don't have to ask the user to rerun with trace on as you should have lots of information in the output file.
Having said all that. This defect was to do with general trace and not necessarily entry and exit. We already have this API in the code it's just that it is not used much :-)
I would like to move to a more well known Opensource trace package (LOG4C) in a future release as most of what we have written is bespoke. ICU4C is based on a well known trace package LOG4J which has the requested trace levels in this issue. But, as there is so little trace in the code, I don't see the point in worrying too much about levels at this point.
> enable axis c++ (engine) tracing
> --------------------------------
>
> Key: AXISCPP-100
> URL: http://issues.apache.org/jira/browse/AXISCPP-100
> Project: Axis-C++
> Type: Wish
> Versions: future (enh)
> Environment: ALL
> Reporter: Aleksander Slominski
>
> i think it would be good to have some kind of tracing/logging compiled into binary that could be triggered by setting environment variable (for example AXISCPP_TRACE=engine:ALL).
> it would be very useful tool when debugging such problems like wrong SOAPAction to see if engine received request and see where did it go and why it was rejected.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Commented: (AXISCPP-100) enable axis c++ (engine) tracing
Posted by "Samisa Abeysinghe (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXISCPP-100?page=comments#action_58285 ]
Samisa Abeysinghe commented on AXISCPP-100:
-------------------------------------------
Nadir Amra :
This is something that is needed. I realize there is a way to incorporate
tracing tool to do debugging, but I think we need something that is in the
code without a need to use the tool, and that is activated by a
configuration file switch. It is on my todo list to use the trace class
(and enhance it) so that there is a global trace object that can be called
by all parts of axis. This class will have methods to dump put entry/exit
and various other objects.
John also mentions ffdc, or maybe an eventlog, to write out serious errors
(on unix maybe it would go to syslog, etc.). Another thing on my list.
Lots of work, but I will get this in, one way or another!
> enable axis c++ (engine) tracing
> --------------------------------
>
> Key: AXISCPP-100
> URL: http://issues.apache.org/jira/browse/AXISCPP-100
> Project: Axis-C++
> Type: Wish
> Versions: future (enh)
> Environment: ALL
> Reporter: Aleksander Slominski
>
> i think it would be good to have some kind of tracing/logging compiled into binary that could be triggered by setting environment variable (for example AXISCPP_TRACE=engine:ALL).
> it would be very useful tool when debugging such problems like wrong SOAPAction to see if engine received request and see where did it go and why it was rejected.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Commented: (AXISCPP-100) enable axis c++ (engine) tracing
Posted by ax...@ws.apache.org.
The following comment has been added to this issue:
Author: Aleksander Slominski
Created: Fri, 15 Oct 2004 6:06 PM
Body:
i was looking for a way to control different levels of tracing/debugging messages for different modules of AXIS so for example so i could see what happens when SOAP message is routed or deserialized. seeing lot of enrty/exit procedure calls may be very difficult to grok ...
best if it can be enabled/disabled in running application - web admin interface to AXIS C++?
---------------------------------------------------------------------
View this comment:
http://issues.apache.org/jira/browse/AXISCPP-100?page=comments#action_54234
---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/AXISCPP-100
Here is an overview of the issue:
---------------------------------------------------------------------
Key: AXISCPP-100
Summary: enable axis c++ (engine) tracing
Type: Wish
Status: Unassigned
Priority: Major
Project: Axis-C++
Versions:
future (enh)
Assignee:
Reporter: Aleksander Slominski
Created: Thu, 17 Jun 2004 2:33 AM
Updated: Fri, 15 Oct 2004 6:06 PM
Environment: ALL
Description:
i think it would be good to have some kind of tracing/logging compiled into binary that could be triggered by setting environment variable (for example AXISCPP_TRACE=engine:ALL).
it would be very useful tool when debugging such problems like wrong SOAPAction to see if engine received request and see where did it go and why it was rejected.
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Commented: (AXISCPP-100) enable axis c++ (engine) tracing
Posted by "Samisa Abeysinghe (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXISCPP-100?page=comments#action_58286 ]
Samisa Abeysinghe commented on AXISCPP-100:
-------------------------------------------
John Hawkins :
Tracing is configurable currently, if you do not set the CLIENTLOGPATH in the axiscpp then you do not get *any* trace. However, for a server this would be no good :-)
> enable axis c++ (engine) tracing
> --------------------------------
>
> Key: AXISCPP-100
> URL: http://issues.apache.org/jira/browse/AXISCPP-100
> Project: Axis-C++
> Type: Wish
> Versions: future (enh)
> Environment: ALL
> Reporter: Aleksander Slominski
>
> i think it would be good to have some kind of tracing/logging compiled into binary that could be triggered by setting environment variable (for example AXISCPP_TRACE=engine:ALL).
> it would be very useful tool when debugging such problems like wrong SOAPAction to see if engine received request and see where did it go and why it was rejected.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (AXISCPP-100) enable axis c++ (engine)
tracing
Posted by "nadir amra (JIRA)" <ax...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/AXISCPP-100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12647434#action_12647434 ]
nadiramra edited comment on AXISCPP-100 at 11/13/08 2:52 PM:
--------------------------------------------------------------
OK, finally got this done. Tracing is now integrated in the code so that only one binary is needed when we put out a release. I have also disabled and removed the previous support in which a tool was used to dynamically produce source with a trace points. That was kludgy and introduced complexity when trying to do tracing of the xml parser and transport, and channels. It is much cleaner now. Here is the information on the support.
To enable tracing, simply set one of ClientLogPath or LogPath (for server logging) to the path of the trace file in the axiscpp.conf file. With this support, a new configuration variable, LogFilter, can be set to filter the trace records so you can isolate a component. The filter is a semicolon delimited string of possible filters. Possible filters include:
* stub - show trace records generated by stubs
* engine - show trace records generated by engine
* parser - show trace records generated by parser
* transport - show trace records generated by transport
* noEntryExit - do not show entry/exit trace records
The default filter is "stub;engine;parser;transport". So, for example, if I wanted to enable client trace and show only transport trace records and no entry/exit trace records, then the following would need to be specified:
ClientLogPath: /tmp/axis.log
LogFilter:transport;noEntryExit;
That it. In addition, I added methods to Axis class:
static int startTrace(const char* logFilePath, const char *logFilter=NULL);
static void stopTrace();
static void writeTrace(const char* functionName, const char * fmt, ...);
So one can programmatically enable trace and write to the trace (this will allow stub tracing in the future if we choose to add it). More information is in the header file Axis.hpp.
Internally, I completely rewrote the AxisTrace class and added a slew of macro to make adding trace points in the code very simple to do and elegant on the eyes. For example, Trace entry and exit is simply done with the following macros:
logEntryEngine("BasicTypeSerializer::BasicTypeSerializer")
logExit()
That it. The checks to determine whether trace is active is an inlined function that checks a boolean, so performance should not be a consideration. In addition, the check is done once within a method or function.
I do not trace parameters unless I fealt there is a need to. However, currently, I do trace anything that is returned by a method or function via the following macros:
#define logExit()
#define logExitWithReturnCode(lRC)
#define logExitWithInteger(lint)
#define logExitWithPointer(lPointer)
#define logExitWithString(lString)
#define logExitWithBoolean(lBoolean)
#define logExitWithMessage(lfmt)
A typical trace record will look like the following (following are entry exit trace records)
[13/11/2008 15:55:55:509] 00007860 transport > HTTPTransport::processHTTPHeader():
[13/11/2008 15:55:55:510] 00007860 transport < HTTPTransport::processHTTPHeader():
It includes a timestamp, a thread ID, the component that is doing the trace, a one character field indicating Trace type:
* > (entry)
* < (exit)
* X (exception)
* D (debug)
and the method/function name. After which there will be additional trace data.
With tracing enabled, you will know exactly where an exception is being thrown from. A typical trace record for when an exception is thrown is as follows:
[13/11/2008 15:55:55:510] 00007860 transport X HTTPTransport::readHTTPHeader(): Line=1851: File=/home/amra/axis/L1.1.0/src/ws-axis/c/src/transport/axis3/HTTPTransport.cpp:
HTTPTransportException - SERVER_TRANSPORT_HTTP_EXCEPTION: Server sent HTTP error: 'Not Found'
And finally, you can dump out the request/response messages by enabling transport trace. Here is a sample:
[13/11/2008 15:55:55:280] 00007860 transport D HTTPChannel::writeBytes():
POST /axis HTTP/1.1
Host: 127.0.0.1:13260
Content-Type: text/xml; charset=UTF-8
SOAPAction: ""
Content-Length: 393
[13/11/2008 15:55:55:280] 00007860 transport < HTTPChannel::writeBytes(): Exit with integer value of 122
[13/11/2008 15:55:55:281] 00007860 transport > HTTPChannel::writeBytes():
[13/11/2008 15:55:55:282] 00007860 transport D HTTPChannel::writeBytes():
<?xml version='1.0' encoding='utf-8' ?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<SOAP-ENV:Body>
<ns1:div xmlns:ns1="http://soapinterop.org/wsdl">
<ns1:arg_0_0>10</ns1:arg_0_0>
<ns1:arg_1_0>5</ns1:arg_1_0>
</ns1:div>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
.
.
.
[13/11/2008 15:55:55:508] 00007860 transport D HTTPChannel::readBytes():
HTTP/1.1 404 Not Found
Server: WebSphere Application Server/5.1
Content-Type: text/html;charset=UTF-8
Content-Language: en-GB
Transfer-Encoding: chunked
21
Error 404: File not found: null 0
[13/11/2008 15:55:55:509] 00007860 transport < HTTPChannel::readBytes(): Exit with integer value of 203
This support has been put in CMVC under the following SVN revisions:
For visual C++ files: http://svn.apache.org/viewvc?view=rev&revision=713844
For external include files and build xml files: http://svn.apache.org/viewvc?view=rev&revision=713843
For engine. parser, transport, channel files: http://svn.apache.org/viewvc?view=rev&revision=713841
was (Author: nadiramra):
OK, finally got this done. Tracing is now integrated in the code so that only one binary is needed when we put out a release. I have also disabled and removed the previous support in which a tool was used to dynamically produce source with a trace points. That was kludgy and introduced complexity when trying to do tracing of the xml parser and transport, and channels. It is much cleaner now. Here is the information on the support.
To enable tracing, simply set one of ClientLogPath or LogPath (for server logging) to the path of the trace file in the axiscpp.conf file. With this support, a new configuration variable, LogFilter, can be set to filter the trace records so you can isolate a component. The filter is a semicolon delimited string of possible filters. Possible filters include:
* stub - show trace records generated by stubs
* engine - show trace records generated by engine
* parser - show trace records generated by parser
* transport - show trace records generated by transport
* noEntryExit - do not show entry/exit trace records
The default filter is "stub;engine;parser;transport". So, for example, if I wanted to enable client trace and show only transport trace records and no entry/exit trace records, then the following would need to be specified:
> enable axis c++ (engine) tracing
> --------------------------------
>
> Key: AXISCPP-100
> URL: https://issues.apache.org/jira/browse/AXISCPP-100
> Project: Axis-C++
> Issue Type: Wish
> Components: Trace Utility
> Affects Versions: future (enh)
> Environment: ALL
> Reporter: Aleksander Slominski
> Fix For: current (nightly)
>
>
> i think it would be good to have some kind of tracing/logging compiled into binary that could be triggered by setting environment variable (for example AXISCPP_TRACE=engine:ALL).
> it would be very useful tool when debugging such problems like wrong SOAPAction to see if engine received request and see where did it go and why it was rejected.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
[jira] Commented: (AXISCPP-100) enable axis c++ (engine) tracing
Posted by "Samisa Abeysinghe (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXISCPP-100?page=comments#action_58287 ]
Samisa Abeysinghe commented on AXISCPP-100:
-------------------------------------------
IMHO FFDC is going to be very useful. Because, as of now, it takes whole lot of effort to get to know the real reasons fo failure. More than for client side, this would make lot of sense on server side
LOG4C - good idea, but would have to have a POC to evaluate feasibility. Specially thread safety etc. (Going by the experiances with LibWWW :) )
> enable axis c++ (engine) tracing
> --------------------------------
>
> Key: AXISCPP-100
> URL: http://issues.apache.org/jira/browse/AXISCPP-100
> Project: Axis-C++
> Type: Wish
> Versions: future (enh)
> Environment: ALL
> Reporter: Aleksander Slominski
>
> i think it would be good to have some kind of tracing/logging compiled into binary that could be triggered by setting environment variable (for example AXISCPP_TRACE=engine:ALL).
> it would be very useful tool when debugging such problems like wrong SOAPAction to see if engine received request and see where did it go and why it was rejected.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Updated: (AXISCPP-100) enable axis c++ (engine) tracing
Posted by "nadir amra (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXISCPP-100?page=all ]
nadir amra updated AXISCPP-100:
-------------------------------
Component/s: Trace Utility
> enable axis c++ (engine) tracing
> --------------------------------
>
> Key: AXISCPP-100
> URL: http://issues.apache.org/jira/browse/AXISCPP-100
> Project: Axis-C++
> Issue Type: Wish
> Components: Trace Utility
> Affects Versions: future (enh)
> Environment: ALL
> Reporter: Aleksander Slominski
>
> i think it would be good to have some kind of tracing/logging compiled into binary that could be triggered by setting environment variable (for example AXISCPP_TRACE=engine:ALL).
> it would be very useful tool when debugging such problems like wrong SOAPAction to see if engine received request and see where did it go and why it was rejected.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
[jira] Commented: (AXISCPP-100) enable axis c++ (engine) tracing
Posted by ax...@ws.apache.org.
The following comment has been added to this issue:
Author: John Hawkins
Created: Fri, 15 Oct 2004 3:55 AM
Body:
We ahve now have entry and exit trace. I suggest that this is the first step. Is this request for something more specific?
---------------------------------------------------------------------
View this comment:
http://issues.apache.org/jira/browse/AXISCPP-100?page=comments#action_54168
---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/AXISCPP-100
Here is an overview of the issue:
---------------------------------------------------------------------
Key: AXISCPP-100
Summary: enable axis c++ (engine) tracing
Type: Wish
Status: Unassigned
Priority: Major
Project: Axis-C++
Versions:
future (enh)
Assignee:
Reporter: Aleksander Slominski
Created: Thu, 17 Jun 2004 2:33 AM
Updated: Fri, 15 Oct 2004 3:55 AM
Environment: ALL
Description:
i think it would be good to have some kind of tracing/logging compiled into binary that could be triggered by setting environment variable (for example AXISCPP_TRACE=engine:ALL).
it would be very useful tool when debugging such problems like wrong SOAPAction to see if engine received request and see where did it go and why it was rejected.
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (AXISCPP-100) enable axis c++ (engine)
tracing
Posted by "nadir amra (JIRA)" <ax...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/AXISCPP-100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12647434#action_12647434 ]
nadiramra edited comment on AXISCPP-100 at 11/20/08 2:16 PM:
--------------------------------------------------------------
OK, finally got this done. Tracing is now integrated in the code so that only one binary is needed when we put out a release. I have also disabled and removed the previous support in which a tool was used to dynamically produce source with a trace points. That was kludgy and introduced complexity when trying to do tracing of the xml parser and transport, and channels. It is much cleaner now. Here is the information on the support.
To enable tracing, simply set one of ClientLogPath or LogPath (for server logging) to the path of the trace file in the axiscpp.conf file. With this support, a new configuration variable, LogFilter, can be set to filter the trace records so you can isolate a component. The filter is a semicolon delimited string of possible filters. Possible filters include:
* stub - show trace records generated by stubs
* engine - show trace records generated by engine
* parser - show trace records generated by parser
* transport - show trace records generated by transport
* noEntryExit - do not show entry/exit trace records
The default filter is "stub;engine;parser;transport". So, for example, if I wanted to enable client trace and show only transport trace records and no entry/exit trace records, then the following would need to be specified:
ClientLogPath: /tmp/axis.log
LogFilter:transport;noEntryExit;
That it. In addition, I added methods to Axis class:
static int startTrace(const char* logFilePath, const char *logFilter=NULL);
static void stopTrace();
static void writeTrace(AXIS_TRACE_TYPE type, const char* functionName, const char * fmt, ...);
So one can programmatically enable trace and write to the trace (this will allow stub tracing in the future if we choose to add it). More information is in the header file Axis.hpp.
Internally, I completely rewrote the AxisTrace class and added a slew of macro to make adding trace points in the code very simple to do and elegant on the eyes. For example, Trace entry and exit is simply done with the following macros:
logEntryEngine("BasicTypeSerializer::BasicTypeSerializer")
logExit()
That it. The checks to determine whether trace is active is an inlined function that checks a boolean, so performance should not be a consideration. In addition, the check is done once within a method or function.
I do not trace parameters unless I fealt there is a need to. However, currently, I do trace anything that is returned by a method or function via the following macros:
#define logExit()
#define logExitWithReturnCode(lRC)
#define logExitWithInteger(lint)
#define logExitWithPointer(lPointer)
#define logExitWithString(lString)
#define logExitWithBoolean(lBoolean)
#define logExitWithMessage(lfmt)
A typical trace record will look like the following (following are entry exit trace records)
[13/11/2008 15:55:55:509] 00007860 transport > HTTPTransport::processHTTPHeader():
[13/11/2008 15:55:55:510] 00007860 transport < HTTPTransport::processHTTPHeader():
It includes a timestamp, a thread ID, the component that is doing the trace, a one character field indicating Trace type:
* > (entry)
* < (exit)
* X (exception)
* D (debug)
and the method/function name. After which there will be additional trace data.
With tracing enabled, you will know exactly where an exception is being thrown from. A typical trace record for when an exception is thrown is as follows:
[13/11/2008 15:55:55:510] 00007860 transport X HTTPTransport::readHTTPHeader(): Line=1851: File=/home/amra/axis/L1.1.0/src/ws-axis/c/src/transport/axis3/HTTPTransport.cpp:
HTTPTransportException - SERVER_TRANSPORT_HTTP_EXCEPTION: Server sent HTTP error: 'Not Found'
And finally, you can dump out the request/response messages by enabling transport trace. Here is a sample:
[13/11/2008 15:55:55:280] 00007860 transport D HTTPChannel::writeBytes():
POST /axis HTTP/1.1
Host: 127.0.0.1:13260
Content-Type: text/xml; charset=UTF-8
SOAPAction: ""
Content-Length: 393
[13/11/2008 15:55:55:280] 00007860 transport < HTTPChannel::writeBytes(): Exit with integer value of 122
[13/11/2008 15:55:55:281] 00007860 transport > HTTPChannel::writeBytes():
[13/11/2008 15:55:55:282] 00007860 transport D HTTPChannel::writeBytes():
<?xml version='1.0' encoding='utf-8' ?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<SOAP-ENV:Body>
<ns1:div xmlns:ns1="http://soapinterop.org/wsdl">
<ns1:arg_0_0>10</ns1:arg_0_0>
<ns1:arg_1_0>5</ns1:arg_1_0>
</ns1:div>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
.
.
.
[13/11/2008 15:55:55:508] 00007860 transport D HTTPChannel::readBytes():
HTTP/1.1 404 Not Found
Server: WebSphere Application Server/5.1
Content-Type: text/html;charset=UTF-8
Content-Language: en-GB
Transfer-Encoding: chunked
21
Error 404: File not found: null 0
[13/11/2008 15:55:55:509] 00007860 transport < HTTPChannel::readBytes(): Exit with integer value of 203
This support has been put in CMVC under the following SVN revisions:
For visual C++ files: http://svn.apache.org/viewvc?view=rev&revision=713844
For external include files and build xml files: http://svn.apache.org/viewvc?view=rev&revision=713843
For engine. parser, transport, channel files: http://svn.apache.org/viewvc?view=rev&revision=713841
was (Author: nadiramra):
OK, finally got this done. Tracing is now integrated in the code so that only one binary is needed when we put out a release. I have also disabled and removed the previous support in which a tool was used to dynamically produce source with a trace points. That was kludgy and introduced complexity when trying to do tracing of the xml parser and transport, and channels. It is much cleaner now. Here is the information on the support.
To enable tracing, simply set one of ClientLogPath or LogPath (for server logging) to the path of the trace file in the axiscpp.conf file. With this support, a new configuration variable, LogFilter, can be set to filter the trace records so you can isolate a component. The filter is a semicolon delimited string of possible filters. Possible filters include:
* stub - show trace records generated by stubs
* engine - show trace records generated by engine
* parser - show trace records generated by parser
* transport - show trace records generated by transport
* noEntryExit - do not show entry/exit trace records
The default filter is "stub;engine;parser;transport". So, for example, if I wanted to enable client trace and show only transport trace records and no entry/exit trace records, then the following would need to be specified:
ClientLogPath: /tmp/axis.log
LogFilter:transport;noEntryExit;
That it. In addition, I added methods to Axis class:
static int startTrace(const char* logFilePath, const char *logFilter=NULL);
static void stopTrace();
static void writeTrace(const char* functionName, const char * fmt, ...);
So one can programmatically enable trace and write to the trace (this will allow stub tracing in the future if we choose to add it). More information is in the header file Axis.hpp.
Internally, I completely rewrote the AxisTrace class and added a slew of macro to make adding trace points in the code very simple to do and elegant on the eyes. For example, Trace entry and exit is simply done with the following macros:
logEntryEngine("BasicTypeSerializer::BasicTypeSerializer")
logExit()
That it. The checks to determine whether trace is active is an inlined function that checks a boolean, so performance should not be a consideration. In addition, the check is done once within a method or function.
I do not trace parameters unless I fealt there is a need to. However, currently, I do trace anything that is returned by a method or function via the following macros:
#define logExit()
#define logExitWithReturnCode(lRC)
#define logExitWithInteger(lint)
#define logExitWithPointer(lPointer)
#define logExitWithString(lString)
#define logExitWithBoolean(lBoolean)
#define logExitWithMessage(lfmt)
A typical trace record will look like the following (following are entry exit trace records)
[13/11/2008 15:55:55:509] 00007860 transport > HTTPTransport::processHTTPHeader():
[13/11/2008 15:55:55:510] 00007860 transport < HTTPTransport::processHTTPHeader():
It includes a timestamp, a thread ID, the component that is doing the trace, a one character field indicating Trace type:
* > (entry)
* < (exit)
* X (exception)
* D (debug)
and the method/function name. After which there will be additional trace data.
With tracing enabled, you will know exactly where an exception is being thrown from. A typical trace record for when an exception is thrown is as follows:
[13/11/2008 15:55:55:510] 00007860 transport X HTTPTransport::readHTTPHeader(): Line=1851: File=/home/amra/axis/L1.1.0/src/ws-axis/c/src/transport/axis3/HTTPTransport.cpp:
HTTPTransportException - SERVER_TRANSPORT_HTTP_EXCEPTION: Server sent HTTP error: 'Not Found'
And finally, you can dump out the request/response messages by enabling transport trace. Here is a sample:
[13/11/2008 15:55:55:280] 00007860 transport D HTTPChannel::writeBytes():
POST /axis HTTP/1.1
Host: 127.0.0.1:13260
Content-Type: text/xml; charset=UTF-8
SOAPAction: ""
Content-Length: 393
[13/11/2008 15:55:55:280] 00007860 transport < HTTPChannel::writeBytes(): Exit with integer value of 122
[13/11/2008 15:55:55:281] 00007860 transport > HTTPChannel::writeBytes():
[13/11/2008 15:55:55:282] 00007860 transport D HTTPChannel::writeBytes():
<?xml version='1.0' encoding='utf-8' ?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<SOAP-ENV:Body>
<ns1:div xmlns:ns1="http://soapinterop.org/wsdl">
<ns1:arg_0_0>10</ns1:arg_0_0>
<ns1:arg_1_0>5</ns1:arg_1_0>
</ns1:div>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
.
.
.
[13/11/2008 15:55:55:508] 00007860 transport D HTTPChannel::readBytes():
HTTP/1.1 404 Not Found
Server: WebSphere Application Server/5.1
Content-Type: text/html;charset=UTF-8
Content-Language: en-GB
Transfer-Encoding: chunked
21
Error 404: File not found: null 0
[13/11/2008 15:55:55:509] 00007860 transport < HTTPChannel::readBytes(): Exit with integer value of 203
This support has been put in CMVC under the following SVN revisions:
For visual C++ files: http://svn.apache.org/viewvc?view=rev&revision=713844
For external include files and build xml files: http://svn.apache.org/viewvc?view=rev&revision=713843
For engine. parser, transport, channel files: http://svn.apache.org/viewvc?view=rev&revision=713841
> enable axis c++ (engine) tracing
> --------------------------------
>
> Key: AXISCPP-100
> URL: https://issues.apache.org/jira/browse/AXISCPP-100
> Project: Axis-C++
> Issue Type: Wish
> Components: Trace Utility
> Affects Versions: future (enh)
> Environment: ALL
> Reporter: Aleksander Slominski
> Fix For: current (nightly)
>
>
> i think it would be good to have some kind of tracing/logging compiled into binary that could be triggered by setting environment variable (for example AXISCPP_TRACE=engine:ALL).
> it would be very useful tool when debugging such problems like wrong SOAPAction to see if engine received request and see where did it go and why it was rejected.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
[jira] Commented: (AXISCPP-100) enable axis c++ (engine) tracing
Posted by "Mark Whitlock (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXISCPP-100?page=comments#action_58297 ]
Mark Whitlock commented on AXISCPP-100:
---------------------------------------
Currently there is entry/exit/catch trace in almost all methods (added in by the TraceInstrumentor at ant build time). Catch trace is trace automatically added into catch blocks. There are a few files that trace is not added into. These are listed in ws-axis/c/tools/org/apache/axis/tools/trace/tracetool.conf. They include files such as AxisTrace.cpp which should never be instrumented with trace, and other files which the tool fails to parse. The files that the tool fails on are mostly not used by Axis.
I hope people find the trace useful and readable. For instance methods, "this" is output in < >, so you can see which instance a method is being called for. In methods that contain multiple return statements or multiple catch blocks, which return or catch is shown after an @ sign.
Here are some enhancements I hope to add to the trace support...
- Support the free trace viewer from alphaworks (see not from John above).
- Output large data areas properly (only the first 32 bytes are output at present)
- Trace pointers to primitives better
- Startup trace - tracing before axiscpp.conf is read in
- Trace thread ids
- Throw trace - instrument the code to add in trace around a throw statement.
- Trace catch (...) blocks better so I can see what has really been caught.
- I suspect trace may get the length of derived classes wrong so not all the data is output.
- Component trace - so that only certain components are traced.
- Trace enums better - so AXIS_SUCCESS comes out as AXIS_SUCCESS and not 0.
- Server-side trace
I haven't added in component trace up until now because the client side trace is not so massive that it is difficult to read. Also the trace viewer will enable component filtering.
> enable axis c++ (engine) tracing
> --------------------------------
>
> Key: AXISCPP-100
> URL: http://issues.apache.org/jira/browse/AXISCPP-100
> Project: Axis-C++
> Type: Wish
> Versions: future (enh)
> Environment: ALL
> Reporter: Aleksander Slominski
>
> i think it would be good to have some kind of tracing/logging compiled into binary that could be triggered by setting environment variable (for example AXISCPP_TRACE=engine:ALL).
> it would be very useful tool when debugging such problems like wrong SOAPAction to see if engine received request and see where did it go and why it was rejected.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
Re: [jira] Commented: (AXISCPP-100) enable axis c++ (engine) tracing
Posted by John Hawkins <HA...@uk.ibm.com>.
Hi Nadir,
Tracing is configurable currently, if you do not set the CLIENTLOGPATH in
the axiscpp then you do not get *any* trace. However, for a server this
would be no good :-)
John Hawkins
Nadir Amra <am...@us.ibm.com>
27/01/2005 17:01
Please respond to
"Apache AXIS C Developers List"
To
"Apache AXIS C Developers List" <ax...@ws.apache.org>
cc
Subject
Re: [jira] Commented: (AXISCPP-100) enable axis c++ (engine) tracing
This is something that is needed. I realize there is a way to incorporate
tracing tool to do debugging, but I think we need something that is in the
code without a need to use the tool, and that is activated by a
configuration file switch. It is on my todo list to use the trace class
(and enhance it) so that there is a global trace object that can be called
by all parts of axis. This class will have methods to dump put entry/exit
and various other objects.
John also mentions ffdc, or maybe an eventlog, to write out serious errors
(on unix maybe it would go to syslog, etc.). Another thing on my list.
Lots of work, but I will get this in, one way or another!
Nadir K. Amra
e-Business Technologies - IBM eServer i5/OS
IBM Rochester, MN, (Tel. 507-253-0645, t/l 553-0645)
Internet: amra@us.ibm.com
"Samisa Abeysinghe (JIRA)" <ax...@ws.apache.org> wrote on 01/27/2005
07:08:17 AM:
> [ http://issues.apache.org/jira/browse/AXISCPP-100?
> page=comments#action_58150 ]
>
> Samisa Abeysinghe commented on AXISCPP-100:
> -------------------------------------------
>
> Are we happy with the current level of tracing available with Axis C++?
>
> Do we have any plans to implement the said level of tracing?
>
> Do we have this kind of feature with Axis Java?
>
> Personally I do feel that this level of tracing would help; however
> would make the code too clumsy, unless otherwise we use AOP, which
> is far too much. Hence I do not think we should go for this.
>
> > enable axis c++ (engine) tracing
> > --------------------------------
> >
> > Key: AXISCPP-100
> > URL: http://issues.apache.org/jira/browse/AXISCPP-100
> > Project: Axis-C++
> > Type: Wish
> > Versions: future (enh)
> > Environment: ALL
> > Reporter: Aleksander Slominski
>
> >
> > i think it would be good to have some kind of tracing/logging
> compiled into binary that could be triggered by setting environment
> variable (for example AXISCPP_TRACE=engine:ALL).
> > it would be very useful tool when debugging such problems like
> wrong SOAPAction to see if engine received request and see where did
> it go and why it was rejected.
Re: [jira] Commented: (AXISCPP-100) enable axis c++ (engine) tracing
Posted by Nadir Amra <am...@us.ibm.com>.
This is something that is needed. I realize there is a way to incorporate
tracing tool to do debugging, but I think we need something that is in the
code without a need to use the tool, and that is activated by a
configuration file switch. It is on my todo list to use the trace class
(and enhance it) so that there is a global trace object that can be called
by all parts of axis. This class will have methods to dump put entry/exit
and various other objects.
John also mentions ffdc, or maybe an eventlog, to write out serious errors
(on unix maybe it would go to syslog, etc.). Another thing on my list.
Lots of work, but I will get this in, one way or another!
Nadir K. Amra
e-Business Technologies - IBM eServer i5/OS
IBM Rochester, MN, (Tel. 507-253-0645, t/l 553-0645)
Internet: amra@us.ibm.com
"Samisa Abeysinghe (JIRA)" <ax...@ws.apache.org> wrote on 01/27/2005
07:08:17 AM:
> [ http://issues.apache.org/jira/browse/AXISCPP-100?
> page=comments#action_58150 ]
>
> Samisa Abeysinghe commented on AXISCPP-100:
> -------------------------------------------
>
> Are we happy with the current level of tracing available with Axis C++?
>
> Do we have any plans to implement the said level of tracing?
>
> Do we have this kind of feature with Axis Java?
>
> Personally I do feel that this level of tracing would help; however
> would make the code too clumsy, unless otherwise we use AOP, which
> is far too much. Hence I do not think we should go for this.
>
> > enable axis c++ (engine) tracing
> > --------------------------------
> >
> > Key: AXISCPP-100
> > URL: http://issues.apache.org/jira/browse/AXISCPP-100
> > Project: Axis-C++
> > Type: Wish
> > Versions: future (enh)
> > Environment: ALL
> > Reporter: Aleksander Slominski
>
> >
> > i think it would be good to have some kind of tracing/logging
> compiled into binary that could be triggered by setting environment
> variable (for example AXISCPP_TRACE=engine:ALL).
> > it would be very useful tool when debugging such problems like
> wrong SOAPAction to see if engine received request and see where did
> it go and why it was rejected.
[jira] Commented: (AXISCPP-100) enable axis c++ (engine) tracing
Posted by "Samisa Abeysinghe (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXISCPP-100?page=comments#action_58150 ]
Samisa Abeysinghe commented on AXISCPP-100:
-------------------------------------------
Are we happy with the current level of tracing available with Axis C++?
Do we have any plans to implement the said level of tracing?
Do we have this kind of feature with Axis Java?
Personally I do feel that this level of tracing would help; however would make the code too clumsy, unless otherwise we use AOP, which is far too much. Hence I do not think we should go for this.
> enable axis c++ (engine) tracing
> --------------------------------
>
> Key: AXISCPP-100
> URL: http://issues.apache.org/jira/browse/AXISCPP-100
> Project: Axis-C++
> Type: Wish
> Versions: future (enh)
> Environment: ALL
> Reporter: Aleksander Slominski
>
> i think it would be good to have some kind of tracing/logging compiled into binary that could be triggered by setting environment variable (for example AXISCPP_TRACE=engine:ALL).
> it would be very useful tool when debugging such problems like wrong SOAPAction to see if engine received request and see where did it go and why it was rejected.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira