As a follow-up to this, CXF 2.7.10 still depends on the ServiceMix specs 2.2.0. Will manually setting the property still work with that version?
Thanks, Chris On Thu, Mar 20, 2014 at 2:17 AM, Bengt Rodehav <[email protected]> wrote: > Great! > > > 2014-03-20 10:01 GMT+01:00 [email protected] <[email protected]>: > > Hi Bengt, >> >> Yes it's already done. >> >> Regards >> JB >> >> >> -- >> Jean-Baptiste Onofré >> [email protected] >> http://blog.nanthrax.net >> Talend - http://wwx.talend.com >> >> >> ----- Reply message ----- >> From: "Bengt Rodehav" <[email protected]> >> To: <[email protected]> >> Subject: XML unmarshalling performance in Karaf >> Date: Thu, Mar 20, 2014 9:38 am >> >> >> OK - thanks JB, >> >> I guess that means that the next version of Karaf will have this property >> set to 0 by default? >> >> /Bengt >> >> >> 2014-03-19 17:30 GMT+01:00 Jean-Baptiste Onofré <[email protected]>: >> >>> Hi guys, >>> >>> the reason is explained in: >>> https://issues.apache.org/jira/browse/KARAF-2269 >>> >>> I already set it to 0, but, as you can see in this commit: >>> http://mail-archives.apache.org/mod_mbox/karaf-commits/201312.mbox/% >>> [email protected]%3E >>> >>> I think we fixed the 0 timeout support in ServiceMix Specs 2.3.0 (the >>> issue was with 1.9.0). I gonna check and I will set the timeout to 0 if >>> it's correctly supported by the specs. >>> >>> Regards >>> JB >>> >>> >>> On 03/19/2014 02:00 PM, Guillaume Nodet wrote: >>> >>>> Mmh, i would have liked to get away with the explanation ;-) >>>> >>>> So the problem is related to java specifications, like jaxp, stax, >>>> jaxws, jaxb, etc... >>>> The packages are usually provided by the JRE and the discovery is done >>>> using META-INF/services usually. >>>> Unfortunately, this does not work well in OSGi because the application >>>> classloader is used for discovery. >>>> >>>> The servicemix-specs project makes this integration of java specs work >>>> in OSGi. >>>> Over the years, it has improved in various ways, but now, we have the >>>> following: >>>> * the discovery part of the various specs is enhanced to be OSGi >>>> friendly >>>> * those enhanced specs are in the ${karaf.home}/endorsed folder so >>>> that they are used instead of the JRE ones >>>> * the discovery mechanism will look for an implementation bundle in >>>> OSGi, then default to the JRE implementation >>>> >>>> Historically, the discovery of JRE implementations was not possible, so >>>> implementations had to be deployed as bundles. >>>> However, given there's no way to order the resolution of bundles >>>> sufficiently, we needed a timeout so that when a bundle was using one of >>>> the spec, for example the xml parser, the discovery would wait for an >>>> implementation bundle to become available. Without that timeout, the >>>> discovery could fail during the karaf startup. >>>> >>>> However, since the JRE implementations can now be leveraged (mostly >>>> because the specs are now endorsed instead of being deployed as >>>> bundles), that timeout can be safely set to 0 so that the specs won't >>>> wait until a bundle implementation is available, but will delegate to >>>> the JRE directly if no bundle implementation is present. >>>> >>>> Some weeks ago, I had a quick chat with Jean-Baptiste about setting back >>>> the timeout to 0, but we delayed it for some reason I don't recall. >>>> Maybe JB remembers ... >>>> >>>> >>>> 2014-03-19 13:28 GMT+01:00 Bengt Rodehav <[email protected] >>>> <mailto:[email protected]>>: >>>> >>>> >>>> Hello Guillaume! >>>> >>>> That made all the difference in the world. The CPU now finally >>>> started to work and processing time for 1000 of my exchanges went >>>> down to 9s from 38s. >>>> >>>> But you've got some explaining to do :-) >>>> >>>> What is the purpose of this property and why is it set as high as >>>> 100 ms? Also, what can go wrong if I set it to 0? >>>> >>>> /Bengt >>>> >>>> >>>> 2014-03-19 11:43 GMT+01:00 Guillaume Nodet <[email protected] >>>> <mailto:[email protected]>>: >>>> >>>> >>>> I don't think your problem is concurrency, but just wait. >>>> Make the org.apache.servicemix.specs.timeout property is set to >>>> 0 in etc/system.properties and retry. >>>> >>>> >>>> 2014-03-19 10:25 GMT+01:00 Bengt Rodehav <[email protected] >>>> <mailto:[email protected]>>: >>>> >>>> >>>> To clarify, again looking at the sampler info, the locate() >>>> method spends all its time waiting which indicates a >>>> concurrency/synchronization problem. >>>> >>>> When googling about this I found the following JIRA: >>>> >>>> https://issues.apache.org/jira/browse/SMX4-803 >>>> >>>> This seems to have been fixed though. >>>> >>>> I'm not exactly sure how the locator works and if I install >>>> a locator myself or not. I've tried to see what bundle >>>> exports the org.apache.servicemix.specs.locator package but >>>> no bundle does that. So I guess it's a private package in >>>> some bundle. >>>> >>>> Perhaps someone can inform me how this works so I can check >>>> if I need an updated version of some bundle? >>>> >>>> /Bengt >>>> >>>> >>>> >>>> >>>> 2014-03-19 9:56 GMT+01:00 Bengt Rodehav <[email protected] >>>> <mailto:[email protected]>>: >>>> >>>> >>>> Thanks to Guillaume I managed to get the VisualVM to >>>> work with Karaf. >>>> >>>> I then ran my transformations a number of times while >>>> sampling to see where the time is spent. I attach an >>>> image from a snapshot from VisualVM. I'm not sure if it >>>> will be accepted by the mailing list but if anyone wants >>>> to look at it I can send it to your email directly if >>>> you want. >>>> >>>> I'm not an expert on interpreting VisualVM profiling >>>> info but it seems to me that in the thread doing the >>>> transformation, more than 90% of the time is spent in >>>> org.apache.servicemix.specs.locator.OsgiLocator.locate(). >>>> This >>>> explains why the XML unmarshalling runs so much slower >>>> in Karaf than outside of OSGi. >>>> Can anyone verify if I'have interpreted this correct? If >>>> so, then we have a serious performance problem in the >>>> OsgiLocator. >>>> >>>> /Bengt >>>> >>>> >>>> Infogad bild 1 >>>> >>>> >>>> 2014-03-18 15:28 GMT+01:00 Bengt Rodehav >>>> <[email protected] <mailto:[email protected]>>: >>>> >>>> >>>> I'm using karaf 2.3.4 and Camel 2.13.3. >>>> >>>> I've been investigating performance problems with >>>> Camel's "sjms" component. Here is the discussion: >>>> >>>> http://camel.465427.n5.nabble. >>>> com/sjms-and-multiple-threads-td5748836.html >>>> >>>> However, at the end I discovered that my real >>>> problem was the unmarshalling of an XML file in >>>> Karaf. For some reason, if I unmarshall a certain >>>> XML file it takes about 105 ms in Karaf. If I do the >>>> same from my Junit test in Eclipse it takes around >>>> 10 ms. In fact, in Eclipse it starts with around 30 >>>> ms but consecutive calls gradually go down to 7-8 >>>> ms. In Karaf it doesn't matter how many times I do >>>> the unmarshalling. It stays at about 105 ms >>>> everytime. >>>> >>>> I'm very confused about this. >>>> >>>> The actual code looks like this (approximately): >>>> >>>> public MmlMessage unmarshallMmlMessage(String >>>> theXml) throws JAXBException { >>>> final Unmarshaller unMarshaller = >>>> cMmlMessageJAXBcontext.createUnmarshaller(); >>>> StreamSource ss = new StreamSource(new >>>> StringReader(theXml)); >>>> long t0 = System.nanoTime(); >>>> JAXBElement<?> mmlMessageElement = >>>> unMarshaller.unmarshal(ss, MmlMessage.class); >>>> long t1 = System.nanoTime(); >>>> MmlMessage mmlMessage = (MmlMessage) >>>> mmlMessageElement.getValue(); >>>> System.out.println("t1: " + (t1-t0) + " ns"); >>>> return mmlMessage; >>>> } >>>> >>>> The MmlMessage class is generated from an XML schema >>>> using maven-jaxb2-plugin. But it shouldn't matter >>>> since the same classes are used within Karaf as >>>> outside of Karaf. >>>> >>>> I assumed that for some reason I'm not running the >>>> same code in Karaf as outside Karaf. When logging >>>> the actual class of the unMarshaller variable I get: >>>> "com.sun.xml.bind.v2.runtime. >>>> unmarshaller.UnmarshallerImpl" >>>> both within and outside Karaf. >>>> >>>> The classloader for the unMarshaller in Karaf is: >>>> "org.apache.felix.framework. >>>> BundleWiringImpl@5740eacd". >>>> >>>> I thought I had the answer when I noted that outside >>>> Karaf I use the Jaxb implementation that is listed >>>> in Camel-jaxb dependencies. This is version 2.1.13. >>>> In Karaf I had installed a jaxb version from >>>> servicemix bundles namely: >>>> >>>> <groupId>org.apache. >>>> servicemix.bundles</groupId> >>>> >>>> <artifactId>org.apache. >>>> servicemix.bundles.jaxb-impl</artifactId> >>>> <version>2.2.1.1_2</version> >>>> >>>> So I forced my Junit test to use the same servicemix >>>> bundles version but it was still equally fast as >>>> before. No where near the 105 ms I get in Karaf. >>>> >>>> I realize that this probably is not a Karaf problem >>>> per se. But, I know there are probably lots of >>>> people on this mailing that have handled XML a lot >>>> in Karaf. Do you have any tips on what to look at? >>>> What could cause this performance problem? >>>> >>>> /Bengt >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> -- >>> Jean-Baptiste Onofré >>> [email protected] >>> http://blog.nanthrax.net >>> Talend - http://www.talend.com >>> >> >> >
