August 2017 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-8186) DistTopologyChangeUnderLoadTest.testPutsSucceedWhileTopologyChanges sometimes fails with magic error

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-8186?page=com.atlassian.jira.plugin.... ] Work on ISPN-8186 stopped by Galder Zamarreño. ---------------------------------------------- > DistTopologyChangeUnderLoadTest.testPutsSucceedWhileTopologyChanges sometimes fails with magic error > ---------------------------------------------------------------------------------------------------- > > Key: ISPN-8186 > URL: https://issues.jboss.org/browse/ISPN-8186 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols > Affects Versions: 9.1.0.Final > Reporter: Tristan Tarrant > Assignee: Galder Zamarreño > > Happens sometimes on CI: > DistTopologyChangeUnderLoadTest.testPutsSucceedWhileTopologyChanges > {code} > org.infinispan.client.hotrod.exceptions.InvalidResponseException:: > Invalid magic number. Expected 0xa1 and received 0xdb at > org.infinispan.client.hotrod.impl.protocol.Codec20.readMagic(Codec20.java:333) at > org.infinispan.client.hotrod.impl.protocol.Codec20.readHeader(Codec20.java:135) at > org.infinispan.client.hotrod.impl.operations.HotRodOperation.readHeaderAndValidate(HotRodOperation.java:60) at > org.infinispan.client.hotrod.impl.operations.AbstractKeyValueOperation.sendPutOperation(AbstractKeyValueOperation.java:58) at > org.infinispan.client.hotrod.impl.operations.PutOperation.executeOperation(PutOperation.java:34) at > org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:56) at > org.infinispan.client.hotrod.impl.RemoteCacheImpl.put(RemoteCacheImpl.java:268) at > org.infinispan.client.hotrod.impl.RemoteCacheSupport.put(RemoteCacheSupport.java:77) at > org.infinispan.client.hotrod.DistTopologyChangeUnderLoadTest.testPutsSucceedWhileTopologyChanges(DistTopologyChangeUnderLoadTest.java:57) at > java.util.concurrent.FutureTask.run(FutureTask.java:266) at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at > java.lang.Thread.run(Thread.java:748) ... Removed 16 stack frames > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8186) DistTopologyChangeUnderLoadTest.testPutsSucceedWhileTopologyChanges sometimes fails with magic error

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-8186?page=com.atlassian.jira.plugin.... ] Work on ISPN-8186 started by Galder Zamarreño. ---------------------------------------------- > DistTopologyChangeUnderLoadTest.testPutsSucceedWhileTopologyChanges sometimes fails with magic error > ---------------------------------------------------------------------------------------------------- > > Key: ISPN-8186 > URL: https://issues.jboss.org/browse/ISPN-8186 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols > Affects Versions: 9.1.0.Final > Reporter: Tristan Tarrant > Assignee: Galder Zamarreño > > Happens sometimes on CI: > DistTopologyChangeUnderLoadTest.testPutsSucceedWhileTopologyChanges > {code} > org.infinispan.client.hotrod.exceptions.InvalidResponseException:: > Invalid magic number. Expected 0xa1 and received 0xdb at > org.infinispan.client.hotrod.impl.protocol.Codec20.readMagic(Codec20.java:333) at > org.infinispan.client.hotrod.impl.protocol.Codec20.readHeader(Codec20.java:135) at > org.infinispan.client.hotrod.impl.operations.HotRodOperation.readHeaderAndValidate(HotRodOperation.java:60) at > org.infinispan.client.hotrod.impl.operations.AbstractKeyValueOperation.sendPutOperation(AbstractKeyValueOperation.java:58) at > org.infinispan.client.hotrod.impl.operations.PutOperation.executeOperation(PutOperation.java:34) at > org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:56) at > org.infinispan.client.hotrod.impl.RemoteCacheImpl.put(RemoteCacheImpl.java:268) at > org.infinispan.client.hotrod.impl.RemoteCacheSupport.put(RemoteCacheSupport.java:77) at > org.infinispan.client.hotrod.DistTopologyChangeUnderLoadTest.testPutsSucceedWhileTopologyChanges(DistTopologyChangeUnderLoadTest.java:57) at > java.util.concurrent.FutureTask.run(FutureTask.java:266) at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at > java.lang.Thread.run(Thread.java:748) ... Removed 16 stack frames > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2103) Concurrent access after removal of an AtomicMap should NOT result in an IllegalStateException when accessed by other threads

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-2103?page=com.atlassian.jira.plugin.... ] Radim Vansa closed ISPN-2103. ----------------------------- Resolution: Out of Date > Concurrent access after removal of an AtomicMap should NOT result in an IllegalStateException when accessed by other threads > ---------------------------------------------------------------------------------------------------------------------------- > > Key: ISPN-2103 > URL: https://issues.jboss.org/browse/ISPN-2103 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 5.1.5.FINAL > Reporter: Adrian Nistor > Assignee: Pedro Ruivo > > ISPN-1121 introduces an IllegalStateException that is being thrown from AtomicMap methods once the map handle has become stale (ie. removed from cache). In case of concurrent access, the exception is thrown to all threads not just to the thread that performed the removal. This was fine-ish in older versions of Infinispan before introduction of optimistic and pessimistic locking but it should be reconsidered now because: > 1. It interferes/overlaps with transaction isolation. We should rely on the selected locking scheme (OL/PL) to detect conflicts between transactions and report the problem accordingly. Especially if the stale map is used just for reading - this should be allowed to work rather than stop it. > 2. This exception is pretty disruptive and awkward to handle. All methods of an AtomicMap can result in this exception and the current thread has to be prepared for handling it if other threads remove the map. Not much transaction isolation. > 3. Since the TreeCache is backed by AtomicMap nearly all Tree API can throw this. > The proposed fix consists of: > 1. removing AtomicHashMap.removed flag and AtomicHashMap.markRemoved() method. > 2. revising AtomicHashMapProxy.assertValid() method to check only if the map is null (ie. removed) but no longer use the removed flag. > 3. revising ReadCommittedEntry.commit() method to no longer call markRemoved() method. > The consequences of these changes are: > 1. Any further access to a stale map results in IllegalStateException ONLY in the thread that performed the removal. This thread 'knows' the map is stale so it is fine to punish it. Other threads remain unaffected until lock acquisition or commit is performed (depending on locking model). > 2. Other threads can continue to use the previously obtained map handle for reads without danger of getting an exception. > 3. If a write operation is done on the map, the results depend on the locking model: > 3.1 optimistic locking + write skew check: a WriteSkewException will stop the commit during prepare > 3.2 optimistic locking, no write skew check: the write is committed and the work of the transaction that removed the map is overwritten. The map is effectively revived. > 3.3 pessimistic locking: same as 3.2 > Please note 3.2 and 3.3 work the same as for normal values (not atomic maps). -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5584) Support fine-grained write skew check for FineGrainedAtomicMap entries

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-5584?page=com.atlassian.jira.plugin.... ] Radim Vansa closed ISPN-5584. ----------------------------- Resolution: Duplicate Issue > Support fine-grained write skew check for FineGrainedAtomicMap entries > ---------------------------------------------------------------------- > > Key: ISPN-5584 > URL: https://issues.jboss.org/browse/ISPN-5584 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Affects Versions: 8.0.0.Alpha2, 7.2.3.Final > Reporter: Dan Berindei > Fix For: 9.2.0.Final > > > FineGrainedAtomicMap doesn't currently work with write skew check enabled. > I was able to make it work by adding a special case for DeltaAwareCacheEntry in WriteSkewHelper, however the map has a single version, so the write skew check fails if any of the sub-keys were modified in parallel. With pessimistic locking, fine-grained maps allow the user to modify different sub-keys concurrently, we should allow the same with optimistic locking. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3123) FineGrainedAtomicHashMap should support independent write skew checks for each key

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-3123?page=com.atlassian.jira.plugin.... ] Radim Vansa resolved ISPN-3123. ------------------------------- Resolution: Done I think this was done in ISPN-7803 > FineGrainedAtomicHashMap should support independent write skew checks for each key > ---------------------------------------------------------------------------------- > > Key: ISPN-3123 > URL: https://issues.jboss.org/browse/ISPN-3123 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 5.3.0.Beta2 > Reporter: Dan Berindei > > FineGrainedAtomicHashMap supports fine-grained locking in pessimistic mode, but in optimistic mode the write-skew check is still done for the entire map. > The write skew check should be done for each entry of the map individually, so that multiple transactions can update the same FineGrainedAtomicHashMap at the same time. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3123) FineGrainedAtomicHashMap should support independent write skew checks for each key

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-3123?page=com.atlassian.jira.plugin.... ] Radim Vansa reassigned ISPN-3123: --------------------------------- Assignee: Radim Vansa > FineGrainedAtomicHashMap should support independent write skew checks for each key > ---------------------------------------------------------------------------------- > > Key: ISPN-3123 > URL: https://issues.jboss.org/browse/ISPN-3123 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 5.3.0.Beta2 > Reporter: Dan Berindei > Assignee: Radim Vansa > > FineGrainedAtomicHashMap supports fine-grained locking in pessimistic mode, but in optimistic mode the write-skew check is still done for the entire map. > The write skew check should be done for each entry of the map individually, so that multiple transactions can update the same FineGrainedAtomicHashMap at the same time. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2729) [FineGrainedAtomicMap] Class Cast Exception in Clustered + Repeatable Read + Write Skew

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-2729?page=com.atlassian.jira.plugin.... ] Radim Vansa closed ISPN-2729. ----------------------------- Resolution: Out of Date > [FineGrainedAtomicMap] Class Cast Exception in Clustered + Repeatable Read + Write Skew > --------------------------------------------------------------------------------------- > > Key: ISPN-2729 > URL: https://issues.jboss.org/browse/ISPN-2729 > Project: Infinispan > Issue Type: Bug > Components: Core, Transactions > Environment: Mac OSx 10.5, Java 1.6 sun-jdk, maven 3.0.4 > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Labels: atomic_map, clustered, write-skew > > Test case available in here [1] > When a transaction commits, the write skew check performs the validation by casting the cache entry to a ClusteredRepeatableReadEntry. However, the entry is a DeltaAwareCacheEntry. > This happens when you have operations over a map inside a transaction. > The tests failing are: > WriteSkewFineGrainedAtomicMapAPITest.testSizeOnCache() > WriteSkewFineGrainedAtomicMapAPITest.testCreateMapInTx() > [1]https://github.com/pruivo/infinispan/commits/t_atomic_map_issue -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7682) DistributionManager's cache topology updated in wrong order

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-7682?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-7682: ------------------------------------ Saw this cause a failure in {{NonTxPutIfAbsentDuringLeaveStressTest}}. > DistributionManager's cache topology updated in wrong order > ----------------------------------------------------------- > > Key: ISPN-7682 > URL: https://issues.jboss.org/browse/ISPN-7682 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.0.0.CR3 > Reporter: Radim Vansa > Assignee: Dan Berindei > Labels: testsuite_stability > Attachments: NonTxPutIfAbsentDuringLeaveStressTest.testNodeLeavingDuringPutIfAbsent_master_5.log.gz > > > {{StateTransferInterceptor}} sets command topology according to {{StateTransferManager.getCacheTopology()}} which goes to {{StateConsumerImpl}}, but {{EntryWrappingInterceptor}} routes according to {{DistributionManager.getCacheTopology()}}. {{StateConsumer}}'s topology is set in {{onTopologyUpdate}} before {{DistributionManager}}'s, and therefore a command can have the current topology set, but EWI does not wrap the entry and some assertions in {{BaseDistributionInterceptor.remoteGet}} fails. > This is a regression brought in ISPN-7400. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7682) DistributionManager's cache topology updated in wrong order

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-7682?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-7682: ------------------------------- Attachment: NonTxPutIfAbsentDuringLeaveStressTest.testNodeLeavingDuringPutIfAbsent_master_5.log.gz > DistributionManager's cache topology updated in wrong order > ----------------------------------------------------------- > > Key: ISPN-7682 > URL: https://issues.jboss.org/browse/ISPN-7682 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.0.0.CR3 > Reporter: Radim Vansa > Assignee: Dan Berindei > Labels: testsuite_stability > Attachments: NonTxPutIfAbsentDuringLeaveStressTest.testNodeLeavingDuringPutIfAbsent_master_5.log.gz > > > {{StateTransferInterceptor}} sets command topology according to {{StateTransferManager.getCacheTopology()}} which goes to {{StateConsumerImpl}}, but {{EntryWrappingInterceptor}} routes according to {{DistributionManager.getCacheTopology()}}. {{StateConsumer}}'s topology is set in {{onTopologyUpdate}} before {{DistributionManager}}'s, and therefore a command can have the current topology set, but EWI does not wrap the entry and some assertions in {{BaseDistributionInterceptor.remoteGet}} fails. > This is a regression brought in ISPN-7400. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7682) DistributionManager's cache topology updated in wrong order

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-7682?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-7682: ------------------------------- Labels: testsuite_stability (was: ) > DistributionManager's cache topology updated in wrong order > ----------------------------------------------------------- > > Key: ISPN-7682 > URL: https://issues.jboss.org/browse/ISPN-7682 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.0.0.CR3 > Reporter: Radim Vansa > Assignee: Dan Berindei > Labels: testsuite_stability > Attachments: NonTxPutIfAbsentDuringLeaveStressTest.testNodeLeavingDuringPutIfAbsent_master_5.log.gz > > > {{StateTransferInterceptor}} sets command topology according to {{StateTransferManager.getCacheTopology()}} which goes to {{StateConsumerImpl}}, but {{EntryWrappingInterceptor}} routes according to {{DistributionManager.getCacheTopology()}}. {{StateConsumer}}'s topology is set in {{onTopologyUpdate}} before {{DistributionManager}}'s, and therefore a command can have the current topology set, but EWI does not wrap the entry and some assertions in {{BaseDistributionInterceptor.remoteGet}} fails. > This is a regression brought in ISPN-7400. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues August 2017