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 16:08:43 GMT
Aah, I had no idea Tomcat had issues with singletons, that's a lessoned
learned! I've run a script for the last couple of hours reloading the webapp
now and then and I haven't run in to any OOM Exceptions since discarding the
singleton.

Thanks again,
Fredrik

On 1/12/06, Will Glass-Husain <wglass@forio.com> wrote:
>
> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message