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 (JIRA)" <ji...@apache.org> on 2010/03/02 11:17:27 UTC
[jira] Created: (CLK-636) Replace
EDU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap with
java.util.concurrent.ConcurrentHashMap
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
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.
[jira] Commented: (CLK-636) Replace
EDU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap with
java.util.concurrent.ConcurrentHashMap
Posted by "Henry Saputra (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLK-636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12841110#action_12841110 ]
Henry Saputra commented on CLK-636:
-----------------------------------
We could simulate behavior of ConcurrentReaderHashMap with ConcurrentHashMap by setting concurrencyLevel to one.
Malcolm, Adrian, do you have sample application that could replicate the weird instantiation error?
I just think that this need to be fixed since Doug Lea (author of ConcurrentReaderHashMap) encourages users to move to Java 5 concurrency package with better lock and synchronization solution.
> 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.
[jira] Commented: (CLK-636) Replace
EDU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap with
java.util.concurrent.ConcurrentHashMap
Posted by "Henry Saputra (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLK-636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12840756#action_12840756 ]
Henry Saputra commented on CLK-636:
-----------------------------------
Hi Joseph,
This is not about coolness.
Stability is important but since the project is no longer maintained moving from concurrentreaderhashmap to Java 5 ConcurrentHashMap class.
I believe we need to move on to the latest Java standards like generics and modern packages like concurrency, especially there is no reason to stay using ConcurrentReaderHashMap.
If you know good reason why switching wont work please let me know.
- Henry
> 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
>
> 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.
[jira] Resolved: (CLK-636) Replace
EDU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap with
java.util.concurrent.ConcurrentHashMap
Posted by "Bob Schellink (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLK-636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bob Schellink resolved CLK-636.
-------------------------------
Resolution: Fixed
fixed in trunk
> 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
> Assignee: Bob Schellink
> Priority: Minor
> Fix For: 2.3.0-M1
>
> 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.
[jira] Commented: (CLK-636) Replace
EDU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap with
java.util.concurrent.ConcurrentHashMap
Posted by "Malcolm Edgar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLK-636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12840106#action_12840106 ]
Malcolm Edgar commented on CLK-636:
-----------------------------------
Hi Henry,
I have tried this before and it caused strange object instantiation errors with Spring. I was not able to determine the underlying cause.
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
>
> 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.
[jira] Updated: (CLK-636) Replace
EDU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap with
java.util.concurrent.ConcurrentHashMap
Posted by "Bob Schellink (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLK-636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bob Schellink updated CLK-636:
------------------------------
Assignee: Bob Schellink
Fix Version/s: 2.3.0-M1
> 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
> Assignee: Bob Schellink
> Priority: Minor
> Fix For: 2.3.0-M1
>
> 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.
[jira] Updated: (CLK-636) Replace
EDU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap with
java.util.concurrent.ConcurrentHashMap
Posted by "Henry Saputra (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLK-636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Henry Saputra updated CLK-636:
------------------------------
Attachment: concurrentreader_patch.diff
Patch for replacing ConcurrentReaderHashMap with ConcurrentHashMap.
Also contains changes to click/build/build.xml to remove this class from build-distribution target.
> 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.
[jira] Commented: (CLK-636) Replace
EDU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap with
java.util.concurrent.ConcurrentHashMap
Posted by "Malcolm Edgar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLK-636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12840928#action_12840928 ]
Malcolm Edgar commented on CLK-636:
-----------------------------------
Hi Henry,
The difficulty in applying this change is that I am not confident that it will not reintroduce the Spring errors we observed earlier. This error is difficult to quantify, does it only occur with certain Spring versions, with certain configurations and application JAR dependencies, does it relate the application server etc.
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.
[jira] Updated: (CLK-636) Replace
EDU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap with
java.util.concurrent.ConcurrentHashMap
Posted by "Malcolm Edgar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLK-636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Malcolm Edgar updated CLK-636:
------------------------------
Priority: Minor (was: Major)
> 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
> Priority: Minor
> 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.
[jira] Commented: (CLK-636) Replace
EDU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap with
java.util.concurrent.ConcurrentHashMap
Posted by "Henry Saputra (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLK-636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12840112#action_12840112 ]
Henry Saputra commented on CLK-636:
-----------------------------------
Hi Malcolm,
I have tried to deploy the click-examples and looks like it run well. I also tried the spring security and able to create account.
I dont see any custom bean/service in the spring xml file.
Is there any other specific test/ example I could run to test with Spring?
- Henry
> 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
>
> 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.
[jira] Commented: (CLK-636) Replace
EDU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap with
java.util.concurrent.ConcurrentHashMap
Posted by "Andrey Rybin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLK-636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12841170#action_12841170 ]
Andrey Rybin commented on CLK-636:
----------------------------------
+1 for ConcurrentHashMap
>I have tried this before and it caused strange object instantiation errors with Spring. I was not able to determine the underlying cause.
May be It was Spring bug (Click should support v2 and up)?
Spring use ConcurrentHashMap internally.
Since 3.0 their own wrapper is deprecated
quote:
* @deprecated as of Spring 3.0, since standard {@link java.util.concurrent.ConcurrentMap}
* is available on Java 5+ anyway
> 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.
[jira] Reopened: (CLK-636) Replace
EDU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap with
java.util.concurrent.ConcurrentHashMap
Posted by "Malcolm Edgar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLK-636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Malcolm Edgar reopened CLK-636:
-------------------------------
Reopening issue for continuing analysis, will look at this in a future release.
> 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.
[jira] Commented: (CLK-636) Replace
EDU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap with
java.util.concurrent.ConcurrentHashMap
Posted by "Joseph Schmidt (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLK-636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12840583#action_12840583 ]
Joseph Schmidt commented on CLK-636:
------------------------------------
> I have tried to deploy the click-examples and looks like it run well. ...
Henry,
If you take a look at the Click history:
http://click.apache.org/docs/roadmap-changes.html
you will see that it's since 2005 (for the public) around, and so, there are many commercial applications that depend on it and it's stability.
It's not that simple as just to change something and see if click-examples work :).
The base of Click applications in production is very very important and this is why backward compatibility and stability is key when considering updates to Click: many "cool" requests(even with patches) were refused because of this.
> 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
>
> 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.
[jira] Commented: (CLK-636) Replace
EDU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap with
java.util.concurrent.ConcurrentHashMap
Posted by "Henry Saputra (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLK-636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12841113#action_12841113 ]
Henry Saputra commented on CLK-636:
-----------------------------------
Actually the code in the PropertyUtils could still allow two threads could go in to call Map.get and both may return null so the operation will execute to override the value in the Map cache.
I am proposing to change the Map instead of <String, Object> but to <String, Future>. Then the first thread call to Map.get will check if there exist task to get the cache value.
If already exist just call get on it otherwise create one and by leveraging ConcurrentHashMap.putIfAbsent we could guarantee only one Future object exist for the String key.
> 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.
[jira] Commented: (CLK-636) Replace
EDU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap with
java.util.concurrent.ConcurrentHashMap
Posted by "Adrian A. (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLK-636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12840108#action_12840108 ]
Adrian A. commented on CLK-636:
-------------------------------
> I have tried this before and it caused strange object instantiation errors with Spring.
> I was not able to determine the underlying cause.
I was experiencing the same problems.
Especially on WebSphere and Weblogic users complained about such problems, so we reverted back the patch.
> 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
>
> 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.
[jira] Commented: (CLK-636) Replace
EDU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap with
java.util.concurrent.ConcurrentHashMap
Posted by "Henry Saputra (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLK-636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12840101#action_12840101 ]
Henry Saputra commented on CLK-636:
-----------------------------------
If its ok, I could work on this and submit a patch.
> 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
>
> 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.
[jira] Closed: (CLK-636) Replace
EDU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap with
java.util.concurrent.ConcurrentHashMap
Posted by "Malcolm Edgar (JIRA)" <ji...@apache.org>.
[ 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.