June 2016 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-6760) Comparing a sum of an attribute fails with ClassCastException

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-6760?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-6760: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Comparing a sum of an attribute fails with ClassCastException > ------------------------------------------------------------- > > Key: ISPN-6760 > URL: https://issues.jboss.org/browse/ISPN-6760 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying > Affects Versions: 9.0.0.Alpha2 > Reporter: Jakub Markos > Assignee: Adrian Nistor > Fix For: 9.0.0.Alpha3, 9.0.0.Final, 8.2.3.Final > > > The following query (in the context of QueryDslConditionsTest) > {code} > public void testSum2() throws Exception { > QueryFactory qf = getQueryFactory(); > Query q = qf.from(getModelFactory().getUserImplClass()) > .select(sum("age")) > .groupBy("name") > .having(sum("age")).gt(50000).toBuilder() > .build(); > List<Object[]> list = q.list(); > } > {code} > fails with > {code} > java.lang.ClassCastException: java.lang.Long cannot be cast to java.lang.Integer > at java.lang.Integer.compareTo(Integer.java:52) > at org.infinispan.objectfilter.impl.util.Interval.contains(Interval.java:92) > at org.infinispan.objectfilter.impl.predicateindex.IntervalCondition.match(IntervalCondition.java:19) > at org.infinispan.objectfilter.impl.predicateindex.IntervalCondition.match(IntervalCondition.java:9) > at org.infinispan.objectfilter.impl.predicateindex.Predicate.match(Predicate.java:37) > at org.infinispan.objectfilter.impl.predicateindex.Predicates.notifyMatchingSubscribers(Predicates.java:118) > at org.infinispan.objectfilter.impl.predicateindex.AttributeNode.processValue(AttributeNode.java:114) > at org.infinispan.objectfilter.impl.predicateindex.RowMatcherEvalContext.processAttributes(RowMatcherEvalContext.java:30) > at org.infinispan.objectfilter.impl.predicateindex.MatcherEvalContext.process(MatcherEvalContext.java:129) > at org.infinispan.objectfilter.impl.ObjectFilterImpl.filter(ObjectFilterImpl.java:213) > at org.infinispan.query.dsl.embedded.impl.HybridQuery$1.updateNext(HybridQuery.java:80) > at org.infinispan.query.dsl.embedded.impl.HybridQuery$1.hasNext(HybridQuery.java:59) > at org.infinispan.query.dsl.embedded.impl.BaseEmbeddedQuery.listInternal(BaseEmbeddedQuery.java:66) > at org.infinispan.query.dsl.embedded.impl.BaseEmbeddedQuery.list(BaseEmbeddedQuery.java:57) > at org.infinispan.query.dsl.embedded.impl.DelegatingQuery.list(DelegatingQuery.java:49) > at org.infinispan.query.dsl.embedded.QueryDslConditionsTest.testSum2(QueryDslConditionsTest.java:2001) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84) > at org.testng.internal.Invoker.invokeMethod(Invoker.java:714) > at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901) > at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231) > at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127) > at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111) > at org.testng.TestRunner.privateRun(TestRunner.java:767) > at org.testng.TestRunner.run(TestRunner.java:617) > at org.testng.SuiteRunner.runTest(SuiteRunner.java:348) > at org.testng.SuiteRunner.access$000(SuiteRunner.java:38) > at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:382) > at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64) > 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) > at java.lang.Thread.run(Thread.java:745) > {code} > Using {code}.having(sum("age")).gt(new Long(50000)).toBuilder(){code} doesn't have any effect. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6773) Metadata updates get dropped with Functional API

by Krzysztof Sobolewski (JIRA)

