commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Stansberry <>
Subject Re: logging: WeakHashtable
Date Thu, 18 Nov 2004 08:51:18 GMT
--- robert burrell donkin
<> wrote:

> i've commit the patch of the 15th (with a few minor
> changes). thanks.
Great.  Thanks much :) 

> this means that the value is (effectively) held by a
> hard reference 
> whilst the key is held by a weak. this should
> address the narrow issue 
> of the most typical use case. i think that probably
> the code could be 
> improved by eliminating some unnecessary complexity
> but that'll have to 
> wait till tomorrow.

Actually, I think it should work with the
"commons-logging in WEB-INF/lib" case as well.  In
that use case, the relevant LogFactory and
WeakHashtable are actually loaded by the webapp
classloader, so they too are gc'ed when the webapp is
undeployed.  Attached is a patch to LogFactoryTest
that I believe shows this.  Please let me know if this
is wrongheaded in some way -- I wouldn't be surprised
at all if it is.  

I took some time to study what the existing LoadTest
class does and tried to mimic it to test different
classloading configurations.  (In fact, if this patch
is accepted down the road I should do a quick refactor
to avoid duplication w/ LoadTest).

The other day when I thought it wouldn't work in the
WEB-INF/lib situation, my test classloader was
delegating all loading to its parent EXCEPT
LogFactoryImpl.  LogFactory and everything else was
loaded by the parent.  That's not the same as putting
commons-lib in WEB-INF/lib.  The classloader in the
attached patch is a more correct mock of a webapp
classloader.  My mistake the other day does show one
area where WeakHashtable will fail -- if a custom
subclass of LogFactory were deployed in WEB-INF/lib
but commons-logging.jar were on the server classpath. 
But I expect that's a pretty small use case.

Oh, BTW, the patch also removes the previous test of
whether the LogFactory is eventually released once the
classloader is released.  Now it just tests if the
classloader is released.  Testing release of the
LogFactory basically duplicated what was already done
in WeakHashtableTest.

> one interesting feature of garbage collectors (which
> foxed me for a 
> while) is that there doesn't seem to be any
> guarantee as to when the 
> reference is placed onto the queue. (at least i
> can't find one: if 
> anyone knows different please jump in.) on the
> (macOSX) JVM i use, it 
> appears that the reference is placed onto the queue
> late enough to 
> cause one of the tests to fail. placing a hard loop
> that polls for the 
> released reference to be placed on another queue
> results in the test 
> passing...
Interesting.  This whole thing's been interesting --
way more than I thought it would be when I started off
grunting through a bunch of reflection :)


> On 16 Nov 2004, at 15:12, Brian Stansberry wrote:
> > Attached is a patch to LogFactory that attempts to
> > play classloader tricks to prevent the hard
> reference
> > problem.  This is not meant to be applied; the
> patch
> > is just a shorthand way to communicate ideas I'm
> > playing with.
> >
P.S. Thanks to all for not laughing at this one!

> > This seemed to work in the sense that the tests I
> > added to LogFactoryTest pass.  But,
> o.a.c.l.LoadTest
> > fails with a ClassCastException.  Other tests in
> that
> > package pass. Haven't had time to try and analyze
> > what's going on with the LoadTest.
> >
> > Gotta run to work.
> >
> > - brian
> >
> >
> > 		
> > __________________________________
> > Do you Yahoo!?
> > The all-new My Yahoo! - Get yours free!
> >
> >
> >
> >
> > To unsubscribe, e-mail:
> > For additional commands, e-mail:
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Do you Yahoo!? 
The all-new My Yahoo! - Get yours free! 

View raw message