April 2018 - infinispan-issues - Jboss List Archives

[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)

6 years, 8 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)

6 years, 8 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)

6 years, 8 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)

6 years, 8 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)

6 years, 8 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)

6 years, 8 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)

6 years, 8 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)

6 years, 8 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 reassigned ISPN-9087: ---------------------------------- Assignee: Dan Berindei > 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 > Assignee: Dan Berindei > > {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)

6 years, 8 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: ------------------------------- Status: Open (was: New) > 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 > Assignee: Dan Berindei > > {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)

6 years, 8 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues April 2018