April 2017 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-7691) infinispan.client.hotrod.protocol_version ignored

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-7691?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes commented on ISPN-7691: ----------------------------------------- I don't have anymore the stackTrace, but it should be reproducible by having a hotrodclient.properties with infinispan.client.hotrod.protocol_version set to an earlier version, e.g. "2.2". At runtime, it will not be taken into account by the created client and it will send the lastes version when contacting the server. > infinispan.client.hotrod.protocol_version ignored > ------------------------------------------------- > > Key: ISPN-7691 > URL: https://issues.jboss.org/browse/ISPN-7691 > Project: Infinispan > Issue Type: Bug > Reporter: Gustavo Fernandes > Assignee: Katia Aresti > > Setting {{infinispan.client.hotrod.protocol_version}} via properties will not take effect due to a parsing error -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7691) infinispan.client.hotrod.protocol_version ignored

by Katia Aresti (JIRA)

[ https://issues.jboss.org/browse/ISPN-7691?page=com.atlassian.jira.plugin.... ] Katia Aresti edited comment on ISPN-7691 at 4/25/17 6:38 AM: ------------------------------------------------------------- Hi Gustavo, could you provide the stack trace please ? Thank you Katia was (Author: karesti): Hi Gustavo, can you provide the stack trace please ? Thank you Katia > infinispan.client.hotrod.protocol_version ignored > ------------------------------------------------- > > Key: ISPN-7691 > URL: https://issues.jboss.org/browse/ISPN-7691 > Project: Infinispan > Issue Type: Bug > Reporter: Gustavo Fernandes > Assignee: Katia Aresti > > Setting {{infinispan.client.hotrod.protocol_version}} via properties will not take effect due to a parsing error -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7691) infinispan.client.hotrod.protocol_version ignored

by Katia Aresti (JIRA)

[ https://issues.jboss.org/browse/ISPN-7691?page=com.atlassian.jira.plugin.... ] Katia Aresti commented on ISPN-7691: ------------------------------------ Hi Gustavo, can you provide the stack trace please ? Thank you Katia > infinispan.client.hotrod.protocol_version ignored > ------------------------------------------------- > > Key: ISPN-7691 > URL: https://issues.jboss.org/browse/ISPN-7691 > Project: Infinispan > Issue Type: Bug > Reporter: Gustavo Fernandes > Assignee: Katia Aresti > > Setting {{infinispan.client.hotrod.protocol_version}} via properties will not take effect due to a parsing error -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7691) infinispan.client.hotrod.protocol_version ignored

by Katia Aresti (JIRA)

[ https://issues.jboss.org/browse/ISPN-7691?page=com.atlassian.jira.plugin.... ] Katia Aresti updated ISPN-7691: ------------------------------- Status: Open (was: New) > infinispan.client.hotrod.protocol_version ignored > ------------------------------------------------- > > Key: ISPN-7691 > URL: https://issues.jboss.org/browse/ISPN-7691 > Project: Infinispan > Issue Type: Bug > Reporter: Gustavo Fernandes > Assignee: Katia Aresti > > Setting {{infinispan.client.hotrod.protocol_version}} via properties will not take effect due to a parsing error -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7691) infinispan.client.hotrod.protocol_version ignored

by Katia Aresti (JIRA)

[ https://issues.jboss.org/browse/ISPN-7691?page=com.atlassian.jira.plugin.... ] Katia Aresti reassigned ISPN-7691: ---------------------------------- Assignee: Katia Aresti > infinispan.client.hotrod.protocol_version ignored > ------------------------------------------------- > > Key: ISPN-7691 > URL: https://issues.jboss.org/browse/ISPN-7691 > Project: Infinispan > Issue Type: Bug > Reporter: Gustavo Fernandes > Assignee: Katia Aresti > > Setting {{infinispan.client.hotrod.protocol_version}} via properties will not take effect due to a parsing error -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7764) Query 'not().having().contains()' gives unexpected result

by Kevin Tabary (JIRA)

Kevin Tabary created ISPN-7764: ---------------------------------- Summary: Query 'not().having().contains()' gives unexpected result Key: ISPN-7764 URL: https://issues.jboss.org/browse/ISPN-7764 Project: Infinispan Issue Type: Bug Components: Remote Querying Affects Versions: 9.0.0.Final Reporter: Kevin Tabary Given following domain object {code} @ProtoMessage @ProtoDoc("@Indexed") @EqualsAndHashCode(of = {"applicationCode", "applicationUserId"}) public class ApplicationUser { private String applicationCode; private String applicationUserId; private Set<String> optoutCategories; private Set<Device> devices; //setter ommited @ProtoField(number = 1) public String getApplicationCode() { return applicationCode; } @ProtoField(number = 2) public String getApplicationUserId() { return applicationUserId; } @ProtoField(number = 3, collectionImplementation = HashSet.class) public Set<String> getOptoutCategories() { return optoutCategories; } @ProtoField(number = 4, collectionImplementation = HashSet.class) public Set<Device> getDevices() { return devices; } {code} and following request embedded in a Spring repository: {code} public List<ApplicationUser> test() { QueryFactory qf = getQueryFactory(); return qf.from(ApplicationUser.class) .not().having("optoutCategories").contains("CAT2") .and().having("applicationCode").eq("My_App_Yaya") .toBuilder() .build() .list(); } {code} and suppose the following json representation: {code} [ { "applicationCode": "My_App_Yaya", "applicationUserId": "123", "optoutCategories": [ "CAT3", "CAT2", "CAT1" ], "uniqueKey": "My_App_Yaya_123" } ] {code} the query returns the ApplicationUser with json representation above, but should not as it precisely contains the optoutCategories we want to exclude. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7470) Distributed executor does not fail over unless future.get() is called

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-7470?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-7470: ------------------------------- Fix Version/s: 9.1.0.Final > Distributed executor does not fail over unless future.get() is called > --------------------------------------------------------------------- > > Key: ISPN-7470 > URL: https://issues.jboss.org/browse/ISPN-7470 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 8.2.6.Final, 9.0.0.CR1 > Reporter: Dan Berindei > Assignee: William Burns > Fix For: 9.1.0.Final > > > After ISPN-6392, {{DistributedExecutorService.submit(...)}} nominally returns a {{CompletableFuture}}. However, it doesn't behave like a regular {{CompletableFuture}}, because it doesn't run the failure policy until the user calls {{future.get()}}. > {{future.isComplete()}} will return {{true}} before running the failure policy, and {{future.whenComplete(callback)}} will also execute the callback before running the failure policy. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7470) Distributed executor does not fail over unless future.get() is called

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-7470?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-7470: ------------------------------- Status: Open (was: New) > Distributed executor does not fail over unless future.get() is called > --------------------------------------------------------------------- > > Key: ISPN-7470 > URL: https://issues.jboss.org/browse/ISPN-7470 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 8.2.6.Final, 9.0.0.CR1 > Reporter: Dan Berindei > Assignee: William Burns > Fix For: 9.1.0.Final > > > After ISPN-6392, {{DistributedExecutorService.submit(...)}} nominally returns a {{CompletableFuture}}. However, it doesn't behave like a regular {{CompletableFuture}}, because it doesn't run the failure policy until the user calls {{future.get()}}. > {{future.isComplete()}} will return {{true}} before running the failure policy, and {{future.whenComplete(callback)}} will also execute the callback before running the failure policy. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7659) Infinispan doesn't build with the latest OpenJDK 9 early access builds

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-7659?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-7659: ------------------------------- Status: Pull Request Sent (was: Reopened) Git Pull Request: https://github.com/infinispan/infinispan/pull/5018, https://github.com/infinispan/infinispan/pull/5067 (was: https://github.com/infinispan/infinispan/pull/5018) > Infinispan doesn't build with the latest OpenJDK 9 early access builds > ---------------------------------------------------------------------- > > Key: ISPN-7659 > URL: https://issues.jboss.org/browse/ISPN-7659 > Project: Infinispan > Issue Type: Bug > Components: Build process > Affects Versions: 9.0.0.CR3 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 9.0.0.Final > > > Tried with builds 146 and 161, both fail to build even the commons module with a cryptic "Compilation failure" error. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7672) NonTotalOrderTxPerCacheInboundInvocationHandler throws warning when adding cache entry using Spring Session

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-7672?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-7672: ------------------------------------ [~galder.zamarreno] -1 to store the version inside the value, I have a feeling it's going to require extra allocations. And I don't know how it would interact with [~gustavonalle]'s transcoding work... For ISPN-4972, I think the HotRod server should use the functional API to execute the replacement based solely on the version. > NonTotalOrderTxPerCacheInboundInvocationHandler throws warning when adding cache entry using Spring Session > ----------------------------------------------------------------------------------------------------------- > > Key: ISPN-7672 > URL: https://issues.jboss.org/browse/ISPN-7672 > Project: Infinispan > Issue Type: Bug > Components: Cloud Integrations, Spring Integration > Affects Versions: 9.0.0.CR4 > Reporter: Sebastian Łaskawiec > Assignee: Galder Zamarreño > Priority: Blocker > Fix For: 9.1.0.Final > > > When I'm trying to add an entry using Spring Session integration with a [transactional cache|https://github.com/slaskawi/presentations/blob/master/2017_spring_s...], the server throws a warning: > {code} > [transactions-repository-1-2cbrv] 06:53:40,773 WARN [org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler] (remote-thread--p2-t18) ISPN000071: Caught exception when handling command DistributedExecuteCommand [cache=Cache 'sessions'@transactions-repository-1-2cbrv, keys=[], callable=ClusterEventCallable{identifier=b345211e-fbd7-4305-b3a6-6979301e0360, events=[ClusterEvent {type=CACHE_ENTRY_CREATED, cache=Cache 'sessions'@transactions-repository-1-2cbrv, key=[B@8c75820, value=[B@76856353, oldValue=null, transaction=RecoveryAwareGlobalTransaction{xid=< 131077, 29, 36, 0000000000-1-1-84170374-96-629488-44-62370001349, 0000000000-1-1-84170374-96-629488-44-62370001400000000 >, internalId=562954248388609} GlobalTx:transactions-repository-1-cwk6f:1, retryCommand=false, origin=transactions-repository-1-cwk6f}]}]: org.infinispan.commons.CacheListenerException: ISPN000280: Caught exception [java.lang.ClassCastException] while invoking method [public void org.infinispan.server.hotrod.ClientListenerRegistry$BaseClientEventSender.onCacheEvent(org.infinispan.notifications.cachelistener.event.CacheEntryEvent)] on listener instance: org.infinispan.server.hotrod.ClientListenerRegistry$StatelessClientEventSender@7b97a57 > [transactions-repository-1-2cbrv] at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl$1.run(AbstractListenerImpl.java:401) > [transactions-repository-1-2cbrv] at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:20) > [transactions-repository-1-2cbrv] at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl.invoke(AbstractListenerImpl.java:419) > [transactions-repository-1-2cbrv] at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.doRealInvocation(CacheNotifierImpl.java:1512) > [transactions-repository-1-2cbrv] at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.doRealInvocation(CacheNotifierImpl.java:1508) > [transactions-repository-1-2cbrv] at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invokeNoChecks(CacheNotifierImpl.java:1503) > [transactions-repository-1-2cbrv] at org.infinispan.notifications.cachelistener.CacheNotifierImpl.notifyClusterListeners(CacheNotifierImpl.java:711) > [transactions-repository-1-2cbrv] at org.infinispan.notifications.cachelistener.cluster.ClusterEventCallable.call(ClusterEventCallable.java:49) > [transactions-repository-1-2cbrv] at org.infinispan.notifications.cachelistener.cluster.ClusterEventCallable.call(ClusterEventCallable.java:25) > [transactions-repository-1-2cbrv] at org.infinispan.commands.read.DistributedExecuteCommand.invokeAsync(DistributedExecuteCommand.java:99) > [transactions-repository-1-2cbrv] at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.invokeCommand(BasePerCacheInboundInvocationHandler.java:90) > [transactions-repository-1-2cbrv] at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.invoke(BaseBlockingRunnable.java:90) > [transactions-repository-1-2cbrv] at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.runAsync(BaseBlockingRunnable.java:68) > [transactions-repository-1-2cbrv] at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.run(BaseBlockingRunnable.java:40) > [transactions-repository-1-2cbrv] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > [transactions-repository-1-2cbrv] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > [transactions-repository-1-2cbrv] at java.lang.Thread.run(Thread.java:745) > [transactions-repository-1-2cbrv] Caused by: java.lang.ClassCastException: org.infinispan.container.versioning.SimpleClusteredVersion cannot be cast to org.infinispan.container.versioning.NumericVersion > [transactions-repository-1-2cbrv] at org.infinispan.server.hotrod.ClientListenerRegistry$BaseClientEventSender.onCacheEvent(ClientListenerRegistry.java:363) > [transactions-repository-1-2cbrv] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > [transactions-repository-1-2cbrv] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > [transactions-repository-1-2cbrv] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > [transactions-repository-1-2cbrv] at java.lang.reflect.Method.invoke(Method.java:498) > [transactions-repository-1-2cbrv] at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl$1.run(AbstractListenerImpl.java:396) > [transactions-repository-1-2cbrv] ... 16 more > [transactions-repository-1-2cbrv] > {code} > This didn't happen in {{CR2}} release, so there must be something that changed since then. I also noticed that this sometimes leads to exceptions in the Hot Rod client. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 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 April 2017