users@jersey.java.net

Re: [Jersey] Java.lang.ThreadDeath GFv2.1 Jersey 1.1.2

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Fri, 18 Dec 2009 09:51:13 +0100

On Dec 18, 2009, at 2:27 AM, Jeanfrancois Arcand wrote:

> Salut,
>
> On 17/12/09 2:07 PM, saturon wrote:
>> Hi all,
>>
>> I am just stumbling into this strange ThreadDeath issue when
>> sending a
>> XML Post request to my Jersey Backend.
>>
>> My Setup is GFv2.1 on Debian Lenny, java 1.6.0_12, Jersey 1.1.2.
>>
>> The XML contains a xsd-date which might be not correct. But surely
>> this
>> should not be a reason for GF/Jersey to just stop the webapp?
>>
>> Has anyone seen such problems?
>
> euh! That's an ugly one. It means one component in GlassFish is
> referencing a ClassLoader that was associated with a web
> application, but the web application has been undeployed and the
> classloader becomes invalid (the error message is misleading).
>

Eeek!


>>
>> I did deploy without restarting before this issue occurred, however
>> the
>> webservice was consuming similar post requests for about 20 Minutes
>> before the error occurred.
>
> Can you file an issue in GlassFish and attach a test case?

Please do, and send the issue URI to this list as well.


> It's either a problem in Jersey (I doubt) or the XML code that hold
> an invalid reference.
>

Jersey does not do anything w.r.t. class loaders. The only thing i can
think of that may be related is that Jersey does is store a Class and
JAXBContext classes in a static weak hash map:

     private static final Map<Class, JAXBContext> jaxbContexts =
             new WeakHashMap<Class, JAXBContext>();

Could this cause the above issue? In fact the above does not need to
be static at all. I thought since JAXBContext instances are expensive
to create it might be useful to share them VM-wide (dependent on class
loading of course).

Paul.