April 2018 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-8719) KeySet.(iterator|spliterator|stream) not compatible with versions before 9.1

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-8719?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-8719: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > KeySet.(iterator|spliterator|stream) not compatible with versions before 9.1 > ---------------------------------------------------------------------------- > > Key: ISPN-8719 > URL: https://issues.jboss.org/browse/ISPN-8719 > Project: Infinispan > Issue Type: Bug > Affects Versions: 9.1.0.Final, 9.2.0.Final > Reporter: Marek Posolda > Assignee: William Burns > Priority: Critical > Fix For: 9.1.8.Final, 9.2.2.Final, 9.3.0.Alpha1 > > Attachments: InfinispanRemote.java > > > Steps to reproduce: > 1) Use infinispan server version 8.2.6 (or JDG server 7.1.0) and start it. > {code} > cd JDG_HOME/bin > ./standalone.sh > {code} > 2) Create sample java project having dependency on latest dependency 9.2.0.CR1 in pom.xml: > {code} > <dependencies> > <dependency> > <groupId>org.infinispan</groupId> > <artifactId>infinispan-core</artifactId> > <version>9.2.0.CR1</version> > </dependency> > <dependency> > <groupId>org.infinispan</groupId> > <artifactId>infinispan-cachestore-remote</artifactId> > <version>9.2.0.CR1</version> > </dependency> > </dependencies> > {code} > 3) Add one simple java class based on the tutorial: http://infinispan.org/tutorials/simple/remote/ . The only difference is that I use hotRod protocolVersion 2.5 and calling: > {code} > remoteCache.keySet().iterator().hasNext() > {code}. I am attaching the class in attachement. > 4) Run the class. Seeing exception in both server log and on client-side. > Server exception > {code} > 10:44:20,365 ERROR [org.infinispan.server.hotrod.CacheDecodeContext] (HotRodServerWorker-6-1) ISPN005003: Exception reported: java.lang.IllegalStateException: ISPN006016: Factory 'org.infinispan.server.hotrod.HotRodServer$ToEmptyBytesKeyValueFilterConverter' not found in server > at org.infinispan.server.hotrod.iteration.DefaultIterationManager.getFactory(DefaultIterationManager.java:148) > at org.infinispan.server.hotrod.iteration.DefaultIterationManager.start(DefaultIterationManager.java:131) > at org.infinispan.server.hotrod.ContextHandler.realRead(ContextHandler.java:175) > at org.infinispan.server.hotrod.ContextHandler.lambda$channelRead0$1(ContextHandler.java:57) > at org.infinispan.server.hotrod.ContextHandler$$Lambda$86/1492247987.run(Unknown Source) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:144) > at java.lang.Thread.run(Thread.java:745) > {code} > Client exception: > {code} > Jan 24, 2018 10:44:20 AM org.infinispan.client.hotrod.impl.protocol.Codec20 checkForErrorsInResponseStatus > WARN: ISPN004005: Error received from the server: java.lang.IllegalStateException: ISPN006016: Factory 'org.infinispan.server.hotrod.HotRodServer$ToEmptyBytesKeyValueFilterConverter' not found in server > Exception in thread "main" org.infinispan.client.hotrod.exceptions.HotRodClientException:Request for messageId=5 returned server error (status=0x85): java.lang.IllegalStateException: ISPN006016: Factory 'org.infinispan.server.hotrod.HotRodServer$ToEmptyBytesKeyValueFilterConverter' not found in server > at org.infinispan.client.hotrod.impl.protocol.Codec20.checkForErrorsInResponseStatus(Codec20.java:408) > at org.infinispan.client.hotrod.impl.protocol.Codec20.readPartialHeader(Codec20.java:162) > at org.infinispan.client.hotrod.impl.protocol.Codec20.readHeader(Codec20.java:148) > at org.infinispan.client.hotrod.impl.operations.HotRodOperation.readHeaderAndValidate(HotRodOperation.java:60) > at org.infinispan.client.hotrod.impl.operations.IterationStartOperation.executeOperation(IterationStartOperation.java:72) > at org.infinispan.client.hotrod.impl.operations.IterationStartOperation.executeOperation(IterationStartOperation.java:21) > at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:56) > at org.infinispan.client.hotrod.impl.iteration.RemoteCloseableIterator.startInternal(RemoteCloseableIterator.java:127) > at org.infinispan.client.hotrod.impl.iteration.RemoteCloseableIterator.start(RemoteCloseableIterator.java:140) > at org.infinispan.client.hotrod.impl.RemoteCacheImpl.retrieveEntries(RemoteCacheImpl.java:162) > at org.infinispan.client.hotrod.impl.RemoteCacheImpl.retrieveEntries(RemoteCacheImpl.java:168) > at org.infinispan.client.hotrod.impl.RemoteCacheImpl.retrieveEntries(RemoteCacheImpl.java:173) > at org.infinispan.client.hotrod.impl.RemoteCacheImpl$KeySet.iterator(RemoteCacheImpl.java:553) > at org.mposolda.ispn.InfinispanRemote.main(InfinispanRemote.java:34) > {code} > Indeed, When looking at this line of class RemoteCacheImpl, I see that it references the class, which seem that it was added in HotRodServer version 9. This looks like the cause of the error: https://github.com/infinispan/infinispan/blob/master/client/hotrod-client... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7420) Hot Rod enhancements for transcoding

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-7420?page=com.atlassian.jira.plugin.... ] Work on ISPN-7420 started by Gustavo Fernandes. ----------------------------------------------- > Hot Rod enhancements for transcoding > ------------------------------------ > > Key: ISPN-7420 > URL: https://issues.jboss.org/browse/ISPN-7420 > Project: Infinispan > Issue Type: Feature Request > Reporter: Galder Zamarreño > Assignee: Gustavo Fernandes > > Several enhancements will need to be made to the Hot Rod protocol to work with transcoding: > h3. Cache Writes (key + value) > * Cache write operations that include values should have an optional parameter to be able to define the MIME type of the key and value that is being written. When the optional parameter is sent to the server, it will enable the server to implicitly discover what the types of the key+value are. > * Once the first cache write has determined the key+value types, the clients do not need to send them again. If the client sends different types for the same cache, it should either result in the server ignoring it or an error (the former is preferable). > * To avoid sending unnecessary data, advanced clients could cache the key+value type for a given cache after the first write request and then don't send it again. > h3. Cache reads > * Any operation that involves retrieving data should optionally take the type that the value should be transcoded to when returning it back to the client. This enables data to be read in different formats. > * Within these operations, write operations that return previous values should be included. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7420) Hot Rod enhancements for transcoding

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-7420?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-7420: ------------------------------------ Status: Open (was: New) > Hot Rod enhancements for transcoding > ------------------------------------ > > Key: ISPN-7420 > URL: https://issues.jboss.org/browse/ISPN-7420 > Project: Infinispan > Issue Type: Feature Request > Reporter: Galder Zamarreño > Assignee: Gustavo Fernandes > > Several enhancements will need to be made to the Hot Rod protocol to work with transcoding: > h3. Cache Writes (key + value) > * Cache write operations that include values should have an optional parameter to be able to define the MIME type of the key and value that is being written. When the optional parameter is sent to the server, it will enable the server to implicitly discover what the types of the key+value are. > * Once the first cache write has determined the key+value types, the clients do not need to send them again. If the client sends different types for the same cache, it should either result in the server ignoring it or an error (the former is preferable). > * To avoid sending unnecessary data, advanced clients could cache the key+value type for a given cache after the first write request and then don't send it again. > h3. Cache reads > * Any operation that involves retrieving data should optionally take the type that the value should be transcoded to when returning it back to the client. This enables data to be read in different formats. > * Within these operations, write operations that return previous values should be included. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9091) Replace Runtime.getRuntime().availableProcessors() usage with a cgroups quota-aware implementation

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-9091?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9091: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/5929 > Replace Runtime.getRuntime().availableProcessors() usage with a cgroups quota-aware implementation > -------------------------------------------------------------------------------------------------- > > Key: ISPN-9091 > URL: https://issues.jboss.org/browse/ISPN-9091 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.2.1.Final > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > > Java's Runtime.getRuntime().availableProcessors() doesn't take into account cgroup quotas correctly. Provide our own implementation that does. > See https://github.com/wildfly/wildfly-common/blob/master/src/main/java/org/w... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9091) Replace Runtime.getRuntime().availableProcessors() usage with a cgroups quota-aware implementation

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-9091?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9091: ---------------------------------- Summary: Replace Runtime.getRuntime().availableProcessors() usage with a cgroups quota-aware implementation (was: Replace Runtime.getRuntime().availableProcessors() usage with a quota-aware implementation) > Replace Runtime.getRuntime().availableProcessors() usage with a cgroups quota-aware implementation > -------------------------------------------------------------------------------------------------- > > Key: ISPN-9091 > URL: https://issues.jboss.org/browse/ISPN-9091 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.2.1.Final > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > > Java's Runtime.getRuntime().availableProcessors() doesn't take into account cgroup quotas correctly. Provide our own implementation that does. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9091) Replace Runtime.getRuntime().availableProcessors() usage with a cgroups quota-aware implementation

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-9091?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9091: ---------------------------------- Description: Java's Runtime.getRuntime().availableProcessors() doesn't take into account cgroup quotas correctly. Provide our own implementation that does. See https://github.com/wildfly/wildfly-common/blob/master/src/main/java/org/w... was:Java's Runtime.getRuntime().availableProcessors() doesn't take into account cgroup quotas correctly. Provide our own implementation that does. > Replace Runtime.getRuntime().availableProcessors() usage with a cgroups quota-aware implementation > -------------------------------------------------------------------------------------------------- > > Key: ISPN-9091 > URL: https://issues.jboss.org/browse/ISPN-9091 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.2.1.Final > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > > Java's Runtime.getRuntime().availableProcessors() doesn't take into account cgroup quotas correctly. Provide our own implementation that does. > See https://github.com/wildfly/wildfly-common/blob/master/src/main/java/org/w... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9091) Replace Runtime.getRuntime().availableProcessors() usage with a quota-aware implementation

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-9091: ------------------------------------- Summary: Replace Runtime.getRuntime().availableProcessors() usage with a quota-aware implementation Key: ISPN-9091 URL: https://issues.jboss.org/browse/ISPN-9091 Project: Infinispan Issue Type: Bug Components: Core Affects Versions: 9.2.1.Final Reporter: Tristan Tarrant Assignee: Tristan Tarrant Java's Runtime.getRuntime().availableProcessors() doesn't take into account cgroup quotas correctly. Provide our own implementation that does. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9091) Replace Runtime.getRuntime().availableProcessors() usage with a quota-aware implementation

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-9091?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9091: ---------------------------------- Status: Open (was: New) > Replace Runtime.getRuntime().availableProcessors() usage with a quota-aware implementation > ------------------------------------------------------------------------------------------ > > Key: ISPN-9091 > URL: https://issues.jboss.org/browse/ISPN-9091 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.2.1.Final > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > > Java's Runtime.getRuntime().availableProcessors() doesn't take into account cgroup quotas correctly. Provide our own implementation that does. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7955) Hot Rod client needs to re-resolve topology addresses after failure to connect

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-7955?page=com.atlassian.jira.plugin.... ] Tristan Tarrant commented on ISPN-7955: --------------------------------------- True, [~rvansa], however client and servers should agree on the external names of the servers. I don't think there is much we can do > Hot Rod client needs to re-resolve topology addresses after failure to connect > ------------------------------------------------------------------------------ > > Key: ISPN-7955 > URL: https://issues.jboss.org/browse/ISPN-7955 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols > Affects Versions: 8.2.6.Final, 8.1.7.Final, 9.1.0.Beta1, 9.0.3.Final > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 8.1.9.Final, 9.1.0.Final, 8.2.8.Final > > > The Hot Rod client resolves topology addresses on reception. In dynamic environments where server nodes can restart with different IPs (but maintaining their external hostname) this causes the client to fail to reconnect. The client should hold on to the original address and re-resolve it in case of failures. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9087) Timeout during put operation when a node is blocked

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-9087?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-9087: ------------------------------- Security: (was: Red Hat Internal) > Timeout during put operation when a node is blocked > --------------------------------------------------- > > Key: ISPN-9087 > URL: https://issues.jboss.org/browse/ISPN-9087 > Project: Infinispan > Issue Type: Bug > Reporter: Diego Lovison > > {noformat} > 2018-04-17 13:30:02.782 ERROR 14932 --- [timeout-thread--p3-t1] o.i.i.impl.InvocationContextInterceptor : ISPN000136: Error executing command PutKeyValueCommand, writing keys [5db796a3-3f65-468a-b86a-6d5ef8b4b330] > > org.infinispan.util.concurrent.TimeoutException: ISPN000427: Timeout after 15 seconds waiting for acks. Id=100000 > at org.infinispan.util.concurrent.CommandAckCollector.createTimeoutException(CommandAckCollector.java:188) ~[infinispan-embedded-8.5.0.Final-redhat-6.jar:8.5.0.Final-redhat-6] > at org.infinispan.util.concurrent.CommandAckCollector.access$300(CommandAckCollector.java:51) ~[infinispan-embedded-8.5.0.Final-redhat-6.jar:8.5.0.Final-redhat-6] > at org.infinispan.util.concurrent.CommandAckCollector$BaseCollector.call(CommandAckCollector.java:214) [infinispan-embedded-8.5.0.Final-redhat-6.jar:8.5.0.Final-redhat-6] > at org.infinispan.util.concurrent.CommandAckCollector$BaseCollector.call(CommandAckCollector.java:191) [infinispan-embedded-8.5.0.Final-redhat-6.jar:8.5.0.Final-redhat-6] > at java.util.concurrent.FutureTask.run(FutureTask.java:266) [na:1.8.0_161] > at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [na:1.8.0_161] > at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [na:1.8.0_161] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [na:1.8.0_161] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [na:1.8.0_161] > at java.lang.Thread.run(Thread.java:748) [na:1.8.0_161] > {noformat} > After some investigation together with [~dan.berindei], we found that the FD_ALL is just too slow. > {noformat} > <FD_ALL timeout="60000" > interval="15000" > timeout_check_interval="5000" > /> > {noformat} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 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 2018