You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Jacques-Olivier Goussard <jo...@gmail.com> on 2010/08/20 17:55:50 UTC
Classloader lock
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: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Classloader lock
Posted by Will Budic <vi...@gmail.com>.
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 <jo...@gmail.com>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 <he...@ungoverned.org>
> 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: users-unsubscribe@felix.apache.org
> >>> For additional commands, e-mail: users-help@felix.apache.org
> >>>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > For additional commands, e-mail: users-help@felix.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: Classloader lock
Posted by Jacques-Olivier Goussard <jo...@gmail.com>.
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 <he...@ungoverned.org> 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: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Classloader lock
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Classloader lock
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org