velocity-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fredrik Andersson <fidde.anders...@gmail.com>
Subject Re: Caching / OutOfMemoryException
Date Thu, 12 Jan 2006 08:41:37 GMT
Thanks Daniel.

You don't have to change the documentation, I just had a hard time googling
it for some reason. Lazy coder syndrome, sorry.

We have done some extensive testing and thinking the last couple of days,
and it seems our OOM Exception surfaces when frequently updating the
WAR-files (containing Velocity servlets) in the Tomcat, not exclusively by
heavy load. This would rather suggest that it's our Tomcat and/or Java
version not working well with Velocity 1.5. I've never had any problems with
other template/servlet systems so I still suspect Velocity to be the culprit
in some way. This bug/phenomena is too critical to not have been noticed
before by other users of Velocity, so it has to be some common denominator
that all our developers use (which leads to the combination of JRE and/or
Tomcat and Velocity).

Even if the Tomcat is somehow caching/serializing some parts of the Velocity
"offspring" between updates of the WAR files, it should in not way lead to
OOM Exception. Definately not by the LRU map, since it has an upper bound
for how much it can grow. But this is probably a question for the tomcat-dev
list, so I'll stop ranting now.

Though this is slightly off-topic, if anyone else is using the very latest
JRE, Tomcat and Velocity 1.5, it'd be swell to hear if you encounter this
problem when frequently updating the webapps.

I'll drop a line when and if we resolve this issue.

Fredrik

On 1/12/06, Daniel Rall <dlr@apache.org> wrote:
>
>
> On Tue, 10 Jan 2006, Fredrik Andersson wrote:
>
> > I'll try the resource.manager.defaultcache setting. I seem to remember
> that
> > I stumbled upon a forum thread or mailinglist some weeks ago arguing
> that
> > this setting was limitless unless you set it explicitly.
>
>
> http://mail-archives.apache.org/mod_mbox/jakarta-velocity-dev/200310.mbox/%3C3F96BB0C.90309@finemaltcoding.com%3E
>
> Even not setting this property should create a (non-greedy) LRUMap by
> default:
>
> public class ResourceCacheImpl implements ResourceCache
> {
>     ...
>     public void initialize( RuntimeServices rs )
>     {
>         rsvc = rs;
>
>         int maxSize =
>             rsvc.getInt(
> RuntimeConstants.RESOURCE_MANAGER_DEFAULTCACHE_SIZE, 89);
>         if (maxSize > 0)
>         {
>             // Create a whole new Map here to avoid hanging on to a
>             // handle to the unsynch'd LRUMap for our lifetime.
>             Map lruCache = Collections.synchronizedMap(new
> LRUMap(maxSize));
>             lruCache.putAll(cache);
>             cache = lruCache;
>         }
>         rsvc.getLog().info("ResourceCache: initialized
> ("+this.getClass()+')');
>     }
>     ...
>
> > This setting isn't very documented, by the way! I'll just browse the
> > source and see what it does.
>
> Here's what I found:
>
> --- snip ---
> resource.manager.cache.class Declares the class to be used for
> resource caching. The current default is
> org.apache.velocity.runtime.resource.ResourceCacheImpl which uses a
> LRU Map to prevent data from being held forever. You can set the size
> of the LRU Map using the parameter
> resource.manager.defaultcache.size. The dafault value of the default
> cache size is currently 89.
>
> resource.manager.defaultcache.size Sets the size of the default
> implementation of the resource manager resource cache.
> --- snip ---
>
> Fredrik, how do you recommend we change that to improve things?
> --
>
> Daniel Rall
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message