[JBoss JIRA] (ISPN-4038) CustomFailurePolicyTxTest.testPrepareFailure random failures
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-4038?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-4038:
-----------------------------------
Fix Version/s: 7.1.0.Alpha1
(was: 7.0.0.Final)
> CustomFailurePolicyTxTest.testPrepareFailure random failures
> -------------------------------------------------------------
>
> Key: ISPN-4038
> URL: https://issues.jboss.org/browse/ISPN-4038
> Project: Infinispan
> Issue Type: Bug
> Components: Cross-Site Replication, Test Suite - Core
> Affects Versions: 6.0.1.Final
> Reporter: Dan Berindei
> Labels: testsuite_stability
> Fix For: 7.1.0.Alpha1
>
>
> http://ci.infinispan.org/viewLog.html?buildId=5935&tab=buildResultsDiv&bu...
> {noformat}
> java.lang.AssertionError: expected:<0> but was:<1>
> at org.testng.AssertJUnit.fail(AssertJUnit.java:59)
> at org.testng.AssertJUnit.failNotEquals(AssertJUnit.java:364)
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:80)
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:245)
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:252)
> at org.infinispan.xsite.backupfailure.tx.BaseBackupTxFailureTest.testPrepareFailure(BaseBackupTxFailureTest.java:45)
> at org.infinispan.xsite.backupfailure.tx.CustomFailurePolicyTxTest.testPrepareFailure(CustomFailurePolicyTxTest.java:37)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 2 months
[JBoss JIRA] (ISPN-4044) OngoingTransactionsAndJoinTest.testRehashOnJoin always fails
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-4044?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-4044:
-----------------------------------
Fix Version/s: 7.1.0.Alpha1
(was: 7.0.0.Final)
> OngoingTransactionsAndJoinTest.testRehashOnJoin always fails
> ------------------------------------------------------------
>
> Key: ISPN-4044
> URL: https://issues.jboss.org/browse/ISPN-4044
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core
> Affects Versions: 6.0.1.Final
> Reporter: Dan Berindei
> Labels: testsuite_stability
> Fix For: 7.1.0.Alpha1
>
>
> http://ci.infinispan.org/viewLog.html?buildId=6695&tab=buildResultsDiv&bu...
> {noformat}
> org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete() throws java.lang.InterruptedException on object of type StateTransferManagerImpl
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:185)
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
> at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638)
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
> at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:216)
> at org.infinispan.CacheImpl.start(CacheImpl.java:674)
> at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:553)
> at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:516)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:398)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:371)
> at org.infinispan.test.MultipleCacheManagersTest.cache(MultipleCacheManagersTest.java:372)
> at org.infinispan.distribution.rehash.OngoingTransactionsAndJoinTest.testRehashOnJoin(OngoingTransactionsAndJoinTest.java:114)
> Caused by: org.infinispan.commons.CacheException: Initial state transfer timed out for cache ___defaultcache on OngoingTransactionsAndJoinTest-NodeB-8681
> at org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete(StateTransferManagerImpl.java:209)
> at sun.reflect.GeneratedMethodAccessor111.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:183)
> ... 33 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 2 months
[JBoss JIRA] (ISPN-4042) MarshalledValueEvictionTest always fails
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-4042?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-4042:
-----------------------------------
Fix Version/s: 7.1.0.Alpha1
(was: 7.0.0.Final)
> MarshalledValueEvictionTest always fails
> ----------------------------------------
>
> Key: ISPN-4042
> URL: https://issues.jboss.org/browse/ISPN-4042
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core
> Affects Versions: 6.0.1.Final
> Reporter: Dan Berindei
> Labels: testsuite_stability
> Fix For: 7.1.0.Alpha1
>
>
> The test might be invalid, it fails every time, even after fixing some obvious issues (such as enabling storeAsBinary).
> {noformat}
> java.lang.AssertionError
> at org.infinispan.eviction.MarshalledValuesEvictionTest.testEvictCustomKeyValue(MarshalledValuesEvictionTest.java:64)
> java.lang.AssertionError
> at org.infinispan.eviction.MarshalledValuesEvictionTest.testEvictPrimitiveKeyCustomValue(MarshalledValuesEvictionTest.java:86)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 2 months
[JBoss JIRA] (ISPN-4088) Modify signature of Query/CacheQuery.getResultSize() and related offset/pagination methods to return long
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-4088?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-4088:
-----------------------------------
Fix Version/s: 7.1.0.Alpha1
(was: 7.0.0.Final)
> Modify signature of Query/CacheQuery.getResultSize() and related offset/pagination methods to return long
> ---------------------------------------------------------------------------------------------------------
>
> Key: ISPN-4088
> URL: https://issues.jboss.org/browse/ISPN-4088
> Project: Infinispan
> Issue Type: Feature Request
> Components: Embedded Querying, Remote Querying
> Affects Versions: 6.0.0.Final
> Reporter: Adrian Nistor
> Assignee: Adrian Nistor
> Labels: 64QueryBlockers
> Fix For: 7.1.0.Alpha1
>
>
> The method exists in both new DSL and the classic query api.
> It should be clarified whether this method and the related pagination methods should use int or long for specifying offsets within the data, also should decide if the total number of results / results per page is a long or an int - and update all involved method signatures to have a unitary treatment of this issue.
> It appears that recent Lucene versions can offer the number of results as long, while older ones offer it as int (should be verified).
> This issue was raised in a github conversation here: https://github.com/infinispan/infinispan/pull/2410
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 2 months
[JBoss JIRA] (ISPN-4075) State transfer should preserve the creation timestamp of entries
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-4075?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-4075:
-----------------------------------
Fix Version/s: 7.1.0.Alpha1
(was: 7.0.0.Final)
> State transfer should preserve the creation timestamp of entries
> ----------------------------------------------------------------
>
> Key: ISPN-4075
> URL: https://issues.jboss.org/browse/ISPN-4075
> Project: Infinispan
> Issue Type: Feature Request
> Components: Core
> Affects Versions: 6.0.1.Final
> Reporter: Dan Berindei
> Fix For: 7.1.0.Alpha1
>
>
> State transfer inserts values with the current time as the creation time. Since the entries store the expected lifespan and not the expected expiration time, entries on the receiving node could expire much later than intended.
> The argument probably doesn't apply to the timestamp of the last usage. Since state transfer process could be interpreted as a reader, it should be fine to extend the update the time of the last usage both on the sending node and on the receiving node.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 2 months