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]
