Guys, in the meantime I found the following solution for us to be acceptable:
1. By exploiting the named properties in the In-Message-Context, the WS method implementations put everything required to do application-specific logging into the Axis2 In-Message-Context 2. The default Axis2 HTTP transport sender is wrapped by an application specific class inheriting from the original Axis2 transport sender. The new class' invoke()-method is a wrapper around the base class' invoke method which catches transport level exceptions and does appropriate logging. 3. The inherited application specific class is activated by editing axis2.xml and adjusting the <transportSender>-nodes for HTTP and HTTPS correspondingly. That seems to work so far thanks to Axis2 flexible handler concepts. And it also works properly for the case of occurring SOAP faults. Thanks, -Rainer From: Stadelmann Josef [mailto:josef.stadelm...@axa-winterthur.ch] Sent: Monday, June 27, 2011 9:20 AM To: java-user@axis.apache.org Subject: AW: Howto get extended log information in case of ClientAbortException Gentlemen's I cannot give you just out of pocket a precise answer, but maybe some idea about how to approach. The issue is most then same: where are the boundaries? In this case I can see about 3 boundaries: a) Your web service method - must be able to log the time of entrance into a method and the completion or exit from that method b) Your axis2/J is a servlet - is a message process in engine, has phases, etc. - it should be able to log the time of entrance at phase-1-incomming and completion of a phase XYZ-incoming (message-receiver) and it should log phase-1-outgoing and phase-XYZ-outgoing c) Your web application server running on top of a JVM, it physically receives the message, takes it from the wire, and calls the proper servlet - axis2 - hence calling and completing of the servlet axis2 should be logged, taking the message from the wire and completing putting the message to the wire should be logged as well. I have configured Tomcat AS to use log4j, and using Chainsaw (log4j) and a sockethubappender I can see all the loggers Tomcat uses. Axis2 has some defined loggers as well, i.e. the deployment engine logs when a axis2 web service is deployed, and there are more i.e. addressing And finally we are logging each time when a request hits one of our long lasting session service objects (instance of the service class, state-full-web-service-object in scope="soapsession"), and we log the time at which the method completes. Putting this 6 message into a sequence of an interaction-frame gives you about the information what happens, what should happen. The message 1. has received at AS-incoming 2. has received at Axi2 Phase XYZ-incoming 3. has received at Method M1 4. has completed Method M1 5. has completed at Axis2 Phase XYZ-outgoing 6. has completed at AS outgoing And now I think the questions have to go to 3 forums 1. The AS Forum how to log incoming request 2. The Axis2 Forum how to log start and completion of phases 3. Your own forum :) how to log start and completion of method And you need to be able to have a consistent message-Id from client to service-method and back. So far my thoughts at the moment, and I agree, it could be more consistent and more easy to handle, and less varying concepts. Also be aware that unhandled exceptions are logged in the AS main log file, so out from experience it is always good to know where your various log files are and what they are able to log. Josef Von: Menzner, Rainer [mailto:rmenz...@l1id.com] Gesendet: Freitag, 24. Juni 2011 09:44 An: axis-u...@ws.apache.org Betreff: Howto get extended log information in case of ClientAbortException Hi everyone, occasionally, when processing a client request takes too long time, the client runs into a timeout condition and closes the connection. When the Axis2 web service later tries to send the request response, the following kind of exception occurs on the server: 09:03:50,932 ERROR [AxisEngine] org.apache.axis2.AxisFault at org.apache.axis2.AxisFault.makeFault(AxisFault.java:430) at org.apache.axis2.transport.http.SOAPMessageFormatter.writeTo(SOAPMessageFormatter.java:83) at org.apache.axis2.transport.http.CommonsHTTPTransportSender.sendUsingOutputStream(CommonsHTTPTransportSender.java:358) [snip] at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:619) Caused by: com.ctc.wstx.exc.WstxIOException: null at com.ctc.wstx.sw.BaseStreamWriter.flush(BaseStreamWriter.java:313) at org.apache.axiom.om.impl.MTOMXMLStreamWriter.flush(MTOMXMLStreamWriter.java:168) at org.apache.axiom.om.impl.llom.OMNodeImpl.serializeAndConsume(OMNodeImpl.java:487) at org.apache.axis2.transport.http.SOAPMessageFormatter.writeTo(SOAPMessageFormatter.java:79) ... 30 more Caused by: ClientAbortException: java.net.SocketException: Software caused connection abort: socket write error at org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:348) at org.apache.catalina.connector.OutputBuffer.flush(OutputBuffer.java:314) at org.apache.catalina.connector.CoyoteOutputStream.flush(CoyoteOutputStream.java:98) at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:124) at com.ctc.wstx.io.UTF8Writer.flush(UTF8Writer.java:99) at com.ctc.wstx.sw.BufferingXmlWriter.flush(BufferingXmlWriter.java:214) at com.ctc.wstx.sw.BaseStreamWriter.flush(BaseStreamWriter.java:311) ... 33 more Caused by: java.net.SocketException: Software caused connection abort: socket write error at java.net.SocketOutputStream.socketWrite0(Native Method) at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92) at java.net.SocketOutputStream.write(SocketOutputStream.java:136) at org.apache.coyote.http11.InternalOutputBuffer.realWriteBytes(InternalOutputBuffer.java:724) at org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:449) at org.apache.coyote.http11.InternalOutputBuffer.flush(InternalOutputBuffer.java:299) at org.apache.coyote.http11.Http11Processor.action(Http11Processor.java:950) at org.apache.coyote.Response.action(Response.java:186) at org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:343) ... 39 more Unfortunately, this kind of exception does not provide any information about which request was unable to complete in time. In our web service we have some further information like a Request Context which has info about request type, user, a context-Id, ip-address, etc., and we would like to have that info printed somewhere in the logs so that we can identify the requests or circumstances under which the service is prone to run out of time. Now, that exception occurs about at the end of processing, at least, beyond our web service implementation code, and also outside the compiled Axis2-generated stub classes. Is there an option of registering a particular handler that could print some more log information at that very late point in processing? I have looked through axis2.xml and into the phase definitions but I don't have an idea where to add a handler or if this is possible at all. I would appreciate any feedback and thoughts on this. We are currently using Axis2 1.5.1 (Java) deployed in a JBoss 5.1.0 under Windows 7 (but I don't think this matters). Thanks, -Rainer
