feature: SOAP usage metrics

[GoogleCodeExporter]

What steps will reproduce the problem?

Currently, all SOAP requests are simply stored as POST statistics without a 
breakdown by method.

SAMPLE:
/services/MySoapService POST   detailed_stats....


What is the expected output? What do you see instead?

Breakdown by SOAP method -
EXAMPLE:
/services/MySoapService/myServiceMethod SOAP detailed_stats.....

/services/MySoapService/myOtherServiceMethod SOAP detailed_stats.....

/services/MySoapService/myHelloWorldMethod SOAP detailed_stats.....




What version of the product are you using? On what application server, JDK,
operating system?
Tomcat 7, CXF webservices, javamelody 1.3X


Please provide any additional information below.

mailing list reference, and some notes:

"I have 2 documentations to possibly monitor Apache CXF, without
looking at parsing the SOAP payload at the moment:
- CXF Interceptors: http://cxf.apache.org/docs/interceptors.html (and
use a javamelody counter)
- or using the CXF perf metrics MBean, including an example jsp page:
http://code.google.com/p/xebia-france/wiki/CxfMonitoring#Spring_configuration
Note: MBeans can already be viewed in the html reports of javamelody.

Original issue reported on code.google.com by binarymo...@gmail.com on 15 Jun 2012 at 8:41

[GoogleCodeExporter]

Original comment by evernat@free.fr on 17 Jun 2012 at 6:38

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Created a patch to add support for SOAP 1.1 and 1.2, using a similar design to 
the existing support for GWT-RPC.  Also added support from XML-RPC and browser 
form posts (builds on patch I submitted for Issue 356).

Refactored the GWT-RPC support to only buffer the minimum amount of bytes 
necessary to identify the method call instead of the whole request.  Other 
formats work similarly.

Original comment by roy.pate...@gmail.com on 11 Nov 2013 at 2:45

Attachments:

• SOAP.patch

[GoogleCodeExporter]

I will look at the patch. Thanks.

Original comment by evernat@free.fr on 11 Nov 2013 at 3:38

[GoogleCodeExporter]

So about the patch:
At first, it was too big for me to analyze and to refactor. And refactoring was 
needed.
So, I have removed include-query-string from the patch. It was not the same 
story as SOAP and should be in a separated commit anyway.
Later, I also removed the parsing of text/xml for XML-RPC. XML-RPC is supposed 
to be obsolete. And text/xml if nowadays more often used for xml data (for 
example, in JENKINS CLI). Parsing uselessly all those text/xml may introduce 
performance or other problems. This is a risk too high just for an obsolete 
protocol.


What gives the patch at the moment?
There are very good things:
- Reading only the first bytes of the GWT or SOAP payload is great
- As using a buffer stream and reset
- Using a scanner is also probably more readable than before

Some things should not be in my opinion:
- Stream (and parameters) should not be touched or wrapped if not for GWT or 
SOAP. There are too much involved parts in servlet streams, including async and 
buffers and flushs, to add unneeded moving parts.
- Exceptions in parsing should not be logged as warn level, because it will 
flood the logs on some servers. Monitoring should not be the cause of floods 
and saturation.

And I have also changed some details, not that much finally:
- Using a pre-compiled pattern in the scanner
- I often work on a laptop and too many blank lines take half of the screen

The new patch is attached

Original comment by evernat@free.fr on 13 Nov 2013 at 1:15

Attachments:

• SOAP-2.patch

[GoogleCodeExporter]

Except if you don't like that, I will of course creedit roy.paterson in the 
release notes to come.
I still need to test GWT and SOAP for real with this patch.

Original comment by evernat@free.fr on 13 Nov 2013 at 1:33

[GoogleCodeExporter]

I don't care about the credit, but I need the XML-RPC support :-(

It's true XML-RPC has gone out of fashion but the spec 
(http://xmlrpc.scripting.com/spec) doesn't officially say it's obsolete, 
neither does Wikipedia (http://en.wikipedia.org/wiki/XML-RPC).  The Apache Java 
XML-RPC library (http://ws.apache.org/xmlrpc/) is still maintained (although 
hasn't had a release since 2010).  

In any event even if XML-RPC is "obsolete" lots of applications still use it so 
I think it would be useful if JavaMelody supported it.

Regarding performance it's not like we're parsing the entire request.  If the 
text/xml content *isn't* XML-RPC we will probably know that after looking at 
the first tag, which is probably in the first dozen characters or so.  Is that 
so bad?

Please can we support XML-RPC as well?

Original comment by roy.pate...@gmail.com on 13 Nov 2013 at 9:24

[GoogleCodeExporter]

I have tested the patch 2 with GWT and SOAP, it works well.
So I have committed in trunk (revision 3563).

Then, I think that you need in fact to customize the request name based on the 
payload, for example for XML-RPC or form parameters.
So, I have refactored to add a protected method "createRequestWrapper" in 
MonitoringFilter. And, you can override MonitoringFilter and 
PayloadNameRequestWrapper.
It's committed:
https://code.google.com/p/javamelody/source/browse/trunk/javamelody-core/src/mai
n/java/net/bull/javamelody/MonitoringFilter.java
https://code.google.com/p/javamelody/source/browse/trunk/javamelody-core/src/mai
n/java/net/bull/javamelody/PayloadNameRequestWrapper.java

To customize the monitoring, in order to add XML-RPC and form parameters in the 
statistics, you will be able to add in your application the attached classes: 
CustomMonitoringFilter and CustomPayloadNameRequestWrapper (and the unit test). 
I have written the 3 files based on your patch.
So, you will be able to use the custom filter in web.xml, instead of 
MonitoringFilter, like that:
    <filter>
        <filter-name>javamelody</filter-name>
        <filter-class>mypackage.CustomMonitoringFilter</filter-class>
        <init-param>
            <param-name>include-query-string</param-name>
            <param-value>true</param-value>
        </init-param>
    </filter>
    <filter-mapping>
    ...

I have made a new build from the current trunk and it is available at:
https://javamelody.googlecode.com/files/javamelody-20131116.jar

Thanks!

Original comment by evernat@free.fr on 16 Nov 2013 at 6:10

• Changed state: Fixed

Attachments:

• CustomMonitoringFilter.java
• CustomPayloadNameRequestWrapper.java
• TestCustomPayloadNameRequestWrapper.java

[GoogleCodeExporter]

I don't control the source code of the application I need to monitor, but I 
guess I could compile those "Custom" classes in to a separate jar and include 
that along with JavaMelody.  It seems like an onerous requirement for people 
who need XML-RPC support to do this though.  Have you considered including 
XML-RPC support but just disabling it by default, and then enabling it with a 
config parameter?

Thanks

Original comment by roy.pate...@gmail.com on 20 Nov 2013 at 9:18