捕获JAX-WS Web服务的JAXB时序

Question

Background: I have an enterprise application with hundreds of JAXB classes. These classes are used in serving 50+ JAX-WS web-services. While troubleshooting performance (source: dynatrace), we realized that lot of time is being spent on the server runtime (container) before request reaches to model objects. I added Servlet filters to capture overall time spent to service the request but I am trying to capture the time spent by JAX-WS to marshal/unmarshal SOAP requests.

I have tried using :

1. JAXB Marshal/Unmarshal listeners using the help from this link Reference 1

My problem with this approach is: All of these examples have their own JAXBContext.. but in my case every server container created its own JAXBContext and I couldn't find way to inject my listeners into app server's JAXBcontext..

-- Can you please help me with this ?

2. SOAP Handlers as described on this link: Reference 2

Problem with this approach: How do I find out if timings include JAXB marshaling ? Also, how to separate the these timings from what SOAP handlers would capture ? Which one gets executed first by the app server - SOAP handler or JAXB marshaling ?

Please let me know if there is any effective way to capture JAXB timings from App server. Also, please let me know if I misunderstanding above approaches. Thank you.

Answer 1

If you want to get faster feedback on dynatrace related questions I suggest you post them on our own disucssion forum: https://community.compuwareapm.com/community/display/DTFORUM/dynaTrace+Forums+Home

We also provide a service called "Share Your PurePath" - http://bit.ly/sharepurepath - where we take a look at your captured dynatrace PurePath data and give you recommendations. I see your described scenario quite often. It typically is related with exhausted thread pools when handing a request from one runtime/engine to the next, eg: from the Web Server to the AppServer you have different worker threads that handle these requests being connected with some type Connection Mechanism. I wrote several blog articles on this already. Please check these two links that explain how to watch out for this particular problem pattern: * http://apmblog.dynatrace.com/2015/01/22/key-performance-metrics-load-tests-beyond-response-time-part/ * https://community.compuwareapm.com/community/display/PUB/How+to+explain+growing+Worker+Threads+under+Load

Andi