This is horrible if you have to pool a parse in production environment. But I can understand. XML folks never thought or designed the system using a sound Compound System Architecture and design pattern.
Felix is the best and leanest servicing OSGi module out there, and soon my PML framework will have an even tighter connection to it and to the Java language itself. Screw XML! On 23 August 2010 23:48, Jacques-Olivier Goussard <[email protected]>wrote: > Thanks ! > I'll see if I can grab and test the fix - I'm unfortunately on Felix > 1.8 (hard to keep up with your release rates with commercial > development :) > FYI, the issue I'm facing is similar to this one: > http://old.nabble.com/Re%3A-DTDDVFactory-td28314363.html > Pooling the XML parsers does indeed fix the pb. > /jog > > On Fri, Aug 20, 2010 at 4:43 PM, Richard S. Hall <[email protected]> > wrote: > > Karl Pauls thought this could be related to Xerces asking for a > > non-existing class repeatedly. With that in mind, we looked more closely > at > > the DirectoryContent class and saw it wasn't handling synchronization > > properly. I committed a patch to fix the issues we saw. > > > > Not sure if it will help your situation or not, but you could try to > re-run > > your scenario using a trunk build (i published a snapshot if you just > want > > to grab that). > > > > -> richard > > > > On 8/20/10 12:12, Richard S. Hall wrote: > >> > >> Yeah, that sounds odd. If you look at ModuleClassLoader.loadClass(): > >> > >> // Make sure the class was not already loaded. > >> synchronized (this) > >> { > >> clazz = findLoadedClass(name); > >> } > >> > >> The first thing we do is check to see if the class is already loaded. If > >> you can create a bundle that reproduces the issue, please open up a JIRA > >> issue and attach the example bundle with steps to reproduce the issue > and > >> I'll look into it. > >> > >> -> richard > >> > >> On 8/20/10 11:55, Jacques-Olivier Goussard wrote: > >>> > >>> Hi > >>> I'm experiencing contention in my Felix bundle due to its use of > >>> Xerces. This is a well known issue that > >>> can be resolved by pooling the SAX parsers obtained from the factory, > >>> but I'd like to understand why > >>> I get into this situation. Basically, the contention happens because > >>> Xerces is calling loadclass on the > >>> current classloader, and my threads get stuck at: > >>> "Thread-34746" daemon prio=10 tid=0x0000000051b42400 nid=0x47db > >>> waiting for monitor entry [0x000000004b6d0000..0x000000004b6d0c90] > >>> java.lang.Thread.State: BLOCKED (on object monitor) > >>> at > >>> > org.apache.felix.framework.cache.DirectoryContent.getEntryAsBytes(DirectoryContent.java:72) > >>> - waiting to lock<0x00002aaab55fb4a0> (a > >>> org.apache.felix.framework.cache.DirectoryContent) > >>> at > >>> > org.apache.felix.framework.searchpolicy.ModuleImpl$ModuleClassLoader.findClass(ModuleImpl.java:1492) > >>> at > >>> > org.apache.felix.framework.searchpolicy.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:562) > >>> at > >>> > org.apache.felix.framework.searchpolicy.ModuleImpl.access$100(ModuleImpl.java:59) > >>> at > >>> > org.apache.felix.framework.searchpolicy.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1446) > >>> at java.lang.ClassLoader.loadClass(ClassLoader.java:252) > >>> at > >>> > org.apache.felix.framework.searchpolicy.ModuleImpl.getClassByDelegation(ModuleImpl.java:481) > >>> at > >>> org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1354) > >>> at > >>> org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:755) > >>> The pb is that I get this contention not only once, but all the time > >>> in the code - and Xerces is always doing a loadClass for the same > >>> class name, so I was under the impression the ModuleClassLoader would > >>> have cached the bytes and class and speedily > >>> return - in contrast it seems to always get to the 'DirectoryContent' > >>> (hence re-reading the bytes each time ?? not sure of this) > >>> Any insight on this ? > >>> On a side note, the BundleImpl.loadClass() call is actually triggered > >>> by a delegating classloader above, that very straightforwardly > >>> delegates the call (no call to findLoadedClass or other magic). > >>> Thanks > >>> /jog > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: [email protected] > >>> For additional commands, e-mail: [email protected] > >>> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
