[jira] [Updated] (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 ] Mario Ivanac updated GEODE-7039: Fix Version/s: 1.11.0 > 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.2#803003)
[jira] [Updated] (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 ] Mario Ivanac updated GEODE-7039: Summary: Server recovery severely degrades client read traffic (no SingleHop no TX) on redundant partitioned persistent regions (was: Server recovery severely degrades client read traffic (no SingleHop no TX) on redundant partitioned regions) > 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 > > Client not using single hop nor transactions is experiencing severe > throttling from the cluster when getting data from a partitioned 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 (v7.6.14#76016)
[jira] [Updated] (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 ] Mario Ivanac updated GEODE-7039: Description: 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. (was: Client not using single hop nor transactions is experiencing severe throttling from the cluster when getting data from a partitioned 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.) > 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 > > 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 (v7.6.14#76016)
