[JBoss JIRA] (ISPN-3365) org.infinispan.lucene.DatabaseStoredIndexTest.indexWasStored fails with AssertionError
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3365?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3365:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 987927|https://bugzilla.redhat.com/show_bug.cgi?id=987927] from NEW to MODIFIED
> org.infinispan.lucene.DatabaseStoredIndexTest.indexWasStored fails with AssertionError
> --------------------------------------------------------------------------------------
>
> Key: ISPN-3365
> URL: https://issues.jboss.org/browse/ISPN-3365
> Project: Infinispan
> Issue Type: Bug
> Components: Lucene Directory
> Affects Versions: 6.0.0.Alpha1
> Environment: RHEL5_x86_64, IBMJDK1.7
> Reporter: Vitalii Chepeliuk
> Assignee: Sanne Grinovero
> Labels: testsuite_stability
> Attachments: infinispan-lucene-v3.log.zip
>
>
> Stacktrace
> 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)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:88)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:613)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:715)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:907)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1237)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
> at org.testng.TestRunner.privateRun(TestRunner.java:767)
> at org.testng.TestRunner.run(TestRunner.java:617)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
> at org.testng.SuiteRunner.access$000(SuiteRunner.java:37)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368)
> at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:345)
> at java.util.concurrent.FutureTask.run(FutureTask.java:177)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1156)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:626)
> at java.lang.Thread.run(Thread.java:780)
> Standard Output
> Key found in store, shouldn't have persisted this or should have cleaned up all readlocks on directory close:_3.fdt|RL|testing index
> Key found in store, shouldn't have persisted this or should have cleaned up all readlocks on directory close:_3.tis|RL|testing index
> Key found in store, shouldn't have persisted this or should have cleaned up all readlocks on directory close:segments_4|RL|testing index
> Key found in store, shouldn't have persisted this or should have cleaned up all readlocks on directory close:_3.nrm|RL|testing index
> Key found in store, shouldn't have persisted this or should have cleaned up all readlocks on directory close:_3.prx|RL|testing index
> Key found in store, shouldn't have persisted this or should have cleaned up all readlocks on directory close:_3.fdx|RL|testing index
> [testng-DatabaseStoredIndexTest] Test indexWasStored(org.infinispan.lucene.DatabaseStoredIndexTest) failed.
> Add link to jenkins job https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/e...
--
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
10 years, 10 months
[JBoss JIRA] (ISPN-3140) JMX operation to suppress state transfer
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3140?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3140:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 974402|https://bugzilla.redhat.com/show_bug.cgi?id=974402] from ASSIGNED to MODIFIED
> JMX operation to suppress state transfer
> ----------------------------------------
>
> Key: ISPN-3140
> URL: https://issues.jboss.org/browse/ISPN-3140
> Project: Infinispan
> Issue Type: Feature Request
> Components: Distributed Cache, State transfer
> Affects Versions: 5.2.6.Final
> Reporter: Manik Surtani
> Assignee: Dan Berindei
> Fix For: 5.2.7.Final, 5.3.0.CR2, 5.3.0.Final
>
>
> This feature request is to expose a JMX operation on each node, to suppress state transfer for a period of time. This flag would be {{false}} by default.
> The use case of this flag would be to ease bringing down (and up) a cluster for maintenance work. A typical workflow would be:
> 1) Shut down application requests to the data grid
> 2) Suppress state transfer on all nodes via JMX
> 3) Bring down all nodes
> 4) Perform maintenance work
> 5) Bring up nodes, one at a time. As each node comes up, disable state transfer for the node via JMX.
> 6) Once all nodes are up, enable state transfer for each node again via JMX
> 7) Allow application requests to reach the grid again.
> The purpose of this is to allow smooth and fast shutdown and startup, remove the risk of OOM errors (when bringing a grid down).
> This is a small but useful subset of full manual state transfer as defined in ISPN-1394.
--
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
10 years, 10 months
[JBoss JIRA] (ISPN-1822) Cache entry not evicted from memory on IBM JDK when another entry was loaded from a cache loader and maxEntries had been reached
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-1822?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-1822:
-------------------------------
Fix Version/s: 6.0.0.Alpha3
(was: 6.0.0.Alpha2)
> Cache entry not evicted from memory on IBM JDK when another entry was loaded from a cache loader and maxEntries had been reached
> --------------------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-1822
> URL: https://issues.jboss.org/browse/ISPN-1822
> Project: Infinispan
> Issue Type: Bug
> Components: Eviction
> Affects Versions: 5.1.0.FINAL
> Environment: java version "1.6.0"
> Java(TM) SE Runtime Environment (build pxi3260sr9fp1-20110208_03(SR9 FP1))
> IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Linux x86-32 jvmxi3260sr9-20110203_74623 (JIT enabled, AOT enabled) ;
> java version "1.7.0"
> Java(TM) SE Runtime Environment (build pxi3270-20110827_01)
> IBM J9 VM (build 2.6, JRE 1.7.0 Linux x86-32 20110810_88604 (JIT enabled, AOT enabled)
> Reporter: Martin Gencur
> Assignee: Tristan Tarrant
> Fix For: 6.0.0.Alpha3
>
>
> This behavior is specific to IBM JDK (I tried JDK6 and 7), it works fine with Java HotSpot.
> Steps to reproduce the problem:
> 1) set maxEntries for eviction to 2 and algorithm e.g. to LRU
> 2) store 3 entries key1, key2, key3 to the cache (after that you can see that the cache contains only 2 entries - key2 and key3, the first one was evicted from memory)
> 3) call cache.get("key1")
> 4) PROBLEM - cache contains all key1, key2, key3 even though it should contain only 2 entries - only happens with IBM JDK (6 or 7 ..no matter)
> I'll shortly issue a pull request with a test to ispn-core
--
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
10 years, 10 months
[JBoss JIRA] (ISPN-2034) Add backwards serialization compatibility tests
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-2034?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-2034:
-------------------------------
Fix Version/s: 6.0.0.Alpha3
(was: 6.0.0.Alpha2)
> Add backwards serialization compatibility tests
> -----------------------------------------------
>
> Key: ISPN-2034
> URL: https://issues.jboss.org/browse/ISPN-2034
> Project: Infinispan
> Issue Type: Enhancement
> Components: Marshalling
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Labels: compatibility
> Fix For: 6.0.0.Alpha3, 6.0.0.Final
>
>
> Take each existing minor branch, i.e. 4.1.x, 4.0.x,...etc and modify VersionAwareMarshallerTest so that payloads are stored in a data file.
> Then, take data files for each branch and store in git (master and 5.1.x), and try reading them with the existing externalizer/marshalling set up.
> It should work...
--
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
10 years, 10 months
[JBoss JIRA] (ISPN-2702) RecoveryWithCustomCacheDistTest.testNodeCrashesAfterPrepare failing randomly
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-2702?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-2702:
-------------------------------
Fix Version/s: 6.0.0.Alpha3
(was: 6.0.0.Alpha2)
> RecoveryWithCustomCacheDistTest.testNodeCrashesAfterPrepare failing randomly
> ----------------------------------------------------------------------------
>
> Key: ISPN-2702
> URL: https://issues.jboss.org/browse/ISPN-2702
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Reporter: Galder Zamarreño
> Assignee: Pedro Ruivo
> Labels: testsuite_stability
> Fix For: 6.0.0.Alpha3, 6.0.0.Final
>
> Attachments: RecoveryWithCustomCacheDistTest.log.gz, testNodeCrashesAfterPrepare-1.log
>
>
> {code}testNodeCrashesAfterPrepare(org.infinispan.tx.recovery.RecoveryWithCustomCacheDistTest) Time elapsed: 0.083 sec <<< FAILURE!
> java.lang.RuntimeException: javax.transaction.xa.XAException
> at org.infinispan.tx.recovery.RecoveryTestUtil.prepareTransaction(RecoveryTestUtil.java:58)
> at org.infinispan.tx.recovery.RecoveryWithDefaultCacheDistTest.testNodeCrashesAfterPrepare(RecoveryWithDefaultCacheDistTest.java:124)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:715)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:907)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1237)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
> at org.testng.TestRunner.privateRun(TestRunner.java:767)
> at org.testng.TestRunner.run(TestRunner.java:617)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
> at org.testng.SuiteRunner.access$000(SuiteRunner.java:37)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368)
> at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
> 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:680)
> Caused by: javax.transaction.xa.XAException
> at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:161)
> at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:123)
> at org.infinispan.transaction.xa.TransactionXaAdapter.prepare(TransactionXaAdapter.java:110)
> at org.infinispan.tx.recovery.RecoveryTestUtil.prepareTransaction(RecoveryTestUtil.java:56)
> ... 22 more{code}
--
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
10 years, 10 months