You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@geode.apache.org by "Mark Hanson (Jira)" <ji...@apache.org> on 2019/12/30 18:51:09 UTC

[jira] [Closed] (GEODE-7039) Server recovery severely degrades client read traffic (no SingleHop no TX) on redundant partitioned persistent regions

     [ https://issues.apache.org/jira/browse/GEODE-7039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mark Hanson closed GEODE-7039.
------------------------------

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> Server recovery severely degrades client read traffic (no SingleHop no TX) on redundant partitioned persistent regions
> ----------------------------------------------------------------------------------------------------------------------
>
>                 Key: GEODE-7039
>                 URL: https://issues.apache.org/jira/browse/GEODE-7039
>             Project: Geode
>          Issue Type: Improvement
>          Components: client/server
>            Reporter: Mario Ivanac
>            Assignee: Mario Ivanac
>            Priority: Major
>              Labels: needs-review, pull-request-available
>             Fix For: 1.11.0
>
>          Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> Client not using single hop nor transactions is experiencing severe throttling from the cluster when getting data from a partitioned persistent region while server hosting one of the redundant buckets is recovering (in the process of image recovery). Get operation that have not landed on a server hosting the bucket will be proxied to other members that do have the bucket in a random fashion. This random picking has the nasty consequence that chosen server might be the one recovering now and the bucket is not yet ready (BucketNotFoundException), which means local server will handle ForceReattemptException by sleeping 100ms before another (random) attempt. This sleeping is devasteting for throughput observed by the client.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)