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 "nadir amra (JIRA)" <ax...@ws.apache.org> on 2008/11/13 23:54:44 UTC
[jira] Issue Comment Edited: (AXISCPP-100) enable axis c++ (engine)
tracing
[ 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