From: Mike McDonald [mailto:[EMAIL PROTECTED]]
>
> > o Control Caching Resource Usage
> > Change resource caching to limit cache size and expire
> > least-recently-used. This is needed to prevent Vel from
> > sucking up RAM uncontrollably for content-centric or
> > other sites that may use #include() or #parse()
> > extensively.
>
> I would like to help add this feature to Velocity. Has there
> been any more
> discussion about this or is anyone already working on an
> implementation? I can
> think of two immediate approaches to doing this:
I was intending to, but, please, have at it.
> A) Replace the Hashtable in ResourceManager with a simple LRU cache
> implementation which enforces a (configurable) maximum # of resources.
>
> B) Make the cache implementation switchable to allow for a variety of
> implementations, like LogSystem. E.g.:
>
> interface ResourceCache {
> Resource get (String resourceName);
> void put (String resourceName, Resource resource);
> void clear ();
> }
I like B, but not really sure yet where to put it. Will follow up later
with my thoughts so far.
> Ideally the Resource cache would be able to enforce a
> byte-size limit but this
> would require some complex changes across the resource
> loading code and the
> template AST. That may not be practical right now.
A byte size limit is important - however, I think that simplicity is better,
and just keeping tabs on the size of the sourced templates is enough, I
would think, as people think in terms of their templates, not the internals.
So they may know they have 100MB of templates, but only 2M are used 95% of
the time, so they can allocate 2.5M of LRU cache space for the input.
(Translation - there is no way for Joe User to predict the internal size,
and further it changes as we change things, so just focus on input template
size...)
geir
