Actually .... Ken & I talked at length about this bug yesterday.
The potential exists for someone who is using a worker thread from the
corba threadpool has set the worker thread's context classloader to the
WebappClassloader and then added a Work item to the CORBA thread pool
work queue.
When a Work item is added to the corba thread pool work queue, if there
is not an available worker thread to handle that new Work request, a new
worker thread is created. It's at worker thread creation time where
the parent thread's context classloader is stored for reset later.
So, it's possible that a worker thread is being created with an improper
context classloader where it will be saved and from then on will always
have that improper context classloader set when that worker thread
handles new and additional work.
Hence, both Ken & I believe the fix for this potential scenario is to
have store the (correct) context classloader at corba thread pool
creation time which happens at orb init time. But, there is a potential
issue that needs to be investigated as Ken described in an earlier
email. That happens to be what are the potential classloaders that
could be active on the thread that initiates a lazyily initiated ORB init?
I think once we have figured out what context class loader should be the
one that worker threads should always have at creation time and what it
should be at any time work is handled, we'll have a solution for this
scenario. Hopefully it's the scenario Ken & I have talked about that's
giving us the problem.
charlie ...
Jeanfrancois Arcand wrote:
> Hi Siva
>
> the problem is not with the WebappClassloader. The problem happens
> because a component (an object) outside the WebContainer is caching
> the WebappClassloader for future usage (most probably a Thread). When
> the application associated with a WebAppClassloader is undeployed,
> that WebappClassloader becomes invalid. Any tentative to re-use this
> Classloader will throw a ThreadDeath exception. Hence if a component
> have reference to that Classloader, trying to load a class using it
> will result in a exception.
>
> We are currently working with the Corba team to find where the Context
> Classloader (WebppClassloader) is cached.
>
> Thanks
>
> -- Jeanfrancois
>
> Sivakumar Thyagarajan wrote:
>> Hi Ken
>>
>> I own classloaders but this seems to be a web app classloaders
>> issue.[ trying to load a class from a webappclassloader that has been
>> stopped ].
>>
>> Could you ensure that the web-appclassloader in your hierarchy has
>> not been stopped? Does this happen during app redeployment ?
>>
>> Jan Luehe might be able to help us further.
>> https://glassfish.dev.java.net/source/browse/glassfish/appserv-webtier/src/java/org/apache/catalina/loader/WebappClassLoader.java
>>
>>
>> Thanks
>> --Siva.
>>
>> Ken Cavanaugh wrote:
>>> I need to re-assign bug 6545419. It is currently filed against
>>> CORBA, but the
>>> root cause is a Webapp ClassLoader that throws ThreadDeath (because
>>> it's no
>>> longer deployed?). This causes the ORB to fail in an attempt to
>>> call Class.forName
>>> on a class (IIOPOutputStream) that is in appserv-rt.jar.
>>>
>>> To whom should I assign this bug?
>>>
>>> Thanks,
>>>
>>> Ken.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>
--
Charlie Hunt
Java Performance Engineer
630.285.7708 x47708 (Internal)
<http://java.sun.com/docs/performance/>