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 >
