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 <cla...@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-unsubscr...@velocity.apache.org > For additional commands, e-mail: dev-h...@velocity.apache.org > >
