You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@click.apache.org by Henry Saputra <he...@gmail.com> on 2010/03/04 20:14:51 UTC
Re: [jira] Closed: (CLK-636) Replace EDU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap
with java.util.concurrent.ConcurrentHashMap
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) <ji...@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.
>
>
Re: [jira] Closed: (CLK-636) Replace EDU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap
with java.util.concurrent.ConcurrentHashMap
Posted by Malcolm Edgar <ma...@gmail.com>.
>From memory this occurred with the Spring 2.x series.
regards Malcolm Edgar
On Fri, Mar 5, 2010 at 7:17 AM, Adrian A. <a....@gmail.com> wrote:
>> 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 haven't tried yet to use Spring 3.0.x to see if there are still any
> problems.
>
> Adrian.
>
>
Re: [jira] Closed: (CLK-636) Replace EDU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap
with java.util.concurrent.ConcurrentHashMap
Posted by "Adrian A." <a....@gmail.com>.
> 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 haven't tried yet to use Spring 3.0.x to see if there are still any
problems.
Adrian.
Re: [jira] Closed: (CLK-636) Replace EDU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap
with java.util.concurrent.ConcurrentHashMap
Posted by Malcolm Edgar <ma...@gmail.com>.
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 <sa...@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
>> <ma...@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 <ma...@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.
>>
>>
>>
>
>
Re: [jira] Closed: (CLK-636) Replace EDU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap
with java.util.concurrent.ConcurrentHashMap
Posted by Bob Schellink <sa...@gmail.com>.
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
> <ma...@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 <ma...@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.
>
>
>
Re: [jira] Closed: (CLK-636) Replace EDU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap
with java.util.concurrent.ConcurrentHashMap
Posted by Henry Saputra <he...@gmail.com>.
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 <he...@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) <ji...@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.
>>
>>
>