[JBoss JIRA] (ISPN-6011) ClassCastException in CDI generated keys for JCache
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-6011?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-6011:
--------------------------------
Fix Version/s: 9.0.0.Beta1
(was: 9.0.0.Alpha4)
> ClassCastException in CDI generated keys for JCache
> ---------------------------------------------------
>
> Key: ISPN-6011
> URL: https://issues.jboss.org/browse/ISPN-6011
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 8.1.0.CR1, 8.0.2.Final
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 9.0.0.Beta1
>
>
> When using JCache-annotations the DefaultCacheKeyGenerator exclusively looks at parameter values to form the cache key. Therefore it will be very likely that collissions occur (resulting in difficult to find ClassCastExceptions). The provided patch uses the method- and class names as additionally values to make the cache key more unique.
> Might also add that I am aware that by spec this should not be an issue when no cachename is given (as it should generate a cache using the class-name), but when a cache name is given collissions may occur.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 11 months
[JBoss JIRA] (ISPN-6039) NonTxBackupOwnerBecomingPrimaryOwnerTest.testPrimaryOwnerChangingDuringPutOverwrite random failures
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-6039?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-6039:
--------------------------------
Fix Version/s: 9.0.0.Beta1
(was: 9.0.0.Alpha4)
> NonTxBackupOwnerBecomingPrimaryOwnerTest.testPrimaryOwnerChangingDuringPutOverwrite random failures
> ---------------------------------------------------------------------------------------------------
>
> Key: ISPN-6039
> URL: https://issues.jboss.org/browse/ISPN-6039
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core
> Affects Versions: 8.1.0.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Blocker
> Labels: testsuite_stability
> Fix For: 9.0.0.Beta1
>
>
> The problem is that the state transfer write can happen after we started the regular put, and is blocked by the {{BlockingInterceptor}}. The test then unblocks the state transfer put, but never unblocks the regular put, which eventually times out.
> {noformat}
> java.util.concurrent.TimeoutException
> at java.util.concurrent.FutureTask.get(FutureTask.java:205)
> at org.infinispan.distribution.rehash.NonTxBackupOwnerBecomingPrimaryOwnerTest.doTest(NonTxBackupOwnerBecomingPrimaryOwnerTest.java:193)
> at org.infinispan.distribution.rehash.NonTxBackupOwnerBecomingPrimaryOwnerTest.testPrimaryOwnerChangingDuringPutOverwrite(NonTxBackupOwnerBecomingPrimaryOwnerTest.java:75)
> {noformat}
> The test should be more explicit about the state transfer put - ideally it should have 2 cases, one with the state transfer put happening before the regular put, and one after.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 11 months
[JBoss JIRA] (ISPN-6038) ClientAsymmetricClusterTest.testAsymmetricCluster random failures
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-6038?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-6038:
--------------------------------
Fix Version/s: 9.0.0.Beta1
(was: 9.0.0.Alpha4)
> ClientAsymmetricClusterTest.testAsymmetricCluster random failures
> -----------------------------------------------------------------
>
> Key: ISPN-6038
> URL: https://issues.jboss.org/browse/ISPN-6038
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Protocols, Test Suite - Server
> Reporter: Dan Berindei
> Assignee: Galder Zamarreño
> Priority: Minor
> Labels: testsuite_stability
> Fix For: 9.0.0.Beta1
>
>
> {{ClientAsymmetricClusterTest.testAsymmetricCluster}} is failing since the ISPN-5981 fix, which enabled {{pingOnStartup}} by default, and now returns {{null}} if the first server to be pinged doesn't have the cache defined.
> {noformat}
> 10:23:07,862 WARN (testng-ClientAsymmetricClusterTest:) [Codec21] ISPN004005: Error received from the server: org.infinispan.server.hotrod.CacheNotFoundException: Cache with name 'asymmetricCache' not found amongst the configured caches
> 10:23:07,862 ERROR (testng-ClientAsymmetricClusterTest:) [UnitTestTestNGListener] Test testAsymmetricCluster(org.infinispan.client.hotrod.ClientAsymmetricClusterTest) failed.
> java.lang.NullPointerException
> at org.infinispan.client.hotrod.ClientAsymmetricClusterTest.testAsymmetricCluster(ClientAsymmetricClusterTest.java:38) ~[test-classes/:?]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 11 months
[JBoss JIRA] (ISPN-6040) FunctionalNonTxBackupOwnerBecomingPrimaryOwnerTest.testPrimaryOwnerChangingDuringRemove random failures
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-6040?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-6040:
--------------------------------
Fix Version/s: 9.0.0.Beta1
(was: 9.0.0.Alpha4)
> FunctionalNonTxBackupOwnerBecomingPrimaryOwnerTest.testPrimaryOwnerChangingDuringRemove random failures
> -------------------------------------------------------------------------------------------------------
>
> Key: ISPN-6040
> URL: https://issues.jboss.org/browse/ISPN-6040
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Test Suite - Core
> Affects Versions: 8.1.0.Final
> Reporter: Dan Berindei
> Assignee: Galder Zamarreño
> Priority: Blocker
> Labels: testsuite_stability
> Fix For: 9.0.0.Beta1
>
>
> Similar to ISPN-6039, the test failure is caused by the state transfer put happening after the test's remove.
> In this case, the command types are different, so blocking works correctly. However, when the {{ReadWriteKeyValueCommand}} executes before the state transfer put, it doesn't find any value, and it doesn't commit the entry. This means the key is not added to {{CommitManager}}'s {{tracker}} map, and the state transfer put is allowed to write to it - effectively undoing the remove.
> {noformat}
> java.lang.AssertionError: expected:<null> but was:<v0>
> 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:88)
> at org.infinispan.distribution.rehash.NonTxBackupOwnerBecomingPrimaryOwnerTest.doTest(NonTxBackupOwnerBecomingPrimaryOwnerTest.java:194)
> at org.infinispan.functional.distribution.rehash.FunctionalNonTxBackupOwnerBecomingPrimaryOwnerTest.testPrimaryOwnerChangingDuringRemove(FunctionalNonTxBackupOwnerBecomingPrimaryOwnerTest.java:103)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 11 months
[JBoss JIRA] (ISPN-6041) Remote Listeners: Client event reader thread reports EOF as error
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-6041?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-6041:
--------------------------------
Fix Version/s: 9.0.0.Beta1
(was: 9.0.0.Alpha4)
> Remote Listeners: Client event reader thread reports EOF as error
> -----------------------------------------------------------------
>
> Key: ISPN-6041
> URL: https://issues.jboss.org/browse/ISPN-6041
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Protocols
> Affects Versions: 8.1.0.Final
> Reporter: Dan Berindei
> Priority: Minor
> Fix For: 9.0.0.Beta1
>
>
> {noformat}
> 14:02:14,904 ERROR (Client-Listener-87aa07aee56d43e1) [ClientListenerNotifier] ISPN004043: Unrecoverable error reading event from server /127.0.0.1:15530, exiting event reader thread
> org.infinispan.client.hotrod.exceptions.TransportException: End of stream reached!
> at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransport.readByte(TcpTransport.java:198)
> at org.infinispan.client.hotrod.impl.protocol.Codec20.readMagic(Codec20.java:305)
> at org.infinispan.client.hotrod.impl.protocol.Codec20.readEvent(Codec20.java:147)
> at org.infinispan.client.hotrod.event.ClientListenerNotifier$EventDispatcher.run(ClientListenerNotifier.java:252)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 11 months