[
https://issues.apache.org/jira/browse/JEXL-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Holger Sunke updated JEXL-414:
------------------------------
Description:
I found the SoftCache used from within the Jexcel 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 `SoftCahce`
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.
was:
I found the SoftCache used from within the Jexcel class `Engin` 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 `SoftCahce`
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.
Summary: SoftCache may suffer from race conditions (was: SoftCach may
suffer from race conditions)
> 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
> Priority: Major
>
> I found the SoftCache used from within the Jexcel 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 `SoftCahce`
> 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)
