[
https://issues.apache.org/jira/browse/GEODE-3948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16354718#comment-16354718
]
ASF subversion and git services commented on GEODE-3948:
--------------------------------------------------------
Commit 906ed2ae369f130f0d6186d636daa5eba0188f43 in geode's branch
refs/heads/feature/GEODE-3967 from [~bschuchardt]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=906ed2a ]
GEODE-3948 Improve CQ performance under flaky network conditions
This adds a new PoolFactory setting allowing subscription connections to
time out and initiate failover to a backup server. The new setting is
setSubscriptionTimeoutMultiplier:
A server has an inactivity monitor that ensures a message is sent to a client
at least once a
minute (60,000 milliseconds). If a subscription timeout multipler is set in the
client it
enables timing out of the subscription feed with failover to another server.
A value of zero (the default) disables timeouts
A value of one will time out the server connection after one of its ping
intervals (not
recommended)
A value of two or more will time out the server connection after that many ping
intervals have
elapsed
The client/server handshake is modified for clients having version 1.5 or
later. The server sends its ping-interval setting to the client. The client
then uses this and the multiplier to establish a read-timeout in the
CacheClientUpdater subscription processor.
Two tests are added to ensure that 1) the Message method that allows a
read to timeout functions correctly and 2) the CacheClientUpdater
correctly receives the multiplier setting.
This closes #1364
> Improve CQ performance under flaky network conditions
> -----------------------------------------------------
>
> Key: GEODE-3948
> URL: https://issues.apache.org/jira/browse/GEODE-3948
> Project: Geode
> Issue Type: Improvement
> Components: docs
> Reporter: Galen O'Sullivan
> Assignee: Joey McAllister
> Priority: Minor
> Labels: pull-request-available
> Time Spent: 2h
> Remaining Estimate: 0h
>
> Client CQ connections occasionally stop receiving messages and become blocked
> indefinitely.
> This can be caused by a server that hangs or dies without sending a close
> message, or by some firewalls.
> The client already gets ping messages from the server, but currently ignores
> them. Let's use those messages to detect a failed connection and close it.
> Probably the client should follow the same logic and send ping messages if it
> has sent no acks for a while, so that the server can also detect and close a
> broken connection.
> The timeout could be specified as a number and time interval, the ping
> interval and the number of missed pings after which to fail.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
