[jira] [Commented] (GEODE-8374) ViewAckTimeout Configuration
[
https://issues.apache.org/jira/browse/GEODE-8374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17296580#comment-17296580
]
ASF GitHub Bot commented on GEODE-8374:
---
davebarnes97 merged pull request #6099:
URL: https://github.com/apache/geode/pull/6099
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> ViewAckTimeout Configuration
>
>
> Key: GEODE-8374
> URL: https://issues.apache.org/jira/browse/GEODE-8374
> Project: Geode
> Issue Type: Bug
> Components: docs, membership
>Reporter: Juan Ramos
>Assignee: Dave Barnes
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> We have the following within our docs (point 4
> [here|https://geode.apache.org/docs/guide/112/managing/network_partitioning/how_network_partitioning_management_works.html]):
> {noformat}
> In the first phase, the membership coordinator sends out a view preparation
> message to all members and waits 12 seconds for a view preparation ack return
> message from each member. If the coordinator does not receive an ack message
> from a member within 12 seconds, the coordinator attempts to connect to the
> member’s failure-detection socket. If the coordinator cannot connect to the
> member’s failure-detection socket, the coordinator declares the member dead
> and starts the membership view protocol again from the beginning.
> {noformat}
> These 12 seconds refer to {{viewAckTimeout}} property within the
> {{GMSJoinLeave}} class, and it’s calculated as follows:
> {code:java|title=GMSJoinLeave.java|borderStyle=solid}
> long ackCollectionTimeout = config.getMemberTimeout() * 2 * 12437 / 1;
> if (ackCollectionTimeout < 1500) {
> ackCollectionTimeout = 1500;
> } else if (ackCollectionTimeout > 12437) {
> ackCollectionTimeout = 12437;
> }
> ackCollectionTimeout = Long
> .getLong(GeodeGlossary.GEMFIRE_PREFIX + "VIEW_ACK_TIMEOUT",
> ackCollectionTimeout)
> .longValue();
> this.viewAckTimeout = ackCollectionTimeout;
> {code}
> So, the actual value for the {{viewAckTimeout}} is {{member-timeout * 2}}
> seconds, but it can’t be lower than {{1.5}}, neither higher than {{12}},
> unless the user configures the undocumented {{VIEW_ACK_TIMEOUT}} system
> property (for which I haven't found any tests nor anything related, meaning
> that _*it shouldn't be used at all as we don't know what the negative
> implications - if any - might be*_).
> We should either remove the internal check and allow the user to fully
> configure this property ({{member-timeout * 2}} by default) or add better
> documentation about this internal timeout and why it shouldn't be changed
> outside of the fixed interval.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8374) ViewAckTimeout Configuration
[
https://issues.apache.org/jira/browse/GEODE-8374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17296583#comment-17296583
]
ASF subversion and git services commented on GEODE-8374:
Commit df0d3c0271c822ed7614951f36f8d59f35ab0637 in geode's branch
refs/heads/develop from Dave Barnes
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=df0d3c0 ]
GEODE-8374 - User Guide: ViewAckTimeout Configuration (#6099)
> ViewAckTimeout Configuration
>
>
> Key: GEODE-8374
> URL: https://issues.apache.org/jira/browse/GEODE-8374
> Project: Geode
> Issue Type: Bug
> Components: docs, membership
>Reporter: Juan Ramos
>Assignee: Dave Barnes
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> We have the following within our docs (point 4
> [here|https://geode.apache.org/docs/guide/112/managing/network_partitioning/how_network_partitioning_management_works.html]):
> {noformat}
> In the first phase, the membership coordinator sends out a view preparation
> message to all members and waits 12 seconds for a view preparation ack return
> message from each member. If the coordinator does not receive an ack message
> from a member within 12 seconds, the coordinator attempts to connect to the
> member’s failure-detection socket. If the coordinator cannot connect to the
> member’s failure-detection socket, the coordinator declares the member dead
> and starts the membership view protocol again from the beginning.
> {noformat}
> These 12 seconds refer to {{viewAckTimeout}} property within the
> {{GMSJoinLeave}} class, and it’s calculated as follows:
> {code:java|title=GMSJoinLeave.java|borderStyle=solid}
> long ackCollectionTimeout = config.getMemberTimeout() * 2 * 12437 / 1;
> if (ackCollectionTimeout < 1500) {
> ackCollectionTimeout = 1500;
> } else if (ackCollectionTimeout > 12437) {
> ackCollectionTimeout = 12437;
> }
> ackCollectionTimeout = Long
> .getLong(GeodeGlossary.GEMFIRE_PREFIX + "VIEW_ACK_TIMEOUT",
> ackCollectionTimeout)
> .longValue();
> this.viewAckTimeout = ackCollectionTimeout;
> {code}
> So, the actual value for the {{viewAckTimeout}} is {{member-timeout * 2}}
> seconds, but it can’t be lower than {{1.5}}, neither higher than {{12}},
> unless the user configures the undocumented {{VIEW_ACK_TIMEOUT}} system
> property (for which I haven't found any tests nor anything related, meaning
> that _*it shouldn't be used at all as we don't know what the negative
> implications - if any - might be*_).
> We should either remove the internal check and allow the user to fully
> configure this property ({{member-timeout * 2}} by default) or add better
> documentation about this internal timeout and why it shouldn't be changed
> outside of the fixed interval.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-8374) ViewAckTimeout Configuration
[
https://issues.apache.org/jira/browse/GEODE-8374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dave Barnes resolved GEODE-8374.
Resolution: Fixed
> ViewAckTimeout Configuration
>
>
> Key: GEODE-8374
> URL: https://issues.apache.org/jira/browse/GEODE-8374
> Project: Geode
> Issue Type: Bug
> Components: docs, membership
>Reporter: Juan Ramos
>Assignee: Dave Barnes
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> We have the following within our docs (point 4
> [here|https://geode.apache.org/docs/guide/112/managing/network_partitioning/how_network_partitioning_management_works.html]):
> {noformat}
> In the first phase, the membership coordinator sends out a view preparation
> message to all members and waits 12 seconds for a view preparation ack return
> message from each member. If the coordinator does not receive an ack message
> from a member within 12 seconds, the coordinator attempts to connect to the
> member’s failure-detection socket. If the coordinator cannot connect to the
> member’s failure-detection socket, the coordinator declares the member dead
> and starts the membership view protocol again from the beginning.
> {noformat}
> These 12 seconds refer to {{viewAckTimeout}} property within the
> {{GMSJoinLeave}} class, and it’s calculated as follows:
> {code:java|title=GMSJoinLeave.java|borderStyle=solid}
> long ackCollectionTimeout = config.getMemberTimeout() * 2 * 12437 / 1;
> if (ackCollectionTimeout < 1500) {
> ackCollectionTimeout = 1500;
> } else if (ackCollectionTimeout > 12437) {
> ackCollectionTimeout = 12437;
> }
> ackCollectionTimeout = Long
> .getLong(GeodeGlossary.GEMFIRE_PREFIX + "VIEW_ACK_TIMEOUT",
> ackCollectionTimeout)
> .longValue();
> this.viewAckTimeout = ackCollectionTimeout;
> {code}
> So, the actual value for the {{viewAckTimeout}} is {{member-timeout * 2}}
> seconds, but it can’t be lower than {{1.5}}, neither higher than {{12}},
> unless the user configures the undocumented {{VIEW_ACK_TIMEOUT}} system
> property (for which I haven't found any tests nor anything related, meaning
> that _*it shouldn't be used at all as we don't know what the negative
> implications - if any - might be*_).
> We should either remove the internal check and allow the user to fully
> configure this property ({{member-timeout * 2}} by default) or add better
> documentation about this internal timeout and why it shouldn't be changed
> outside of the fixed interval.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8374) ViewAckTimeout Configuration
[
https://issues.apache.org/jira/browse/GEODE-8374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols updated GEODE-8374:
Labels: blocks-1.14.0 pull-request-available (was: pull-request-available)
> ViewAckTimeout Configuration
>
>
> Key: GEODE-8374
> URL: https://issues.apache.org/jira/browse/GEODE-8374
> Project: Geode
> Issue Type: Bug
> Components: docs, membership
>Reporter: Juan Ramos
>Assignee: Dave Barnes
>Priority: Minor
> Labels: blocks-1.14.0, pull-request-available
> Fix For: 1.14.0
>
>
> We have the following within our docs (point 4
> [here|https://geode.apache.org/docs/guide/112/managing/network_partitioning/how_network_partitioning_management_works.html]):
> {noformat}
> In the first phase, the membership coordinator sends out a view preparation
> message to all members and waits 12 seconds for a view preparation ack return
> message from each member. If the coordinator does not receive an ack message
> from a member within 12 seconds, the coordinator attempts to connect to the
> member’s failure-detection socket. If the coordinator cannot connect to the
> member’s failure-detection socket, the coordinator declares the member dead
> and starts the membership view protocol again from the beginning.
> {noformat}
> These 12 seconds refer to {{viewAckTimeout}} property within the
> {{GMSJoinLeave}} class, and it’s calculated as follows:
> {code:java|title=GMSJoinLeave.java|borderStyle=solid}
> long ackCollectionTimeout = config.getMemberTimeout() * 2 * 12437 / 1;
> if (ackCollectionTimeout < 1500) {
> ackCollectionTimeout = 1500;
> } else if (ackCollectionTimeout > 12437) {
> ackCollectionTimeout = 12437;
> }
> ackCollectionTimeout = Long
> .getLong(GeodeGlossary.GEMFIRE_PREFIX + "VIEW_ACK_TIMEOUT",
> ackCollectionTimeout)
> .longValue();
> this.viewAckTimeout = ackCollectionTimeout;
> {code}
> So, the actual value for the {{viewAckTimeout}} is {{member-timeout * 2}}
> seconds, but it can’t be lower than {{1.5}}, neither higher than {{12}},
> unless the user configures the undocumented {{VIEW_ACK_TIMEOUT}} system
> property (for which I haven't found any tests nor anything related, meaning
> that _*it shouldn't be used at all as we don't know what the negative
> implications - if any - might be*_).
> We should either remove the internal check and allow the user to fully
> configure this property ({{member-timeout * 2}} by default) or add better
> documentation about this internal timeout and why it shouldn't be changed
> outside of the fixed interval.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8374) ViewAckTimeout Configuration
[
https://issues.apache.org/jira/browse/GEODE-8374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17296625#comment-17296625
]
ASF subversion and git services commented on GEODE-8374:
Commit fbef0554e024e50103804bed52734692f074edcb in geode's branch
refs/heads/support/1.14 from Dave Barnes
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=fbef055 ]
GEODE-8374 - User Guide: ViewAckTimeout Configuration (#6099)
(cherry picked from commit df0d3c0271c822ed7614951f36f8d59f35ab0637)
> ViewAckTimeout Configuration
>
>
> Key: GEODE-8374
> URL: https://issues.apache.org/jira/browse/GEODE-8374
> Project: Geode
> Issue Type: Bug
> Components: docs, membership
>Reporter: Juan Ramos
>Assignee: Dave Barnes
>Priority: Minor
> Labels: blocks-1.14.0, pull-request-available
> Fix For: 1.14.0
>
>
> We have the following within our docs (point 4
> [here|https://geode.apache.org/docs/guide/112/managing/network_partitioning/how_network_partitioning_management_works.html]):
> {noformat}
> In the first phase, the membership coordinator sends out a view preparation
> message to all members and waits 12 seconds for a view preparation ack return
> message from each member. If the coordinator does not receive an ack message
> from a member within 12 seconds, the coordinator attempts to connect to the
> member’s failure-detection socket. If the coordinator cannot connect to the
> member’s failure-detection socket, the coordinator declares the member dead
> and starts the membership view protocol again from the beginning.
> {noformat}
> These 12 seconds refer to {{viewAckTimeout}} property within the
> {{GMSJoinLeave}} class, and it’s calculated as follows:
> {code:java|title=GMSJoinLeave.java|borderStyle=solid}
> long ackCollectionTimeout = config.getMemberTimeout() * 2 * 12437 / 1;
> if (ackCollectionTimeout < 1500) {
> ackCollectionTimeout = 1500;
> } else if (ackCollectionTimeout > 12437) {
> ackCollectionTimeout = 12437;
> }
> ackCollectionTimeout = Long
> .getLong(GeodeGlossary.GEMFIRE_PREFIX + "VIEW_ACK_TIMEOUT",
> ackCollectionTimeout)
> .longValue();
> this.viewAckTimeout = ackCollectionTimeout;
> {code}
> So, the actual value for the {{viewAckTimeout}} is {{member-timeout * 2}}
> seconds, but it can’t be lower than {{1.5}}, neither higher than {{12}},
> unless the user configures the undocumented {{VIEW_ACK_TIMEOUT}} system
> property (for which I haven't found any tests nor anything related, meaning
> that _*it shouldn't be used at all as we don't know what the negative
> implications - if any - might be*_).
> We should either remove the internal check and allow the user to fully
> configure this property ({{member-timeout * 2}} by default) or add better
> documentation about this internal timeout and why it shouldn't be changed
> outside of the fixed interval.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
