[JBoss JIRA] (ISPN-2623) SimpleEvictionMaxEntries fails consistently on IBM JDK with "cache size too big: 182"
by Jitka Kudrnacova (JIRA)
Jitka Kudrnacova created ISPN-2623:
--------------------------------------
Summary: SimpleEvictionMaxEntries fails consistently on IBM JDK with "cache size too big: 182"
Key: ISPN-2623
URL: https://issues.jboss.org/browse/ISPN-2623
Project: Infinispan
Issue Type: Bug
Components: Eviction, Test Suite
Affects Versions: 5.1.8.Final
Environment: IBM JDK6, IBM JDK7, any platfrom
Reporter: Jitka Kudrnacova
Assignee: Mircea Markus
Test SimpleEvictionMaxEntries fails consistently across platforms with the following (output from RHEL6_x86_64):
{code}
2012-12-05 10:53:13,616 ERROR [UnitTestTestNGListener] (testng-LRUEvictionFunctionalTest) Method testSimpleEvictionMaxEntries(org.infinispan.eviction.LRUEvictionFunctionalTest) threw an exception
java.lang.AssertionError: cache size too big: 182
at org.infinispan.eviction.BaseEvictionFunctionalTest.testSimpleEvictionMaxEntries(BaseEvictionFunctionalTest.java:67)
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:74)
at org.testng.internal.Invoker.invokeMethod(Invoker.java:673)
at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:846)
at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1170)
at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109)
at org.testng.TestRunner.runWorkers(TestRunner.java:1147)
at org.testng.TestRunner.privateRun(TestRunner.java:749)
at org.testng.TestRunner.run(TestRunner.java:600)
at org.testng.SuiteRunner.runTest(SuiteRunner.java:317)
at org.testng.SuiteRunner.access$000(SuiteRunner.java:34)
at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:351)
at org.testng.internal.thread.ThreadUtil$CountDownLatchedRunnable.run(ThreadUtil.java:147)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1121)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:614)
at java.lang.Thread.run(Thread.java:780)
[testng-LRUEvictionFunctionalTest] Test testSimpleEvictionMaxEntries(org.infinispan.eviction.LRUEvictionFunctionalTest) failed.
{code}
Seen during TS runs for test cycle EAP 6.0.1.ER4.2.
--
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, 1 month
[JBoss JIRA] (ISPN-2081) Transaction leak caused by reordering between prepare and rollback
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-2081?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-2081:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 841889|https://bugzilla.redhat.com/show_bug.cgi?id=841889] from NEW to ASSIGNED
> Transaction leak caused by reordering between prepare and rollback
> ------------------------------------------------------------------
>
> Key: ISPN-2081
> URL: https://issues.jboss.org/browse/ISPN-2081
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 5.1.5.FINAL
> Reporter: Mircea Markus
> Assignee: Mircea Markus
> Priority: Blocker
> Labels: jdg, jdg6
> Fix For: 5.2.0.Beta3, 5.2.0.Final
>
> Attachments: DistL1WriteSkewTest.txt, RollbackNotSentBeforePrepareTest.java
>
>
> There's no ordering between the prepare and commit/rollback messages, as the later are sent OOB.
> With this in mind, the following transaction leak might happen:
> Tx1 send prepare on nodes {A,B}
> 1. the message reaches A and timeouts but hasn't yet been processed on B
> 2. The transaction originator reacts immediately to the timeout received from A without waiting the response from B and sends a rollback request
> 3. The rollback request is processed on A and B
> 4. The initial prepare is then processed on B
> At this point we have an orphan transaction prepare on B.
> Whilst this is not causing any inconsistencies, it keeps keys locked indefinitely and is a memory leak.
> The solution would be to wait at 2 for all the prepare messages *before* sending the rollback.
> Attached is a unit test to reproduce the issue.
> Related mailing list thread: http://infinispan.markmail.org/search/#query:%20list%3Aorg.jboss.lists.in...
--
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, 1 month
[JBoss JIRA] (ISPN-1965) Some entries not available during view change
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-1965?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-1965:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 808623|https://bugzilla.redhat.com/show_bug.cgi?id=808623] from NEW to ASSIGNED
> Some entries not available during view change
> ---------------------------------------------
>
> Key: ISPN-1965
> URL: https://issues.jboss.org/browse/ISPN-1965
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.1.3.FINAL
> Reporter: Michal Linhard
> Assignee: Dan Berindei
>
> In the 4 node, dist mode, num-owners=2, elasticity test
> http://www.qa.jboss.com/~mlinhard/hyperion/run44-elas-dist/
> there is a cca 90 sec period of time where clients get null responses to GET
> requests on entries that should exist in the cache.
> first occurence:
> hyperion1139.log 05:31:01,202 286.409
> last occurence:
> hyperion1135.log 05:32:45,441 390.648
> total occurence count: (in all 19 driver nodes)
> 152241
> (this doesn't mean it happens for 152K keys, because each key is retried after
> erroneous attempt)
> data doesn't seem to be lost, because these errors cease after a while and
> number of entries returns back to normal (see cache_entries.csv)
> this happens approximately in the period between node0001 is killed and cluster
> {node0002 - node0004} is formed (and shortly after).
--
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, 1 month
[JBoss JIRA] (ISPN-2187) Pre-Invocation flag PUT_FOR_EXTERNAL_READ throws exception
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-2187?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-2187:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 847062|https://bugzilla.redhat.com/show_bug.cgi?id=847062] from NEW to ASSIGNED
> Pre-Invocation flag PUT_FOR_EXTERNAL_READ throws exception
> ----------------------------------------------------------
>
> Key: ISPN-2187
> URL: https://issues.jboss.org/browse/ISPN-2187
> Project: Infinispan
> Issue Type: Bug
> Components: Core API
> Reporter: Anna Manukyan
> Assignee: Galder Zamarreño
> Labels: jdg6
> Fix For: 5.2.0.Alpha3, 5.2.0.Final
>
>
> Hi,
> While writing tests for Infinispan Flag.PUT_FOR_EXTERNAL_READ the following issue has been found.
> In documentation it is said:
> PUT_FOR_EXTERNAL_READ
> Flags the invocation as a Cache.putForExternalRead(Object, Object) call, as opposed to a regular Map.put(Object, Object).
> And the documentation for Cache.putForExternalRead(Object, Object) says:
> void putForExternalRead(K key,
> V value)
> ...................
> Errors and exceptions are 'silent' - logged at a much lower level than normal, and this method does not throw exceptions
> The issue is the following:
> when trying to perform operation using PUT_FOR_EXTERNAL_READ flag, the exception is thrown, it is not 'silent'.
> cache1.getAdvancedCache().withFlags(Flag.PUT_FOR_EXTERNAL_READ).put(key, value);
> The test is the following:
> {code}
> public void testExceptionSuppression() throws Exception {
> Cache cache1 = cache(0, "replSync");
> Cache cache2 = cache(1, "replSync");
> Transport mockTransport = mock(Transport.class);
> RpcManagerImpl rpcManager = (RpcManagerImpl) TestingUtil.extractComponent(cache1, RpcManager.class);
> Transport originalTransport = TestingUtil.extractComponent(cache1, Transport.class);
> try {
> Address mockAddress1 = mock(Address.class);
> Address mockAddress2 = mock(Address.class);
> List<Address> memberList = new ArrayList<Address>(2);
> memberList.add(mockAddress1);
> memberList.add(mockAddress2);
> rpcManager.setTransport(mockTransport);
> when(mockTransport.getMembers()).thenReturn(memberList);
> when(mockTransport.getViewId()).thenReturn(originalTransport.getViewId());
> when(mockTransport.invokeRemotely(anyAddresses(), (CacheRpcCommand) anyObject(), anyResponseMode(),
> anyLong(), anyBoolean(), (ResponseFilter) anyObject()))
> .thenThrow(new RuntimeException("Barf!"));
> try {
> cache1.put(key, value);
> fail("Should have barfed");
> }
> catch (RuntimeException re) {
> }
> // clean up any indeterminate state left over
> try {
> cache1.remove(key);
> fail("Should have barfed");
> }
> catch (RuntimeException re) {
> }
> assertNull("Should have cleaned up", cache1.get(key));
> // should not barf
> cache1.putForExternalRead(key, value);
> /** ------------------- Testing the same feature with Flag.PUT_FOR_EXTERNAL_READ **/
> try {
> cache1.remove(key);
> fail("Should have barfed");
> }
> catch (RuntimeException re) {
> }
> cache1.getAdvancedCache().withFlags(Flag.PUT_FOR_EXTERNAL_READ).put(key, value);
> }
> finally {
> if (rpcManager != null) rpcManager.setTransport(originalTransport);
> }
> }
> {code}
> Best regards,
> Anna.
--
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, 1 month
[JBoss JIRA] (ISPN-2198) Cluster with non-shared JDBC cache store has too much entries after node failure
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-2198?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-2198:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 847809|https://bugzilla.redhat.com/show_bug.cgi?id=847809] from NEW to ASSIGNED
> Cluster with non-shared JDBC cache store has too much entries after node failure
> --------------------------------------------------------------------------------
>
> Key: ISPN-2198
> URL: https://issues.jboss.org/browse/ISPN-2198
> Project: Infinispan
> Issue Type: Feature Request
> Affects Versions: 5.1.5.FINAL
> Reporter: Radim Vansa
> Assignee: Mircea Markus
> Fix For: 6.0.0.Final
>
> Attachments: cache_entries.csv, logs.zip, sfout.txt
>
>
> In resilience test with 4-node cluster where one node is killed a weird situation appears. Before the node kill have this number of entries:
> 210602;215820;209400;203038 = 838860 entries
> After the kill the number of entries changes for a while:
> 210602;null;209400;203038
> 250602;null;269400;243038
> 290602;null;269400;273038
> 300602;null;289400;293038
> 300602;null;289400;293038
> 321218;null;296035;293038
> But then it stabilizes on
> 326899;null;305039;314165 = 946103 entries
> When the node02 is restarted it complains about duplicit entries:
> ERROR [org.infinispan.loaders.jdbc.stringbased.JdbcStringBasedCacheStore] (OOB-124,null) ISPN008024: Error while storing string key to database; key: '8Az4Ia2V5NzYzNDI=', buffer size of value: 1050 bytes: com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationException: Duplicate entry '?8Az4Ia2V5NzYzNDI=' for key 'PRIMARY'
> Is this a bug or wrong configuration?
> Here is an excerpt from configuration (sorry for no formatting):
> <distributed-cache batching="false" indexing="NONE" l1-lifespan="0" mode="SYNC" name="memcachedCache" owners="2" remote-timeout="60000" start="EAGER" virtual-nodes="512">
> <locking acquire-timeout="3000" concurrency-level="1000" isolation="REPEATABLE_READ" striping="false"/>
> <transaction mode="NONE"/>
> <state-transfer enabled="true" timeout="600000"/>
> <eviction max-entries="-1" strategy="NONE"/>
> <string-keyed-jdbc-store datasource="java:jboss/datasources/JdbcDS" passivation="false" preload="false" purge="true" shared="false">
> <property name="databaseType">MYSQL</property>
> <string-keyed-table prefix="node01">
> <id-column name="id" type="VARCHAR(100)"/>
> <data-column name="value" type="BLOB(1200)"/>
> </string-keyed-table>
> </string-keyed-jdbc-store>
> </distributed-cache>
--
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, 1 month
[JBoss JIRA] (ISPN-2137) Potential tx lock leaks when nodes are added to the cluster
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-2137?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-2137:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 841891|https://bugzilla.redhat.com/show_bug.cgi?id=841891] from NEW to ASSIGNED
> Potential tx lock leaks when nodes are added to the cluster
> -----------------------------------------------------------
>
> Key: ISPN-2137
> URL: https://issues.jboss.org/browse/ISPN-2137
> Project: Infinispan
> Issue Type: Bug
> Components: State transfer, Transactions
> Affects Versions: 5.1.5.FINAL
> Reporter: Mircea Markus
> Assignee: Mircea Markus
> Priority: Critical
> Labels: jdg6
> Fix For: 5.2.0.Beta2, 5.2.0.Final
>
>
> Here's the sequence that might cause the leak:
> - a tx locking K is prepared and committed on node A
> - node B joins and becomes the primary owner of K
> - tx and the lock on key is moved from A to B as part of the state transfer
> - tx completion notification for tx is sent (async+oob) to A and not to B(old view)
> - there's no way for A to reply to the the originator telling it to re-send the tx completion notification to B as the call is async+oob
> - this would cause the lock transaction to leak on B
> Suggested solution:
> After a chat with Dan, following fixed seemed to be the most appropriate:
> when receiving a tx completion notification for a tx that's being migrated over as result of state transfer forward it to the new lock owner. With current blocking ST, this fwd call waits only after the tx state is transferred to the new owner. This would need some more thought for the new NBST code.
> Note: there's no issue in the case of nodes leaving the cluster, as the current logic of backup nodes would assure a proper cleanup.
--
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, 1 month
[JBoss JIRA] (ISPN-2550) NoSuchElementException in Hot Rod Encoder
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-2550?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-2550:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 875151|https://bugzilla.redhat.com/show_bug.cgi?id=875151] from NEW to ASSIGNED
> NoSuchElementException in Hot Rod Encoder
> -----------------------------------------
>
> Key: ISPN-2550
> URL: https://issues.jboss.org/browse/ISPN-2550
> Project: Infinispan
> Issue Type: Bug
> Components: Remote protocols
> Affects Versions: 5.2.0.Beta4
> Reporter: Michal Linhard
> Assignee: Galder Zamarreño
> Priority: Blocker
> Fix For: 5.2.0.Beta6
>
>
> Tomas noticed this a while ago in a specific functional test:
> https://bugzilla.redhat.com/show_bug.cgi?id=875151
> I'm creating a more general JIRA, cause I'm having this in resilience test.
> What I found by quick debug, is that here:
> https://github.com/infinispan/infinispan/blob/master/server/hotrod/src/ma...
> {code}
> for (segmentIdx <- 0 until numSegments) {
> val denormalizedSegmentHashIds = allDenormalizedHashIds(segmentIdx)
> val segmentOwners = ch.locateOwnersForSegment(segmentIdx)
> for (ownerIdx <- 0 until segmentOwners.length) {
> val address = segmentOwners(ownerIdx % segmentOwners.size)
> val serverAddress = members(address)
> val hashId = denormalizedSegmentHashIds(ownerIdx)
> log.tracef("Writing hash id %d for %s:%s", hashId, serverAddress.host, serverAddress.port)
> writeString(serverAddress.host, buf)
> writeUnsignedShort(serverAddress.port, buf)
> buf.writeInt(hashId)
> }
> }
> {code}
> we're trying to obtain serverAddress for nonexistent address and NoSuchElementException is not handled properly.
> It hapens after I kill a node in a resilience test and the exception appears when querying for the node in the members cache.
--
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, 1 month
[JBoss JIRA] (ISPN-2614) org.infinispan.marshall.MarshallExternalPojosTest.testReplicateJBossExternalizePojoToNewJoiningNode fails randomly
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-2614?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-2614:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 885623|https://bugzilla.redhat.com/show_bug.cgi?id=885623] from NEW to ASSIGNED
> org.infinispan.marshall.MarshallExternalPojosTest.testReplicateJBossExternalizePojoToNewJoiningNode fails randomly
> ------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-2614
> URL: https://issues.jboss.org/browse/ISPN-2614
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.2.0.Beta5
> Reporter: Anna Manukyan
> Assignee: Mircea Markus
> Labels: testsuite_stability
>
> The test org.infinispan.marshall.MarshallExternalPojosTest.testReplicateJBossExternalizePojoToNewJoiningNode fails randomly on all environments - Windows, Solaris, RHEL - jdk7 & openjdk7
> The failure is:
> {code}
> Error Message
> Replication timeout for MarshallExternalPojosTest-NodeD-24038
> Stacktrace
> org.infinispan.util.concurrent.TimeoutException: Replication timeout for MarshallExternalPojosTest-NodeD-24038
> at org.infinispan.remoting.transport.AbstractTransport.parseResponseAndAddToResponseList(AbstractTransport.java:110)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:541)
> at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:180)
> at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:202)
> at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:259)
> at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:246)
> at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:241)
> at org.infinispan.remoting.rpc.RpcManagerImpl.broadcastRpcCommand(RpcManagerImpl.java:220)
> at org.infinispan.remoting.rpc.RpcManagerImpl.broadcastRpcCommand(RpcManagerImpl.java:212)
> at org.infinispan.interceptors.ReplicationInterceptor.handleCrudMethod(ReplicationInterceptor.java:280)
> at org.infinispan.interceptors.ReplicationInterceptor.visitPutKeyValueCommand(ReplicationInterceptor.java:244)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.EntryWrappingInterceptor.invokeNextAndApplyChanges(EntryWrappingInterceptor.java:211)
> at org.infinispan.interceptors.EntryWrappingInterceptor.visitPutKeyValueCommand(EntryWrappingInterceptor.java:149)
> 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.NonTransactionalLockingInterceptor.visitPutKeyValueCommand(NonTransactionalLockingInterceptor.java:70)
> 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.statetransfer.StateTransferInterceptor.handleTopologyAffectedCommand(StateTransferInterceptor.java:214)
> at org.infinispan.statetransfer.StateTransferInterceptor.handleWriteCommand(StateTransferInterceptor.java:192)
> at org.infinispan.statetransfer.StateTransferInterceptor.visitPutKeyValueCommand(StateTransferInterceptor.java:135)
> 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:1016)
> at org.infinispan.CacheImpl.put(CacheImpl.java:712)
> at org.infinispan.CacheImpl.put(CacheImpl.java:704)
> at org.infinispan.CacheSupport.put(CacheSupport.java:53)
> at org.infinispan.marshall.MarshallExternalPojosTest.doReplicatePojoToNewJoiningNode(MarshallExternalPojosTest.java:91)
> at org.infinispan.marshall.MarshallExternalPojosTest.testReplicateMarshallableByPojoToNewJoiningNode(MarshallExternalPojosTest.java:76)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> 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:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> {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
12 years, 1 month
[JBoss JIRA] (ISPN-2618) org.infinispan.distribution.rehash.L1OnRehashDisabledTest.testInvalidationBehaviorOnRehash randomly fails
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-2618?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-2618:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 885995|https://bugzilla.redhat.com/show_bug.cgi?id=885995] from NEW to ASSIGNED
> org.infinispan.distribution.rehash.L1OnRehashDisabledTest.testInvalidationBehaviorOnRehash randomly fails
> ----------------------------------------------------------------------------------------------------------
>
> Key: ISPN-2618
> URL: https://issues.jboss.org/browse/ISPN-2618
> Project: Infinispan
> Issue Type: Feature Request
> Affects Versions: 5.2.0.Beta5
> Reporter: Anna Manukyan
> Assignee: Dan Berindei
> Labels: testsuite_stability
>
> The test is randomly failing on different environments.
> The error is:
> {code}
> Error Message
> Fail on non-owner cache L1OnRehashDisabledTest-NodeA-8972: dc.get(MagicKey#k2{18b213c7@L1OnRehashDisabledTest-NodeC-18200}) returned MortalCacheEntry{key=MagicKey#k2{18b213c7@L1OnRehashDisabledTest-NodeC-18200}, value=MortalCacheValue{value=v2, lifespan=600000, created=1355149157148}}!
> Stacktrace
> java.lang.AssertionError: Fail on non-owner cache L1OnRehashDisabledTest-NodeA-8972: dc.get(MagicKey#k2{18b213c7@L1OnRehashDisabledTest-NodeC-18200}) returned MortalCacheEntry{key=MagicKey#k2{18b213c7@L1OnRehashDisabledTest-NodeC-18200}, value=MortalCacheValue{value=v2, lifespan=600000, created=1355149157148}}!
> at org.infinispan.distribution.BaseDistFunctionalTest.assertOwnershipAndNonOwnership(BaseDistFunctionalTest.java:212)
> at org.infinispan.distribution.rehash.L1OnRehashTest.testInvalidationBehaviorOnRehash(L1OnRehashTest.java:117)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> 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:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> {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
12 years, 1 month