[JBoss JIRA] (ISPN-2771) WriteSkewTest.testWriteSkewWithOnlyPut fails randomly
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-2771?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo commented on ISPN-2771:
-----------------------------------
[~dan.berindei] don't miss understand me. I think the most correct is only to perform the write skew check at prepare time (as it is done in clustered mode).
> WriteSkewTest.testWriteSkewWithOnlyPut fails randomly
> -----------------------------------------------------
>
> Key: ISPN-2771
> URL: https://issues.jboss.org/browse/ISPN-2771
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite, Transactions
> Affects Versions: 5.2.0.CR3
> Reporter: Adrian Nistor
> Assignee: Pedro Ruivo
> Fix For: 6.0.0.Alpha2, 6.0.0.Final
>
> Attachments: WriteSkewTest.zip
>
>
> {noformat}
> org.infinispan.api.mvcc.repeatable_read.WriteSkewTest:testWriteSkewWithOnlyPut
> org.infinispan.transaction.WriteSkewException: Detected write skew.
> java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:222)
> at java.util.concurrent.FutureTask.get(FutureTask.java:83)
> at org.infinispan.api.mvcc.repeatable_read.WriteSkewTest.testWriteSkewWithOnlyPut(WriteSkewTest.java:315)
> 22 lines not shown
> Caused by Detected write skew.
> org.infinispan.container.entries.RepeatableReadEntry.performLocalWriteSkewCheck(RepeatableReadEntry.java:68)
> at org.infinispan.container.entries.RepeatableReadEntry.copyForUpdate(RepeatableReadEntry.java:52)
> at org.infinispan.container.EntryFactoryImpl.wrapEntryForPut(EntryFactoryImpl.java:170)
> at org.infinispan.interceptors.EntryWrappingInterceptor.visitPutKeyValueCommand(EntryWrappingInterceptor.java:164)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.locking.OptimisticLockingInterceptor.visitPutKeyValueCommand(OptimisticLockingInterceptor.java:142)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:132)
> at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:62)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:251)
> at org.infinispan.interceptors.TxInterceptor.visitPutKeyValueCommand(TxInterceptor.java:191)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:128)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:92)
> at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:62)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:343)
> at org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1162)
> at org.infinispan.CacheImpl.putInternal(CacheImpl.java:760)
> at org.infinispan.CacheImpl.put(CacheImpl.java:754)
> at org.infinispan.CacheImpl.put(CacheImpl.java:748)
> at org.infinispan.CacheSupport.put(CacheSupport.java:53)
> at org.infinispan.api.mvcc.repeatable_read.WriteSkewTest$EntryWriter.call(WriteSkewTest.java:433)
> at org.infinispan.api.mvcc.repeatable_read.WriteSkewTest$EntryWriter.call(WriteSkewTest.java:418)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> 1 lines not shown
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (ISPN-2771) WriteSkewTest.testWriteSkewWithOnlyPut fails randomly
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-2771?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-2771:
------------------------------------
[~pruivo] why is the second approach more correct than the first? Shouldn't one write skew check be enough?
> WriteSkewTest.testWriteSkewWithOnlyPut fails randomly
> -----------------------------------------------------
>
> Key: ISPN-2771
> URL: https://issues.jboss.org/browse/ISPN-2771
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite, Transactions
> Affects Versions: 5.2.0.CR3
> Reporter: Adrian Nistor
> Assignee: Pedro Ruivo
> Fix For: 6.0.0.Alpha2, 6.0.0.Final
>
> Attachments: WriteSkewTest.zip
>
>
> {noformat}
> org.infinispan.api.mvcc.repeatable_read.WriteSkewTest:testWriteSkewWithOnlyPut
> org.infinispan.transaction.WriteSkewException: Detected write skew.
> java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:222)
> at java.util.concurrent.FutureTask.get(FutureTask.java:83)
> at org.infinispan.api.mvcc.repeatable_read.WriteSkewTest.testWriteSkewWithOnlyPut(WriteSkewTest.java:315)
> 22 lines not shown
> Caused by Detected write skew.
> org.infinispan.container.entries.RepeatableReadEntry.performLocalWriteSkewCheck(RepeatableReadEntry.java:68)
> at org.infinispan.container.entries.RepeatableReadEntry.copyForUpdate(RepeatableReadEntry.java:52)
> at org.infinispan.container.EntryFactoryImpl.wrapEntryForPut(EntryFactoryImpl.java:170)
> at org.infinispan.interceptors.EntryWrappingInterceptor.visitPutKeyValueCommand(EntryWrappingInterceptor.java:164)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.locking.OptimisticLockingInterceptor.visitPutKeyValueCommand(OptimisticLockingInterceptor.java:142)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:132)
> at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:62)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:251)
> at org.infinispan.interceptors.TxInterceptor.visitPutKeyValueCommand(TxInterceptor.java:191)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:128)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:92)
> at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:62)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:343)
> at org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1162)
> at org.infinispan.CacheImpl.putInternal(CacheImpl.java:760)
> at org.infinispan.CacheImpl.put(CacheImpl.java:754)
> at org.infinispan.CacheImpl.put(CacheImpl.java:748)
> at org.infinispan.CacheSupport.put(CacheSupport.java:53)
> at org.infinispan.api.mvcc.repeatable_read.WriteSkewTest$EntryWriter.call(WriteSkewTest.java:433)
> at org.infinispan.api.mvcc.repeatable_read.WriteSkewTest$EntryWriter.call(WriteSkewTest.java:418)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> 1 lines not shown
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (ISPN-3329) DatabaseStoredIndexTest.indexWasStored random failures
by Dan Berindei (JIRA)
Dan Berindei created ISPN-3329:
----------------------------------
Summary: DatabaseStoredIndexTest.indexWasStored random failures
Key: ISPN-3329
URL: https://issues.jboss.org/browse/ISPN-3329
Project: Infinispan
Issue Type: Bug
Components: Querying
Affects Versions: 6.0.0.Alpha1
Reporter: Dan Berindei
Assignee: Sanne Grinovero
Fix For: 6.0.0.Final
The test fails quite often with an assertion error like this:
{noformat}
java.lang.AssertionError:
at org.testng.AssertJUnit.fail(AssertJUnit.java:59)
at org.testng.AssertJUnit.assertTrue(AssertJUnit.java:24)
at org.testng.AssertJUnit.assertFalse(AssertJUnit.java:41)
at org.testng.AssertJUnit.assertFalse(AssertJUnit.java:49)
at org.infinispan.lucene.DatabaseStoredIndexTest.indexWasStored(DatabaseStoredIndexTest.java:111)
------- Stdout: -------
Failure on key[_0.nrm|0|16384|testing index] expected value:
ByteArray{size=6, array=0x4e524dff7c79..} actual value:
null
{noformat}
See http://ci.infinispan.org/project.html?projectId=Infinispan&tab=testDetail...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (ISPN-3197) Message ordering of Get and Invalidation can cause L1 to be inconsistent
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3197?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-3197:
-------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Message ordering of Get and Invalidation can cause L1 to be inconsistent
> ------------------------------------------------------------------------
>
> Key: ISPN-3197
> URL: https://issues.jboss.org/browse/ISPN-3197
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.2.6.Final
> Reporter: William Burns
> Assignee: William Burns
> Fix For: 6.0.0.Alpha2, 6.0.0.Final
>
>
> This is based off of discussion here: https://issues.jboss.org/browse/ISPN-2990?focusedCommentId=12779491&page=...
> This can occur with a synchronous cache.
> 1. A reads k1. This is an OOB call.
> 2. B processes the read message and sends back the response
> 3. C updates k1, at this stage B sends the invalidation message to A (OOB call)
> 4. A processes(ignores) the invalidation message
> 5. A puts the stale value sent at 2 in L1
> The OOB portions don't actually matter that they are OOB as even if B's messages were ordered it sill could process the get and update in a different order since they originate from different nodes.
> The initial thought is to solve this with some type of tombstone to sygnal the removal of the L1 cache, but this also still doesn't catch the problem if A did not have key k1 in it's L1 cache to receive an invalidation message.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (ISPN-3325) ConsistentHashV1IntegrationTest.testCorrectBalancingOfKeysAfterNodeKill random failures
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3325?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-3325:
-------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/1974
> ConsistentHashV1IntegrationTest.testCorrectBalancingOfKeysAfterNodeKill random failures
> ---------------------------------------------------------------------------------------
>
> Key: ISPN-3325
> URL: https://issues.jboss.org/browse/ISPN-3325
> Project: Infinispan
> Issue Type: Feature Request
> Components: Test Suite
> Affects Versions: 5.3.0.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Labels: testsuite_stability
> Fix For: 6.0.0.Alpha2, 6.0.0.Final
>
>
> The test adds a 5th server, but {{ConsistentHashV1IntegrationTest.getHitServer()}} assumes that the requests hit one of the original 4 servers. Because the server CH to client CH is imperfect in protocol versions 1.1 and 1.2, some of the requests may instead hit server 5, causing a {{NullPointerException}}:
> {noformat}
> java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
> at java.util.ArrayList.RangeCheck(ArrayList.java:547)
> at java.util.ArrayList.get(ArrayList.java:322)
> at org.infinispan.client.hotrod.ConsistentHashV1IntegrationTest.getHitServer(ConsistentHashV1IntegrationTest.java:204)
> at org.infinispan.client.hotrod.ConsistentHashV1IntegrationTest.runTest(ConsistentHashV1IntegrationTest.java:129)
> at org.infinispan.client.hotrod.ConsistentHashV1IntegrationTest.testCorrectBalancingOfKeysAfterNodeKill(ConsistentHashV1IntegrationTest.java:160)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (ISPN-3035) Members can re-appear by itself in the consistent hash after leaving
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3035?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-3035:
------------------------------------
[~mircea.markus] We don't roll back state transfers any more, but still we shouldn't lose any state.
However, I saw this again in ParticipantFailureAfterPrepareTest, and there the cluster never recovered: the remaining nodes couldn't communicate with C, but FD/FD_SOCK didn't suspect it either. I have raised an issue in Jgroups for this: JGRP-1658.
> Members can re-appear by itself in the consistent hash after leaving
> --------------------------------------------------------------------
>
> Key: ISPN-3035
> URL: https://issues.jboss.org/browse/ISPN-3035
> Project: Infinispan
> Issue Type: Bug
> Components: State transfer
> Affects Versions: 5.2.5.Final, 5.3.0.Alpha1
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 6.0.0.Final
>
> Attachments: dret.log, dret2.log
>
>
> Seen as an intermittent failure in DataRehashedEventTest:
> {noformat}
> 2013-04-23 14:07:45,459 DEBUG (testng-DataRehashedEventTest) [org.infinispan.manager.DefaultCacheManager] Stopping cache manager ISPN on NodeC-58711
> 2013-04-23 14:07:45,468 INFO (testng-DataRehashedEventTest) [org.infinispan.remoting.transport.jgroups.JGroupsTransport] ISPN000080: Disconnecting and closing JGroups Channel
> 2013-04-23 14:07:46,469 DEBUG (testng-DataRehashedEventTest) [org.jgroups.protocols.pbcast.GMS] NodeC-58711: sending LEAVE request to NodeA-28008
> 2013-04-23 14:07:46,489 DEBUG (Incoming-2,ISPN,NodeA-28008) [org.jgroups.protocols.pbcast.GMS] NodeA-28008: installing [NodeA-28008|4] [NodeA-28008, NodeB-46156, NodeC-58711]
> 2013-04-23 14:07:46,491 DEBUG (asyncTransportThread-0,NodeA) [org.infinispan.topology.ClusterTopologyManagerImpl] Starting cluster-wide rebalance for cache ___defaultcache, topology = CacheTopology{id=8, currentCH=DefaultConsistentHash{numSegments=60, numOwners=2, members=[NodeA-28008, NodeB-46156]}, pendingCH=DefaultConsistentHash{numSegments=60, numOwners=2, members=[NodeA-28008, NodeB-46156, NodeC-58711]}}
> 2013-04-23 14:07:49,493 ERROR (testng-DataRehashedEventTest) [org.infinispan.test.fwk.UnitTestTestNGListener] Test testJoinAndLeave(org.infinispan.statetransfer.DataRehashedEventTest) failed.
> java.lang.AssertionError: expected [2] but found [6]
> at org.testng.Assert.fail(Assert.java:94)
> at org.testng.Assert.failNotEquals(Assert.java:494)
> at org.testng.Assert.assertEquals(Assert.java:123)
> at org.testng.Assert.assertEquals(Assert.java:370)
> at org.testng.Assert.assertEquals(Assert.java:380)
> at org.infinispan.statetransfer.DataRehashedEventTest.testJoinAndLeave(DataRehashedEventTest.java:114)
> {noformat}
> The initial cluster has 3 nodes: A, B, C. C is killed, but somehow remains in the ClusterCacheStatus on the coordinator.
> Then C re-appears in the JGroups view (possibly a JGroups issue). The problem in Infinispan is that the coordinator now sees C as a joiner, and it rebalances the cache to include C in the consistent hash again.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (ISPN-2903) Manual eviction should not delete entry from cache store
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-2903?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-2903:
-----------------------------------------------
Paul Gier <pgier(a)redhat.com> changed the Status of [bug 900549|https://bugzilla.redhat.com/show_bug.cgi?id=900549] from MODIFIED to ON_QA
> Manual eviction should not delete entry from cache store
> --------------------------------------------------------
>
> Key: ISPN-2903
> URL: https://issues.jboss.org/browse/ISPN-2903
> Project: Infinispan
> Issue Type: Bug
> Components: Eviction
> Affects Versions: 5.2.3.Final
> Reporter: Paul Ferraro
> Assignee: Galder Zamarreño
> Priority: Critical
> Labels: 5.2.x, jdg6
> Fix For: 5.2.5.Final, 5.3.0.Alpha1, 5.3.0.Final
>
> Attachments: AtomicMapServlet.java, AtomicMapTestCase.java, server.log, server.log
>
>
> Here's the scenario:
> Given 2 nodes with REPL_SYNC cache with passivating cache store (e.g. default web cache in AS7).
> 1. Create cache entry containing atomic map with 2 map entries on node1.
> 2. Passivate that cache entry on node2 via manual evict.
> 3. Modify 1 of the atomic map entries within the cache entry on node1.
> 4. Lookup atomic map on node2. It only contains 1 map entry - the map entry modified in step 3. The other map entry is lost.
> It's a side effect of ISPN-2384, where some changes were made to tighten the passivation/activation scenarios, but it did not cover manual eviction calls.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (ISPN-3328) Provide cache view history
by Richard Achmatowicz (JIRA)
Richard Achmatowicz created ISPN-3328:
-----------------------------------------
Summary: Provide cache view history
Key: ISPN-3328
URL: https://issues.jboss.org/browse/ISPN-3328
Project: Infinispan
Issue Type: Feature Request
Components: Core API
Affects Versions: 5.3.0.Final
Reporter: Richard Achmatowicz
Assignee: Mircea Markus
Priority: Minor
In a clustered context, having information on the sequence of views which an application participated in and the membership of those views can be useful for post-mortem debugging as well as monitoring.
At present, JGroups provides such information (e.g. see GMS.printPreviousViews) for group membership at the channel level in the form of a bounded sequence of previous views, as well as a bounded sequence of previous members. This makes it easy to confirm that expected sequences of membership changes have actually occurred.
Having a similar history for Infinispan caches would provide the same benefit at the cache level.
Motivation: I would like to expose such information as part of the cluster subsystem if possible (see WFLY-1430).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months