[
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
