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]
