velocity-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Malcolm Edgar <malcolm.ed...@gmail.com>
Subject Re: Caching / OutOfMemoryException
Date Thu, 12 Jan 2006 08:58:28 GMT
Are you using the Velocity singleton pattern or VelocityEngine? There
can be memory "leaking" issues if you are continually reloading the
Velocity singleton instance.

regards Malcolm

On 1/12/06, Fredrik Andersson <fidde.andersson@gmail.com> wrote:
> 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
> >
> >
> >
>
>

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


Mime
View raw message