[
https://issues.apache.org/jira/browse/GEODE-8800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17260076#comment-17260076
]
ASF GitHub Bot commented on GEODE-8800:
---------------------------------------
dschneider-pivotal commented on pull request #5879:
URL: https://github.com/apache/geode/pull/5879#issuecomment-755739949
My concern was that we can have a cluster in which all the members use SSL
but we might only have some of them configure slow receiver. But if that
happens then any of the members that configured slow receiver will fail to
start (with this change) so I think this current PR is enough without adding an
additional check in Connection.readHandshakeForSender
----------------------------------------------------------------
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:
[email protected]
> SSL is supposed to disable slower receiver feature
> --------------------------------------------------
>
> Key: GEODE-8800
> URL: https://issues.apache.org/jira/browse/GEODE-8800
> Project: Geode
> Issue Type: Bug
> Reporter: Xiaojian Zhou
> Assignee: Xiaojian Zhou
> Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> According to document, slow receiver options are disabled in systems using
> SSL
> (https://geode.apache.org/docs/guide/12/managing/monitor_tune/slow_receivers_managing.html).
>
> But TLS tests found it did not. If the cluster specified
> async-distribution-timeout to 1 aggressively, it will cause SSL test to hang.
> When distribution took longer than async-distribution-timeout, even d-ack
> region will be using async message queue, which conflicts with SSL.
>
> There're 2 alternatives to fix:
> (1) if SSL is enabled, and detected asyncDistributionTimeout>0, throw
> exception.
> (2) if SSL is enabled, force asyncDistributionTimeout to be 0 even it
> configed >0.
> We decide to take alternative-(1).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
