[GLASSFISH-15559] [PERF]: JAXB string interning introduces major performance regression for webservices Created: 13/Jan/11  Updated: 03/Dec/12  Resolved: 18/Jan/11

Status: Closed
Project: glassfish
Component/s: jax-rs
Affects Version/s: 3.1_b31
Fix Version/s: 3.1

Type: Bug Priority: Blocker
Reporter: Scott Oaks Assignee: Pavel Bucek
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
depends on JAXB-805 [PERF]: JAXB string interning introdu... Resolved
blocks GLASSFISH-13944 [PERF] specj enterprise 2010 benchmar... Closed


The upgrade to jaxb 2.2.2 in build 31 has caused a significant regression in webservices performance. [The underlying issue is in jaxb, which isn't a category, so I'm using jax-rs; not sure if that is the most appropriate.]

The root cause is the new string.intern() calls performed by FastInfosetConnector.InterningXmlVisitor. If I take the 2.2.1 FastInfosetConnector class and run it in 2.2.2, the regression goes away (the only difference in that class is the 2.2.2 classes uses a new InterningXmlVisitor(visitor) object; the 2.2.1 class uses the passed-in visitor directly). Running that test is what I referred to below when I said I needed to gather a little more data first.

I realize that may affect other parts of the code, but these intern calls are clearly a problem. In specj, we are spending 10% of our time just doing string intern calls, and the webservices calls in specj (which is what uses jaxb) are a very minor part of the workload. The actual webservice call – that is com.sun.xml.ws.server.sei.EndpointMethodHandler.invoke() – takes 3x longer with jaxb 2.2.2, and the jaxb unmarshalling (com.sun.xml.bin.api.Bridge.unmarshal -> com.sun.xml.bind.v2.runtime.unmarshaller.FastInfosetConnector.bridge()) takes 7x longer. All that time is from the string interning.

Comment by Martin Grebac [ 18/Jan/11 ]

The updated jaxb release 2.2.3-1 was integrated to GF 3.1.

Generated at Mon Aug 29 09:25:20 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.