At the time, I was able to create the OOM with by myself clicking around the
site. I doubt you would consider these templates very large, mostly just
html with a few variables.with the largest template being about 32k. And my
JVM settings where the same as I had for the 1.5 version. However, I do
have my own ResourceCacheImpl (any issues jump out at you?):
*
import* java.util.Iterator;
*
import* net.sf.ehcache.Cache;
*
import* net.sf.ehcache.Element;
*
import* org.apache.velocity.runtime.RuntimeServices;
*
import* org.apache.velocity.runtime.resource.Resource;
*
import* org.apache.velocity.runtime.resource.ResourceCache;
*
import* org.slf4j.Logger;
*
import* org.slf4j.LoggerFactory;
*
import* com.company.product.web.Constants;
*
import* com.company.product.lifecycle.ContainerFactory;
*
public* *class* WCResourceCacheImpl *implements* ResourceCache {
/** The Constant logger. */
*private* *final* Logger logger = LoggerFactory.*getLogger*
((WCResourceCacheImpl.*class*).getName());
/**
* Cache storage, assumed to be thread-safe.
*/
*protected* Cache cache;
/**
* Runtime services, generally initialized by the
* <code>initialize()</code> method.
*/
*protected* RuntimeServices rsvc = *null*;
/* (non-*Javadoc*)
* @see org.apache.velocity.runtime.resource.ResourceCache#enumerateKeys()
*/
*public* Iterator enumerateKeys() {
logger.debug(Constants.*ENTRY*);
Iterator keys = cache.getKeys().iterator();
logger.debug(Constants.*EXIT*);
*return* keys;
}
/* (non-*Javadoc*)
* @see
org.apache.velocity.runtime.resource.ResourceCache#get(java.lang.Object)
*/
*public* Resource get(Object key) {
logger.debug(Constants.*ENTRY*, key.toString());
Element entry = cache.get(key);
Resource value = entry == *null* ? *null* : (Resource)
entry.getObjectValue();
logger.debug(Constants.*EXIT*);
*return* value;
}
/* (non-*Javadoc*)
* @see
org.apache.velocity.runtime.resource.ResourceCache#initialize(org.apache.velocity.runtime.RuntimeServices)
*/
*public* *void* initialize(RuntimeServices rs) {
rsvc = rs;
cache = (Cache) ContainerFactory.*getContainer*().getComponentInstance(
"templateCache");
rsvc.getLog().debug("ResourceCache: initialized (" + *this*.getClass() + ')'
);
}
/* (non-*Javadoc*)
* @see
org.apache.velocity.runtime.resource.ResourceCache#put(java.lang.Object,
org.apache.velocity.runtime.resource.Resource)
*/
*public* Resource put(Object key, Resource value) {
logger.debug(Constants.*ENTRY*, key.toString() + value.toString());
Element entry = *new* Element(key, value);
cache.put(entry);
logger.debug(Constants.*EXIT*);
*return* value;
}
/* (non-*Javadoc*)
* @see
org.apache.velocity.runtime.resource.ResourceCache#remove(java.lang.Object)
*/
*public* Resource remove(Object key) {
logger.debug(Constants.*ENTRY*, key.toString());
Resource value = (Resource) cache.get(key).getObjectValue();
cache.remove(key);
logger.debug(Constants.*EXIT*);
*return* value;
}
}
On Thu, Aug 14, 2008 at 4:08 AM, Jarkko Viinamäki <[EMAIL PROTECTED]>wrote:
>
> Hi Erron,
>
> Thanks for reporting this issue. Unfortunately I don't have time at the
> moment to investigate but one possible cause for this is that resource
> loading was made concurrent in 1.6-dev. See ResourceManagerImpl: public
> Resource getResource(final String resourceName, final int resourceType,
> final String encoding)
>
> Basically this means that there can be an unlimited number of threads that
> are reloading templates and resources simultaneously. In 1.5 only one
> thread
> at a time could load resources. When there are big templates and several
> threads loading those resources, the JVM may run out of memory. This can
> happen even if caching is on given that modificationCheckInterval > 0.
>
> It's odd though that I didn't get OOM errors in my tests and you reported
> that this is repeatable with light load. What's the configured heap size in
> your application server? Does 1.5 work fine with the same settings?
>
> One alternative is to increase the heap size but I suspect that we may need
> to limit the amount of threads that are allowed to do simultaneous parsing
> -
> in order to guarantee rough memory usage bounds under heavy load.
>
>
>
> erron wrote:
> >
> > Heads up. I need to investigate the exact cause, but applying Jarkko
> patch
> > (velocity-1.6-dev-macro-performance-IDEAS-v2.5.patch) I'm getting OOM
> > errors
> > now. Unfortunately, I've had to revert to get a project going. Soon,
> I'll
> > download trunk and re-test and profile if I run across the issue again.
> My
> > application is pretty straightforward. I'm extending VelocityViewServlet
> > and
> > serving up a basically static website. So if someone wants to test, I
> > would
> > create 20 templates with an external macros file that is added using
> > template.merge(context,
> > writer, templates). No heavy load needed. Just navigate through the
> > templates (with caching turned on) fairly quickly.
> >
> > On oddity I did notice is that my status page which determines the total
> > amount of memory allocated (Runtime.*getRuntime*().totalMemory() ) and
> the
> > amount of free memory left, indicated that at some point the allocated
> > memory was reduced. I thought this was strange.
> >
>
> --
> View this message in context:
> http://www.nabble.com/-jira--Created%3A-%28VELOCITY-607%29-Runtime-macro-rendering-very-slow-in-Velocity-1.6-dev-%28679708%29-compared-to-1.5-tp18648266p18977414.html
> Sent from the Velocity - Dev mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
