On Mon November 9 2009 2:02:27 pm Daniel Feist wrote:
> > Please file JIRA's and patches if at all possible.   I'm actually
> > wondering if
> > some of your descriptions are the causes of:
> >
> > https://issues.apache.org/jira/browse/CXF-2286
> > https://issues.apache.org/jira/browse/CXF-1816
> >
> > If we can get your patches in, it would be good to recheck those to
> > see if
> > they are then fixed.
> 
> Don't immediately seem related but may be.
> 
> Whenever cxf is on server classpath and webapps use cxf any static
> instance variable in cxf classes can potentially cause issues with hot-
> deploy and pergen issues..

And, on windows, jar locking.   On Windows, if the classloader referencing a 
jar cannot be garbage collected, the jar cannot be deleted.   I THINK that's 
the cause of the above errors.  (not 100% sure though)

 
> >>> Probable Causes:
> >>> - org.apache.cxf.common.util.ASMHelper.LOADER_MAP
> >>>
> >>> This map continues to have reference to classes generated and used
> >>> by the now undeployed webapp meaning the webapp classloader never
> >>> goes away.
> >>> The implementation of this map although weak is not weak enough,
> >>> because if a entry references a key (it seems to) then the key
> >>> although it is a WeakReference never goes away and therefore neither
> >>> does the entry (the classloader).
> >
> > OK.   Makes sense.
> 
> I have patch for this one, not test case though.

Super cool.  :-)    Please log a JIRA and attach.  


> >>> - org.apache.cxf.jaxb.JAXBDataBinding.JAXBCONTEXT_CACHE
> >>>
> >>> Here is appears we have another map the maintains references to the
> >>> generated classes and in turn to the webappClassloader that is no
> >>> more expect this one doesn't even try to be weak.  I notice there is
> >>> a clearCaches() method but i'm unsure about using that at anytime in
> >>> runtime because even though i'm taking down one cxf Service there
> >>> may be user services alive using jaxb at the same time.
> 
> Will do.  No patch for this one yet, but if it's the same as the other
> issue above then should be pretty easier.

Yea.  It might just be making the referecne to the JAXBContext a 
WeakReference<JAXBContext> or similar.   That may be enough to do it.

 
> If you have any thoughts on unit testing either of these then please
> let me know..

Oi.   I have NO idea on that one short of writing several custom classloader 
things and such, but that's probably more work than it's worth.

If you can get a test case, great.   If not, at least get the patches up as 
long as you've tested it in your environment.  (and, of course, all our 
existing tests pass)

-- 
Daniel Kulp
[email protected]
http://www.dankulp.com/blog

Reply via email to