[prev in list] [next in list] [prev in thread] [next in thread]
List: velocity-dev
Subject: [jira] Updated: (VELOCITY-595) ResourceManagerImpl.getResource()
From: "Nathan Bubna (JIRA)" <dev () velocity ! apache ! org>
Date: 2008-07-23 21:38:31
Message-ID: 36683698.1216849111704.JavaMail.jira () brutus
[Download RAW message or body]
[ 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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic