You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by robert burrell donkin <ro...@blueyonder.co.uk> on 2006/02/21 23:15:33 UTC
[logging] discovery and memory leaks
too much caffine for me yesterday (very bad for me resulting in mental
overdrive and then no sleep). even though i'm tired now, it the manic
phase may have produced a positive side effect - or possibly just
another mad idea...
a lot of difficulties (including issues with hot deployment) arise from
JCL caching classloaders. most of these issues should be addressed by
using a weakhashtable but there are certain cases where even a weak hash
table cannot solve the issue.
the reason for indexing on classloaders is to allow configurations to be
saved on a per classloader basis. it strikes me that identity should be
as good as equality for this indexing. if so, then we could use
System.identityHashCode as the index rather than the actual classloader.
please feel free to spot the flaws with this plan :)
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] discovery and memory leaks
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Wed, 2006-02-22 at 17:45 +1300, Simon Kitching wrote:
> On Tue, 2006-02-21 at 22:15 +0000, robert burrell donkin wrote:
> > too much caffine for me yesterday (very bad for me resulting in mental
> > overdrive and then no sleep). even though i'm tired now, it the manic
> > phase may have produced a positive side effect - or possibly just
> > another mad idea...
> >
> > a lot of difficulties (including issues with hot deployment) arise from
> > JCL caching classloaders. most of these issues should be addressed by
> > using a weakhashtable but there are certain cases where even a weak hash
> > table cannot solve the issue.
> >
> > the reason for indexing on classloaders is to allow configurations to be
> > saved on a per classloader basis. it strikes me that identity should be
> > as good as equality for this indexing. if so, then we could use
> > System.identityHashCode as the index rather than the actual classloader.
> >
> > please feel free to spot the flaws with this plan :)
>
> The problem is a shared LogFactory class has a map holding (TCCL,
> LogFactoryImpl) pairs. This of course prevents the TCCL from being
> collected without an explicit release() call to clear that map entry.
>
> Using a weakref to the TCCL ensures that the map entry is automatically
> deleted when the container drops its reference to the TCCL.
>
> Using a stringified TCCL would no longer block the TCCL from being
> collected. However it would leave the entry in the map forever, ie would
> not allow the LogFactoryImpl instance (and all the Log objects held by
> it) to be collected.
>
> And it doesn't fix the corner case "leak" problems that exist with the
> current solution either; these occur because the *value* in the map has
> an indirect reference to the TCCL. That's only fixable by an explicit
> release as far as I know (hence ServletContextCleaner).
yes, that it :)
good: for a while i thought that we'd managed to miss a solution.
it does lead onto something i've been pondering for a while (though):
perhaps it might be possible to discover only the appropriate
configuration and then load the classes from the current loader. if this
were possible then this would remove the indirect reference provided.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] discovery and memory leaks
Posted by Simon Kitching <sk...@apache.org>.
On Tue, 2006-02-21 at 22:15 +0000, robert burrell donkin wrote:
> too much caffine for me yesterday (very bad for me resulting in mental
> overdrive and then no sleep). even though i'm tired now, it the manic
> phase may have produced a positive side effect - or possibly just
> another mad idea...
>
> a lot of difficulties (including issues with hot deployment) arise from
> JCL caching classloaders. most of these issues should be addressed by
> using a weakhashtable but there are certain cases where even a weak hash
> table cannot solve the issue.
>
> the reason for indexing on classloaders is to allow configurations to be
> saved on a per classloader basis. it strikes me that identity should be
> as good as equality for this indexing. if so, then we could use
> System.identityHashCode as the index rather than the actual classloader.
>
> please feel free to spot the flaws with this plan :)
The problem is a shared LogFactory class has a map holding (TCCL,
LogFactoryImpl) pairs. This of course prevents the TCCL from being
collected without an explicit release() call to clear that map entry.
Using a weakref to the TCCL ensures that the map entry is automatically
deleted when the container drops its reference to the TCCL.
Using a stringified TCCL would no longer block the TCCL from being
collected. However it would leave the entry in the map forever, ie would
not allow the LogFactoryImpl instance (and all the Log objects held by
it) to be collected.
And it doesn't fix the corner case "leak" problems that exist with the
current solution either; these occur because the *value* in the map has
an indirect reference to the TCCL. That's only fixable by an explicit
release as far as I know (hence ServletContextCleaner).
Cheers,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] discovery and memory leaks
Posted by Sandy McArthur <sa...@gmail.com>.
On 2/21/06, robert burrell donkin <ro...@blueyonder.co.uk> wrote:
> the reason for indexing on classloaders is to allow configurations to be
> saved on a per classloader basis. it strikes me that identity should be
> as good as equality for this indexing. if so, then we could use
> System.identityHashCode as the index rather than the actual classloader.
>
> please feel free to spot the flaws with this plan :)
Just gotta stress the *should*. System.identityHashCode returns an
int, technically that won't cut it for 64 bit Java.
That said if you find a real solution to this problem I'd like to know
because the reference and debug features of composite pool
implementation I submitted currently depend on hoping the
System.identityHashCode doesn't return the same value for two
different instances.
I don't like that code but I don't expect many people to use it in
production. If you expect people to often use that technique in
production I think we should keep looking.
--
Sandy McArthur
"He who dares not offend cannot be honest."
- Thomas Paine
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org