February 2020 - infinispan-issues

[JBoss JIRA] (ISPN-11366) Remove Deprecated ConsistentHash methods

by Dan Berindei (Jira)

[ https://issues.redhat.com/browse/ISPN-11366?page=com.atlassian.jira.plugi... ] Dan Berindei updated ISPN-11366: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Remove Deprecated ConsistentHash methods > ---------------------------------------- > > Key: ISPN-11366 > URL: https://issues.redhat.com/browse/ISPN-11366 > Project: Infinispan > Issue Type: Task > Components: Core > Affects Versions: 11.0.0.Alpha1 > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Priority: Major > Fix For: 11.0.0.Alpha2 > > > Removing the deprecated {{ConsistentHash}} methods and add no longer serialize a generic Hash implementation as implementation is always Murmur3Hash. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-11377) Change default flow control protocol back to UFC/MFC

by Dan Berindei (Jira)

[ https://issues.redhat.com/browse/ISPN-11377?page=com.atlassian.jira.plugi... ] Dan Berindei updated ISPN-11377: -------------------------------- Git Pull Request: https://github.com/infinispan/infinispan/pull/7938, https://github.com/infinispan/infinispan/pull/7947, https://github.com/infinispan/infinispan/pull/7948 (was: https://github.com/infinispan/infinispan/pull/7938, https://github.com/infinispan/infinispan/pull/7947) > Change default flow control protocol back to UFC/MFC > ---------------------------------------------------- > > Key: ISPN-11377 > URL: https://issues.redhat.com/browse/ISPN-11377 > Project: Infinispan > Issue Type: Task > Components: Configuration, Core > Affects Versions: 9.4.18.Final, 10.1.2.Final, 11.0.0.Alpha1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 10.1.3.Final, 11.0.0.Alpha2 > > > The server default configuration started using {{UFC_NB}} and {{MFC_NB}} in order to avoid blocking on the Netty event loop threads, slowing client requests, and then the core default configurations started using {{UFC_NB}} and {{MFC_NB}} as well with ISPN-9886. > Unfortunately the _NB variants aren't really non-blocking: they have an extra queue for messages that require more credits, but that queue is limited (2MB by default), and once the queue is full, they also block. They also have much more complex locking than the blocking variants: we actually had to increase max_credits from 2MB to 3MB in order to get the same performance with {{UFC_NB}} that we had with {{UFC}}. > We're changing the defaults back to {{UFC}} and {{MFC}} while we investigate possible alternatives to avoid blocking. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-11377) Change default flow control protocol back to UFC/MFC

by Dan Berindei (Jira)

[ https://issues.redhat.com/browse/ISPN-11377?page=com.atlassian.jira.plugi... ] Dan Berindei updated ISPN-11377: -------------------------------- Git Pull Request: https://github.com/infinispan/infinispan/pull/7938, https://github.com/infinispan/infinispan/pull/7947 (was: https://github.com/infinispan/infinispan/pull/7938) > Change default flow control protocol back to UFC/MFC > ---------------------------------------------------- > > Key: ISPN-11377 > URL: https://issues.redhat.com/browse/ISPN-11377 > Project: Infinispan > Issue Type: Task > Components: Configuration, Core > Affects Versions: 9.4.18.Final, 10.1.2.Final, 11.0.0.Alpha1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 10.1.3.Final, 11.0.0.Alpha2 > > > The server default configuration started using {{UFC_NB}} and {{MFC_NB}} in order to avoid blocking on the Netty event loop threads, slowing client requests, and then the core default configurations started using {{UFC_NB}} and {{MFC_NB}} as well with ISPN-9886. > Unfortunately the _NB variants aren't really non-blocking: they have an extra queue for messages that require more credits, but that queue is limited (2MB by default), and once the queue is full, they also block. They also have much more complex locking than the blocking variants: we actually had to increase max_credits from 2MB to 3MB in order to get the same performance with {{UFC_NB}} that we had with {{UFC}}. > We're changing the defaults back to {{UFC}} and {{MFC}} while we investigate possible alternatives to avoid blocking. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-11341) Client requests go to wrong server with binary storage

by Gustavo Fernandes (Jira)

[ https://issues.redhat.com/browse/ISPN-11341?page=com.atlassian.jira.plugi... ] Gustavo Fernandes updated ISPN-11341: ------------------------------------- Git Pull Request: https://github.com/infinispan/infinispan/pull/7944, https://github.com/infinispan/infinispan/pull/7945, https://github.com/infinispan/infinispan/pull/7946 (was: https://github.com/infinispan/infinispan/pull/7944, https://github.com/infinispan/infinispan/pull/7945) > Client requests go to wrong server with binary storage > ------------------------------------------------------ > > Key: ISPN-11341 > URL: https://issues.redhat.com/browse/ISPN-11341 > Project: Infinispan > Issue Type: Bug > Components: Core, Hot Rod, Server > Affects Versions: 9.4.18.Final, 10.1.2.Final, 11.0.0.Alpha1 > Reporter: Dan Berindei > Assignee: Gustavo Fernandes > Priority: Major > Fix For: 10.1.3.Final, 11.0.0.Alpha2, 9.4.19.Final > > > Caches with BINARY storage accept {{byte[]}} keys, but add a prefix to indicate that the input was a {{byte[]}} and not a {{WrappedByteArray}}. > This happens in {{BinaryEncoder.toStorage()}}, before the segment of the key is computed, so the segment computed by the server is different from the segment computed by the client (based on the key without the prefix). > Since the client doesn't know (and shouldn't know) the server cache's storage type, the server should always compute the segment of the key based on the {{byte[]}} sent by the client. The simplest way to achieve that would be to make {{BinaryEncoder}} skip the marshalling for {{byte[]}}. > The only problem is that we don't want users to put in a {{WrappedByteArray}} and get back a {{byte[]}}, so we should disallow {{WrappedByteArray}} keys and values in {{Cache}} methods. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-11341) Client requests go to wrong server with binary storage

by Gustavo Fernandes (Jira)

[ https://issues.redhat.com/browse/ISPN-11341?page=com.atlassian.jira.plugi... ] Gustavo Fernandes updated ISPN-11341: ------------------------------------- Git Pull Request: https://github.com/infinispan/infinispan/pull/7944, https://github.com/infinispan/infinispan/pull/7945 (was: https://github.com/infinispan/infinispan/pull/7944) > Client requests go to wrong server with binary storage > ------------------------------------------------------ > > Key: ISPN-11341 > URL: https://issues.redhat.com/browse/ISPN-11341 > Project: Infinispan > Issue Type: Bug > Components: Core, Hot Rod, Server > Affects Versions: 9.4.18.Final, 10.1.2.Final, 11.0.0.Alpha1 > Reporter: Dan Berindei > Assignee: Gustavo Fernandes > Priority: Major > Fix For: 10.1.3.Final, 11.0.0.Alpha2, 9.4.19.Final > > > Caches with BINARY storage accept {{byte[]}} keys, but add a prefix to indicate that the input was a {{byte[]}} and not a {{WrappedByteArray}}. > This happens in {{BinaryEncoder.toStorage()}}, before the segment of the key is computed, so the segment computed by the server is different from the segment computed by the client (based on the key without the prefix). > Since the client doesn't know (and shouldn't know) the server cache's storage type, the server should always compute the segment of the key based on the {{byte[]}} sent by the client. The simplest way to achieve that would be to make {{BinaryEncoder}} skip the marshalling for {{byte[]}}. > The only problem is that we don't want users to put in a {{WrappedByteArray}} and get back a {{byte[]}}, so we should disallow {{WrappedByteArray}} keys and values in {{Cache}} methods. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-11341) Client requests go to wrong server with binary storage

by Gustavo Fernandes (Jira)

[ https://issues.redhat.com/browse/ISPN-11341?page=com.atlassian.jira.plugi... ] Gustavo Fernandes updated ISPN-11341: ------------------------------------- Status: Open (was: New) > Client requests go to wrong server with binary storage > ------------------------------------------------------ > > Key: ISPN-11341 > URL: https://issues.redhat.com/browse/ISPN-11341 > Project: Infinispan > Issue Type: Bug > Components: Core, Hot Rod, Server > Affects Versions: 9.4.18.Final, 10.1.2.Final, 11.0.0.Alpha1 > Reporter: Dan Berindei > Assignee: Gustavo Fernandes > Priority: Major > Fix For: 10.1.3.Final, 11.0.0.Alpha2, 9.4.19.Final > > > Caches with BINARY storage accept {{byte[]}} keys, but add a prefix to indicate that the input was a {{byte[]}} and not a {{WrappedByteArray}}. > This happens in {{BinaryEncoder.toStorage()}}, before the segment of the key is computed, so the segment computed by the server is different from the segment computed by the client (based on the key without the prefix). > Since the client doesn't know (and shouldn't know) the server cache's storage type, the server should always compute the segment of the key based on the {{byte[]}} sent by the client. The simplest way to achieve that would be to make {{BinaryEncoder}} skip the marshalling for {{byte[]}}. > The only problem is that we don't want users to put in a {{WrappedByteArray}} and get back a {{byte[]}}, so we should disallow {{WrappedByteArray}} keys and values in {{Cache}} methods. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-11341) Client requests go to wrong server with binary storage

by Gustavo Fernandes (Jira)

[ https://issues.redhat.com/browse/ISPN-11341?page=com.atlassian.jira.plugi... ] Gustavo Fernandes updated ISPN-11341: ------------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/7944 > Client requests go to wrong server with binary storage > ------------------------------------------------------ > > Key: ISPN-11341 > URL: https://issues.redhat.com/browse/ISPN-11341 > Project: Infinispan > Issue Type: Bug > Components: Core, Hot Rod, Server > Affects Versions: 9.4.18.Final, 10.1.2.Final, 11.0.0.Alpha1 > Reporter: Dan Berindei > Assignee: Gustavo Fernandes > Priority: Major > Fix For: 10.1.3.Final, 11.0.0.Alpha2, 9.4.19.Final > > > Caches with BINARY storage accept {{byte[]}} keys, but add a prefix to indicate that the input was a {{byte[]}} and not a {{WrappedByteArray}}. > This happens in {{BinaryEncoder.toStorage()}}, before the segment of the key is computed, so the segment computed by the server is different from the segment computed by the client (based on the key without the prefix). > Since the client doesn't know (and shouldn't know) the server cache's storage type, the server should always compute the segment of the key based on the {{byte[]}} sent by the client. The simplest way to achieve that would be to make {{BinaryEncoder}} skip the marshalling for {{byte[]}}. > The only problem is that we don't want users to put in a {{WrappedByteArray}} and get back a {{byte[]}}, so we should disallow {{WrappedByteArray}} keys and values in {{Cache}} methods. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-10900) Remove GlobalJmxStatisticsConfiguration.allowDuplicateDomains

by Nistor Adrian (Jira)

[ https://issues.redhat.com/browse/ISPN-10900?page=com.atlassian.jira.plugi... ] Nistor Adrian updated ISPN-10900: --------------------------------- Fix Version/s: 11.0.0.Alpha2 (was: 11.0.0.Final) > Remove GlobalJmxStatisticsConfiguration.allowDuplicateDomains > ------------------------------------------------------------- > > Key: ISPN-10900 > URL: https://issues.redhat.com/browse/ISPN-10900 > Project: Infinispan > Issue Type: Enhancement > Components: Configuration, JMX, reporting and management > Affects Versions: 10.0.1.Final > Reporter: Nistor Adrian > Priority: Critical > Fix For: 11.0.0.Alpha2 > > > This was deprecated in 10. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-10900) Remove GlobalJmxStatisticsConfiguration.allowDuplicateDomains

by Nistor Adrian (Jira)

[ https://issues.redhat.com/browse/ISPN-10900?page=com.atlassian.jira.plugi... ] Nistor Adrian reassigned ISPN-10900: ------------------------------------ Assignee: Nistor Adrian > Remove GlobalJmxStatisticsConfiguration.allowDuplicateDomains > ------------------------------------------------------------- > > Key: ISPN-10900 > URL: https://issues.redhat.com/browse/ISPN-10900 > Project: Infinispan > Issue Type: Enhancement > Components: Configuration, JMX, reporting and management > Affects Versions: 10.0.1.Final > Reporter: Nistor Adrian > Assignee: Nistor Adrian > Priority: Critical > Fix For: 11.0.0.Alpha2 > > > This was deprecated in 10. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-10900) Remove GlobalJmxStatisticsConfiguration.allowDuplicateDomains

by Nistor Adrian (Jira)

[ https://issues.redhat.com/browse/ISPN-10900?page=com.atlassian.jira.plugi... ] Nistor Adrian updated ISPN-10900: --------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/7943 > Remove GlobalJmxStatisticsConfiguration.allowDuplicateDomains > ------------------------------------------------------------- > > Key: ISPN-10900 > URL: https://issues.redhat.com/browse/ISPN-10900 > Project: Infinispan > Issue Type: Enhancement > Components: Configuration, JMX, reporting and management > Affects Versions: 10.0.1.Final > Reporter: Nistor Adrian > Priority: Critical > Fix For: 11.0.0.Final > > > This was deprecated in 10. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues February 2020