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]
