Re: Fate of master branch
I would not delete the branch without a new branch 'main' in its place On Jul 23, 2020 17:50, Owen Nichols wrote: Now that geode-examples' default branch has been changed to develop, and nothing further has been added to this discussion in a while, would anyone like to call for a vote to eliminate master branch from all geode projects? I would suggest holding this vote under 'code modification' rules[1] since we would be deleting code. Even though master should be substantially equivalent to latest release tag (currently rel/v1.12.0), git diff shows a few small differences. [1] a timeframe of at least 72 hours and a single -1 can veto, see https://www.apache.org/foundation/voting.html On 7/7/20, 6:33 PM, "Owen Nichols" wrote: Since the branch proposed for deletion is the default branch in geode-examples, you will need to file an ASF INFRA ticket to change that default. This is a great discussion thread, but ASF will require a [VOTE] thread to be cited. I am concerned about keeping it easy for someone who has just cloned geode to identify the most stable branch for their purpose. Before, they could always be assured `git checkout master` would give the flagship release. Now, new users will be immediately forced into some daunting detective work to sift through hundreds of haphazard tags and branches (a task even veteran committers frequently fail). I would strongly encourage an aggressive cleanup of unhelpful branches and tags, as Jacob proposed last month, before getting rid of the latest_release concept. On 7/7/20, 8:24 AM, "Blake Bender" wrote: Just to follow up on this: I've filed GEODE-8335 (https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-8335data=02%7C01%7Crhoughton%40vmware.com%7Ce8af678cedaa48c3f19408d82f6b846d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637311486111409381sdata=K%2Fs68rCpCgsc6Duzey9Iodf9gdUyE0AMAfGFzr2y4VA%3Dreserved=0) to track, respectfully (cowardly __ ) deferring to individuals who regularly contribute to the various Geode repos to handle it as they see fit. I'll take care of the several Geode Native associated repos. Thanks, Blake On 6/26/20, 12:21 PM, "Dave Barnes" wrote: +1 if we can override git’s ‘master’ default and establish ‘develop’ in its place. Otherwise renaming to ‘main’ would solve the problem with the negative connotations. NB: Mark, I think the 3-vote convention is just for back-ports to the release-branch. I don’t think of it as applying to a general discussion like this one. > On Jun 26, 2020, at 9:42 AM, Anthony Baker wrote: > > By just do it, I assume you mean: > > - Contact delete master where not needed > - Rename master to main when needed > - Contact INFRA to change the default branch > - Update README and CI jobs as needed > > Across *all* geode repos. > > > Anthony > > >> On Jun 26, 2020, at 9:38 AM, Mark Hanson wrote: >> >> +1 to delete. No good reason to keep it that I know of. I think I am the third +1 with no -1s so just do it. >> >> Thanks, >> Mark >> >>> On Jun 26, 2020, at 9:13 AM, Alexander Murmann wrote: >>> >>> +1 to deleting. Given we tag everything properly on the other branches, I >>> don't see the need for it either. >>> >>> On Fri, Jun 26, 2020 at 9:03 AM Alberto Bustamante Reyes >>> wrote: >>> +1 for deleting master branch. An also for updating the wiki page about branching that Alberto pointed out. De: Bruce Schuchardt Enviado: viernes, 26 de junio de 2020 17:37 Para: dev@geode.apache.org Asunto: Re: Fate of master branch Let's just delete it. I need to do that in my own repos as well. On 6/26/20, 8:05 AM, "Blake Bender" wrote: Apologies if this has been addressed already and I missed it. In keeping with other OSS projects, I believe it’s time we did something about removing the insensitive term master from Geode repositories. One choice a lot of projects appear to be going with is a simple rename from master • main. In our own case, however, master isn’t really in use for anything vital. We track releases with a tag and a branch to backport fixes to, and the develop branch is the “source of truth”
Re: Fate of master branch
Now that geode-examples' default branch has been changed to develop, and nothing further has been added to this discussion in a while, would anyone like to call for a vote to eliminate master branch from all geode projects? I would suggest holding this vote under 'code modification' rules[1] since we would be deleting code. Even though master should be substantially equivalent to latest release tag (currently rel/v1.12.0), git diff shows a few small differences. [1] a timeframe of at least 72 hours and a single -1 can veto, see https://www.apache.org/foundation/voting.html On 7/7/20, 6:33 PM, "Owen Nichols" wrote: Since the branch proposed for deletion is the default branch in geode-examples, you will need to file an ASF INFRA ticket to change that default. This is a great discussion thread, but ASF will require a [VOTE] thread to be cited. I am concerned about keeping it easy for someone who has just cloned geode to identify the most stable branch for their purpose. Before, they could always be assured `git checkout master` would give the flagship release. Now, new users will be immediately forced into some daunting detective work to sift through hundreds of haphazard tags and branches (a task even veteran committers frequently fail). I would strongly encourage an aggressive cleanup of unhelpful branches and tags, as Jacob proposed last month, before getting rid of the latest_release concept. On 7/7/20, 8:24 AM, "Blake Bender" wrote: Just to follow up on this: I've filed GEODE-8335 (https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-8335data=02%7C01%7Conichols%40vmware.com%7Cff4858c7e66c4a5dd66d08d822dedc70%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637297687860702537sdata=r07swTcgtBGXkdbGaZEVDwMSQrPL4RGqlG3Jc7wnQcE%3Dreserved=0) to track, respectfully (cowardly __ ) deferring to individuals who regularly contribute to the various Geode repos to handle it as they see fit. I'll take care of the several Geode Native associated repos. Thanks, Blake On 6/26/20, 12:21 PM, "Dave Barnes" wrote: +1 if we can override git’s ‘master’ default and establish ‘develop’ in its place. Otherwise renaming to ‘main’ would solve the problem with the negative connotations. NB: Mark, I think the 3-vote convention is just for back-ports to the release-branch. I don’t think of it as applying to a general discussion like this one. > On Jun 26, 2020, at 9:42 AM, Anthony Baker wrote: > > By just do it, I assume you mean: > > - Contact delete master where not needed > - Rename master to main when needed > - Contact INFRA to change the default branch > - Update README and CI jobs as needed > > Across *all* geode repos. > > > Anthony > > >> On Jun 26, 2020, at 9:38 AM, Mark Hanson wrote: >> >> +1 to delete. No good reason to keep it that I know of. I think I am the third +1 with no -1s so just do it. >> >> Thanks, >> Mark >> >>> On Jun 26, 2020, at 9:13 AM, Alexander Murmann wrote: >>> >>> +1 to deleting. Given we tag everything properly on the other branches, I >>> don't see the need for it either. >>> >>> On Fri, Jun 26, 2020 at 9:03 AM Alberto Bustamante Reyes >>> wrote: >>> +1 for deleting master branch. An also for updating the wiki page about branching that Alberto pointed out. De: Bruce Schuchardt Enviado: viernes, 26 de junio de 2020 17:37 Para: dev@geode.apache.org Asunto: Re: Fate of master branch Let's just delete it. I need to do that in my own repos as well. On 6/26/20, 8:05 AM, "Blake Bender" wrote: Apologies if this has been addressed already and I missed it. In keeping with other OSS projects, I believe it’s time we did something about removing the insensitive term master from Geode repositories. One choice a lot of projects appear to be going with is a simple rename from master • main. In our own case, however, master isn’t really in use for anything vital. We track releases with a tag and a branch to backport fixes to, and the develop branch is the “source of truth” latest-and-greatest version of the code. We could thus simply delete master with no
Re: [Proposal] Back-port doc fixes to support/1.13
Thanks, y'all. On Wed, Jul 22, 2020 at 5:01 PM Dick Cavender wrote: > +1 > > -Original Message- > From: Owen Nichols > Sent: Wednesday, July 22, 2020 4:59 PM > To: dev@geode.apache.org > Subject: Re: [Proposal] Back-port doc fixes to support/1.13 > > > > > +1 > > On July 22, 2020 at 3:43:16 PM PDT, Jinmei Liao wrote: > +1 > > On Jul 22, 2020 3:39 PM, Dave Barnes wrote: > I propose back-porting the following doc updates to Geode support/1.13 > (and 1.12, while we're at it): > > > - GEODE-2113: User Guide - p2p.HANDSHAKE_POOL_SIZE is obsolete, remove > from docs (code fixed in 1.9.0, docs fixed in 1.14.0) > > - GEODE-7628: Block jmx mbean creation when no security manager is > configured (docs) (code fixed in 1.12.0, docs fixed in 1.14.0) > > - GEODE-8308: Some formatting text visible in the docs (docs only, fixed in > 1.14.0) > > - GEODE-8363: Label Micrometer docs as experimental (docs only, fixed in > 1.14.0) > > - GEODE-8377: User Guide: GFSH GC command should be documented to use only > in non-production environments (docs only, fixed in 1.14.0) >
Odg: negative ActiveCQCount
Hi,
Thanks for the response!
Decrementing is happening on both servers, I add some check to decrement on
just one on which is incremented.
You can find changes on https://github.com/apache/geode/pull/5397.
BR,
Mario
Šalje: Anilkumar Gingade
Poslano: 17. srpnja 2020. 21:19
Prima: dev@geode.apache.org
Predmet: Re: negative ActiveCQCount
Mario,
Here is how the CQ register behaves:
When there is a single client and two servers.
When CQ is registered, with redundancy 0:
- On non-partitioned region, the CQ gets registered on one server, through
registerCQ().
- On partitioned region, if the region is hosted on both server, the CQ gets
registered on one server through registerCQ() and another through
FilterProfile.process*()
In the code, I do see the stat for active CQ getting incremented correctly for
both kind of registration.
Seems the decrementing is also happening, but need to verify. You can add logs
at CqServiceVSDStats.inc/dec methods to see if they are happening.
If this is working as expected, then it could be related to how gfsh/mbean
collecting the data and aggregating it.
Also, need to consider the cases where not all the nodes are cache servers.
-Anil.
On 7/17/20, 12:47 AM, "Mario Kevo" wrote:
Hi devs,
Just reminder if someone is familiar with this, or someone has some idea
how to resolve this issue.
Thanks and BR,
Mario
Šalje: Mario Kevo
Poslano: 7. srpnja 2020. 15:24
Prima: dev@geode.apache.org
Predmet: Odg: Odg: negative ActiveCQCount
Hi,
Thank you all for the response!
What I got for now is that when I register CQ on the one server it
processMessage to the other server through FilterProfile and in the message
opType is REGISTER_CQ.
In fromData() method in FilterProfile.java states following:
if (isCqOp(this.opType)) {
this.serverCqName = in.readUTF();
if (this.opType == operationType.REGISTER_CQ || this.opType ==
operationType.SET_CQ_STATE) {
this.cq = CqServiceProvider.readCq(in);
}
And there it register cq on the other server and not increment
cqActiveCount, which is ok as redundancy is 0. But it now has on both server
different instances of ServerCqImpl for the same cq. The ones created with
constructor with arguments at the execute cq and another with empty constructor
while deserializing the message with opType=REGISTER_CQ. For me this is ok as
we need to follow up all changes on both servers as maybe some fullfil CQ
condition on the other server. Correct me if I'm wrong.
But when it is going to close cq it executes it on both server, for me it
is ok that what is started should be closed. But in the close method we have
decrement if stateBeforeClosing is RUNNING. So it will be good if we can
somehow process cq_state of this ServerCqImpl instance which is created by
constructor with parameters before closing this created by deserialization.
Does anyone has an idea how to get this? Or some other idea to solve this
issue?
BR,
Mario
Šalje: Kirk Lund
Poslano: 1. srpnja 2020. 19:52
Prima: dev@geode.apache.org
Predmet: Re: Odg: negative ActiveCQCount
Yeah, https://issues.apache.org/jira/browse/GEODE-8293 sounds like a
statistic decrement bug for activeCqCount. Somewhere, each Server is
decrementing it once too many times.
You could find the statistics class containing activeCqCount and try adding
some debugging log statements or even add some breakpoints for debugger if
it's easily reproduced.
On Wed, Jul 1, 2020 at 5:52 AM Mario Kevo wrote:
> Hi Kirk, thanks for the response!
>
> I just realized that I wrongly describe the problem as I tried so many
> case. Sorry!
>
> We have system with two servers. If the redundancy is 0 then we have
> properly that on the first server is activeCqCount=1 and on the second is
> activeCqCount=0.
> After close CQ we got on first server activeCqCount=0 and on the second is
> activeCqCount=-1.
> gfsh>show metrics --categories=query
> Cluster-wide Metrics
>
> Category | Metric | Value
> | | -
> query| activeCQCount| -1
> | queryRequestRate | 0.0
>
>
> In case we set redundancy to 1 it increments properly as expected, on both
> servers by one. But when cq is closed we got on both servers
> activeCqCount=-1. And show metrics command has the following output
> gfsh>show metrics --categories=query
> Cluster-wide Metrics
>
> Category | Metric | Value
> | | -
> query| activeCQCount| -1
> | queryRequestRate | 0.0
>
> What I found is that when server register cq on one server it send message
> to other servers in the
Review needed for c++ client ticket
Hi, Could someone please take a look at this c++ client PR? https://github.com/apache/geode-native/pull/628 It solves a problem reported in the users list: https://markmail.org/thread/gajd4ok65w227fhl Thanks, Alberto B.
