You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by "Nathan Bubna (JIRA)" <de...@velocity.apache.org> on 2008/07/23 23:38:31 UTC
[jira] Updated: (VELOCITY-595) ResourceManagerImpl.getResource()
causes locking issues
[ https://issues.apache.org/jira/browse/VELOCITY-595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Nathan Bubna updated VELOCITY-595:
----------------------------------
Attachment: VELOCITY-595.jarkko.patch
Jarkko Viinamäki contributed an alternate patch for this issue as part of his performance improvement patch to VELOCITY-606. I've pulled this patch out, tidied it up and attached it here.
Rather than synchronize resource fetching on a per-resource basis (as my patch does), he takes the "wasteful" approach of having both refreshResource and loadResource return new Resource instances for every request (updating the cache each time, as well). This keeps subsequent requests from stomping on each other's Template instances (as was happening in VELOCITY-24 via the resource.process() call in refreshResource) by letting simultaneous requests always have their own separate Template instance.
Again, i still don't have access to the testbed app Henning was using to test these things (to my knowledge), so i can't personally confirm that this doesn't re-introduce VELOCITY-24, but the fix makes sense to me. Also, Jarkko is doing multi-thread load testing as part of VELOCITY-606 and has not hit the bug with this patch in place. So, i think this is sound. I'll leave some time for comment and for Jarkko to retest his VELOCITY-606 changes (including this) once they're adapted to JDK 1.4 before i commit this.
> ResourceManagerImpl.getResource() causes locking issues
> -------------------------------------------------------
>
> Key: VELOCITY-595
> URL: https://issues.apache.org/jira/browse/VELOCITY-595
> Project: Velocity
> Issue Type: Bug
> Components: Engine
> Affects Versions: 1.5
> Environment: jdk 1.5
> Reporter: Allen Gilliland
> Attachments: VELOCITY-595.jarkko.patch, VELOCITY-595.patch
>
>
> The ResourceManagerImpl.getResource() method is synchronized, which makes it difficult to share a Velocity Runtime between threads in an environment such as a j2ee web application.
> After upgrading Velocity to version 1.5 in Roller and running some performance tests I saw a very noticeable decrease in throughput for the application. I fired up jconsole and noticed that almost all of my app server threads were in a BLOCKED state and were waiting on the ResourceManagerImpl.getResource() method.
> In my particular case the difference resulted in a loss of 2/3 of my original ops/sec, which is pretty huge. After simply switching Velocity back to the 1.4 release and rerunning the test I saw the results I expected.
> I assume this is overactive use of Java synchronization because the developer guide suggests that the singleton model is "very appropriate model for use in a Servlet 2.2+ compliant web application".
--
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: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org