[
https://issues.apache.org/jira/browse/GEODE-9067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider updated GEODE-9067:
------------------------------------
Description:
If a client does a register-interest to a server that is a newer geode version
than its peer servers (which happens during a rolling upgrade), and the
InterestResultPolicy is KEYS_VALUES (the default), on a partitioned region,
then the way the server fetches values that are on the older peer servers is
slower than it needs to be. Instead of sending that server a single
FetchBulkEntries message, it does an individual get for each key. This
individual get can also go to a primary of secondary and for correctness
register-interest needs to do all its reads from the primary.
The code has been doing this ever since the first release of geode. Once all
the members have been restarted then register-interest does its reads
optimally. Since a register-interest that is in progress prevents its
subscription queue from draining, this slow register-interest could cause
memory issues or performance issues on the cluster. But it really depends on
how big the region is, how big the cluster is, and the rate at which operations
that go into the subscription queue are being done.
was:
If a client does a register-interest to a server that is a newer geode version
than its peer servers (which happens during a rolling upgrade), and the
InterestResultPolicy is KEYS_VALUES (the default), then the way the server
fetches values that are on the older peer servers is slower than it needs to
be. Instead of sending that server a single FetchBulkEntries message, it does
an individual get for each key. This individual get can also go to a primary of
secondary and for correctness register-interest needs to do all its reads from
the primary.
The code has been doing this ever since the first release of geode. Once all
the members have been restarted then register-interest does its reads
optimally. Since a register-interest that is in progress prevents its
subscription queue from draining, this slow register-interest could cause
memory issues or performance issues on the cluster. But it really depends on
how big the region is, how big the cluster is, and the rate at which operations
that go into the subscription queue are being done.
> register-interest done during rolling upgrade can take longer than needed
> -------------------------------------------------------------------------
>
> Key: GEODE-9067
> URL: https://issues.apache.org/jira/browse/GEODE-9067
> Project: Geode
> Issue Type: Improvement
> Components: client/server
> Affects Versions: 1.1.0, 1.10.0, 1.11.0, 1.12.0, 1.12.1, 1.13.0, 1.13.1
> Reporter: Darrel Schneider
> Priority: Major
>
> If a client does a register-interest to a server that is a newer geode
> version than its peer servers (which happens during a rolling upgrade), and
> the InterestResultPolicy is KEYS_VALUES (the default), on a partitioned
> region, then the way the server fetches values that are on the older peer
> servers is slower than it needs to be. Instead of sending that server a
> single FetchBulkEntries message, it does an individual get for each key. This
> individual get can also go to a primary of secondary and for correctness
> register-interest needs to do all its reads from the primary.
> The code has been doing this ever since the first release of geode. Once all
> the members have been restarted then register-interest does its reads
> optimally. Since a register-interest that is in progress prevents its
> subscription queue from draining, this slow register-interest could cause
> memory issues or performance issues on the cluster. But it really depends on
> how big the region is, how big the cluster is, and the rate at which
> operations that go into the subscription queue are being done.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
