[JBoss JIRA] (ISPN-5803) Custom Key Results in ClassCastException in CacheLoader
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-5803?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-5803:
----------------------------------
Fix Version/s: 9.0.0.CR2
(was: 9.0.0.CR1)
> Custom Key Results in ClassCastException in CacheLoader
> -------------------------------------------------------
>
> Key: ISPN-5803
> URL: https://issues.jboss.org/browse/ISPN-5803
> Project: Infinispan
> Issue Type: Bug
> Components: JCache
> Affects Versions: 8.0.1.Final
> Reporter: Dan Siviter
> Assignee: Galder Zamarreño
> Fix For: 9.0.0.CR2
>
>
> If a a JCache is created using a read-through {{javax.cache.integration.CacheLoader}} using a custom Serializable key (in this case {{acme.MyCache$MyKey}}) a {{ClassCastException}} is thrown when trying to pass the key value of {{org.infinispan.marshall.core.MarshalledValue}} instead of {{MarshalledValue#get()}} into the {{CacheLoader}} instance.
> {code}
> java.lang.ClassCastException: org.infinispan.marshall.core.MarshalledValue cannot be cast to acme.MyCache$MyKey
> at acme.MyCache$2.load(MyCache.java:1) [my-app-1.0.0-SNAPSHOT.jar:]
> at org.infinispan.jcache.embedded.JCacheLoaderAdapter.loadKey(JCacheLoaderAdapter.java:65) [infinispan-jcache-8.0.1.Final.jar:8.0.1.Final]
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (ISPN-5929) InfinispanQueryIT.testQueryOnFirstNode random failures
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-5929?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-5929:
----------------------------------
Fix Version/s: 9.0.0.CR2
(was: 9.0.0.CR1)
> InfinispanQueryIT.testQueryOnFirstNode random failures
> ------------------------------------------------------
>
> Key: ISPN-5929
> URL: https://issues.jboss.org/browse/ISPN-5929
> Project: Infinispan
> Issue Type: Bug
> Components: Integration , Test Suite - Query
> Affects Versions: 8.1.0.Alpha2
> Reporter: Dan Berindei
> Assignee: Adrian Nistor
> Priority: Blocker
> Fix For: 9.0.0.CR2
>
>
> {{InfinispanQueryIT.testQueryOnFirstNode()}} and {{InfinispanQueryIT.testQueryOnSecondNode()}} fail randomly in CI with this assertion:
> {noformat}
> java.lang.AssertionError: expected:<3> but was:<2>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:555)
> at org.junit.Assert.assertEquals(Assert.java:542)
> at org.infinispan.test.integration.as.query.InfinispanQueryIT.testQueryOnFirstNode(InfinispanQueryIT.java:99)
> {noformat}
> Example: http://ci.infinispan.org/viewLog.html?buildId=31810&tab=buildResultsDiv&b...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (ISPN-6011) ClassCastException in CDI generated keys for JCache
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-6011?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-6011:
----------------------------------
Fix Version/s: 9.0.0.CR2
(was: 9.0.0.CR1)
> 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.CR2
>
>
> 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
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (ISPN-6039) NonTxBackupOwnerBecomingPrimaryOwnerTest.testPrimaryOwnerChangingDuringPutOverwrite random failures
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-6039?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-6039:
----------------------------------
Fix Version/s: 9.0.0.CR2
(was: 9.0.0.CR1)
> 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.CR2
>
>
> 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
(v7.2.3#72005)
9 years, 1 month