Re: Making Velocity truly concurent

[Christopher Schultz <ch...@christopherschultz.net>]

Jan,

On 9/28/12 3:15 PM, Jan Algermissen wrote:
> 
> On Sep 28, 2012, at 8:36 PM, Christopher Schultz wrote:
> 
>> Jan,
>>
>> On 9/21/12 2:45 AM, Jan Algermissen wrote:
>>> looking at the code yesterday, I saw that Velocity uses a number of
>>> Serialized classes (e.g. the SerializedMap in ResourceCache).
>>>
>>> I would like to replace all relevant classes to avoid serialization
>>> completely.
>>
>> Do you mean avoid all /synchronization/?
> 
> Yes, because I am in Java EE6 container and have a request scoped Velocity
> context. In my understanding the only hot spot is the template cache and a
> concurrent Map would solve that, correct?

If you have a request-scoped Velocity (meaning that each request gets
its own Velocity object), then you can certainly create separate
resource loaders, etc. and have zero contention at all. Un-contended
lock acquisition is very cheap these days.

>>> Are concurrent versions of these classes available already?
>>
>> You mean something like java.util.concurrent?
> 
> Yes. I would basically replace the SynchronizedMap with a ConcurrentHashMap.
> Before I do that, I was wondering whether anyone has done that already.
> 
> ... and whether it would work, of course :-)

Since you have studied things in-depth, what do you think? Could
SynchronizedMap be directly-replaced by ConcurrentHashMap? I think it
would be better to use an API-provided class than to use a hand-rolled
one from Velocity.

-chris

Re: Making Velocity truly concurent

[Jan Algermissen <ja...@nordsc.com>]

On Oct 1, 2012, at 5:04 PM, Christopher Schultz wrote:

> Jan,
> 
> On 9/28/12 3:15 PM, Jan Algermissen wrote:
>> 
>> On Sep 28, 2012, at 8:36 PM, Christopher Schultz wrote:
>> 
>>> Jan,
>>> 
>>> On 9/21/12 2:45 AM, Jan Algermissen wrote:
>>>> looking at the code yesterday, I saw that Velocity uses a number of
>>>> Serialized classes (e.g. the SerializedMap in ResourceCache).
>>>> 
>>>> I would like to replace all relevant classes to avoid serialization
>>>> completely.
>>> 
>>> Do you mean avoid all /synchronization/?
>> 
>> Yes, because I am in Java EE6 container and have a request scoped Velocity
>> context. In my understanding the only hot spot is the template cache and a
>> concurrent Map would solve that, correct?
> 
> If you have a request-scoped Velocity (meaning that each request gets
> its own Velocity object), then you can certainly create separate
> resource loaders, etc. and have zero contention at all.

No, I have a singleton with bean managed concurrency (and I do not @Lock any
method there) that holds the single velocity instance.

Every requests gets its own Velocity*Context*.

That should work, because Velocity object is managing concurreny itself by using
a SynchronizedMap.

Correct?


> Un-contended
> lock acquisition is very cheap these days.
> 
>>>> Are concurrent versions of these classes available already?
>>> 
>>> You mean something like java.util.concurrent?
>> 
>> Yes. I would basically replace the SynchronizedMap with a ConcurrentHashMap.
>> Before I do that, I was wondering whether anyone has done that already.
>> 
>> ... and whether it would work, of course :-)
> 
> Since you have studied things in-depth, what do you think? Could
> SynchronizedMap be directly-replaced by ConcurrentHashMap?

That's what I would do - but wasn't sure which classes I'd need to
modify / replace. Also I wasn't sure whether my approach was the
right one to take.

> I think it
> would be better to use an API-provided class than to use a hand-rolled
> one from Velocity.
> 

Hmm, this I do not understand. Can you explain what you mean?


Jan




> -chris
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org