Re: Handling packet drop between sites

TCP behaves really poorly in the face of significant packet loss. You can look into tcp_retries1 and tcp_retries2 [1] for some explanations and tuning. Eventually, TCP will give up attempting to deliver a packet but this may take up to 30min depending on configuration. IIRC, it’s only at that

Re: [Discuss] Cache.close synchronous is not synchronous, but code still expects it to be....

Done and merged to develop. Thanks to Donal for helping me out. On Tue, Apr 28, 2020 at 3:21 PM Kirk Lund wrote: > In addition to PR precheckin jobs, I've also run a full regression against > the changes to make Cache.close() synchronous. There are failures, but I > have no idea if they are norm

Wiki edit permissions

My colleague and I are hoping to add a new RFC to the Geode wiki, but we need edit permissions to do it. I created an account on the wiki in the name of ring...@vmware.com, and Sarah did so with the address sabbe...@gmail.com. Who should we c

Re: Wiki edit permissions

Granting you permissions now... hang on a minute or two. On Wed, Apr 29, 2020 at 11:20 AM Raymond Ingles wrote: > My colleague and I are hoping to add a new RFC to the Geode wiki, but we > need edit permissions to do it. I created an account on the wiki in the > name of ring...@vmware.com

Re: Wiki edit permissions

You should both have permissions for creating and editing now. Thanks! On Wed, Apr 29, 2020 at 2:29 PM Kirk Lund wrote: > Granting you permissions now... hang on a minute or two. > > On Wed, Apr 29, 2020 at 11:20 AM Raymond Ingles > wrote: > >> My colleague and I are hoping to add a new RFC to

[DISCUSS] etiquette around breaking the pipeline

There are many ways a commit can break the Geode CI pipeline[1] despite our required PR checks, such as: - merge a PR that failed some non-required PR checks - merge a PR that last ran checks awhile ago and now interacts unexpectedly with other recent changes - merge a PR that fails Windows tests

Re: [DISCUSS] etiquette around breaking the pipeline

I am very pro-revert for breaking changes. The Benchmark or Windows tests being a culprit is unfortunate, since the PR pipeline cannot tell us about those, but thats the cost of our excellence :) On Wed, Apr 29, 2020 at 4:06 PM Owen Nichols wrote: > There are many ways a commit can break the Geo

Re: [DISCUSS] etiquette around breaking the pipeline

+1 for a quick revert from me. Preferably by the person whose commit is causing the issue, since I think it's healthy to encourage a stigma-free revert process and a sense of individual responsibility for the health of the pipeline, but theoretically by anyone, as long there's a concrete idea of wh

Re: [DISCUSS] etiquette around breaking the pipeline

Recent experience makes me lean towards quick revert as well. Takes the pressure off when trying to produce a fix and if done soon enough it is usually quite straightforward. From: Owen Nichols Sent: April 29, 2020 7:06 PM To: dev@geode.apache.org Subject: [DISC

Re: [DISCUSS] etiquette around breaking the pipeline

As far as I am aware, I think this is already a settled decision. The decision was quick revert. In almost every case the build is more important than the change. Thanks, Mark > On Apr 29, 2020, at 4:14 PM, Robert Houghton wrote: > > I am very pro-revert for breaking changes. The Benchmark or

Re: [DISCUSS] etiquette around breaking the pipeline

1. create the revert PR ASAP 2. work on the fix properly and create the fix PR 3. wait and merge whichever goes green and approved first. On Wed, Apr 29, 2020 at 7:13 PM Joris Melchior wrote: > Recent experience makes me lean towards quick revert as well. Takes the > pressure off when trying to

Re: [DISCUSS] etiquette around breaking the pipeline

Hi Mark, I’ve noticed some voluntarily quick reverts, which is awesome, but other times CI has stayed broken for days, so it doesn’t feel like we’re all on the same page. I cannot find anything in the wiki or dev list archives to suggest this was “settled” previously, but please share a link if