[JBoss JIRA] (ISPN-7157) NPE possible in cache eviction 'HIR_NONRESIDENT'
by Elias Ross (JIRA)
Elias Ross created ISPN-7157:
--------------------------------
Summary: NPE possible in cache eviction 'HIR_NONRESIDENT'
Key: ISPN-7157
URL: https://issues.jboss.org/browse/ISPN-7157
Project: Infinispan
Issue Type: Bug
Components: Core
Affects Versions: 8.2.2.Final
Reporter: Elias Ross
Observed the following:
java.lang.NullPointerException: null
at org.infinispan.commons.util.concurrent.jdk8backported.BoundedEquivalentConcurrentHashMapV8$LIRSEvictionPolicy.findIfEntriesNeedEvicting(BoundedEquivalentConcurrentHashMapV8.java:1531) ~[org.infinispan-infinispan-commons-8.2.2.Final.jar:8.2.2.Final]
at org.infinispan.commons.util.concurrent.jdk8backported.BoundedEquivalentConcurrentHashMapV8.compute(BoundedEquivalentConcurrentHashMapV8.java:3657) ~[org.infinispan-infinispan-commons-8.2.2.Final.jar:8.2.2.Final]
at org.infinispan.container.DefaultDataContainer.put(DefaultDataContainer.java:227) ~[org.infinispan-infinispan-core-8.2.2.Final.jar:8.2.2.Final]
at org.infinispan.container.entries.ReadCommittedEntry.commit(ReadCommittedEntry.java:168) ~[org.infinispan-infinispan-core-8.2.2.Final.jar:8.2.2.Final]
at org.infinispan.statetransfer.CommitManager.commit(CommitManager.java:100) ~[org.infinispan-infinispan-core-8.2.2.Final.jar:8.2.2.Final]
at org.infinispan.interceptors.locking.ClusteringDependentLogic$LocalLogic.commitSingleEntry(ClusteringDependentLogic.java:299) ~[org.infinispan-infinispan-core-8.2.2.Final.jar:8.2.2.Final]
at org.infinispan.interceptors.locking.ClusteringDependentLogic$AbstractClusteringDependentLogic.commitEntry(ClusteringDependentLogic.java:115) ~[org.infinispan-infinispan-core-8.2.2.Final.jar:8.2.2.Final]
at org.infinispan.interceptors.EntryWrappingInterceptor.commitContextEntry(EntryWrappingInterceptor.java:479) ~[org.infinispan-infinispan-core-8.2.2.Final.jar:8.2.2.Final]
at org.infinispan.interceptors.EntryWrappingInterceptor.commitEntryIfNeeded(EntryWrappingInterceptor.java:655) ~[org.infinispan-infinispan-core-8.2.2.Final.jar:8.2.2.Final]
at org.infinispan.interceptors.EntryWrappingInterceptor.commitContextEntries(EntryWrappingInterceptor.java:456) ~[org.infinispan-infinispan-core-8.2.2.Final.jar:8.2.2.Final]
at org.infinispan.interceptors.EntryWrappingInterceptor.invokeNextAndApplyChanges(EntryWrappingInterceptor.java:530) ~[org.infinispan-infinispan-core-8.2.2.Final.jar:8.2.2.Final]
...
I think the cause is this code:
} else if (evict.state == Recency.HIR_NONRESIDENT) {
Node<K, V> node = f.find(hash, evict.getKey());
V prevValue = node.val;
^^^ node can be null here
if (prevValue != NULL_VALUE) {
node.val = (V) NULL_VALUE;
map.addCount(-1, -1);
This is 8.2.2
In 8.2.x the code is:
} else if (evict.state == Recency.HIR_NONRESIDENT) {
BoundedEquivalentConcurrentHashMapV8.Node<K, V> node = f.find(hash, evict.getKey());
V prevValue = node.val;
^^^ node can be null here
if (prevValue != BoundedEquivalentConcurrentHashMapV8.NULL_VALUE) {
node.val = (V) BoundedEquivalentConcurrentHashMapV8.NULL_VALUE;
Solution would be to check for null values here.
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
7 years, 11 months
[JBoss JIRA] (ISPN-7140) Concurrent modifications succeed in pessimistic cache
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-7140?page=com.atlassian.jira.plugin.... ]
Radim Vansa updated ISPN-7140:
------------------------------
Status: Open (was: New)
> Concurrent modifications succeed in pessimistic cache
> -----------------------------------------------------
>
> Key: ISPN-7140
> URL: https://issues.jboss.org/browse/ISPN-7140
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.0.0.Alpha4
> Reporter: Radim Vansa
> Labels: testsuite_stability
> Attachments: log2.txt
>
>
> During node crash, two concurrent modifications in can both succeed in pessimistic tx cache.
> This also causes random failures in {{InfinispanNodeFailureTest}}:
> 1. TX1 originating on A acquires lock for key X, A is primary owner
> 2. C is killed and B becomes primary owner of key X
> 3. TX2 originating on B acquires lock for key X, B is now primary owner
> 4. TX1 commits the tx, Prepare is sent with the new topology id so it commits fine
> 5. TX2 also commits the transaction
> Log attached (this is not master but changes should not be related).
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
7 years, 11 months