[ https://issues.jboss.org/browse/ISPN-6773?page=com.atlassian.jira.plugin.... ] Krzysztof Sobolewski updated ISPN-6773: --------------------------------------- Git Pull Request: https://github.com/infinispan/infinispan/pull/4412, https://github.com/infinispan/infinispan/pull/4413 > Metadata updates get dropped with Functional API > ------------------------------------------------ > > Key: ISPN-6773 > URL: https://issues.jboss.org/browse/ISPN-6773 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.0.0.Alpha2, 8.2.2.Final > Reporter: Krzysztof Sobolewski > > I have a CacheLoader that injects EmbeddedMetadata so that I can specify the lifetime of the newly loaded entry. EmbeddedMetadata is supposed to be used when only lifespan or maxIdle are required (I only need lifespan); this works because the lifespan (and maxIdle) information is copied into the internal node itself - no extra Metadata object is allocated. > The InternalNode has several implementations, each used for the different combination of lifespan and maxIdle. Let's proceed with MortalCacheEntry (lifespan only). Its metadata-aware sibling is MetadataMortalCacheEntry. Each of those has a special code path in EntryWrappingInterceptor for updates of metadata. This path is chosen not based on the type of the InternalEntry (so that it can also work for new entries, where there's no internal entry object yet) but instead the decision is made in InternalEntryFactoryImpl.isStoreMetadata() based on the type of the Metadata object - if it returns true, then the path for MetadataMortalCacheEntry is used. This path then inspects the actual type of the internal entry object so that can update it accordingly. > Enter Functional API. > After I return EmbeddedMetadata from the CacheLoader, the expiration parameters are updated just fine - the EmbeddedMetadata is recognized and a MortalCacheEntry is created with the expected lifespan. Then, when we use {code:java}EntryView.WriteEntryView.set(value, params...){code} to update the metadata (which is the only way to do that in Functional API), the Metadata object in the entry gets replaced with an instance of MetaParamsInternalMetadata. This makes isStoreMetadata() return true (because the Metadata object is no longer EmbeddedMetadata). EntryWrappingInterceptor then goes into the metadata-aware code path where MortalCacheEntry is not handled (MetadataMortalCacheEntry is instead) and the metadata update is not performed at all. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (HRJS-22) Exponential wait-based retries

by Galder Zamarreño (JIRA)

Galder Zamarreño created HRJS-22: ------------------------------------ Summary: Exponential wait-based retries Key: HRJS-22 URL: https://issues.jboss.org/browse/HRJS-22 Project: Infinispan Javascript client Issue Type: Enhancement Reporter: Galder Zamarreño Switch Hot Rod client from using maxRetries to using time based retries with exponential backoffs in order to avoid overloading the server with continuous retries. Also, make sure you retry errors that can be fixed, e.g. connection close, IllegalLifecycleStateExceptions. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6774) Exponential wait-based retries

by Galder Zamarreño (JIRA)

Galder Zamarreño created ISPN-6774: -------------------------------------- Summary: Exponential wait-based retries Key: ISPN-6774 URL: https://issues.jboss.org/browse/ISPN-6774 Project: Infinispan Issue Type: Enhancement Reporter: Galder Zamarreño Switch Hot Rod client from using maxRetries to using time based retries with exponential backoffs in order to avoid overloading the server with continuous retries. Also, make sure you retry errors that can be fixed, e.g. connection close, IllegalLifecycleStateExceptions. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6773) Metadata updates get dropped with Functional API

by Krzysztof Sobolewski (JIRA)

Krzysztof Sobolewski created ISPN-6773: ------------------------------------------ Summary: Metadata updates get dropped with Functional API Key: ISPN-6773 URL: https://issues.jboss.org/browse/ISPN-6773 Project: Infinispan Issue Type: Bug Components: Core Affects Versions: 8.2.2.Final, 9.0.0.Alpha2 Reporter: Krzysztof Sobolewski I have a CacheLoader that injects EmbeddedMetadata so that I can specify the lifetime of the newly loaded entry. EmbeddedMetadata is supposed to be used when only lifespan or maxIdle are required (I only need lifespan); this works because the lifespan (and maxIdle) information is copied into the internal node itself - no extra Metadata object is allocated. The InternalNode has several implementations, each used for the different combination of lifespan and maxIdle. Let's proceed with MortalCacheEntry (lifespan only). Its metadata-aware sibling is MetadataMortalCacheEntry. Each of those has a special code path in EntryWrappingInterceptor for updates of metadata. This path is chosen not based on the type of the InternalEntry (so that it can also work for new entries, where there's no internal entry object yet) but instead the decision is made in InternalEntryFactoryImpl.isStoreMetadata() based on the type of the Metadata object - if it returns true, then the path for MetadataMortalCacheEntry is used. This path then inspects the actual type of the internal entry object so that can update it accordingly. Enter Functional API. After I return EmbeddedMetadata from the CacheLoader, the expiration parameters are updated just fine - the EmbeddedMetadata is recognized and a MortalCacheEntry is created with the expected lifespan. Then, when we use {code:java}EntryView.WriteEntryView.set(value, params...){code} to update the metadata (which is the only way to do that in Functional API), the Metadata object in the entry gets replaced with an instance of MetaParamsInternalMetadata. This makes isStoreMetadata() return true (because the Metadata object is no longer EmbeddedMetadata). EntryWrappingInterceptor then goes into the metadata-aware code path where MortalCacheEntry is not handled (MetadataMortalCacheEntry is instead) and the metadata update is not performed at all. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6758) JDBC DB Major/Minor Versions not exposed by the server

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-6758?page=com.atlassian.jira.plugin.... ] Ryan Emerson updated ISPN-6758: ------------------------------- Description: The ability for the user to configure the Major and Minor versions of the underlying DB that JDBC connects was added as part of ISPN-20, however the ability to read/configure these values via the server was omitted. > JDBC DB Major/Minor Versions not exposed by the server > ------------------------------------------------------ > > Key: ISPN-6758 > URL: https://issues.jboss.org/browse/ISPN-6758 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores, Server > Affects Versions: 9.0.0.Alpha2 > Reporter: Ryan Emerson > Assignee: Ryan Emerson > > The ability for the user to configure the Major and Minor versions of the underlying DB that JDBC connects was added as part of ISPN-20, however the ability to read/configure these values via the server was omitted. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6772) Clarify error messages from JPA CacheStore failing to boot

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-6772?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-6772: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done Integrated in master. Thanks [~sannegrinovero]! > Clarify error messages from JPA CacheStore failing to boot > ---------------------------------------------------------- > > Key: ISPN-6772 > URL: https://issues.jboss.org/browse/ISPN-6772 > Project: Infinispan > Issue Type: Enhancement > Components: Loaders and Stores > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Priority: Trivial > Fix For: 9.0.0.Alpha3, 9.0.0.Final > > > Currently when for any reason a Persistence Unit fails to boot - most commonly because of wrong configuration details or connection issues - the reported error is: > {quote}Persistence unit [name of PU] not found{quote} > This is confusing and never accurate, while avoiding to override the exceptions will result in better explanations. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6772) Clarify error messages from JPA CacheStore failing to boot

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-6772?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-6772: -------------------------------- Fix Version/s: 9.0.0.Final > Clarify error messages from JPA CacheStore failing to boot > ---------------------------------------------------------- > > Key: ISPN-6772 > URL: https://issues.jboss.org/browse/ISPN-6772 > Project: Infinispan > Issue Type: Enhancement > Components: Loaders and Stores > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Priority: Trivial > Fix For: 9.0.0.Alpha3, 9.0.0.Final > > > Currently when for any reason a Persistence Unit fails to boot - most commonly because of wrong configuration details or connection issues - the reported error is: > {quote}Persistence unit [name of PU] not found{quote} > This is confusing and never accurate, while avoiding to override the exceptions will result in better explanations. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6744) ClusterEvent doesn't implement CacheEntryExpired

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-6744?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-6744: -------------------------------- Git Pull Request: https://github.com/infinispan/infinispan/pull/4406, https://github.com/infinispan/infinispan/pull/4411 (was: https://github.com/infinispan/infinispan/pull/4406) > ClusterEvent doesn't implement CacheEntryExpired > ------------------------------------------------ > > Key: ISPN-6744 > URL: https://issues.jboss.org/browse/ISPN-6744 > Project: Infinispan > Issue Type: Bug > Components: Expiration, Listeners > Reporter: William Burns > Assignee: William Burns > Fix For: 9.0.0.Alpha3, 9.0.0.Final, 8.2.3.Final > > > ClusterEvent needs to implement CacheEntryExpired or else it cannot be replicated as a cluster event in the event of an expiration not on a node where a cluster listener was registered. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6744) ClusterEvent doesn't implement CacheEntryExpired

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-6744?page=com.atlassian.jira.plugin.... ] Adrian Nistor commented on ISPN-6744: ------------------------------------- [~william.burns] It seems backporting to 8.2.x is enough. There is no sight of a 8.1.x release. > ClusterEvent doesn't implement CacheEntryExpired > ------------------------------------------------ > > Key: ISPN-6744 > URL: https://issues.jboss.org/browse/ISPN-6744 > Project: Infinispan > Issue Type: Bug > Components: Expiration, Listeners > Reporter: William Burns > Assignee: William Burns > Fix For: 9.0.0.Alpha3, 9.0.0.Final, 8.2.3.Final > > > ClusterEvent needs to implement CacheEntryExpired or else it cannot be replicated as a cluster event in the event of an expiration not on a node where a cluster listener was registered. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues June 2016