[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.Beta2
(was: 9.0.0.Beta1)
> 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.Beta2
>
>
> {{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, 4 months
[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.Beta2
(was: 9.0.0.Beta1)
> 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.Beta2
>
>
> 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, 4 months
[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.Beta2
(was: 9.0.0.Beta1)
> 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.Beta2
>
>
> 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, 4 months
[JBoss JIRA] (ISPN-5849) AutoCloseable return from adding listeners can be clunky to use
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-5849?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-5849:
----------------------------------
Fix Version/s: 9.0.0.Beta2
(was: 9.0.0.Beta1)
> AutoCloseable return from adding listeners can be clunky to use
> ---------------------------------------------------------------
>
> Key: ISPN-5849
> URL: https://issues.jboss.org/browse/ISPN-5849
> Project: Infinispan
> Issue Type: Sub-task
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 9.0.0.Beta2
>
>
> On one side, to use it as a try-with-resource, you need to declare it right in the {{try()}};
> {code}
> try(AutoCloseable handler = writeOnlyMap.listeners().onWrite(written ->
> System.out.printf("Written (via onWrite): %s%n", written.get()))) {
> Map<String, String> entries = new HashMap<>();
> entries.put("key1", "value1");
> entries.put("key2", "value2");
> writeOnlyMap.evalMany(entries, (v, writeView) -> writeView.set(v))
> .get(); // Wait for completable future
> }
> {code}
> So it's usability is mostly designed for unit tests since listeners tend to be set and removed at a later stage. IOW, listeners are not generally a short-lived object.
> The other aspect that is clunky to use is the fact that AutoCloseable's close() throws Exception, which again makes it ackward to use for example if lambdas.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months