[
https://issues.apache.org/jira/browse/JEXL-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787449#comment-17787449
]
Henri Biestro edited comment on JEXL-414 at 11/18/23 4:32 AM:
--------------------------------------------------------------
I've dropped a
[version|https://github.com/apache/commons-jexl/commit/e4b6b3956ed4f7e1404e4523c6629216b2384476]
that exposes a cache interface and method factories to create either
synchronous or concurrent caches.
The former uses a linkedhashmap but fully synchronized (to correct the initial
bug) whilst the latter uses a concurrentlinkedhashmap-lru (from Google). Since
this introduces a new dependency, it would be nice to ensure this improves
concurrency; I suspect that under low contention, there is no disadvantage to
the synchronized version.
I may revise this to let the concurrent version in the test directory to avoid
the new dependency; it might also be better to use Cafeine but that is an even
bigger dependency.
Let me know what you think and find.
was (Author: henrib):
I've dropped a
[version|https://github.com/apache/commons-jexl/commit/e4b6b3956ed4f7e1404e4523c6629216b2384476]
that exposes a cache interface and method factories to create either
synchronous or concurrent caches.
The former uses a linkedhashmap but fully synchronized (to correct the initial
bug) whilst the latter uses a concurrentlinkedhashmap-lru (from Google). Since
this introduces a new dependency, it would be nice to ensure this improves
concurrency; I suspect that under low contention, there is no disadvantage to
the synchronized version.
I may revise this to let the concurrent version in the test directory to avoid
the new dependency; it might also be better to use Cafeine but that is an even
bigger dependency.
> SoftCache may suffer from race conditions
> -----------------------------------------
>
> Key: JEXL-414
> URL: https://issues.apache.org/jira/browse/JEXL-414
> Project: Commons JEXL
> Issue Type: Bug
> Affects Versions: 3.3
> Reporter: Holger Sunke
> Assignee: Henri Biestro
> Priority: Major
>
> I found the SoftCache used from within the JEXL class Engine to be very
> relevant for overall performance (depending on the application) on the one
> hand, but on the other hand it may suffer from race conditions.
> While solid efford was taken to protect it from race conditions by
> surrounding access using a ReadWriteLock, parallel read access actually do
> reach out on a LinkedHashMap having set accessOrder=true. This means that on
> every potentially parallel, non serialized invocation of LinkedHashMap#get
> the order of elements is modified to bring the last accessed element down to
> the tail of the internal linked list structure and modCount is incremented.
>
> In our application rendering web templates, we observe multiple of 10000
> access on the SoftCache per page impression and multiple of 10 page
> impressions per second per JVM instance.
> Not sure whether this is result of race condition claimed above, in heapdumps
> of that application I observed the LinkedHashMap used within SoftCache having
> a size of ~9500 elements while the SoftCache#size is set to limit the cache
> to 5000 elements. Additionaly the LinkedHashMap#modCount shows up with
> arbitrary giant positive or negative numbers, telling me it has overflown
> already after some hours of application uptime.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
