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/26 00:51:31 UTC
[jira] Resolved: (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 resolved VELOCITY-595.
-----------------------------------
Resolution: Fixed
Fix Version/s: 1.6
Ok, i've run Velocity under heavy load with Jarkko's "pathetic little testbed" (VELOCITY-606), and i don't see any problems. I think this is safe and worthwhile.
> 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
> Fix For: 1.6
>
> 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
Re: [jira] Resolved: (VELOCITY-595) ResourceManagerImpl.getResource() causes locking issues
Posted by Will Glass-Husain <wg...@gmail.com>.
Nice work. An important improvement to our engine.
WILL
On Fri, Jul 25, 2008 at 3:51 PM, Nathan Bubna (JIRA)
<de...@velocity.apache.org> wrote:
>
> [ https://issues.apache.org/jira/browse/VELOCITY-595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>
> Nathan Bubna resolved VELOCITY-595.
> -----------------------------------
>
> Resolution: Fixed
> Fix Version/s: 1.6
>
> Ok, i've run Velocity under heavy load with Jarkko's "pathetic little testbed" (VELOCITY-606), and i don't see any problems. I think this is safe and worthwhile.
>
>> 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
>> Fix For: 1.6
>>
>> 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
>
>
--
Forio Business Simulations
Will Glass-Husain
wglass@forio.com
www.forio.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org