[JBoss JIRA] (ISPN-4044) OngoingTransactionsAndJoinTest.testRehashOnJoin always fails
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-4044?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-4044:
--------------------------------
Fix Version/s: 7.0.0.Beta2
(was: 7.0.0.Beta1)
> OngoingTransactionsAndJoinTest.testRehashOnJoin always fails
> ------------------------------------------------------------
>
> Key: ISPN-4044
> URL: https://issues.jboss.org/browse/ISPN-4044
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Test Suite - Core
> Affects Versions: 6.0.1.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Labels: testsuite_stability
> Fix For: 7.0.0.Beta2
>
>
> 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.2.6#6264)
11 years, 8 months
[JBoss JIRA] (ISPN-4042) MarshalledValueEvictionTest always fails
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-4042?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-4042:
--------------------------------
Fix Version/s: 7.0.0.Beta2
(was: 7.0.0.Beta1)
> MarshalledValueEvictionTest always fails
> ----------------------------------------
>
> Key: ISPN-4042
> URL: https://issues.jboss.org/browse/ISPN-4042
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Test Suite - Core
> Affects Versions: 6.0.1.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Labels: testsuite_stability
> Fix For: 7.0.0.Beta2
>
>
> 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.2.6#6264)
11 years, 8 months
[JBoss JIRA] (ISPN-4057) ClusteredCacheConfigurationTest.testQueueFlushIntervalMemcached random failures
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-4057?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-4057:
--------------------------------
Fix Version/s: 7.0.0.Beta2
(was: 7.0.0.Beta1)
> ClusteredCacheConfigurationTest.testQueueFlushIntervalMemcached random failures
> -------------------------------------------------------------------------------
>
> Key: ISPN-4057
> URL: https://issues.jboss.org/browse/ISPN-4057
> Project: Infinispan
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Test Suite - Server
> Affects Versions: 6.0.1.Final
> Reporter: Dan Berindei
> Assignee: Mircea Markus
> Labels: testsuite_stability
> Fix For: 7.0.0.Beta2
>
>
> This code will always fail (lines 109-110):
> {noformat}
> assertNotNull(mc1.get("k2"));
> assertNull(mc1.get("k2"));
> {noformat}
> However, this code path is not hit often, so the failures are quite rare.
> I think the second line should be {{assertNull(mc2.get("k2"));}}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 8 months
[JBoss JIRA] (ISPN-4159) DefaultTwoWayKey2StringMapper encodes objects to strings in a manner that is incompatible with string handling of some databases
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-4159?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-4159:
--------------------------------
Fix Version/s: 7.0.0.Beta2
(was: 7.0.0.Beta1)
> DefaultTwoWayKey2StringMapper encodes objects to strings in a manner that is incompatible with string handling of some databases
> --------------------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-4159
> URL: https://issues.jboss.org/browse/ISPN-4159
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Loaders and Stores
> Affects Versions: 6.0.0.Final
> Reporter: Adrian Nistor
> Assignee: Adrian Nistor
> Fix For: 7.0.0.Beta2, 7.0.0.Final
>
>
> DefaultTwoWayKey2StringMapper uses two neat tricks.
> 1. it does not encode all supported types, it only encodes non-Strings. Strings are kept unmodified.
> 2. it uses a special prefix (unicode char 0xfeff) to mark which strings were encoded and which are plain.
> Unfortunately some databases, notably MySql, interpret the endianness mark (0xfeff, 0xfffe), convert to native byte order and then drop it.
> This leaves us with no clue the string is not an actual String but an encoded representation of another type. This misinterpretation leads later to ClassCastExceptions in various places in core and user code.
> Proposed fix: get rid of #1 and #2 optimisations. Encode all objects, including Strings and always use the ?n prefix (where n stands for the original type). Drop the 0xFEFF marker prefix.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 8 months
[JBoss JIRA] (ISPN-4176) Forcing a commit via recovery RecoveryAdminOperations may create a duplicate GlobalTransaction
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-4176?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-4176:
--------------------------------
Fix Version/s: 7.0.0.Beta2
(was: 7.0.0.Beta1)
> Forcing a commit via recovery RecoveryAdminOperations may create a duplicate GlobalTransaction
> ----------------------------------------------------------------------------------------------
>
> Key: ISPN-4176
> URL: https://issues.jboss.org/browse/ISPN-4176
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Core, Transactions
> Affects Versions: 6.0.2.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 7.0.0.Beta2
>
>
> {{RecoveryManagerImpl.forceTransactionCompletion()}} modifies the {{GlobalTransaction.address}} of the transaction being committed so that the local node is the originator. But the {{GlobalTransaction.id}} stays the same, we could have two transactions with the same {{GlobalTransaction}} - which shouldn't be possible.
> We can't remove the code that changes the {{GlobalTransaction.address}}, because we use it as the originator in other parts of the code. So the only option is to generate a new id as well.
> But there is another problem: RecoveryAwareTransactionTable.cleanupStaleTransactions() doesn't release the locks acquired by that transaction on the primary node. So forcing a commit with a different GlobalTransaction will not be able to acquire the locks that were held by the original transaction.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 8 months
[JBoss JIRA] (ISPN-4167) DummyBaseTransactionManager doesn't clean up when rollback fails
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-4167?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-4167:
--------------------------------
Fix Version/s: 7.0.0.Beta2
(was: 7.0.0.Beta1)
> DummyBaseTransactionManager doesn't clean up when rollback fails
> ----------------------------------------------------------------
>
> Key: ISPN-4167
> URL: https://issues.jboss.org/browse/ISPN-4167
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Core
> Affects Versions: 6.0.2.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 7.0.0.Beta2
>
>
> If the rollback fails, the thread local holding the current transaction is not cleared, and it becomes impossible to start a new transaction on the same thread.
> One way this can happen is when Infinispan registers as a XA transaction, but DummyTransactionManager is not configured to use XA Xids:
> {noformat}
> 12:47:57,169 ERROR (testng-ReplicationExceptionTest:) [DummyTransaction] ISPN000098: Exception while rollback
> java.lang.UnsupportedOperationException
> at org.infinispan.transaction.tm.DummyNoXaXid.getBranchQualifier(DummyNoXaXid.java:30)
> at org.infinispan.transaction.xa.recovery.SerializableXid.<init>(SerializableXid.java:37)
> at org.infinispan.transaction.xa.TransactionXaAdapter.convertXid(TransactionXaAdapter.java:251)
> at org.infinispan.transaction.xa.TransactionXaAdapter.rollback(TransactionXaAdapter.java:122)
> at org.infinispan.transaction.tm.DummyTransaction.runRollback(DummyTransaction.java:281)
> at org.infinispan.transaction.tm.DummyTransaction.rollback(DummyTransaction.java:88)
> at org.infinispan.transaction.tm.DummyBaseTransactionManager.rollback(DummyBaseTransactionManager.java:104)
> at org.infinispan.CacheImpl.tryRollback(CacheImpl.java:1442)
> at org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1418)
> at org.infinispan.CacheImpl.putInternal(CacheImpl.java:894)
> at org.infinispan.CacheImpl.put(CacheImpl.java:886)
> at org.infinispan.CacheImpl.put(CacheImpl.java:1461)
> at org.infinispan.CacheImpl.put(CacheImpl.java:225)
> at org.infinispan.tx.synchronisation.ReplicationExceptionTest.testSyncReplTimeout(ReplicationExceptionTest.java:54)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 8 months