AW: [JBoss-dev] Workaround for JUNG's RFE and load deadlock
Strike!
CGJ
-Ursprüngliche Nachricht-
Von: Alarik Myrin [mailto:[EMAIL PROTECTED]]
Gesendet: Donnerstag, 25. April 2002 06:24
An: [EMAIL PROTECTED]
Betreff: RE: [JBoss-dev] Workaround for JUNG's RFE and load deadlock
WAIT! EVERYTHING WORKS FINE!
Don't i feel like a dumb ass. Although I got the new code and built it,
when I went to copy the jars to the directory that I usually run out of
(don't ask...bad habits are hard to break), somehow the jboss-jmx-core.jar
and jboss-jmx-services.jar were still in the directory from when i built the
3.0.0RC1 release (they don't seem to get built with the MAIN branch of the
code). So the wrong version of the classes were being loaded in (ironic,
don't you think?) The line numbers in the stack traces should have given it
away hours ago. well, at least it's given me a chance to review the fix,
and i have to say: very nice. if i had to spend all night chasing down a
bug that wasn't there, at least i learned something.
Sorry if I scared anybody, or wasted anybody's time...
alarik
> -Original Message-
> From: Alarik Myrin [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, April 24, 2002 8:22 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [JBoss-dev] Workaround for JUNG's RFE and load deadlock
>
>
> Alas, I am getting a little further, but still getting a deadlock.
> Below please find the relavent stack traces. Here is my take on what
> they might mean, in case it is interesting to you:
>
> There are two relavent threads. One (the first stack trace) is trying
> to load a class needed by a stateless session bean in an effor to
> deploy the bean. The class does not exist in the bean's jar file,
> instead it exists in a another archive called picasso.zip. The other
> (the second stack trace), was spawned by a class found in picasso.zip.
> It is trying to load a class from (I suspect) a third party jar file
> called osji.jar. Because there is a seperate class loader for each
> archive, the deadlock becomes possible. Does this sound right? (I am
> not really an expert at class loading, but learning as I go :).
>
> What makes this problem quite tricky (it seems to me) is that in both
> threads the UnifiedClassLoader instance is _already locked_ by the
> time _any_ of its methods are even executed.
>
> What about this: instead of
>
>/**
>* We intercept the load class to know exactly the dependencies
>* of the underlying jar.
>*
>* Forwards request to {@link UnifiedLoaderRepository}.
>*/
>public Class loadClass(String name, boolean resolve)
>throws ClassNotFoundException
>{
> synchronized(this)
> {
> return repository.loadClass(name, resolve, this);
> }
>}
>
> What if we did this:
>
>/**
>* We intercept the load class to know exactly the dependencies
>* of the underlying jar.
>*
>* Forwards request to {@link UnifiedLoaderRepository}.
>*/
>public Class loadClass(String name, boolean resolve)
>throws ClassNotFoundException
>{
> synchronized(this.getClass())
> {
> return repository.loadClass(name, resolve, this);
> }
>}
>
> Another observation: startup appears to be taking noticably longer
> than it did with JBoss 2.4.x, even in parts of the startup process
> where I suspect it is mostly just executing my code. The CPU just
> spikes like crazy. Whenever I do a thread dump to check what it is up
> to, it always appears to be trying to load a class. Startup time
> isn't the most important thing in the world, but it does impact the
> speed of development (although I suspect that if I really understood
> the power of the deploy/undeploy functionality of JBoss 3, I wouldn't
> need to restart the server nearly so often...).
>
> Anyway, I hope all of this helps. I'll be available all week to run
> any tests you'd like, but then I start traveling for almost a month...
>
> Alarik
>
> "main" prio=5 tid=0xc7d640 nid=0x157 waiting for monitor entry
> [0x93fd000..0x93ffdc0]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:286)
> - waiting to lock <3329c48> (a
> org.jboss.mx.loading.UnifiedClassLoader)
> at
> org.jboss.mx.loading.UnifiedClassLoader.loadClassLocally(UnifiedCl
> assLoader.java:180)
> at
> org.jboss.mx.loading.UnifiedLoaderRepository.loadClass(UnifiedLoad
> erRepository.java:178)
> at
> org.jboss.mx.loading.UnifiedClassLoader.loadClass(UnifiedClassLoad
> er.java:217)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:253)
> at java.lang.ClassLoader.loadClassInternal(Cla
RE: [JBoss-dev] Workaround for JUNG's RFE and load deadlock
WAIT! EVERYTHING WORKS FINE!
Don't i feel like a dumb ass. Although I got the new code and built it,
when I went to copy the jars to the directory that I usually run out of
(don't ask...bad habits are hard to break), somehow the jboss-jmx-core.jar
and jboss-jmx-services.jar were still in the directory from when i built the
3.0.0RC1 release (they don't seem to get built with the MAIN branch of the
code). So the wrong version of the classes were being loaded in (ironic,
don't you think?) The line numbers in the stack traces should have given it
away hours ago. well, at least it's given me a chance to review the fix,
and i have to say: very nice. if i had to spend all night chasing down a
bug that wasn't there, at least i learned something.
Sorry if I scared anybody, or wasted anybody's time...
alarik
> -Original Message-
> From: Alarik Myrin [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, April 24, 2002 8:22 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [JBoss-dev] Workaround for JUNG's RFE and load deadlock
>
>
> Alas, I am getting a little further, but still getting a
> deadlock. Below please find the relavent stack traces. Here is
> my take on what they might mean, in case it is interesting to you:
>
> There are two relavent threads. One (the first stack trace) is
> trying to load a class needed by a stateless session bean in an
> effor to deploy the bean. The class does not exist in the bean's
> jar file, instead it exists in a another archive called
> picasso.zip. The other (the second stack trace), was spawned by
> a class found in picasso.zip. It is trying to load a class from
> (I suspect) a third party jar file called osji.jar. Because
> there is a seperate class loader for each archive, the deadlock
> becomes possible. Does this sound right? (I am not really an
> expert at class loading, but learning as I go :).
>
> What makes this problem quite tricky (it seems to me) is that in
> both threads the UnifiedClassLoader instance is _already locked_
> by the time _any_ of its methods are even executed.
>
> What about this: instead of
>
>/**
>* We intercept the load class to know exactly the dependencies
>* of the underlying jar.
>*
>* Forwards request to {@link UnifiedLoaderRepository}.
>*/
>public Class loadClass(String name, boolean resolve)
>throws ClassNotFoundException
>{
> synchronized(this)
> {
> return repository.loadClass(name, resolve, this);
> }
>}
>
> What if we did this:
>
>/**
>* We intercept the load class to know exactly the dependencies
>* of the underlying jar.
>*
>* Forwards request to {@link UnifiedLoaderRepository}.
>*/
>public Class loadClass(String name, boolean resolve)
>throws ClassNotFoundException
>{
> synchronized(this.getClass())
> {
> return repository.loadClass(name, resolve, this);
> }
>}
>
> Another observation: startup appears to be taking noticably
> longer than it did with JBoss 2.4.x, even in parts of the startup
> process where I suspect it is mostly just executing my code. The
> CPU just spikes like crazy. Whenever I do a thread dump to check
> what it is up to, it always appears to be trying to load a class.
> Startup time isn't the most important thing in the world, but it
> does impact the speed of development (although I suspect that if
> I really understood the power of the deploy/undeploy
> functionality of JBoss 3, I wouldn't need to restart the server
> nearly so often...).
>
> Anyway, I hope all of this helps. I'll be available all week to
> run any tests you'd like, but then I start traveling for almost a month...
>
> Alarik
>
> "main" prio=5 tid=0xc7d640 nid=0x157 waiting for monitor entry
> [0x93fd000..0x93ffdc0]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:286)
> - waiting to lock <3329c48> (a
> org.jboss.mx.loading.UnifiedClassLoader)
> at
> org.jboss.mx.loading.UnifiedClassLoader.loadClassLocally(UnifiedCl
> assLoader.java:180)
> at
> org.jboss.mx.loading.UnifiedLoaderRepository.loadClass(UnifiedLoad
> erRepository.java:178)
> at
> org.jboss.mx.loading.UnifiedClassLoader.loadClass(UnifiedClassLoad
> er.java:217)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:253)
> at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313)
> - locked <330edc0> (a org.jboss.mx.loading.UnifiedClassLoader)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:195)
> at
Re: [JBoss-dev] Workaround for JUNG's RFE and load deadlock
Is there any chance of fixing this by making the LoaderRepository into a
classloader, and the only one accessible externally? Maybe it could check
the cache unsynchronized, and then, synchronized on itself, try to load the
class from its UnifiedClassLoaders, so only one call at a time could get to
the native code and the evil method. Would this require that we be able to
set the classloader on the classes ?
david jencks
On 2002.04.24 20:44:05 -0400 Alarik Myrin wrote:
> Never mind the suggestion of synchronizing on (this.getClass()), you just
> run into the same problem. I'll try and given the matter some thought,
> although I don't know how much hope I'd hold out for a brilliant idea
> from
> me...
>
> Alarik
>
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]On Behalf Of
> > Alarik Myrin
> > Sent: Wednesday, April 24, 2002 8:22 PM
> > To: [EMAIL PROTECTED]
> > Subject: RE: [JBoss-dev] Workaround for JUNG's RFE and load deadlock
> >
> >
> > Alas, I am getting a little further, but still getting a deadlock.
> Below
> > please find the relavent stack traces. Here is my take on what they
> might
> > mean, in case it is interesting to you:
> >
> > There are two relavent threads. One (the first stack trace) is trying
> to
> > load a class needed by a stateless session bean in an effor to deploy
> the
> > bean. The class does not exist in the bean's jar file, instead
> > it exists in
> > a another archive called picasso.zip. The other (the second stack
> trace),
> > was spawned by a class found in picasso.zip. It is trying to load a
> class
> > from (I suspect) a third party jar file called osji.jar. Because
> > there is a
> > seperate class loader for each archive, the deadlock becomes
> > possible. Does
> > this sound right? (I am not really an expert at class loading,
> > but learning
> > as I go :).
> >
> > What makes this problem quite tricky (it seems to me) is that in both
> > threads the UnifiedClassLoader instance is _already locked_ by the time
> > _any_ of its methods are even executed.
> >
> > What about this: instead of
> >
> >/**
> >* We intercept the load class to know exactly the dependencies
> >* of the underlying jar.
> >*
> >* Forwards request to {@link UnifiedLoaderRepository}.
> >*/
> >public Class loadClass(String name, boolean resolve)
> >throws ClassNotFoundException
> >{
> > synchronized(this)
> > {
> > return repository.loadClass(name, resolve, this);
> > }
> >}
> >
> > What if we did this:
> >
> >/**
> >* We intercept the load class to know exactly the dependencies
> >* of the underlying jar.
> >*
> >* Forwards request to {@link UnifiedLoaderRepository}.
> >*/
> >public Class loadClass(String name, boolean resolve)
> >throws ClassNotFoundException
> >{
> > synchronized(this.getClass())
> > {
> > return repository.loadClass(name, resolve, this);
> > }
> >}
> >
> > Another observation: startup appears to be taking noticably
> > longer than it
> > did with JBoss 2.4.x, even in parts of the startup process where I
> suspect
> > it is mostly just executing my code. The CPU just spikes like crazy.
> > Whenever I do a thread dump to check what it is up to, it always
> > appears to
> > be trying to load a class. Startup time isn't the most important thing
> in
> > the world, but it does impact the speed of development (although I
> suspect
> > that if I really understood the power of the deploy/undeploy
> functionality
> > of JBoss 3, I wouldn't need to restart the server nearly so often...).
> >
> > Anyway, I hope all of this helps. I'll be available all week to run
> any
> > tests you'd like, but then I start traveling for almost a month...
> >
> > Alarik
> >
> > "main" prio=5 tid=0xc7d640 nid=0x157 waiting for monitor entry
> > [0x93fd000..0x93ffdc0]
> > at java.lang.ClassLoader.loadClass(ClassLoader.java:286)
> > - waiting to lock <3329c48> (a
> > org.jboss.mx.loading.UnifiedClassLoader)
> > at
> > org.jboss.mx.loading.UnifiedClassLoader.loadClassLocally(UnifiedCl
> > assLoader.
> > java:180)
> > at
> > org.jboss.mx.loading.UnifiedLoaderRepository.loadClass(UnifiedLoad
> > erReposito
> > ry.
RE: [JBoss-dev] Workaround for JUNG's RFE and load deadlock
g.reflect.Method.invoke(Native Method) > at > org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispat > cher.java:284) > at > org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:492) > at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:320) > at org.jboss.system.server.ServerImpl.start(ServerImpl.java:218) > at org.jboss.Main.boot(Main.java:142) > at org.jboss.Main$1.run(Main.java:375) > at java.lang.Thread.run(Thread.java:484) > > "Thread-29" prio=5 tid=0xb59a6b0 nid=0xe6 waiting for monitor entry > [0xc6af000..0xc6afdc0] > at java.lang.ClassLoader.loadClass(ClassLoader.java:286) > - waiting to lock <330edc0> (a > org.jboss.mx.loading.UnifiedClassLoader) > at > org.jboss.mx.loading.UnifiedClassLoader.loadClassLocally(UnifiedClassLoader. > java:180) > at > org.jboss.mx.loading.UnifiedLoaderRepository.loadClass(UnifiedLoaderReposito > ry.java:178) > at > org.jboss.mx.loading.UnifiedClassLoader.loadClass(UnifiedClassLoader.java:21 > 7) > at java.lang.ClassLoader.loadClass(ClassLoader.java:253) > at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313) > - locked <3329c48> (a org.jboss.mx.loading.UnifiedClassLoader) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:120) > at com.odi.imp.Server.create(Server.java:106) > at com.odi.imp.ObjectManager.(ObjectManager.java:4093) > at com.odi.Session.create(Session.java:502) > - locked <3887ac0> (a java.util.Hashtable) > at > com.sknt.picasso.lib.PicassoServerEnv.startJMS(PicassoServerEnv.java:393) > at > com.sknt.picasso.lib.PicassoServerEnv$TestJMS.run(PicassoServerEnv.java:771) > - locked <44893c8> (a com.sknt.picasso.lib.PicassoServerEnv$TestJMS) > at java.lang.Thread.run(Thread.java:484) > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of marc > > fleury > > Sent: Wednesday, April 24, 2002 10:36 AM > > To: [EMAIL PROTECTED] > > Subject: Re: [JBoss-dev] Workaround for JUNG's RFE and load deadlock > > > > > > Done, > > > > Dave please test > > > > Jung, thanks man > > > > marcf > > > > > > * * * > > > > View thread online: > > http://jboss.org/forums/thread.jsp?forum=66&thread=13851 > > > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Workaround for JUNG's RFE and load deadlock
Never mind the suggestion of synchronizing on (this.getClass()), you just
run into the same problem. I'll try and given the matter some thought,
although I don't know how much hope I'd hold out for a brilliant idea from
me...
Alarik
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of
> Alarik Myrin
> Sent: Wednesday, April 24, 2002 8:22 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [JBoss-dev] Workaround for JUNG's RFE and load deadlock
>
>
> Alas, I am getting a little further, but still getting a deadlock. Below
> please find the relavent stack traces. Here is my take on what they might
> mean, in case it is interesting to you:
>
> There are two relavent threads. One (the first stack trace) is trying to
> load a class needed by a stateless session bean in an effor to deploy the
> bean. The class does not exist in the bean's jar file, instead
> it exists in
> a another archive called picasso.zip. The other (the second stack trace),
> was spawned by a class found in picasso.zip. It is trying to load a class
> from (I suspect) a third party jar file called osji.jar. Because
> there is a
> seperate class loader for each archive, the deadlock becomes
> possible. Does
> this sound right? (I am not really an expert at class loading,
> but learning
> as I go :).
>
> What makes this problem quite tricky (it seems to me) is that in both
> threads the UnifiedClassLoader instance is _already locked_ by the time
> _any_ of its methods are even executed.
>
> What about this: instead of
>
>/**
>* We intercept the load class to know exactly the dependencies
>* of the underlying jar.
>*
>* Forwards request to {@link UnifiedLoaderRepository}.
>*/
>public Class loadClass(String name, boolean resolve)
>throws ClassNotFoundException
>{
> synchronized(this)
> {
> return repository.loadClass(name, resolve, this);
> }
>}
>
> What if we did this:
>
>/**
>* We intercept the load class to know exactly the dependencies
>* of the underlying jar.
>*
>* Forwards request to {@link UnifiedLoaderRepository}.
>*/
>public Class loadClass(String name, boolean resolve)
>throws ClassNotFoundException
>{
> synchronized(this.getClass())
> {
> return repository.loadClass(name, resolve, this);
> }
>}
>
> Another observation: startup appears to be taking noticably
> longer than it
> did with JBoss 2.4.x, even in parts of the startup process where I suspect
> it is mostly just executing my code. The CPU just spikes like crazy.
> Whenever I do a thread dump to check what it is up to, it always
> appears to
> be trying to load a class. Startup time isn't the most important thing in
> the world, but it does impact the speed of development (although I suspect
> that if I really understood the power of the deploy/undeploy functionality
> of JBoss 3, I wouldn't need to restart the server nearly so often...).
>
> Anyway, I hope all of this helps. I'll be available all week to run any
> tests you'd like, but then I start traveling for almost a month...
>
> Alarik
>
> "main" prio=5 tid=0xc7d640 nid=0x157 waiting for monitor entry
> [0x93fd000..0x93ffdc0]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:286)
> - waiting to lock <3329c48> (a
> org.jboss.mx.loading.UnifiedClassLoader)
> at
> org.jboss.mx.loading.UnifiedClassLoader.loadClassLocally(UnifiedCl
> assLoader.
> java:180)
> at
> org.jboss.mx.loading.UnifiedLoaderRepository.loadClass(UnifiedLoad
> erReposito
> ry.java:178)
> at
> org.jboss.mx.loading.UnifiedClassLoader.loadClass(UnifiedClassLoad
> er.java:21
> 7)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:253)
> at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313)
> - locked <330edc0> (a org.jboss.mx.loading.UnifiedClassLoader)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:195)
> at com.odi.ClassInfo.lookupClassInfoByName(ClassInfo.java:608)
> at com.odi.ClassInfo.lookupClassInfoByName(ClassInfo.java:589)
> at com.odi.ClassInfo.findAndRegister(ClassInfo.java:502)
> at com.odi.ClassInfo.get(ClassInfo.java:483)
> at
> com.sknt.picasso.lib.gui.TableConfiguration.getClassInfoInstance(T
> ableConfig
> uration.java)
> at
> com.sknt.picasso.lib.gui.TableConfiguration.(TableConfigur
> ation.java
> )
> at java.lang.Class.forName0(
RE: [JBoss-dev] Workaround for JUNG's RFE and load deadlock
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313) - locked <3329c48> (a org.jboss.mx.loading.UnifiedClassLoader) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:120) at com.odi.imp.Server.create(Server.java:106) at com.odi.imp.ObjectManager.(ObjectManager.java:4093) at com.odi.Session.create(Session.java:502) - locked <3887ac0> (a java.util.Hashtable) at com.sknt.picasso.lib.PicassoServerEnv.startJMS(PicassoServerEnv.java:393) at com.sknt.picasso.lib.PicassoServerEnv$TestJMS.run(PicassoServerEnv.java:771) - locked <44893c8> (a com.sknt.picasso.lib.PicassoServerEnv$TestJMS) at java.lang.Thread.run(Thread.java:484) > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of marc > fleury > Sent: Wednesday, April 24, 2002 10:36 AM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] Workaround for JUNG's RFE and load deadlock > > > Done, > > Dave please test > > Jung, thanks man > > marcf > > > * * * > > View thread online: > http://jboss.org/forums/thread.jsp?forum=66&thread=13851 > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: AW: [JBoss-dev] Workaround for JUNG's RFE and load deadlock
yeah... well.. one more thing do we have the same getResourceInternal that would lock the cl or are we clear on the resource front? marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Jung |, Dr. Christoph |Sent: Wednesday, April 24, 2002 7:48 AM |To: '[EMAIL PROTECTED]' |Subject: AW: AW: [JBoss-dev] Workaround for JUNG's RFE and load deadlock | | |Marc, | |But the way you are juggling is really worth waiting for Sun to |understand a |single percent |of what is happening at Jboss ;-) | |CGJ | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Workaround for JUNG's RFE and load deadlock
YES!!! Looks good. will continue to run with the -XDebug flag and let you know if anything else comes up. On Wed, 2002-04-24 at 10:35, marc fleury wrote: > Done, > > Dave please test > > Jung, thanks man > > marcf > > > * * * > > View thread online: http://jboss.org/forums/thread.jsp?forum=66&thread=13851 > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
AW: AW: [JBoss-dev] Workaround for JUNG's RFE and load deadlock
Marc, But the way you are juggling is really worth waiting for Sun to understand a single percent of what is happening at Jboss ;-) CGJ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Workaround for JUNG's RFE and load deadlock
Done, Dave please test Jung, thanks man marcf * * * View thread online: http://jboss.org/forums/thread.jsp?forum=66&thread=13851 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Workaround for JUNG's RFE and load deadlock
The answer is the Jung patch. I will add that right now * * * View thread online: http://jboss.org/forums/thread.jsp?forum=66&thread=13851 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: AW: [JBoss-dev] Workaround for JUNG's RFE and load deadlock
This is about right, although I haven't gone through the analysis, I will commit this and Dave if you can try it I would appreciate it. It is the case of 2 threads going throught the same UCL one through loadClassInternal and one through loadClass. Jung, i believe your RFE is very valid, there is a total assymetry between LCI and LC that are just broken. If you allow one you must allow the other, otherwise you are juggling like we do marcf * * * View thread online: http://jboss.org/forums/thread.jsp?forum=66&thread=13890 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: AW: [JBoss-dev] Workaround for JUNG's RFE and load deadlock
No file uploaded .. On Wed, 2002-04-24 at 09:55, Jung , Dr. Christoph wrote: > I hope this patch will also meet your scenario of having 2 threads coming > through a single UnifiedClassLoader ... > > http://sourceforge.net/tracker/index.php?func=detail&aid=548098&group_id=228 > 66&atid=376687 > > Weird, > CGJ > -Ursprüngliche Nachricht- > Von: Dave Smith [mailto:[EMAIL PROTECTED]] > Gesendet: Mittwoch, 24. April 2002 13:45 > An: [EMAIL PROTECTED] > Betreff: Re: [JBoss-dev] Workaround for JUNG's RFE and load deadlock > > > Well my simple test cases worked but I pulled out the heavy hitters and > managed to get a dead lock. Stack traces follow ... > > "Thread-23" prio=5 tid=0x81a4f60 nid=0x69cb waiting on monitor > [0xbe7fe000..0xbe7ffad8] > at java.lang.Object.wait(Native Method) > - waiting on <43a28660> (a > org.jboss.mx.loading.UnifiedLoaderRepository) > at java.lang.Object.wait(Object.java:420) > at > org.jboss.mx.loading.UnifiedLoaderRepository.sync(UnifiedLoaderRepository.ja > va:717) > - locked <43a28660> (a > org.jboss.mx.loading.UnifiedLoaderRepository) > at > org.jboss.mx.loading.UnifiedLoaderRepository.releaseLock(UnifiedLoaderReposi > tory.java:313) > at > org.jboss.mx.loading.UnifiedLoaderRepository.loadClass(UnifiedLoaderReposito > ry.java:261) > at > org.jboss.mx.loading.UnifiedClassLoader.loadClass(UnifiedClassLoader.java:21 > 7) > at java.lang.ClassLoader.loadClass(ClassLoader.java:255) > at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:315) > - locked <43f72c18> (a org.jboss.mx.loading.UnifiedClassLoader) > at iaik.security.cipher.j.a(RawCipher.java) > at iaik.security.cipher.n.a(RawBlockCipher64.java) > at iaik.security.cipher.r.engineInit(BufferedCipher.java) > at javax.crypto.Cipher.init(Cipher.java) > at iaik.pkcs.pkcs7.SignerInfo.encodeCalled(SignerInfo.java) > at iaik.asn1.ASN1Object.encodeObject(ASN1Object.java) > at iaik.asn1.DerCoder.a(DerCoder.java) > at iaik.asn1.DerCoder.a(DerCoder.java) > at iaik.asn1.ConstructedType.encode(ConstructedType.java) > at iaik.asn1.ASN1Object.encodeObject(ASN1Object.java) > at iaik.asn1.DerCoder.a(DerCoder.java) > at iaik.asn1.DerCoder.a(DerCoder.java) > at iaik.asn1.ConstructedType.encode(ConstructedType.java) > at iaik.asn1.SET.encode(SET.java) > at iaik.asn1.ASN1Object.encodeObject(ASN1Object.java) > at iaik.asn1.DerCoder.a(DerCoder.java) > at iaik.asn1.DerCoder.a(DerCoder.java) > at iaik.asn1.ConstructedType.encode(ConstructedType.java) > at iaik.asn1.ASN1Object.encodeObject(ASN1Object.java) > at iaik.asn1.DerCoder.a(DerCoder.java) > at iaik.asn1.CON_SPEC.encode(CON_SPEC.java) > at iaik.asn1.ASN1Object.encodeObject(ASN1Object.java) > at iaik.asn1.DerCoder.a(DerCoder.java) > at iaik.asn1.DerCoder.a(DerCoder.java) > at iaik.asn1.ConstructedType.encode(ConstructedType.java) > at iaik.asn1.ASN1Object.encodeObject(ASN1Object.java) > at iaik.asn1.DerCoder.a(DerCoder.java) > at iaik.asn1.DerCoder.a(DerCoder.java) > at iaik.asn1.DerCoder.encode(DerCoder.java) > - locked <441342d0> (a iaik.asn1.SEQUENCE) > at iaik.asn1.DerCoder.encodeTo(DerCoder.java) > at iaik.asn1.DerCoder.encodeTo(DerCoder.java) > at > iaik.pkcs.pkcs7.ContentInfoStream.writeTo(ContentInfoStream.java) > at com.entrust.toolkit.a.run(PKCS7EncodeStream.java) > at java.lang.Thread.run(Thread.java:484) > > > "CCRAPoll" prio=5 tid=0x81b3940 nid=0x69b4 waiting for monitor entry > [0xbb5ff000..0xbb5ffad8] > at > org.jboss.mx.loading.UnifiedLoaderRepository.lock(UnifiedLoaderRepository.ja > va:283) > - waiting to lock <43f72c18> (a > org.jboss.mx.loading.UnifiedClassLoader) > at > org.jboss.mx.loading.UnifiedLoaderRepository.loadClass(UnifiedLoaderReposito > ry.java:156) > at > org.jboss.mx.loading.UnifiedClassLoader.loadClass(UnifiedClassLoader.java:21 > 7) > at java.lang.ClassLoader.loadClass(ClassLoader.java:255) > at java.security.Security.getImpl(Security.java:815) > at java.security.Signature.getInstance(Signature.java:172) > at iaik.x509.X509CRL.verify(X509CRL.java) > at iaik.x509.X509CRL.verify(X509CRL.java) > at > com.entrust.toolkit.x509.revocation.X509CRLRS.validateCRL(X509CRLRS.java) > at > com.entrust.toolkit.x509.revocation.CachedCRLRS.loadC
Re: [JBoss-dev] Workaround for JUNG's RFE and load deadlock
Yes On Wed, 2002-04-24 at 09:52, marc fleury wrote: > > > "Thread-23" prio=5 tid=0x81a4f60 nid=0x69cb waiting > > on monitor > > [0xbe7fe000..0xbe7ffad8] > > > "CCRAPoll" prio=5 tid=0x81b3940 nid=0x69b4 waiting > > for monitor entry > > [0xbb5ff000..0xbb5ffad8] > > > "Thread-23" prio=5 tid=0x81a4f60 nid=0x69cb waiting > > on monitor > > [0xbe7fe000..0xbe7ffad8] > > You list Thread-23 twice, I will assume it is a typo > > marcf > > > > * * * > > View thread online: http://jboss.org/forums/thread.jsp?forum=66&thread=13851 > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Workaround for JUNG's RFE and load deadlock
> "Thread-23" prio=5 tid=0x81a4f60 nid=0x69cb waiting > on monitor > [0xbe7fe000..0xbe7ffad8] > "CCRAPoll" prio=5 tid=0x81b3940 nid=0x69b4 waiting > for monitor entry > [0xbb5ff000..0xbb5ffad8] > "Thread-23" prio=5 tid=0x81a4f60 nid=0x69cb waiting > on monitor > [0xbe7fe000..0xbe7ffad8] You list Thread-23 twice, I will assume it is a typo marcf * * * View thread online: http://jboss.org/forums/thread.jsp?forum=66&thread=13851 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
AW: [JBoss-dev] Workaround for JUNG's RFE and load deadlock
I hope this patch will also meet your scenario of having 2 threads coming through a single UnifiedClassLoader ... http://sourceforge.net/tracker/index.php?func=detail&aid=548098&group_id=228 66&atid=376687 Weird, CGJ -Ursprüngliche Nachricht- Von: Dave Smith [mailto:[EMAIL PROTECTED]] Gesendet: Mittwoch, 24. April 2002 13:45 An: [EMAIL PROTECTED] Betreff: Re: [JBoss-dev] Workaround for JUNG's RFE and load deadlock Well my simple test cases worked but I pulled out the heavy hitters and managed to get a dead lock. Stack traces follow ... "Thread-23" prio=5 tid=0x81a4f60 nid=0x69cb waiting on monitor [0xbe7fe000..0xbe7ffad8] at java.lang.Object.wait(Native Method) - waiting on <43a28660> (a org.jboss.mx.loading.UnifiedLoaderRepository) at java.lang.Object.wait(Object.java:420) at org.jboss.mx.loading.UnifiedLoaderRepository.sync(UnifiedLoaderRepository.ja va:717) - locked <43a28660> (a org.jboss.mx.loading.UnifiedLoaderRepository) at org.jboss.mx.loading.UnifiedLoaderRepository.releaseLock(UnifiedLoaderReposi tory.java:313) at org.jboss.mx.loading.UnifiedLoaderRepository.loadClass(UnifiedLoaderReposito ry.java:261) at org.jboss.mx.loading.UnifiedClassLoader.loadClass(UnifiedClassLoader.java:21 7) at java.lang.ClassLoader.loadClass(ClassLoader.java:255) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:315) - locked <43f72c18> (a org.jboss.mx.loading.UnifiedClassLoader) at iaik.security.cipher.j.a(RawCipher.java) at iaik.security.cipher.n.a(RawBlockCipher64.java) at iaik.security.cipher.r.engineInit(BufferedCipher.java) at javax.crypto.Cipher.init(Cipher.java) at iaik.pkcs.pkcs7.SignerInfo.encodeCalled(SignerInfo.java) at iaik.asn1.ASN1Object.encodeObject(ASN1Object.java) at iaik.asn1.DerCoder.a(DerCoder.java) at iaik.asn1.DerCoder.a(DerCoder.java) at iaik.asn1.ConstructedType.encode(ConstructedType.java) at iaik.asn1.ASN1Object.encodeObject(ASN1Object.java) at iaik.asn1.DerCoder.a(DerCoder.java) at iaik.asn1.DerCoder.a(DerCoder.java) at iaik.asn1.ConstructedType.encode(ConstructedType.java) at iaik.asn1.SET.encode(SET.java) at iaik.asn1.ASN1Object.encodeObject(ASN1Object.java) at iaik.asn1.DerCoder.a(DerCoder.java) at iaik.asn1.DerCoder.a(DerCoder.java) at iaik.asn1.ConstructedType.encode(ConstructedType.java) at iaik.asn1.ASN1Object.encodeObject(ASN1Object.java) at iaik.asn1.DerCoder.a(DerCoder.java) at iaik.asn1.CON_SPEC.encode(CON_SPEC.java) at iaik.asn1.ASN1Object.encodeObject(ASN1Object.java) at iaik.asn1.DerCoder.a(DerCoder.java) at iaik.asn1.DerCoder.a(DerCoder.java) at iaik.asn1.ConstructedType.encode(ConstructedType.java) at iaik.asn1.ASN1Object.encodeObject(ASN1Object.java) at iaik.asn1.DerCoder.a(DerCoder.java) at iaik.asn1.DerCoder.a(DerCoder.java) at iaik.asn1.DerCoder.encode(DerCoder.java) - locked <441342d0> (a iaik.asn1.SEQUENCE) at iaik.asn1.DerCoder.encodeTo(DerCoder.java) at iaik.asn1.DerCoder.encodeTo(DerCoder.java) at iaik.pkcs.pkcs7.ContentInfoStream.writeTo(ContentInfoStream.java) at com.entrust.toolkit.a.run(PKCS7EncodeStream.java) at java.lang.Thread.run(Thread.java:484) "CCRAPoll" prio=5 tid=0x81b3940 nid=0x69b4 waiting for monitor entry [0xbb5ff000..0xbb5ffad8] at org.jboss.mx.loading.UnifiedLoaderRepository.lock(UnifiedLoaderRepository.ja va:283) - waiting to lock <43f72c18> (a org.jboss.mx.loading.UnifiedClassLoader) at org.jboss.mx.loading.UnifiedLoaderRepository.loadClass(UnifiedLoaderReposito ry.java:156) at org.jboss.mx.loading.UnifiedClassLoader.loadClass(UnifiedClassLoader.java:21 7) at java.lang.ClassLoader.loadClass(ClassLoader.java:255) at java.security.Security.getImpl(Security.java:815) at java.security.Signature.getInstance(Signature.java:172) at iaik.x509.X509CRL.verify(X509CRL.java) at iaik.x509.X509CRL.verify(X509CRL.java) at com.entrust.toolkit.x509.revocation.X509CRLRS.validateCRL(X509CRLRS.java) at com.entrust.toolkit.x509.revocation.CachedCRLRS.loadCRLs(CachedCRLRS.java) - locked <437fbb80> (a com.entrust.toolkit.x509.revocation.CachedCRLRS) at com.entrust.toolkit.x509.revocation.X509CRLRS.findCRL(X509CRLRS.java) - locked <437fbb80> (a com.entrust.toolkit.x509.revocation.CachedCRLRS) at com.entrust.toolkit.x509.revocation.X509CRLRS.check(X509CRLRS.java) at com.entrust.toolkit.x509.revocation.CollectionRS.check(CollectionRS.java) at com.entrust.toolkit.x509.revocation.CollectionRS.check(CollectionRS.java) at com.entrust.toolkit.x509.certstore.c.a(Nod
Re: [JBoss-dev] Workaround for JUNG's RFE and load deadlock
Well my simple test cases worked but I pulled out the heavy hitters and managed to get a dead lock. Stack traces follow ... "Thread-23" prio=5 tid=0x81a4f60 nid=0x69cb waiting on monitor [0xbe7fe000..0xbe7ffad8] at java.lang.Object.wait(Native Method) - waiting on <43a28660> (a org.jboss.mx.loading.UnifiedLoaderRepository) at java.lang.Object.wait(Object.java:420) at org.jboss.mx.loading.UnifiedLoaderRepository.sync(UnifiedLoaderRepository.java:717) - locked <43a28660> (a org.jboss.mx.loading.UnifiedLoaderRepository) at org.jboss.mx.loading.UnifiedLoaderRepository.releaseLock(UnifiedLoaderRepository.java:313) at org.jboss.mx.loading.UnifiedLoaderRepository.loadClass(UnifiedLoaderRepository.java:261) at org.jboss.mx.loading.UnifiedClassLoader.loadClass(UnifiedClassLoader.java:217) at java.lang.ClassLoader.loadClass(ClassLoader.java:255) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:315) - locked <43f72c18> (a org.jboss.mx.loading.UnifiedClassLoader) at iaik.security.cipher.j.a(RawCipher.java) at iaik.security.cipher.n.a(RawBlockCipher64.java) at iaik.security.cipher.r.engineInit(BufferedCipher.java) at javax.crypto.Cipher.init(Cipher.java) at iaik.pkcs.pkcs7.SignerInfo.encodeCalled(SignerInfo.java) at iaik.asn1.ASN1Object.encodeObject(ASN1Object.java) at iaik.asn1.DerCoder.a(DerCoder.java) at iaik.asn1.DerCoder.a(DerCoder.java) at iaik.asn1.ConstructedType.encode(ConstructedType.java) at iaik.asn1.ASN1Object.encodeObject(ASN1Object.java) at iaik.asn1.DerCoder.a(DerCoder.java) at iaik.asn1.DerCoder.a(DerCoder.java) at iaik.asn1.ConstructedType.encode(ConstructedType.java) at iaik.asn1.SET.encode(SET.java) at iaik.asn1.ASN1Object.encodeObject(ASN1Object.java) at iaik.asn1.DerCoder.a(DerCoder.java) at iaik.asn1.DerCoder.a(DerCoder.java) at iaik.asn1.ConstructedType.encode(ConstructedType.java) at iaik.asn1.ASN1Object.encodeObject(ASN1Object.java) at iaik.asn1.DerCoder.a(DerCoder.java) at iaik.asn1.CON_SPEC.encode(CON_SPEC.java) at iaik.asn1.ASN1Object.encodeObject(ASN1Object.java) at iaik.asn1.DerCoder.a(DerCoder.java) at iaik.asn1.DerCoder.a(DerCoder.java) at iaik.asn1.ConstructedType.encode(ConstructedType.java) at iaik.asn1.ASN1Object.encodeObject(ASN1Object.java) at iaik.asn1.DerCoder.a(DerCoder.java) at iaik.asn1.DerCoder.a(DerCoder.java) at iaik.asn1.DerCoder.encode(DerCoder.java) - locked <441342d0> (a iaik.asn1.SEQUENCE) at iaik.asn1.DerCoder.encodeTo(DerCoder.java) at iaik.asn1.DerCoder.encodeTo(DerCoder.java) at iaik.pkcs.pkcs7.ContentInfoStream.writeTo(ContentInfoStream.java) at com.entrust.toolkit.a.run(PKCS7EncodeStream.java) at java.lang.Thread.run(Thread.java:484) "CCRAPoll" prio=5 tid=0x81b3940 nid=0x69b4 waiting for monitor entry [0xbb5ff000..0xbb5ffad8] at org.jboss.mx.loading.UnifiedLoaderRepository.lock(UnifiedLoaderRepository.java:283) - waiting to lock <43f72c18> (a org.jboss.mx.loading.UnifiedClassLoader) at org.jboss.mx.loading.UnifiedLoaderRepository.loadClass(UnifiedLoaderRepository.java:156) at org.jboss.mx.loading.UnifiedClassLoader.loadClass(UnifiedClassLoader.java:217) at java.lang.ClassLoader.loadClass(ClassLoader.java:255) at java.security.Security.getImpl(Security.java:815) at java.security.Signature.getInstance(Signature.java:172) at iaik.x509.X509CRL.verify(X509CRL.java) at iaik.x509.X509CRL.verify(X509CRL.java) at com.entrust.toolkit.x509.revocation.X509CRLRS.validateCRL(X509CRLRS.java) at com.entrust.toolkit.x509.revocation.CachedCRLRS.loadCRLs(CachedCRLRS.java) - locked <437fbb80> (a com.entrust.toolkit.x509.revocation.CachedCRLRS) at com.entrust.toolkit.x509.revocation.X509CRLRS.findCRL(X509CRLRS.java) - locked <437fbb80> (a com.entrust.toolkit.x509.revocation.CachedCRLRS) at com.entrust.toolkit.x509.revocation.X509CRLRS.check(X509CRLRS.java) at com.entrust.toolkit.x509.revocation.CollectionRS.check(CollectionRS.java) at com.entrust.toolkit.x509.revocation.CollectionRS.check(CollectionRS.java) at com.entrust.toolkit.x509.certstore.c.a(Node.java) at com.entrust.toolkit.x509.certstore.c.a(Node.java) at com.entrust.toolkit.x509.certstore.CollectionCS.validate(CollectionCS.java) - locked <437fb078> (a com.entrust.toolkit.x509.certstore.CollectionCS) at com.entrust.toolkit.credentials.Profile.a(Profile.java) at com.entrust.toolkit.credentials.Profile.a(Profile.java) - locked <43fe7ac0> (a com.entrust.toolkit.credentials.Profile) at com.entrust.toolkit.credentials.Profile.(Profile.java) at com.e
Re: [JBoss-dev] Workaround for JUNG's RFE and load deadlock
> > >PS: instructions >remove your current codebase >cvs co jboss-all > I think this is extreme, but certainly won't hurt > >build/sh build.sh > If you choose not to re-checkout then: build/build.sh clean most =) --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Workaround for JUNG's RFE and load deadlock
So I commited a workaround for the RFE that jung has with SUN. Essentially it all amounts to making the ULR mono-threaded and relinqueshing the locks as we go. It's pretty simple stuff since it is a subset of the locking in the container. Plus it is the kind of stuff I get off with :) Ok seriously now, the stuff boots, however *i haven't tested it*. I know there is some multithreaded loading in the server because it locked when I put a buggy "workaround" and it comes from the clustering code BUT since I didn't have a reproducible case of deadlock in my code I haven't tested. I don't know if this actually fixes anything, I just think it does. Dave, Alarik, can I ask you guys to test if you deadlock. please update from CVS for the latest JMX code. thanks please let me know on this thread if the stuff doesn't work (could very well be since, again, I haven't tested it with a real deadlock). most likely I will need a few iterations on this :) marcf PS: instructions remove your current codebase cvs co jboss-all build/sh build.sh cd output/jboss3.1... put your files in the deploy dir bin/sh run.sh report what goes on * * * View thread online: http://jboss.org/forums/thread.jsp?forum=66&thread=13851 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
