velocity-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Will Glass-Husain" <wgl...@forio.com>
Subject Re: Caching / OutOfMemoryException
Date Thu, 12 Jan 2006 14:57:10 GMT
Tomcat has issues with Singletons.  If you're talking about reloading the 
web app (e.g. from the Tomcat manager), I often get OutOfMemoryExceptions 
with both my Velocity and non Velocity apps.  It's really a pain.

There seems to be subtle issues with classloaders in which old instances of 
classes are not discarded.  And of course if you run Velocity in singleton 
mode this would be worse.

Try using the latest VelocityViewServlet from the Velocity Tools sub 
project.  This relies on VelocityEngine.

WILL

----- Original Message ----- 
From: "Fredrik Andersson" <fidde.andersson@gmail.com>
To: "Velocity Developers List" <velocity-dev@jakarta.apache.org>
Sent: Thursday, January 12, 2006 1:52 AM
Subject: Re: Caching / OutOfMemoryException


We're using the bundled VelocityServlet (deprecated, I know) and it uses a
singleton approach as far I can see. I'll try to use an instance of
VelocityEngine instead. It is obvious that some junk (threads, resources or
whatever) carries over between updates of the WAR file. Using an instance
would definately kill all the associated resources, so that sounds like an
excellent idea.

I'll give it a whirl and see what happens, big thanks Malcolm!

Fredrik

On 1/12/06, Malcolm Edgar <malcolm.edgar@gmail.com> wrote:
>
> 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
>
>


---------------------------------------------------------------------
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