click-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bob Schellink <sab...@gmail.com>
Subject Re: [jira] Closed: (CLK-636) Replace EDU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap with java.util.concurrent.ConcurrentHashMap
Date Thu, 04 Mar 2010 21:56:46 GMT
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