click-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Malcolm Edgar <malcolm.ed...@gmail.com>
Subject Re: [jira] Closed: (CLK-636) Replace EDU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap with java.util.concurrent.ConcurrentHashMap
Date Fri, 05 Mar 2010 00:05:16 GMT
I am happy to leave this issue open, to be revisited latter.

regards Malcolm Edgar

On Fri, Mar 5, 2010 at 8:56 AM, Bob Schellink <sabob1@gmail.com> wrote:
> Speaking of performance, we have a simple performance benchmark
> application[1] that renders a 5x50 table grid (It contains implementations
> for other well known frameworks as well). Would be interesting to see if the
> different Map implementations will impact this test.
>
> kind regards
>
> bob
>
> [1]: http://svn.apache.org/repos/asf/click/trunk/examples/click-bench/
>
> On 5/03/2010 07:56 AM, Henry Saputra wrote:
>>
>> HI Malcolm,
>>
>> If you think the risk is too high for now could we just leave it open so
>> it could be revisited later?
>>
>> Sorry about keep pushing about this but maintaining legacy code is a
>> pain and could have impact on performance.
>>
>> Thanks,
>>
>> - Henry
>>
>> On Thu, Mar 4, 2010 at 11:14 AM, Henry Saputra <henry.saputra@gmail.com
>> <mailto:henry.saputra@gmail.com>> wrote:
>>
>>    Hi Malcolm,
>>
>>    Thanks for your input for this bug.
>>
>>    I understand the risk but I dont think this is the right solution
>>    since the more Java move to better concurrency support, sticking
>>    with the "deprecated" class will make the framework to be sluggish.
>>
>>    Removing this dependency on Doug's concurrency package to Java EE
>>    concurrency package and supporting Java generics should make the
>>    Click framework to be more faster and efficient.
>>
>>    I have used Spring 2.5 before with Java concurrent package before
>>    and never see any problem.
>>
>>    - Henry
>>
>>
>>    On Thu, Mar 4, 2010 at 4:11 AM, Malcolm Edgar (JIRA)
>>    <jira@apache.org <mailto:jira@apache.org>> wrote:
>>
>>
>>             [
>>
>>  https://issues.apache.org/jira/browse/CLK-636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
>>        ]
>>
>>        Malcolm Edgar closed CLK-636.
>>        -----------------------------
>>
>>            Resolution: Won't Fix
>>
>>        I appreciate the though around this issue but risk to production
>>        applications using various Spring version is too high for the
>>        reward of removing this class.
>>
>>        regards Malcolm Edgar
>>
>>         > Replace
>>        EDU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap with
>>        java.util.concurrent.ConcurrentHashMap
>>         >
>>
>>  ------------------------------------------------------------------------------------------------------------
>>         >
>>         >                 Key: CLK-636
>>         >                 URL:
>>        https://issues.apache.org/jira/browse/CLK-636
>>         >             Project: Click
>>         >          Issue Type: Improvement
>>         >          Components: core
>>         >    Affects Versions: 2.2.0
>>         >            Reporter: Henry Saputra
>>         >         Attachments: concurrentreader_patch.diff
>>         >
>>         >
>>         > Since Click required Java SDK 1.5 or later, we could leverage
>>        the java.util.concurrent.ConcurrentHashMap class to replace
>>        EDU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap class
>>        so reducing the Click runtime dependency.
>>         > In my opinion here are some good reasons why:
>>         > 1. The ConcurrentHashMap class in Java SDK is more efficient
>>        since it utilizes internal hash classes to support better
>>        granularity and concurrency compare to simple syncrhonized on
>>        the instance like in
>>        DU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap.
>>         > 2. Looking at the use case ConcurrentReaderHashMap in Click,
>>        it used to cache the OGNL expression (please correct me if I am
>>        wrong). This scenario does not need exclusive lock on update
>>        which is the intended/ preferred use case for
>>        ConcurrentReaderHashMap. If there is a miss on OGNL expression
>>        on a name in the cache, it will cerate one and put it to the map
>>        if no other thread has not. So it will still perform as well as
>>        or better locking entire table. However, if we do need exclusive
>>        lock on update, we can simulate ConcurrentReaderHashMap with
>>        ConcurrentHashMap by setting concurrencyLevel to one.
>>         > 3. The ConcurrentHashMap support generic which is part of
>>        task being done to move Click code to Java generics.
>>         > 4. Looks like the
>>        EDU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap class
>>        is created by Doug Lea before contributions to
>>        java.util.concurrent packages in Java 1.5 SDK so the code may no
>>        longer optimized.
>>
>>        --
>>        This message is automatically generated by JIRA.
>>        -
>>        You can reply to this email to add a comment to the issue online.
>>
>>
>>
>
>

Mime
View raw message