[
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.patch
Ok, i read through VELOCITY-24 more carefully. It looks like this was
originally an issue with inline macros when caching is on and auto-reloading is
on. But then Henning proffers a fix that hurts those who do not use caching,
with no mention of auto-reloading or not. It's clear that the fix worked for
the original problem, but without more investigation and/or input from Henning,
i'm not sure if we can limit the synchronization at all. At the least, it
seems that loadResource() is not the issue, but rather refreshResource() and
perhaps the put/get of a Resource into the cache and the return of the Resource.
Allen, what cache/reload settings are you using when you experience the
slowdown?
Henning, are you following this? Can we get the test template and/or help
reproducing this?
I know it is difficult to properly synchronize, but it seems like we could
carefully use the resourceKey created at the start of getResource() as a lock
object to be more fine-grained about this. The patch i attached is totally
untested (didn't even compile it) and really just a rough idea, but i suspect
something like it would solve the race condition for VELOCITY-24 with less
thread contention.
> 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.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]
