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