You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by "Ben Manes (JIRA)" <ji...@apache.org> on 2010/05/23 09:55:16 UTC
[jira] Created: (OFBIZ-3779) Upgrade ConcurrentLinkedHashMap
Upgrade ConcurrentLinkedHashMap
-------------------------------
Key: OFBIZ-3779
URL: https://issues.apache.org/jira/browse/OFBIZ-3779
Project: OFBiz
Issue Type: Improvement
Reporter: Ben Manes
Priority: Trivial
The UtilCache class should use v1.0 of the CLHM library. While the previous version is fully functional, I am no longer supporting it. The new design should be faster and more reliable due to not needing to use a pseudo LRU algorithm for performance (which has degradation scenarios ). A true LRU is now supported with no lock contention issues. Please consider upgrading when convenient.
http://code.google.com/p/concurrentlinkedhashmap/
JavaDoc:
http://concurrentlinkedhashmap.googlecode.com/svn/wiki/release-1.0-LRU/index.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Reopened: (OFBIZ-3779) Upgrade ConcurrentLinkedHashMap
Posted by "Adam Heath (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OFBIZ-3779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Adam Heath reopened OFBIZ-3779:
-------------------------------
Sorry, I had to revert this. It breaks the test cases. If you edit framework/base/build.xml, so that only UtilCache is being tested, the testChangeMemSize testcase fails with the new library. Reducing the capacity of CLHM *must* remove items in LRU order. Any other removal order doesn't make sense; If I reduce the capacity, I want to keep the items that were most recently used, and throw away items that are older, until the size is within the new limit.
> Upgrade ConcurrentLinkedHashMap
> -------------------------------
>
> Key: OFBIZ-3779
> URL: https://issues.apache.org/jira/browse/OFBIZ-3779
> Project: OFBiz
> Issue Type: Improvement
> Reporter: Ben Manes
> Assignee: Jacques Le Roux
> Priority: Trivial
> Fix For: SVN trunk
>
>
> The UtilCache class should use v1.0 of the CLHM library. While the previous version is fully functional, I am no longer supporting it. The new design should be faster and more reliable due to not needing to use a pseudo LRU algorithm for performance (which has degradation scenarios ). A true LRU is now supported with no lock contention issues. Please consider upgrading when convenient.
> http://code.google.com/p/concurrentlinkedhashmap/
> JavaDoc:
> http://concurrentlinkedhashmap.googlecode.com/svn/wiki/release-1.0-LRU/index.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3779) Upgrade ConcurrentLinkedHashMap
Posted by "Ben Manes (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OFBIZ-3779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12871229#action_12871229 ]
Ben Manes commented on OFBIZ-3779:
----------------------------------
Fyi, the package name and API changed. I don't see the UtilCache in your file list and the old pkg is referred to in trunk version of UtilCache. You may have broken the build. ;)
> Upgrade ConcurrentLinkedHashMap
> -------------------------------
>
> Key: OFBIZ-3779
> URL: https://issues.apache.org/jira/browse/OFBIZ-3779
> Project: OFBiz
> Issue Type: Improvement
> Reporter: Ben Manes
> Assignee: Jacques Le Roux
> Priority: Trivial
> Fix For: SVN trunk
>
>
> The UtilCache class should use v1.0 of the CLHM library. While the previous version is fully functional, I am no longer supporting it. The new design should be faster and more reliable due to not needing to use a pseudo LRU algorithm for performance (which has degradation scenarios ). A true LRU is now supported with no lock contention issues. Please consider upgrading when convenient.
> http://code.google.com/p/concurrentlinkedhashmap/
> JavaDoc:
> http://concurrentlinkedhashmap.googlecode.com/svn/wiki/release-1.0-LRU/index.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3779) Upgrade ConcurrentLinkedHashMap
Posted by "Adam Heath (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OFBIZ-3779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12871536#action_12871536 ]
Adam Heath commented on OFBIZ-3779:
-----------------------------------
To me, LRU means that when an item needs to be removed, for *whatever* reason, the most LRU item that qualifies will be removed. This applies both to an insert operator, and a size reduction. If that is not what is occurring, then CLHM doesn't implement LRU. LinkedHashMap maintains this LRU design. I could switch to that, and the test cases would function identically(except that then it has to have correct synchronized blocks).
The design of UtilCache is that it uses LRU if there is a maxMemSize parameter set. CLHM 1.0 doesn't implement LRU, so we can't use it.
> Upgrade ConcurrentLinkedHashMap
> -------------------------------
>
> Key: OFBIZ-3779
> URL: https://issues.apache.org/jira/browse/OFBIZ-3779
> Project: OFBiz
> Issue Type: Improvement
> Reporter: Ben Manes
> Assignee: Jacques Le Roux
> Priority: Trivial
> Fix For: SVN trunk
>
>
> The UtilCache class should use v1.0 of the CLHM library. While the previous version is fully functional, I am no longer supporting it. The new design should be faster and more reliable due to not needing to use a pseudo LRU algorithm for performance (which has degradation scenarios ). A true LRU is now supported with no lock contention issues. Please consider upgrading when convenient.
> http://code.google.com/p/concurrentlinkedhashmap/
> JavaDoc:
> http://concurrentlinkedhashmap.googlecode.com/svn/wiki/release-1.0-LRU/index.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (OFBIZ-3779) Upgrade ConcurrentLinkedHashMap
Posted by "Jacques Le Roux (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OFBIZ-3779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jacques Le Roux closed OFBIZ-3779.
----------------------------------
Assignee: Jacques Le Roux
Fix Version/s: SVN trunk
Resolution: Fixed
Thanks for the head ups Ben,
Done in trunk at r947993
> Upgrade ConcurrentLinkedHashMap
> -------------------------------
>
> Key: OFBIZ-3779
> URL: https://issues.apache.org/jira/browse/OFBIZ-3779
> Project: OFBiz
> Issue Type: Improvement
> Reporter: Ben Manes
> Assignee: Jacques Le Roux
> Priority: Trivial
> Fix For: SVN trunk
>
>
> The UtilCache class should use v1.0 of the CLHM library. While the previous version is fully functional, I am no longer supporting it. The new design should be faster and more reliable due to not needing to use a pseudo LRU algorithm for performance (which has degradation scenarios ). A true LRU is now supported with no lock contention issues. Please consider upgrading when convenient.
> http://code.google.com/p/concurrentlinkedhashmap/
> JavaDoc:
> http://concurrentlinkedhashmap.googlecode.com/svn/wiki/release-1.0-LRU/index.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3779) Upgrade ConcurrentLinkedHashMap
Posted by "Adam Heath (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OFBIZ-3779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12871276#action_12871276 ]
Adam Heath commented on OFBIZ-3779:
-----------------------------------
This is cool. I had searched for ages to find some non-blocking LRU system, and fell in love when I found this library. But I never notified upstream that I was using it. It's very excellent that you were able to find us. This kind of cross-community discussion makes me feel all happy and gushi inside.
> Upgrade ConcurrentLinkedHashMap
> -------------------------------
>
> Key: OFBIZ-3779
> URL: https://issues.apache.org/jira/browse/OFBIZ-3779
> Project: OFBiz
> Issue Type: Improvement
> Reporter: Ben Manes
> Assignee: Jacques Le Roux
> Priority: Trivial
> Fix For: SVN trunk
>
>
> The UtilCache class should use v1.0 of the CLHM library. While the previous version is fully functional, I am no longer supporting it. The new design should be faster and more reliable due to not needing to use a pseudo LRU algorithm for performance (which has degradation scenarios ). A true LRU is now supported with no lock contention issues. Please consider upgrading when convenient.
> http://code.google.com/p/concurrentlinkedhashmap/
> JavaDoc:
> http://concurrentlinkedhashmap.googlecode.com/svn/wiki/release-1.0-LRU/index.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3779) Upgrade ConcurrentLinkedHashMap
Posted by "Ben Manes (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OFBIZ-3779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12871291#action_12871291 ]
Ben Manes commented on OFBIZ-3779:
----------------------------------
ha, thanks guys! Its nice to have appreciative users. :)
> Upgrade ConcurrentLinkedHashMap
> -------------------------------
>
> Key: OFBIZ-3779
> URL: https://issues.apache.org/jira/browse/OFBIZ-3779
> Project: OFBiz
> Issue Type: Improvement
> Reporter: Ben Manes
> Assignee: Jacques Le Roux
> Priority: Trivial
> Fix For: SVN trunk
>
>
> The UtilCache class should use v1.0 of the CLHM library. While the previous version is fully functional, I am no longer supporting it. The new design should be faster and more reliable due to not needing to use a pseudo LRU algorithm for performance (which has degradation scenarios ). A true LRU is now supported with no lock contention issues. Please consider upgrading when convenient.
> http://code.google.com/p/concurrentlinkedhashmap/
> JavaDoc:
> http://concurrentlinkedhashmap.googlecode.com/svn/wiki/release-1.0-LRU/index.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3779) Upgrade ConcurrentLinkedHashMap
Posted by "Ben Manes (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OFBIZ-3779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12871541#action_12871541 ]
Ben Manes commented on OFBIZ-3779:
----------------------------------
In any concurrent LRU policy you'll have some fuzziness, though with CLHM it reduces that more than other approaches. The most common concurrent LRU caches use a per-segment LRU link chain such that the global order is lost and you lose efficiency / true LRU order and reads are cheaper by splitting the lock. This type of cache is used in large data sets, e.g. Oracle. The other common approach is to make writes fairly expensive by performing an O(n) scan and tagging an element with its timestamp on reads (how soft references are maintained in LRU order). The LHM approach is fairly common due to its simplicity and the fact that generally the cache operations are not the bottleneck (e.g. memcached does this and spends most of its time on the network protocol). When performance is critical these caches are written in C, such in all of the previous examples.
The only way to have a perfect LRU policy in a concurrent setting is to use a LHM with a fair lock which forces sequential odering. All other approaches may show LRU characteristics in single-threaded context, but the interleaving of operations / threads will break the its purity. A fair lock will be a severe performance hit.
Its fair to argue that CLHM v1.0 weakens a _least recently used_ policy to a _less recently used_ policy, though the statistical error will be quite small. An application's expectation of a cache should be to try to remove entries less likely to be reduce the occurrences of suffering a miss penalty. The LRU policy is one approach at that, but it is routinely beaten in studies due to not accounting for frequency and by not being scan resistant. The LIRS policy will provide a superior hit rate while maintaining the application's expectation. This version of CLHM is intended to provide the architectural structure for supporting LIRS while achieving high performance as well.
You should definitely choose what works best for your needs, so using v1.0 may not be best. Just make sure that you are making the correct trade-off between the performance and efficiency while meeting the usage needs. I suspect that a strict LRU ordering is not actually the application's requirement of a cache.
> Upgrade ConcurrentLinkedHashMap
> -------------------------------
>
> Key: OFBIZ-3779
> URL: https://issues.apache.org/jira/browse/OFBIZ-3779
> Project: OFBiz
> Issue Type: Improvement
> Reporter: Ben Manes
> Assignee: Jacques Le Roux
> Priority: Trivial
> Fix For: SVN trunk
>
>
> The UtilCache class should use v1.0 of the CLHM library. While the previous version is fully functional, I am no longer supporting it. The new design should be faster and more reliable due to not needing to use a pseudo LRU algorithm for performance (which has degradation scenarios ). A true LRU is now supported with no lock contention issues. Please consider upgrading when convenient.
> http://code.google.com/p/concurrentlinkedhashmap/
> JavaDoc:
> http://concurrentlinkedhashmap.googlecode.com/svn/wiki/release-1.0-LRU/index.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3779) Upgrade ConcurrentLinkedHashMap
Posted by "Ben Manes (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OFBIZ-3779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12871529#action_12871529 ]
Ben Manes commented on OFBIZ-3779:
----------------------------------
Ouch, okay. Its hard to guarantee strict LRU order under concurrency due to the randomness of concurrent operations. The previous version in LRU mode provided stronger order by having separate locking for the hash table and the list. The problem with this version was that reads still had to lock the list so under load it would show contention.
This new version weakens recency ordering slightly by using a per-segment buffer for reads and single write queue. The read queues allows for both shrinking the critical section (append to a queue) and not requiring the obtaining the lock (scheduled on queue to allow any thread can drain it). The write queue avoids concurrent writers on different segments from blocking each other, while also maintaining a global capacity constraint when an eviction is required (vs. per-segment LRU chain). While the recency ordering was weakened slightly for performance it is generally acceptable because the evicted entry is cold and may only be slightly off from being the least recently used. The enhancement to include frequency (LIRS) will allow for having a better hit rate than a strict LRU while maintaining performance near that of a raw ConcurrentHashMap. The reducing of capacity evicts the most suitable victim based on the policy described, until it reaches the new threshold.
I'm not sure if your tests needs enforce a strict LRU order since cached data is expected to be transient by the application. You can, however, coerce the new version into behaving like a strict LRU by setting the concurrency level to 1 (a single segment) as a single read queue will be utilized. Because I wanted the flexibility to improve the eviction policy and applications should be dependent on removal order (but rather want a high hit rate), I left the policy details outside of the class's JavaDoc.
Are you sure that you aren't being too strict in your requirements?
> Upgrade ConcurrentLinkedHashMap
> -------------------------------
>
> Key: OFBIZ-3779
> URL: https://issues.apache.org/jira/browse/OFBIZ-3779
> Project: OFBiz
> Issue Type: Improvement
> Reporter: Ben Manes
> Assignee: Jacques Le Roux
> Priority: Trivial
> Fix For: SVN trunk
>
>
> The UtilCache class should use v1.0 of the CLHM library. While the previous version is fully functional, I am no longer supporting it. The new design should be faster and more reliable due to not needing to use a pseudo LRU algorithm for performance (which has degradation scenarios ). A true LRU is now supported with no lock contention issues. Please consider upgrading when convenient.
> http://code.google.com/p/concurrentlinkedhashmap/
> JavaDoc:
> http://concurrentlinkedhashmap.googlecode.com/svn/wiki/release-1.0-LRU/index.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3779) Upgrade ConcurrentLinkedHashMap
Posted by "Jacques Le Roux (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OFBIZ-3779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12871281#action_12871281 ]
Jacques Le Roux commented on OFBIZ-3779:
----------------------------------------
Yes, I feel the same, really nice!
> Upgrade ConcurrentLinkedHashMap
> -------------------------------
>
> Key: OFBIZ-3779
> URL: https://issues.apache.org/jira/browse/OFBIZ-3779
> Project: OFBiz
> Issue Type: Improvement
> Reporter: Ben Manes
> Assignee: Jacques Le Roux
> Priority: Trivial
> Fix For: SVN trunk
>
>
> The UtilCache class should use v1.0 of the CLHM library. While the previous version is fully functional, I am no longer supporting it. The new design should be faster and more reliable due to not needing to use a pseudo LRU algorithm for performance (which has degradation scenarios ). A true LRU is now supported with no lock contention issues. Please consider upgrading when convenient.
> http://code.google.com/p/concurrentlinkedhashmap/
> JavaDoc:
> http://concurrentlinkedhashmap.googlecode.com/svn/wiki/release-1.0-LRU/index.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (OFBIZ-3779) Upgrade
ConcurrentLinkedHashMap
Posted by "Ben Manes (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OFBIZ-3779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12871529#action_12871529 ]
Ben Manes edited comment on OFBIZ-3779 at 5/26/10 2:34 AM:
-----------------------------------------------------------
Ouch, okay. Its hard to guarantee strict LRU order under concurrency due to the randomness of concurrent operations. The previous version in LRU mode provided stronger order by having separate locking for the hash table and the list. The problem with this version was that reads still had to lock the list so under load it would show contention.
This new version weakens recency ordering slightly by using a per-segment queue for reads and single write queue. The read queues allows for both shrinking the critical section (append to a queue) and not require obtaining the lock (scheduled on queue to allow any thread can drain it). The write queue avoids concurrent writers on different segments from blocking each other, while also maintaining a global capacity constraint when an eviction is required (vs. per-segment LRU chain). While the recency ordering was weakened slightly for performance it is generally acceptable because the evicted entry is cold and may only be slightly off from being the least recently used. The enhancement to include frequency (LIRS) will allow for having a better hit rate than a strict LRU while maintaining performance near that of a raw ConcurrentHashMap. The reducing of capacity evicts the most suitable victim based on the policy described, until it reaches the new threshold.
I'm not sure if your tests needs to enforce a strict LRU order since cached data is expected to be transient by the application. You can, however, coerce the new version into behaving like a strict LRU by setting the concurrency level to 1 (a single segment) as a single read queue will be utilized. Because I wanted the flexibility to improve the eviction policy and applications should not be dependent on removal order (but rather want a high hit rate), I left the policy details outside of the class's JavaDoc.
Are you sure that you aren't being too strict in your requirements?
was (Author: ben.manes):
Ouch, okay. Its hard to guarantee strict LRU order under concurrency due to the randomness of concurrent operations. The previous version in LRU mode provided stronger order by having separate locking for the hash table and the list. The problem with this version was that reads still had to lock the list so under load it would show contention.
This new version weakens recency ordering slightly by using a per-segment buffer for reads and single write queue. The read queues allows for both shrinking the critical section (append to a queue) and not requiring the obtaining the lock (scheduled on queue to allow any thread can drain it). The write queue avoids concurrent writers on different segments from blocking each other, while also maintaining a global capacity constraint when an eviction is required (vs. per-segment LRU chain). While the recency ordering was weakened slightly for performance it is generally acceptable because the evicted entry is cold and may only be slightly off from being the least recently used. The enhancement to include frequency (LIRS) will allow for having a better hit rate than a strict LRU while maintaining performance near that of a raw ConcurrentHashMap. The reducing of capacity evicts the most suitable victim based on the policy described, until it reaches the new threshold.
I'm not sure if your tests needs enforce a strict LRU order since cached data is expected to be transient by the application. You can, however, coerce the new version into behaving like a strict LRU by setting the concurrency level to 1 (a single segment) as a single read queue will be utilized. Because I wanted the flexibility to improve the eviction policy and applications should be dependent on removal order (but rather want a high hit rate), I left the policy details outside of the class's JavaDoc.
Are you sure that you aren't being too strict in your requirements?
> Upgrade ConcurrentLinkedHashMap
> -------------------------------
>
> Key: OFBIZ-3779
> URL: https://issues.apache.org/jira/browse/OFBIZ-3779
> Project: OFBiz
> Issue Type: Improvement
> Reporter: Ben Manes
> Assignee: Jacques Le Roux
> Priority: Trivial
> Fix For: SVN trunk
>
>
> The UtilCache class should use v1.0 of the CLHM library. While the previous version is fully functional, I am no longer supporting it. The new design should be faster and more reliable due to not needing to use a pseudo LRU algorithm for performance (which has degradation scenarios ). A true LRU is now supported with no lock contention issues. Please consider upgrading when convenient.
> http://code.google.com/p/concurrentlinkedhashmap/
> JavaDoc:
> http://concurrentlinkedhashmap.googlecode.com/svn/wiki/release-1.0-LRU/index.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3779) Upgrade ConcurrentLinkedHashMap
Posted by "Jacques Le Roux (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OFBIZ-3779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12871759#action_12871759 ]
Jacques Le Roux commented on OFBIZ-3779:
----------------------------------------
Good news thanks Adam!
> Upgrade ConcurrentLinkedHashMap
> -------------------------------
>
> Key: OFBIZ-3779
> URL: https://issues.apache.org/jira/browse/OFBIZ-3779
> Project: OFBiz
> Issue Type: Improvement
> Reporter: Ben Manes
> Assignee: Jacques Le Roux
> Priority: Trivial
> Fix For: SVN trunk
>
>
> The UtilCache class should use v1.0 of the CLHM library. While the previous version is fully functional, I am no longer supporting it. The new design should be faster and more reliable due to not needing to use a pseudo LRU algorithm for performance (which has degradation scenarios ). A true LRU is now supported with no lock contention issues. Please consider upgrading when convenient.
> http://code.google.com/p/concurrentlinkedhashmap/
> JavaDoc:
> http://concurrentlinkedhashmap.googlecode.com/svn/wiki/release-1.0-LRU/index.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (OFBIZ-3779) Upgrade
ConcurrentLinkedHashMap
Posted by "Jacques Le Roux (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OFBIZ-3779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12871080#action_12871080 ]
Jacques Le Roux edited comment on OFBIZ-3779 at 5/25/10 6:13 AM:
-----------------------------------------------------------------
Thanks for the heads up Ben,
Done in trunk at r947993
was (Author: jacques.le.roux):
Thanks for the head ups Ben,
Done in trunk at r947993
> Upgrade ConcurrentLinkedHashMap
> -------------------------------
>
> Key: OFBIZ-3779
> URL: https://issues.apache.org/jira/browse/OFBIZ-3779
> Project: OFBiz
> Issue Type: Improvement
> Reporter: Ben Manes
> Assignee: Jacques Le Roux
> Priority: Trivial
> Fix For: SVN trunk
>
>
> The UtilCache class should use v1.0 of the CLHM library. While the previous version is fully functional, I am no longer supporting it. The new design should be faster and more reliable due to not needing to use a pseudo LRU algorithm for performance (which has degradation scenarios ). A true LRU is now supported with no lock contention issues. Please consider upgrading when convenient.
> http://code.google.com/p/concurrentlinkedhashmap/
> JavaDoc:
> http://concurrentlinkedhashmap.googlecode.com/svn/wiki/release-1.0-LRU/index.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3779) Upgrade ConcurrentLinkedHashMap
Posted by "Jacques Le Roux (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OFBIZ-3779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12871243#action_12871243 ]
Jacques Le Roux commented on OFBIZ-3779:
----------------------------------------
:) Yes I did (too fast, too much things at the same time), I have already fixed it at r948037
Thanks to care!
> Upgrade ConcurrentLinkedHashMap
> -------------------------------
>
> Key: OFBIZ-3779
> URL: https://issues.apache.org/jira/browse/OFBIZ-3779
> Project: OFBiz
> Issue Type: Improvement
> Reporter: Ben Manes
> Assignee: Jacques Le Roux
> Priority: Trivial
> Fix For: SVN trunk
>
>
> The UtilCache class should use v1.0 of the CLHM library. While the previous version is fully functional, I am no longer supporting it. The new design should be faster and more reliable due to not needing to use a pseudo LRU algorithm for performance (which has degradation scenarios ). A true LRU is now supported with no lock contention issues. Please consider upgrading when convenient.
> http://code.google.com/p/concurrentlinkedhashmap/
> JavaDoc:
> http://concurrentlinkedhashmap.googlecode.com/svn/wiki/release-1.0-LRU/index.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (OFBIZ-3779) Upgrade ConcurrentLinkedHashMap
Posted by "Adam Heath (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OFBIZ-3779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Adam Heath closed OFBIZ-3779.
-----------------------------
Resolution: Fixed
Reapplied this, while updating the test case, in revision 948449.
> Upgrade ConcurrentLinkedHashMap
> -------------------------------
>
> Key: OFBIZ-3779
> URL: https://issues.apache.org/jira/browse/OFBIZ-3779
> Project: OFBiz
> Issue Type: Improvement
> Reporter: Ben Manes
> Assignee: Jacques Le Roux
> Priority: Trivial
> Fix For: SVN trunk
>
>
> The UtilCache class should use v1.0 of the CLHM library. While the previous version is fully functional, I am no longer supporting it. The new design should be faster and more reliable due to not needing to use a pseudo LRU algorithm for performance (which has degradation scenarios ). A true LRU is now supported with no lock contention issues. Please consider upgrading when convenient.
> http://code.google.com/p/concurrentlinkedhashmap/
> JavaDoc:
> http://concurrentlinkedhashmap.googlecode.com/svn/wiki/release-1.0-LRU/index.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.