Cache handling in DuckType

[Cédric Tabin <ta...@gmail.com>]

Hi,

I suggest to add a method to allow to clear the cache owned by each Type in
org.apache.velocity.util.DuckType.
This cache causes us some memory leak problems, because we are reloading
classes at runtime, causing it to grow indefinitely while preventing
"unloaded" classes to be garbage collected.

Since I'm not sure how to submit a patch to velocity, I submitted this PR
<https://github.com/apache/velocity-engine/pull/6> a while ago. It would be
great if a dev could check it out.

Actually, I wonder if this type of cache should be improved so it can be
configured by the developer ? It could be interesting at least to limit the
number of objects held by the cache.

Thanks & best regards,
Cédric

Re: Cache handling in DuckType

[Cédric Tabin <ta...@gmail.com>]

Hello Claude,

Thanks for your consideration !

As far as I can tell, this seems to be the only place memory is leaking.
We have a lot of templates, with a wide range of used features from
velocity and we don't see any other place memory is leaking within our
automated tests.

IMAHO, a simple [configurable] cache limit could also do the trick (ie do
not store all the objects in the cache for ever). But at least, the new
method allows the developer to clear the cache when needed.

Best regards,
Cédric

On Sat, Dec 8, 2018 at 7:31 PM Claude Brisson <cl...@renegat.net.invalid>
wrote:

> Thanks for the patch. It has been commited in the svn trunk branch
> (2.1-SNAPSHOT).
>
> Do you think there is any other precaution to take about this issue of
> class reloading, for instance in the introspection package? Or would
> there be any benefit to declare our own class loader to be able to
> propagate some class reloading events to inner caches?
>
>    Claude
>
> On 11/11/18 6:15 PM, Cédric Tabin wrote:
> > Hi,
> >
> > I suggest to add a method to allow to clear the cache owned by each Type
> in
> > org.apache.velocity.util.DuckType.
> > This cache causes us some memory leak problems, because we are reloading
> > classes at runtime, causing it to grow indefinitely while preventing
> > "unloaded" classes to be garbage collected.
> >
> > Since I'm not sure how to submit a patch to velocity, I submitted this PR
> > <https://github.com/apache/velocity-engine/pull/6> a while ago. It
> would be
> > great if a dev could check it out.
> >
> > Actually, I wonder if this type of cache should be improved so it can be
> > configured by the developer ? It could be interesting at least to limit
> the
> > number of objects held by the cache.
> >
> > Thanks & best regards,
> > Cédric
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
> For additional commands, e-mail: dev-help@velocity.apache.org
>
>

Re: Cache handling in DuckType

[Claude Brisson <cl...@renegat.net.INVALID>]

Thanks for the patch. It has been commited in the svn trunk branch 
(2.1-SNAPSHOT).

Do you think there is any other precaution to take about this issue of 
class reloading, for instance in the introspection package? Or would 
there be any benefit to declare our own class loader to be able to 
propagate some class reloading events to inner caches?

   Claude

On 11/11/18 6:15 PM, Cédric Tabin wrote:
> Hi,
>
> I suggest to add a method to allow to clear the cache owned by each Type in
> org.apache.velocity.util.DuckType.
> This cache causes us some memory leak problems, because we are reloading
> classes at runtime, causing it to grow indefinitely while preventing
> "unloaded" classes to be garbage collected.
>
> Since I'm not sure how to submit a patch to velocity, I submitted this PR
> <https://github.com/apache/velocity-engine/pull/6> a while ago. It would be
> great if a dev could check it out.
>
> Actually, I wonder if this type of cache should be improved so it can be
> configured by the developer ? It could be interesting at least to limit the
> number of objects held by the cache.
>
> Thanks & best regards,
> Cédric
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org