[ https://issues.apache.org/jira/browse/VELOCITY-223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489376 ]
Alexey Panchenko commented on VELOCITY-223: ------------------------------------------- Synchronization "stringImagePool.get(image)" should be inside synchronized block too. Memory Usage The memory held by "private static Map<String, String> stringImagePool" will be never released. The same applies to String.intern(). > VMs that use a large number of directives and macros use excessive amounts of > memory - over 4-6MB RAM per form > -------------------------------------------------------------------------------------------------------------- > > Key: VELOCITY-223 > URL: https://issues.apache.org/jira/browse/VELOCITY-223 > Project: Velocity > Issue Type: Bug > Components: Engine > Affects Versions: 1.3.1 > Environment: Operating System: All > Platform: All > Reporter: Christian Nichols > Fix For: 1.6 > > Attachments: 223-patch.txt, AllVelocityMemoryByClass.html, > StringImagePool.java, VelocityCharStream.java, VelocityMemory.JPG > > > Our application FinanceCenter is based on Velocity as the template engine. > We > have a library of about 200 macros and about 400 VM files. Because the > velocity parser copies the macro body into the VM during parsing, macros that > are frequently used (even though identical and using local contexts) use up > large amounts of memory. On our Linux server (running Redhat 7.2 with Sun > JDK > 1.4.1_04) we can easily use up over 1GB of RAM simply by opening up many > forms > (about 150) - the server starts out using 60MB after startup. This memory > times out after 5 minutes and is returned which tells me that it is screen > memory. Our problem is that the NT JVM and Linux JVM (32 bit) are currently > limited to about 1.6 - 2.0 GB of ram for heap space. Thus, using a fair > number > of forms in the application leaves little space for user session data. > We have implemented a caching mechanism for compiled templates and integrated > it into Velocity so that cached objects are timed out of the cache but the > server is still using large amounts of memory. We finally had to rewrite > many > of our macros into Java so that memory usage would be reduced (note that > these > macros were doing complex screen formatting not business logic). Doing this > has reduced our memory by about 30%. This is currently our biggest issue > with > Velocity and is causing us to review our decision to stay with Velocity going > forward. This is because we will likely end up with close to 1,000 forms by > the end of next year and need to know that Velocity can deal with this. Is > there any work underway to share compiled macro AST's? This would greatly > reduce the amount of memory used. I have reviewed the parser code that is > doing this but it seems that this is an embedded part of the design and not > easily changed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]