[JBoss JIRA] (ISPN-11377) Change default flow control protocol back to UFC/MFC
by Dan Berindei (Jira)
Dan Berindei created ISPN-11377:
-----------------------------------
Summary: 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: 11.0.0.Alpha1, 10.1.2.Final, 9.4.18.Final
Reporter: Dan Berindei
Assignee: Dan Berindei
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:
--------------------------------
Status: Open (was: New)
> 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-11266) Split CacheTopologyControlCommand into individual commands
by Dan Berindei (Jira)
[ https://issues.redhat.com/browse/ISPN-11266?page=com.atlassian.jira.plugi... ]
Dan Berindei updated ISPN-11266:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Split CacheTopologyControlCommand into individual commands
> ----------------------------------------------------------
>
> Key: ISPN-11266
> URL: https://issues.redhat.com/browse/ISPN-11266
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core
> Affects Versions: 10.1.1.Final
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Priority: Major
> Fix For: 11.0.0.Alpha2
>
>
> Currently the {{CacheTopologyControlCommand}} uses a Type field and a switch statement to differentiate between various topology actions. This worked well for the old Externalizer approach, however it does not fit well with protobuf messages. Instead, the CacheTopologyControlCommand should be split into individual commands, e.g. a TopologyJoinCommand etc.
> This enables the logic of the command types to be separated, making it easier to maintain backwards compatibility in the long term. Each command will use a ProtoStream TypeId in the range of 1000 -> 3999, so the cost of two bytes is the same as the existing class ID plus enum Type that we require with the single CacheTopologyControlCommand.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month