Hi, In case if JAXB is the bottleneck, could you try to define InputStream or String instead JAXB object in API and parse it in more effective way, for example using StAX?
Regards, Andrei. > -----Original Message----- > From: kevin.viet [mailto:[email protected]] > Sent: Freitag, 18. Januar 2019 12:29 > To: [email protected] > Subject: Slow > > Hello > > We are using CXF to implement low response time XML services. > We noticed, since 1.5 year now, that we the usage of our XML service is > increasing, the CXF framework does not seem to scale under certain condition. > We tried as much as possible to understand how to get the best of CXF but > today, it seems we are kind of stuck and think that this scaling issue could > be > fixed in CXF. > > Our problem is related to the usage of XmlAnyElement in JAXB mappings. > Everything is running fine when the input XML does not trigger the catchall > process of our grammars, but once the catch all is triggered the application > is > not able to scale if all input XML contain an "unknown element". > We use this mechanism to have a kind of forward compatilibity of our > grammars : catching all unknown elements is part of this forward > compatibility. > > What's the issue then with XmlAnyelement? > We have a catchall inside of our custom soap header, i.e: > > @XmlRootElement > public class OurSoapHeader { > > // .... > @XmlAnyElement > List importantTechnicalData > > // ... > > The transformation of OurSoapHeader to JaxB is started in > org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor, when the > Jaxb unmarshaller encounters the wildcard element, it kicks out XML factories > for parsing and transforming : there's an attached flamegraph showing the > time consumed as per creation of that. > XmlTransformersFG.png > <https://urldefense.proofpoint.com/v2/url?u=http- > 3A__cxf.547215.n5.nabble.com_file_t341788_XmlTransformersFG.png&d=DwI > CAg&c=2w5q_42kFG40MI2alLPgJw&r=bWOqkHjIZE0sZtdpFMIhm- > lcbhtB3cv08OlIr0lkKR4&m=Fme-Nw6YtB- > hDqIyPwE2lgg7bbJtlLxZObhDR55dCLo&s=gEdpL- > QGoosPS0Tka25aQgtq5TGytkfsGzQ2_Ta5DYU&e=> > You can see the implementation of Jaxb here : > https://urldefense.proofpoint.com/v2/url?u=https- > 3A__github.com_javaee_jaxb-2Dv2_blob_master_jaxb- > 2Dri_runtime_impl_src_main_java_com_sun_xml_bind_v2_runtime_unmarsha > ller_DomLoader.java-23L75- > 2DL84&d=DwICAg&c=2w5q_42kFG40MI2alLPgJw&r=bWOqkHjIZE0sZtdpFMIhm > -lcbhtB3cv08OlIr0lkKR4&m=Fme-Nw6YtB- > hDqIyPwE2lgg7bbJtlLxZObhDR55dCLo&s=qJUhQ-6MwsX_-bmm49uyI-jmGDzn- > 3BmYkHCFa3olgc&e= > that triggers this specific use case. > The issue with this code is that there are synchronized blocks in a bunch of > Factories methods that implies a lot of contention when the traffic increase > on > our servers, and prevent our application from scaling well. > > We need a bit of help to sort out this issue, on your side, are you aware of > such > problem ? > Do you have any idea on how to fix the behavior of CXF or Jaxb to avoid > creation of Factories ? > > On my side I was thinking of having CXF maintaining a pool of JAXB > unmarshallers, do you know if it can solve this specific issue? > > Regards > Kevin > > > > -- > Sent from: https://urldefense.proofpoint.com/v2/url?u=http- > 3A__cxf.547215.n5.nabble.com_cxf-2Duser- > 2Df547216.html&d=DwICAg&c=2w5q_42kFG40MI2alLPgJw&r=bWOqkHjIZE0sZt > dpFMIhm-lcbhtB3cv08OlIr0lkKR4&m=Fme-Nw6YtB- > hDqIyPwE2lgg7bbJtlLxZObhDR55dCLo&s=4EKsyr9L3nQMTgcseJ- > vX_A0BSWb967zNMMTl9f2QUo&e= As a recipient of an email from Talend, your contact personal data will be on our systems. Please see our contacts privacy notice at Talend, Inc. <https://www.talend.com/contacts-privacy-policy/>
