Re: [VOTE] Apache Geode 1.14.1.RC2

[Jianxia Chen]

+1

Build from source code
Run binary with some basic gfsh commands
Verified pipelines
Verified log4j version 2.15.0 in lib

On Fri, Dec 10, 2021 at 2:09 PM Owen Nichols  wrote:

> Hello Geode Dev Community,
>
> This is a release candidate for Apache Geode version 1.14.1.RC2.
> Thanks to all the community members for their contributions to this
> release!
>
> Please do a review and give your feedback, including the checks you
> performed.
>
> EXPEDITED Voting deadline:
> 3PM PST Sat, December 11 2021.
>
> Please note that we are voting upon the source tag:
> rel/v1.14.1.RC2
>
> Release notes:
>
> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.14.1
>
> Source and binary distributions:
> https://dist.apache.org/repos/dist/dev/geode/1.14.1.RC2/
>
> Maven staging repo:
> https://repository.apache.org/content/repositories/orgapachegeode-1118
>
> GitHub:
> https://github.com/apache/geode/tree/rel/v1.14.1.RC2
> https://github.com/apache/geode-examples/tree/rel/v1.14.1.RC2
> https://github.com/apache/geode-native/tree/rel/v1.14.1.RC2
> https://github.com/apache/geode-benchmarks/tree/rel/v1.14.1.RC2
>
> Pipelines:
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-14-main
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-14-rc
>
> Geode's KEYS file containing PGP keys we use to sign the release:
> https://github.com/apache/geode/blob/develop/KEYS
>
> Command to run geode-examples:
> ./gradlew -PgeodeReleaseUrl=
> https://dist.apache.org/repos/dist/dev/geode/1.14.1.RC2
> -PgeodeRepositoryUrl=
> https://repository.apache.org/content/repositories/orgapachegeode-1118
> build runAll
>
> Regards
> Owen Nichols
>

Concourse permissions

[Jianxia Chen]

Hi,

Can I have the permission to “fly intercept” into the concourse pipeline
container? I need it to debug a pull request pipeline failure. I tried “fly
login” and got an error: you are not a member of ‘main’.

Thanks,
Jianxia

Re: [VOTE] Apache Geode 1.14.0.RC2

[Jianxia Chen]

+1

* Use binary distribution to create region, put, get and persistent restart
* Verified the pipelines

On Tue, Aug 31, 2021 at 5:37 PM nabarun nag  wrote:

> Hello Geode Dev Community,
>
> This is a release candidate for Apache Geode version 1.14.0.RC2.
> Thanks to all the community members for their contributions to this
> release!
>
> Please do a review and give your feedback, including the checks you
> performed.
>
> Voting deadline: Please note that this is an expedited voting process
> 3PM PST Thur, September 02 2021.
>
> Please note that we are voting upon the source tag:
> rel/v1.14.0.RC2
>
> Release notes:
>
> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.14.0
>
> Source and binary distributions:
> https://dist.apache.org/repos/dist/dev/geode/1.14.0.RC2/
>
> Maven staging repo:
> https://repository.apache.org/content/repositories/orgapachegeode-1098
>
> GitHub:
> https://github.com/apache/geode/tree/rel/v1.14.0.RC2
> https://github.com/apache/geode-examples/tree/rel/v1.14.0.RC2
> https://github.com/apache/geode-native/tree/rel/v1.14.0.RC2
> https://github.com/apache/geode-benchmarks/tree/rel/v1.14.0.RC2
>
> Pipelines:
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-14-main
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-14-rc
>
> Geode's KEYS file containing PGP keys we use to sign the release:
> https://github.com/apache/geode/blob/develop/KEYS
>
> Command to run geode-examples:
> ./gradlew -PgeodeReleaseUrl=
> https://dist.apache.org/repos/dist/dev/geode/1.14.0.RC2
> -PgeodeRepositoryUrl=
> https://repository.apache.org/content/repositories/orgapachegeode-1098
> build runAll
>
> Regards
> Naburun Nag
>

[Proposal] Backport GEODE-9016 to 1.14, 1.13 and 1.12

[Jianxia Chen]

Hi,

I would like to backport the fix of GEODE-9016 to Geode 1.14, 1.13 and 1.12
branches. This would help resolve the NPE for certain cases of PutAll with
CQ.

Thanks,
Jianxia

Re: [Proposal] Backport GEODE-8886 to 1.14

[Jianxia Chen]

+1

On Fri, Mar 5, 2021 at 2:48 PM Mark Hanson  wrote:

> Hi All,
>
> It was discovered that there was a bug with unprocessed events under
> certain conditions with WAN specifically when old and new servers are vying
> for primary status.
> This fix will alleviate the problem in 1.14. The code that caused the
> problem is present in 1.14, hence the backport request.
>
> Thanks,
> Mark
>

Re: [PROPOSAL] backport GEODE-8998 to 1.14

[Jianxia Chen]

+1

On Thu, Mar 4, 2021 at 9:37 AM Darrel Schneider  wrote:

> I'm resending this request because my previous request was labelled as
> junk.
>
> I would like to backport GEODE-8998 to 1.14. If fixes an NPE
> that will cause the geode cluster to not be able to do any
> cluster messaging if thread monitoring is disabled.
> This bug has never been released so it would be nice
> keep it that way.
>
> https://issues.apache.org/jira/browse/GEODE-8998
>
>

Re: [Proposal] Backport GEODE-8671 to 1.14.x, 1.13.x and 1.12.x branches

[Jianxia Chen]

Thanks Owen!

On Wed, Mar 3, 2021 at 11:33 AM Owen Nichols  wrote:

> This was already added to the 1.14.0 blocker board on Feb 19 so you are
> free to backport it anytime, no need for additional proposal.  Additionally
> support/1.13 and support/1.12 do not have an active Geode release proposal
> or release manager so it's fine to bring fixes any time.
>
> On 3/3/21, 11:03 AM, "Mark Hanson"  wrote:
>
> +1
>
> On 3/3/21, 10:24 AM, "Jianxia Chen"  wrote:
>
> I would like to backport the fix of GEODE-8671, currently a 1.14
> blocker,
> to support/1.14, support 1.13 and support/1.12. This would help
> avoid Pdx
> corruption.
>
> Thanks,
> Jianxia
>
>
>

[Proposal] Backport GEODE-8671 to 1.14.x, 1.13.x and 1.12.x branches

[Jianxia Chen]

I would like to backport the fix of GEODE-8671, currently a 1.14 blocker,
to support/1.14, support 1.13 and support/1.12. This would help avoid Pdx
corruption.

Thanks,
Jianxia

Re: [Proposal] Backport GEODE-8958 into 1.14.x, 1.13.x, 1.12.x branches

[Jianxia Chen]

+1

On Wed, Mar 3, 2021 at 9:44 AM Darrel Schneider  wrote:

> +1
> 
> From: Xiaojian Zhou 
> Sent: Wednesday, March 3, 2021 9:43 AM
> To: dev@geode.apache.org 
> Subject: Re: [Proposal] Backport GEODE-8958 into 1.14.x, 1.13.x, 1.12.x
> branches
>
> +1
>
> On 3/1/21, 11:30 PM, "Owen Nichols"  wrote:
>
> That sounds a lot better than never expiring them if that does happen,
> I think this would be good to include.
>
> On 3/1/21, 2:41 PM, "Mark Hanson"  wrote:
>
> I would like to backport GEODE-8958 into previous release branches
> to alleviate a problem with tombstones if timestamps become corrupt for
> some reason.
>
> Thanks,
> Mark
>
>
>

Re: [DISCUSS] Geode 1.14

[Jianxia Chen]

A JIRA dashboard for 1.14.0 might help. Do we currently have one? I am not
sure whether there is some JIRA label introduced for the release of 1.14.0.
A quick search of open JIRA that affects 1.14.0 returns 29 tickets.

Jianxia

On Mon, Jan 4, 2021 at 3:43 PM Owen Nichols  wrote:

> How to tell whether develop is stable?
>
> From: Jacob Barrett 
> Date: Monday, January 4, 2021 at 8:59 AM
> To: dev@geode.apache.org 
> Subject: Re: [DISCUSS] Geode 1.14
> Keep develop stable, cut when we want to release. If develop isn’t stable
> we don’t cut until it is. There is no reason we can’t keep develop stable.
> If develop is stable then there is no reason we can’t release when we want
> to, whether that is a date or after a feature.
>
> -Jake
>
>
> > On Jan 4, 2021, at 7:22 AM, Anilkumar Gingade 
> wrote:
> >
> > My recommendation will be:
> > - Identify, Prioritize, Merge 1.14 related work
> > - Stabilize. Cut the branch and Stabilize again (to test any new changes
> added during first stabilize period)
> >
> > -Anil.
> >
> >
> > On 12/18/20, 2:26 PM, "Mark Hanson"  wrote:
> >
> >I support the cut on a predetermined date. But I will be ok with the
> Stabilize first approach, because I think that having a stable build is a
> prerequisite for any time based model. But like all things, this is a smell
> that we have to do this... The other thing is that specifying a date or a
> window of time in my opinion is crucial to ensuring freshly baked features
> are not merged until we cut the release. The window need not be very long a
> day or two as an example. With the volume of defects that we need to
> assess/fix maintaining control of develop seems important.  So I would
> propose that we give notice of when we are looking to cut the branch (once
> we have made adequate determinations for the defects).
> >
> >Thanks,
> >Mark
> >
> >On 12/18/20, 12:09 PM, "Owen Nichols"  wrote:
> >
> >To summarize this thread so far:
> >@Robert and @Jens seem to favor “cut then stabilize”
> >@Alexander and @John seem to favor “stabilize then cut”
> >No one seems to favor “cut on a predetermined date” (at least for
> 1.14)
> >
> >@John also made a creative suggestion that maybe 1.14 doesn’t
> have to be cut from latest develop…what if we cut it from support/1.13 and
> then backport just the redis changes (in parallel with continuing to
> stabilize what’s currently on develop into a 1.15 release).
> >
> >For now let’s try to proceed on the “stabilize then cut” plan.
> All committers, please hold off on merging big refactorings or other
> high-risk changes to develop until after the branch is cut.  Let’s regroup
> next month and try to clarify exactly which GEODE Jira tickets we need to
> focus on to make sure 1.14 is our best release.
> >
> >From: Owen Nichols 
> >Date: Tuesday, December 1, 2020 at 12:26 PM
> >To: dev@geode.apache.org 
> >Subject: Re: [DISCUSS] Geode 1.14
> >If someone wants to propose a list of must-fix Jira tickets
> before we can cut the branch, I see that as a shift from a time-based to
> feature-based branch-cut strategy.  Might be fun to try?
> >
> >Given the distributed nature of the Geode community, picking a
> date and sticking to it allows decentralized decision-making (each
> contributor can plan on their own what they can finish and/or how they can
> help get develop as stable as possible by that date).
> >
> >To answer your question: the current state of develop feels
> “pretty good” to me.  Knowing that only critical fixes will be allowed onto
> the branch once cut, the question is really about features.  It sounds like
> there is redis work we’d like to ship.  Anything else nearly-done we should
> considering waiting on?
> >
> >From: Alexander Murmann 
> >Date: Monday, November 30, 2020 at 11:57 AM
> >To: dev@geode.apache.org 
> >Subject: Re: [DISCUSS] Geode 1.14
> >Hi all,
> >
> >Thanks, Owen for reminding us all of this topic!
> >
> >I wonder how we feel about the state of develop right now. If we
> cut 1.14 right now, it will make it easier to stabilize and ship it.
> However, I see 21 open JIRA tickets affecting 1.14.0. It might be better to
> have an all-hands effort to address as much as possible on develop and then
> cut 1.14. If we shift all attention to 1.14, develop will likely never get
> better. I'd love to get closer to an always shippable develop branch. That
> should vastly reduce future release pain and make everyday development
> better as well.
> >
> >Thoughts?
> >
> >From: Jens Deppe 
> >Sent: Wednesday, November 25, 2020 20:11
> >To: dev@geode.apache.org 
> >Subject: Re: [DISCUSS] Geode 1.14
> >
> >Hi Owen,
> >
> >Thanks for starting this conversation and especially for
> volunteering as Release Manager!
> >
> >

Re: [Proposal] Backport GEODE-8422 to support/1.13

[Jianxia Chen]

+1

On Wed, Aug 12, 2020 at 4:41 PM Mark Hanson  wrote:

> Hi All,
>
> We have found a case where tombstones were being cleared when the region
> was not initialized. This was causing some test failures and potential
> field failures. We would like to put this into support/1.13.
>
> Thanks,
> Mark
>

Re: [PROPOSAL] backport GEODE-8394 to support/1.13

[Jianxia Chen]

+1

On Fri, Aug 7, 2020 at 10:35 AM Anilkumar Gingade 
wrote:

> This causes a large object to be partially (corrupt data) stored in cache
> instead of throwing an exception.
>
>

Re: [PROPOSAL] backport GEODE-6564 to support/1.13

[Jianxia Chen]

+1

On Mon, Aug 3, 2020 at 4:13 PM Darrel Schneider  wrote:

> GEODE-6564 is a memory leak that has impacted users so it would be good to
> have it in 1.13. It has a simple, low risk, fix.
>

Re: [PROPOSAL] port GEODE-8385 changes to support/1.13

[Jianxia Chen]

+1

On Wed, Jul 29, 2020 at 8:04 AM Bruce Schuchardt  wrote:

> This concerns a hang during recovery from disk.  The problem was
> introduced in 1.13.
>
> https://issues.apache.org/jira/browse/GEODE-8385
>
>

Re: [PROPOSAL] Add windows jobs to PR checks

[Jianxia Chen]

+1 to add Windows tests to the PR pipeline. It may take longer time to run
(up to 4 hours). But consider the time wasted on reverting, fixing and
resubmitting, if there is a failure after merging to the develop branch. It
is better to add the Windows tests to the PR pipeline. We can reevaluate
and optimize the pipeline if the long running time is truly a concern.

On Thu, Jun 25, 2020 at 9:29 AM Kirk Lund  wrote:

> I merged some new AcceptanceTests to develop after having my PR go GREEN.
> But now these tests are failing in Windows.
>
> I'd like to propose that we add the Windows jobs to our PR checks if we
> plan to keep testing on Windows in CI.
>
> Please vote or discuss.
>
> Thanks,
> Kirk
>

Re: [VOTE] Backporting of GEODE-8261 to 1.13 release branch.

[Jianxia Chen]

+1

On Fri, Jun 19, 2020 at 12:16 PM Nabarun Nag  wrote:

> Hi Geode devs,
>
> Requesting vote to backport of GEODE-8261 to 1.13
>
> Why?
> This commit fixes an issue with servers throwing null pointer exceptions
> while a member is being shutdown and registering interest is in process.
>
> SHA
> 720a4caea2ddb22296aa3225fc5264d2096cdf20
>
>
> Regards
> Nabarun
>

Re: [PROPOSAL] back port fix for GEODE-8251 to support branches

[Jianxia Chen]

+1

On Fri, Jun 19, 2020 at 8:46 AM Jinmei Liao  wrote:

> Need one more vote 
> 
> From: Bruce Schuchardt 
> Sent: Thursday, June 18, 2020 3:43 PM
> To: dev@geode.apache.org 
> Subject: Re: [PROPOSAL] back port fix for GEODE-8251 to support branches
>
> +1
>
> On 6/18/20, 3:24 PM, "Jinmei Liao"  wrote:
>
> The fix for this issue
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-8251data=02%7C01%7Cjiliao%40vmware.com%7C76cb38f955c84ade5d9f08d813d91e9c%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637281170530289424sdata=a8fdpKs4MUwr90bE0oOgobk5so840TJhK47%2FJFE0JDs%3Dreserved=0
> is needed on support 1.13 branch in order for rolling upgrade to work from
> 1.12 to 1.13.
>
> Thanks!
>
> Jinmei
>
>

Re: [PROPOSAL] backport PR #5250 to support/1.13

[Jianxia Chen]

+1

On Tue, Jun 16, 2020 at 3:24 PM Bruce Schuchardt  wrote:

> This PR has been merged to develop.  It fixes a problem with the previous
> commit for GEODE-8144 that caused performance degradation when TLS is
> enabled between servers.  I have run perf tests and verified that it fixes
> the problem.
>
> It’s a small change that makes a big difference…
> https://github.com/apache/geode/pull/5250
>
>

Re: [DISCUSSION] Stop using the Geode Repository for Feature/WIP Branches

[Jianxia Chen]

The contributor has to add you as a collaborator of the contributor’s fork.

On Wed, Jun 3, 2020 at 5:05 PM Dave Barnes  wrote:

> Suppose I want to commit to another contributor's fork. How can they grant
> me permission to do so? (This is a common predicament for me when I'm
> reviewing doc PRs.)
>
>
> On Wed, Jun 3, 2020 at 2:04 PM Xiaojian Zhou  wrote:
>
> > We have discussed that when in Common team. The current solution worked
> > perfectly.
> >
> > One person will merge the develop into feature/GEODE-7665 (which
> > conceptually can be anyone. I did 2 times) every week. Now Naba is taking
> > the responsibility to do the weekly merge. He did great!
> >
> > Fork will cause many other issues, it will still need a person to
> maintain
> > it. I feel fork is only suitable for a work that will be finished within
> a
> > week.
> >
> > Regards
> > Gester
> >
> > On 6/2/20, 4:41 PM, "Nabarun Nag"  wrote:
> >
> > I don’t think it is right to make the open source Geode Community to
> > work on my personal fork
> >
> > Regards
> > Naba
> >
> >
> > -Original Message-
> > From: Mark Hanson 
> > Sent: Tuesday, June 2, 2020 4:35 PM
> > To: dev@geode.apache.org
> > Subject: Re: [DISCUSSION] Stop using the Geode Repository for
> > Feature/WIP Branches
> >
> > While I am not 100% sure, I understand your thoughts here, I am
> pretty
> > sure I do. We have already done such work in a branch in a fork
> (Micrometer
> > work). The only real gotcha was that there needed to be one person at
> least
> > as a collaborator, in case of vacations and such.
> >
> > All of the things you have specified are possible within the confines
> > of a fork.
> >
> > Thanks,
> > Mark
> >
> > On 6/2/20, 4:29 PM, "Nabarun Nag"  wrote:
> >
> > - We are maintaining feature/GEODE-7665 which is the feature
> > branch for PR clear work on which multiple developers are working on.
> > - We are maintaining this in Geode repository.
> > - All sub-tasks of GEODE-7665 are merged into this feature
> branch.
> > - Anyone in the Geode community can work on any subtask
> > - This is a long running, and a massive feature development which
> > is manipulating core code on Apache Geode. Hence all work is pushed to
> the
> > feature branch to keep develop isolated from a regression introduced in
> PR
> > clear work.
> > - We have previously used release flags for Lucene work which we
> > found to be inefficient and unnecessary extra work.
> >
> > We vote that PR clear feature branch be maintained in the Geode
> > Repository as this is a long running, massive effort involving everyone
> > from the community.
> >
> > When the PR clear tasks are completed, the branch will be
> > rigorously tested and then squash merged into develop and the feature
> > branch will be deleted.
> >
> >
> > Regards
> > Naba
> >
> > -Original Message-
> > From: Jacob Barrett 
> > Sent: Tuesday, June 2, 2020 3:43 PM
> > To: dev@geode.apache.org
> > Subject: [DISCUSSION] Stop using the Geode Repository for
> > Feature/WIP Branches
> >
> > I know this has been brought up multiple times without
> resolution.
> > I want us resolve to ban the use of Geode repository for work in
> progress,
> > feature branches, or any other branches that are not release or support
> > branches. There is no reason given the nature of GitHub why you can’t
> fork
> > the repository to contribute.
> >
> > * Work done on these branches results in the ASF bots updating
> the
> > associated JIRAs and email blasting all of us with your work.
> >
> > * People don’t clean up these branches, which leads to a mess of
> > branches on everyones clones and in the UI.
> >
> > * All your intermediate commits get synced to the repo, which
> > bloats the repo for everyone else. Even your commits you rebase over and
> > force push are left in the repo. When you delete your branch these
> commits
> > are not removed. There is no way for us to prune unreferenced commits.
> > Nobody else needs your commits outside of what was merged to a production
> > branch.
> >
> > If anyone has a use case for working directly from Geode repo
> that
> > can’t work from a fork please post it here so we can resolve.
> >
> > Thanks,
> > Jake
> >
> >
> >
> >
> >
> >
>

Re: [DISCUSSION] Stop using the Geode Repository for Feature/WIP Branches

[Jianxia Chen]

For features that need collaboration among multiple contributors/committers
and extended amount of time, using a feature branch in ASF repo is more
convenient, compared to using a fork. Other than that, using a fork is
preferable.

Thanks,
Jianxia

On Wed, Jun 3, 2020 at 11:06 AM Mark Hanson  wrote:

> There is also one other positive of having it in the ASF repo which is
> visibility to other people committing breaking changes. That might help
> with coordination.
>
> Thanks,
> Mark
>
>
> On 6/3/20, 10:51 AM, "Nabarun Nag"  wrote:
>
> Thank you Aaron.
>
> We will continue using feature branch in ASF repo for development of
> PR clear work.
>
> Yes, we can manage access to personal/non-ASF hosted forks but I do
> not have the list of people to set that up. This is automatic default when
> we create in ASF repositories.
>
> Also, I am vehemently against using one person's personal fork for
> massive collaborative open source feature development involving the entire
> Geode Community. Every collaborator should have the same rights on the
> source code rather than a gatekeeper.
>
> But again, I agree it is wrong to use the repo to create short living
> branches with single contributor and then not cleaning up after the branch
> is merged.
>
> Regards
> Naba
>
> -Original Message-
> From: Aaron Lindsey 
> Sent: Wednesday, June 3, 2020 8:50 AM
> To: dev@geode.apache.org
> Subject: Re: [DISCUSSION] Stop using the Geode Repository for
> Feature/WIP Branches
>
> I'm on board with using forks — the exception being Naba's use case
> for long running feature branches where developers actually want to open a
> PR into the branch
>
> 
> From: Bruce Schuchardt 
> Sent: Wednesday, June 3, 2020 8:23 AM
> To: dev@geode.apache.org
> Subject: Re: [DISCUSSION] Stop using the Geode Repository for
> Feature/WIP Branches
>
> Jake, you make some good points that I hadn't considered before.
>
> On 6/2/20, 3:42 PM, "Jacob Barrett"  wrote:
>
> I know this has been brought up multiple times without resolution.
> I want us resolve to ban the use of Geode repository for work in progress,
> feature branches, or any other branches that are not release or support
> branches. There is no reason given the nature of GitHub why you can’t fork
> the repository to contribute.
>
> * Work done on these branches results in the ASF bots updating the
> associated JIRAs and email blasting all of us with your work.
>
> * People don’t clean up these branches, which leads to a mess of
> branches on everyones clones and in the UI.
>
> * All your intermediate commits get synced to the repo, which
> bloats the repo for everyone else. Even your commits you rebase over and
> force push are left in the repo. When you delete your branch these commits
> are not removed. There is no way for us to prune unreferenced commits.
> Nobody else needs your commits outside of what was merged to a production
> branch.
>
> If anyone has a use case for working directly from Geode repo that
> can’t work from a fork please post it here so we can resolve.
>
> Thanks,
> Jake
>
>
>
>
>
>
>

Re: [PROPOSAL]: GEODE-8071 to support/1.12 and support/1.13

[Jianxia Chen]

+1

On Thu, May 7, 2020 at 7:47 AM Ju@N  wrote:

> Hello devs,
>
> I'd like to propose bringing GEODE-8071 [1] to the *support/1.12* and
> *support/1.13* branches.
> The bug was introduced in Geode 1.8.0 and, long story short, prevents
> locators from gracefully shutting down whenever a rebalance operation is
> launched from gfsh (doesn't matter whether the rebalance is successful or
> not).
> The fix has been merged into develop through commit
> d8e86cb720c054b154a16cc88fee88e73db709f3 [2].
> Best regards.
>
> [1]: https://issues.apache.org/jira/browse/GEODE-8071
> [2:]
>
> https://github.com/apache/geode/commit/d8e86cb720c054b154a16cc88fee88e73db709f3
>
> --
> Ju@N
>

Re: Weird (Memcached) IntegrationJUnitTest failure

[Jianxia Chen]

When I tried, I didn't use the refactored waitIfClosing(). I used the
original waitUntilClosed() and the if statements surrounding it.

On Fri, May 1, 2020 at 3:40 PM Jianxia Chen  wrote:

> I don't know the exact root cause. This failure can be consistently
> reproduced in my local environment.
>
> I tried the following:
>
> 1. Revert the changes of GemFireCacheImpl
> 2. Introduced the new doClose() method as in your pull request
> 3. Change the return statements to return true or false accordingly as in
> your pull request.
>
> The test IntegrationJUnitTest passes.
>
> -Jianxia
>
> On Fri, May 1, 2020 at 1:42 PM Kirk Lund  wrote:
>
>> This is from a PR in which I extracted doClose from
>> GemFireCacheImpl.close(). Any ideas what would cause
>> *java.lang.NoClassDefFoundError:
>> Could not initialize class
>> org.apache.geode.internal.cache.TXCommitMessage*?
>>
>> org.apache.geode.memcached.IntegrationJUnitTest > testGemFireProperty
>> FAILED
>> *java.lang.NoClassDefFoundError: Could not initialize class
>> org.apache.geode.internal.cache.TXCommitMessage*
>> at
>>
>> org.apache.geode.internal.cache.GemFireCacheImpl.doClose(GemFireCacheImpl.java:2357)
>> at
>>
>> org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:2066)
>> at
>>
>> org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:1934)
>> at
>>
>> org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:1924)
>> at
>>
>> org.apache.geode.memcached.IntegrationJUnitTest.testGemFireProperty(IntegrationJUnitTest.java:58)
>>
>> My PR only has changes to GemFireCacheImpl and GemFireCacheImplCloseTest.
>>
>> -Kirk
>>
>

Re: Weird (Memcached) IntegrationJUnitTest failure

[Jianxia Chen]

I don't know the exact root cause. This failure can be consistently
reproduced in my local environment.

I tried the following:

1. Revert the changes of GemFireCacheImpl
2. Introduced the new doClose() method as in your pull request
3. Change the return statements to return true or false accordingly as in
your pull request.

The test IntegrationJUnitTest passes.

-Jianxia

On Fri, May 1, 2020 at 1:42 PM Kirk Lund  wrote:

> This is from a PR in which I extracted doClose from
> GemFireCacheImpl.close(). Any ideas what would cause
> *java.lang.NoClassDefFoundError:
> Could not initialize class
> org.apache.geode.internal.cache.TXCommitMessage*?
>
> org.apache.geode.memcached.IntegrationJUnitTest > testGemFireProperty
> FAILED
> *java.lang.NoClassDefFoundError: Could not initialize class
> org.apache.geode.internal.cache.TXCommitMessage*
> at
>
> org.apache.geode.internal.cache.GemFireCacheImpl.doClose(GemFireCacheImpl.java:2357)
> at
>
> org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:2066)
> at
>
> org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:1934)
> at
>
> org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:1924)
> at
>
> org.apache.geode.memcached.IntegrationJUnitTest.testGemFireProperty(IntegrationJUnitTest.java:58)
>
> My PR only has changes to GemFireCacheImpl and GemFireCacheImplCloseTest.
>
> -Kirk
>

Re: Reconfiguring our notifications and more

[Jianxia Chen]

+1

On Tue, Apr 21, 2020 at 8:54 AM Anthony Baker  wrote:

> I’d like a quick round of feedback so we can stop the dev@ spamming [1].
>
> ASF has implemented a cool way to give projects control of lots of things
> [2].  In short, you provide a .asf.yml in each and every GitHub repo to
> control lots of interesting things.  For us the most immediately relevant
> are:
>
> notifications:
>   commits: comm...@geode.apache.org
>   issues:  iss...@geode.apache.org
>   pullrequests:  notificati...@geode.apache.org
>   jira_options: link label comment
>
> I’d like to commit this to /develop and cherry-pick over to /master ASAP.
> Later on we can explore the website and GitHub sections.  Let me know what
> you think.
>
> Anthony
>
>
> [1] https://issues.apache.org/jira/browse/INFRA-20156
> [2]
> https://cwiki.apache.org/confluence/display/INFRA/.asf.yaml+features+for+git+repositories#id-.asf.yamlfeaturesforgitrepositories-Notificationsettingsforrepositories

Re: [PROPOSAL]: Include GEODE-7789 in Release 1.12.0

[Jianxia Chen]

+1

On Thu, Feb 13, 2020 at 7:11 AM Udo Kohlmeyer  wrote:

> +1
>
> On 2/13/20 6:49 AM, Jinmei Liao wrote:
> > +1
> >
> > On Thu, Feb 13, 2020, 6:47 AM Owen Nichols  wrote:
> >
> >> +1
> >>
> >> On Thu, Feb 13, 2020 at 3:05 AM Nabarun Nag  wrote:
> >>
> >>> +1
> >>>
> >>> On Thu, Feb 13, 2020 at 2:09 AM Ju@N  wrote:
> >>>
>  Hello devs,
> 
>  I'd like to include the fix for GEODE-7789 [1] in release 1.12.0.
>  The change prevents a performance degradation introduced in Geode
> 1.11,
> >>> it
>  basically shows up on clusters where there's at least one client with
>  subscription enabled.
>  The SHA is 71e156a55228d89efafd048e1533debba606c064 [2].
>  Best regards.
> 
>  [1]: https://issues.apache.org/jira/browse/GEODE-7789
>  [2]:
> 
> 
> >>
> https://github.com/apache/geode/commit/71e156a55228d89efafd048e1533debba606c064
>  --
>  Ju@N
> 
>

Re: [PROPOSAL]: Include GEODE-7756 in Release 1.12.0

[Jianxia Chen]

+1

On Thu, Feb 13, 2020 at 6:50 AM Jinmei Liao  wrote:

> +1
>
> On Thu, Feb 13, 2020, 6:47 AM Owen Nichols  wrote:
>
> > +1
> >
> > On Thu, Feb 13, 2020 at 3:38 AM Ju@N  wrote:
> >
> > > Hello devs,
> > >
> > > I'd like to include the fix for GEODE-7756 [1] in release 1.12.0.
> > > The change prevents a performance degradation introduced in Geode 1.11
> > > through to the OQL Method Invocation authorization feature, for which
> > > regular cache operations are slowed down on clusters where there are
> > > running CQs.
> > > The SHA is 5dd7a8420bbe43657abc82e5b8d073eb01b51d8d [2].
> > > Best regards.
> > >
> > > [1]: https://issues.apache.org/jira/browse/GEODE-7756
> > > [2]:
> > >
> > >
> >
> https://github.com/apache/geode/commit/5dd7a8420bbe43657abc82e5b8d073eb01b51d8d
> > >
> > > --
> > > Ju@N
> > >
> >
>

Re: Release 1.8.0 pipeline issue

[Jianxia Chen]

It sounds like we shouldn't have this job in the pipeline at all, since we
only publish snapshots for the community on develop (and not release
branches). I suggest you ignore it for now, and Patrick said he would look
into deleting it properly tomorrow.

On Thu, Nov 15, 2018 at 10:47 AM Alexander Murmann 
wrote:

> Hi community,
>
> With the fix that Owen contributed the build on the 1.8.0 release pipeline
> is passing. However, the PublishArtifacts job is failing with the below
> error:
>
> > > Failed to publish publication 'maven' to repository 'maven'
> >  <
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-8-0-main/jobs/PublishArtifacts/builds/1#L5bea432b:881
> >
> >> Failed to deploy artifacts: Could not transfer artifact
> org.apache.geode:geode-dunit:jar:1.8.0 from/to remote (
> https://repository.apache.org/service/local/staging/deploy/maven2): Could
> not write to resource
> 'org/apache/geode/geode-dunit/1.8.0/geode-dunit-1.8.0.jar'
> >
> >
> Is someone able to look at this who is more familiar with that particular
> job?
>
> Thanks!
>

Re: [discuss] Should we evaluate at commit messages as part of PR review?

[Jianxia Chen]

There is a good article on this topic that Anthony recommended a while ago:
http://chris.beams.io/posts/git-commit/

Jianxia

On Wed, Sep 12, 2018 at 4:30 PM Michael Stolz  wrote:

> +1 to descriptive commit messages
>
> Done well they will save time on every post commit access to that commit.
>
> --
> Mike Stolz
> Principal Engineer - Gemfire Product Manager
> Mobile: 631-835-4771
>
> On Sep 12, 2018 4:15 PM, "Alexander Murmann"  wrote:
>
> > While our wiki page primarily calls out the 50/74 rule which is
> important,
> > my bigger concern is in that I'd love to see commit messages that explain
> > why a change was made. Sometimes that information is in the reference
> JIRA
> > ticket, but not always. Especially with bug fixes we tend to not explain
> > what actually caused the bug and how the code changes address it. It's
> also
> > nice to minimize moving back and forth between editor and browsing JIRA
> and
> > even better not to have to read 20+ messages long comment threads about a
> > bug in JIRA to find out what the problem was. No hard rule can make sure
> we
> > are doing that right, only human reviewers and care can. I don't think
> it's
> > actually any extra work, since we are already reading the PR description
> > and commit messages when we are doing a PR review. How else can you
> > understand the PR? In fact better commit messages should save time here
> and
> > not steal it.
> >
> > I totally agree that we don't always need a long text. "Fix typo in XYZ
> > output" is totally fine. Both the why and what are obvious.
> >
> > On Wed, Sep 12, 2018 at 4:07 PM, Helena Bales  wrote:
> >
> > > I'm a fan of having useful commit messages. I would prefer this to be
> > > another checkbox in our list of 6 things to do for Pull Requests as
> > opposed
> > > to something that is strictly enforced. There are cases where a simple
> > > one-liner commit message is enough. I personally use commit messages
> > often,
> > > even when looking back at my own work. Additionally, I think it is a
> > useful
> > > exercise as it forces the dev to think back on the original problem and
> > > think about how the solution addresses that.
> > >
> > > tl;dr -- +1 for commit messages
> > >
> > > ~Helena
> > >
> > > On Wed, Sep 12, 2018 at 11:50 AM, Pulkit Chandra 
> > > wrote:
> > >
> > > > Have we thought about git hooks as a way to enforce policy
> > > > https://git-scm.com/book/en/v2/Customizing-Git-An-Example-
> > > > Git-Enforced-Policy
> > > > ?
> > > >
> > > > *Pulkit Chandra*
> > > >
> > > >
> > > > On Wed, Sep 12, 2018 at 2:46 PM Alexander Murmann <
> amurm...@pivotal.io
> > >
> > > > wrote:
> > > >
> > > > > Hi everyone,
> > > > >
> > > > > We have a wiki page
> > > > >  > > Commit+Message+Format
> > > > >
> > > > > that discusses why good commit messages matter and links to a even
> > > better
> > > > > article on the topic. In addition to what's described in those
> > > documents,
> > > > > better commit messages also would make it easier to have good PR
> > > > messages.
> > > > > Good commit and PR messages also provide more context to the
> reviewer
> > > who
> > > > > in turn now can do a better job at reviewing the pull request.
> > > > >
> > > > > Looking at our git log gives me the impression that we aren't
> always
> > > > living
> > > > > up to that standard. In fact we frequently aren't even close.
> > > > >
> > > > > I propose taking clear and well formatted commit messages into
> > account
> > > as
> > > > > part of our PR review process. Lacking commit messages can be just
> as
> > > bad
> > > > > as bad naming in our code.
> > > > >
> > > > > Thoughts?
> > > > >
> > > >
> > >
> >
>

Re: Instructions for Setting Up IntelliJ

[Jianxia Chen]

+1 to revise the wiki to link to README.md/BUILDING.md

On Tue, Sep 11, 2018 at 3:22 PM Ryan McMahon  wrote:

> Hi all,
>
> I am looking to add more comprehensive instructions for how to bring Geode
> into IntelliJ.  I've written the instructions but am now looking at where
> to put them.
>
> There appears to be duplicate information in these sections of the Geode
> wiki and the README.md/BUILDING.md in the Geode Git repository.
>
>
> https://cwiki.apache.org/confluence/display/GEODE/Getting+Started+for+Geode+Developers
>
> https://cwiki.apache.org/confluence/display/GEODE/Building+and+Running+Geode+from+Source
>
> I'm a fan of one source of truth, but I wanted to see if anyone felt
> strongly about where the information lives.  I propose we revise the wiki
> to simply link to the README.md/BUILDING.md and eliminate the duplicate
> information (how to run gradlew, etc).  Any thoughts?
>
> Thanks,
> Ryan
>

Re: Revert recent Gradle upgrade

[Jianxia Chen]

The long build time might be due to the old version of gradle daemon (pre
4.8). Try kill it if you have one running.

On Thu, Jun 21, 2018 at 1:42 PM Jacob Barrett  wrote:

> I am suffering quite the opposite with 8.4 and seeing much longer build
> times and rebuilds on things that have not changed.
>
> > On Jun 21, 2018, at 12:47 PM, Jens Deppe  wrote:
> >
> > I have a fix which I think will resolve the current problems:
> > https://github.com/apache/geode/pull/2074 (currently running
> precheckin).
> >
> > It does require deferring IntelliJ's build to gradle (which may slow some
> > tasks down a bit) but will at least let you continue to work.
> >
> > The perceived slowdown should be mitigated to a large part by Gradle
> 4.8's
> > ability to cache build results.
> >
> > I'd encourage you to grab the diff and see if it helps.
> >
> > --Jens
> >
> >> On Thu, Jun 21, 2018 at 12:19 PM, Kirk Lund  wrote:
> >>
> >> I think we should revert the recent Gradle upgrade. This change
> apparently
> >> causes IntelliJ to not be able to build Geode which prevents us from
> >> running any Tests in the IDE.
> >>
> >> I'd prefer to fix how IntelliJ works with our project but we cannot be
> >> without the ability to debug tests. I don't know enough to fix this
> >> problem.
> >>
> >> If we can't fix the ability to run Tests in the IDE, then we should
> revert
> >> this commit:
> >>
> >> commit 7685375ea7229ad0e0fc9ea188cccfa56ff7d8ef
> >> Author: Robert Houghton <
> 32176082+rhoughton-pi...@users.noreply.github.com
> >>>
> >> Date:   Tue Jun 19 08:28:51 2018 -0700
> >>
> >>GEODE-4791: Enable gradle 4.8 for features and futureproofing (#2050)
> >>
> >>Enable:
> >>* Java 10 (when ready)
> >>* remove deprecated configuration settings
> >>* build-cache
> >>* incremental
> >>* Update classpath/srcpath logic
> >>
> >>Disable:
> >>* parallel (to fix Tomcat tests bind issues)
> >>
> >>Signed-off-by: Robert Houghton 
> >>Signed-off-by: Jens Deppe 
> >>Signed-off-by: Robert Houghton 
> >>Signed-off-by: Jens Deppe 
> >>
>

Re: [DISCUSS] CI improvements

[Jianxia Chen]

+1 to switch to Concourse
+1 As a first step we could run both CI systems side-by-side and see how
the Concourse approach works for our project.

On Fri, Oct 6, 2017 at 7:08 AM, Anthony Baker  wrote:

> Hi all,
>
> I’d like to propose the following that we switch our continuous
> integration (CI) system from Jenkins [1] to Concourse [2].  I suggest
> this because we continue to experience a significant number of
> environmental-related test failures.
>
> These issues include CPU interference from other Jenkins jobs on the
> same host, running out of disk space, port conflicts, and other
> gremlins.  The net effect is that we are only getting 1-2 successful
> builds per month.  Certainly not all test failures can be traced back
> to environmental issues.  However, internal testing on isolated VM’s
> shows a combined success rate of about 3X higher compared to ASF
> Jenkins for the same tests.  This is still definitely NotAwesome, but
> removing environmental factors will let us focus on stabilizing flaky
> tests.
>
> Concourse is an Apache-licensed open source CI system based on
> pipelines.  The pipelines are defined in a YML file containing job
> definitions—inputs, outputs, resources, and tasks.  A task is simply a
> bash script that returns 0/1 for success/failure.  A web UI displays
> build status.  Importantly, each job runs inside an isolated
> container.  The containers are load-balanced across a pool of workers.
> For an example of a build pipeline, see [3] for the pipeline used to
> build concourse itself.
>
> A Concourse environment is deployed and managed in cloud environments
> through bosh [4].  Pivotal has agreed to donate AWS and/or GCP compute
> and storage resources as well as manage the infrastructure.  These
> project resources would be available for use by all committers and
> community members regardless of corporate affiliations.  Note that
> AFAIK there is no explicit requirement to host CI on ASF
> infrastructure—unlike for critical project resources such as source
> code, mailing lists, and issue tracking.
>
> The source for the pipeline and job scripts would reside within the
> geode-* repos.  Geode committers would be able to modify those, same
> as with our .travis.yml scripts.  All test results and build artifacts
> would be publicly viewable just like with our Jenkins build output
> today.  Requests for admin assistance would go through the dev@geode
> mailing list.
>
> Thoughts?  As a first step we could run both CI systems side-by-side
> and see how the Concourse approach works for our project.
>
> Thanks,
> Anthony
>
>
> [1] https://builds.apache.org/job/Geode-nightly/
> [2] https://concourse.ci
> [3] https://ci.concourse.ci
> [4] https://bosh.io
>

Re: What to do with the geode-spark-connector

[Jianxia Chen]

I prefer option A: Move it into it's own repository, with it's own release
cycle.

On Wed, May 24, 2017 at 5:17 PM, Dan Smith  wrote:

> Our geode-spark-connector needs some work. It's currently building against
> geode 1.0.0-incubating, because it has it's own separate build process.
> It's also somewhat out of date, we're building against spark 1.3. Is anyone
> actually using the spark connector?
>
> I think we need to get the spark connector out of the main geode repo since
> people are currently modifying code in the connector without even compiling
> it, since it's not linked into the gradle build.
>
> What do the geode devs think we should do with the geode-spark-connector?
>
> A) Move it into it's own repository, with it's own release cycle
> B) Delete it
> C) Other??
>
> -Dan
>

Re: Orphaned Server processes

[Jianxia Chen]

Thanks Jinmei! You are right. I missed that.

Thanks,
Jianxia

On Wed, Apr 5, 2017 at 12:24 PM, Jinmei Liao <jil...@pivotal.io> wrote:

> for your #1, there is a --properties-file option when you do "start
> server".
>
> On Wed, Apr 5, 2017 at 12:20 PM, Jianxia Chen <jc...@pivotal.io> wrote:
>
> > Thank you William!
> >
> > I tried with it. It works. But there is something tricky in order to
> start
> > the embedded locator.
> >
> > 1) the gemfire.properties file has to be in the right place, either in
> the
> > server directory or home directory. Looks like this is not documented.
> > I was trying to specify the properties file in gfsh when starting server.
> > However, there is no such option for `start server` command. There is an
> > `--security-properties-file` option though, for gfsecurity.properties.
> >
> > 2) jmx-manager has to be true. Otherwise the embedded locator won't
> start.
> > The server can be started successfully though.
> >
> > Thanks,
> > Jianxia
> >
> > On Wed, Apr 5, 2017 at 11:03 AM, William Markito Oliveira <
> > william.mark...@gmail.com> wrote:
> >
> > > Jianxia, you can set the property "start-locator" in gemfire.properties
> > as
> > > below...  So the server then will have an embedded locator.
> > >
> > > http://geode.apache.org/docs/guide/11/reference/topics/
> > > gemfire_properties.html
> > > start-locator If set, automatically starts a locator in the current
> > process
> > > when the member connects to the distributed system and stops the
> locator
> > > when the member disconnects.
> > >
> > > To use, specify the locator with an optional address or host
> > specification
> > > and a required port number, in one of these formats:
> > >
> > > start-locator=address[port1]
> > >
> > > start-locator=port1
> > >
> > > If you only specify the port, the address assigned to the member is
> used
> > > for the locator.
> > >
> > > If not already there, this locator is automatically added to the list
> of
> > > locators in this set of gemfire properties.
> > > *not set*
> > >
> > > On Wed, Apr 5, 2017 at 12:50 PM, Jianxia Chen <jc...@pivotal.io>
> wrote:
> > >
> > > > Hi Darrel,
> > > >
> > > > How to configure a colocated locator in the same server process? Just
> > > > curious. What I understand is that the locator is in its own process.
> > > >
> > > > Thanks,
> > > > Jianxia
> > > >
> > > > On Wed, Apr 5, 2017 at 10:36 AM, Darrel Schneider <
> > dschnei...@pivotal.io
> > > >
> > > > wrote:
> > > >
> > > > > I like the idea of servers failing to start if no locator exists.
> > > > > But does a use case for a server with no locator exist? What about
> > ease
> > > > of
> > > > > development?
> > > > >
> > > > > I could see that it would be easier to start just a single server
> > > process
> > > > > instead of two (locator and server). But for this use case couldn't
> > the
> > > > > developer just configure a colocated locator in the same server
> > > process?
> > > > > This would have the benefit of the clients during development and
> > > > > production using a locator consistently.
> > > > >
> > > > > Is it true that the server with no locator will never have any peer
> > > > members
> > > > > in its cluster?
> > > > > Clients can still connect to this singleton server by being
> > configured
> > > > with
> > > > > the server host and port instead of the locator.
> > > > >
> > > > >
> > > > > On Wed, Apr 5, 2017 at 10:24 AM, Jinmei Liao <jil...@pivotal.io>
> > > wrote:
> > > > >
> > > > > > Without connecting to the server, I think you can still stop it
> by
> > > > > > specifying --pid or --dir in "stop server" command.
> > > > > >
> > > > > > On Wed, Apr 5, 2017 at 10:15 AM, Udo Kohlmeyer <
> > > ukohlme...@pivotal.io>
> > > > > > wrote:
> > > > > >
> > > > > > > Hey there,
> > > > > > >
> > > > > > > Current Geode allows a user to start a server without being
> > linked
> > > > to a
> > > > > > > Locator. Which in itself is not incorrect, but once started
> there
> > > is
> > > > no
> > > > > > way
> > > > > > > to connect to that server to manage it.
> > > > > > >
> > > > > > > I know that we have taken an opinionated view that member
> > discovery
> > > > can
> > > > > > > only now happen through a locator and that multicast is an
> option
> > > > > > anymore.
> > > > > > >
> > > > > > > Can we take the same opinionated view where we either state
> that
> > > > unless
> > > > > > > your server is connecting to a locator, it cannot be started OR
> > we
> > > > fix
> > > > > > the
> > > > > > > default behavior where we can start a server but cannot connect
> > to
> > > > it,
> > > > > > and
> > > > > > > have to resort to "kill -9" commands to kill the server.
> > > > > > >
> > > > > > > --Udo
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Cheers
> > > > > >
> > > > > > Jinmei
> > > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > ~/William
> > >
> >
>
>
>
> --
> Cheers
>
> Jinmei
>

Re: Orphaned Server processes

[Jianxia Chen]

Thank you William!

I tried with it. It works. But there is something tricky in order to start
the embedded locator.

1) the gemfire.properties file has to be in the right place, either in the
server directory or home directory. Looks like this is not documented.
I was trying to specify the properties file in gfsh when starting server.
However, there is no such option for `start server` command. There is an
`--security-properties-file` option though, for gfsecurity.properties.

2) jmx-manager has to be true. Otherwise the embedded locator won't start.
The server can be started successfully though.

Thanks,
Jianxia

On Wed, Apr 5, 2017 at 11:03 AM, William Markito Oliveira <
william.mark...@gmail.com> wrote:

> Jianxia, you can set the property "start-locator" in gemfire.properties as
> below...  So the server then will have an embedded locator.
>
> http://geode.apache.org/docs/guide/11/reference/topics/
> gemfire_properties.html
> start-locator If set, automatically starts a locator in the current process
> when the member connects to the distributed system and stops the locator
> when the member disconnects.
>
> To use, specify the locator with an optional address or host specification
> and a required port number, in one of these formats:
>
> start-locator=address[port1]
>
> start-locator=port1
>
> If you only specify the port, the address assigned to the member is used
> for the locator.
>
> If not already there, this locator is automatically added to the list of
> locators in this set of gemfire properties.
> *not set*
>
> On Wed, Apr 5, 2017 at 12:50 PM, Jianxia Chen <jc...@pivotal.io> wrote:
>
> > Hi Darrel,
> >
> > How to configure a colocated locator in the same server process? Just
> > curious. What I understand is that the locator is in its own process.
> >
> > Thanks,
> > Jianxia
> >
> > On Wed, Apr 5, 2017 at 10:36 AM, Darrel Schneider <dschnei...@pivotal.io
> >
> > wrote:
> >
> > > I like the idea of servers failing to start if no locator exists.
> > > But does a use case for a server with no locator exist? What about ease
> > of
> > > development?
> > >
> > > I could see that it would be easier to start just a single server
> process
> > > instead of two (locator and server). But for this use case couldn't the
> > > developer just configure a colocated locator in the same server
> process?
> > > This would have the benefit of the clients during development and
> > > production using a locator consistently.
> > >
> > > Is it true that the server with no locator will never have any peer
> > members
> > > in its cluster?
> > > Clients can still connect to this singleton server by being configured
> > with
> > > the server host and port instead of the locator.
> > >
> > >
> > > On Wed, Apr 5, 2017 at 10:24 AM, Jinmei Liao <jil...@pivotal.io>
> wrote:
> > >
> > > > Without connecting to the server, I think you can still stop it by
> > > > specifying --pid or --dir in "stop server" command.
> > > >
> > > > On Wed, Apr 5, 2017 at 10:15 AM, Udo Kohlmeyer <
> ukohlme...@pivotal.io>
> > > > wrote:
> > > >
> > > > > Hey there,
> > > > >
> > > > > Current Geode allows a user to start a server without being linked
> > to a
> > > > > Locator. Which in itself is not incorrect, but once started there
> is
> > no
> > > > way
> > > > > to connect to that server to manage it.
> > > > >
> > > > > I know that we have taken an opinionated view that member discovery
> > can
> > > > > only now happen through a locator and that multicast is an option
> > > > anymore.
> > > > >
> > > > > Can we take the same opinionated view where we either state that
> > unless
> > > > > your server is connecting to a locator, it cannot be started OR we
> > fix
> > > > the
> > > > > default behavior where we can start a server but cannot connect to
> > it,
> > > > and
> > > > > have to resort to "kill -9" commands to kill the server.
> > > > >
> > > > > --Udo
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Cheers
> > > >
> > > > Jinmei
> > > >
> > >
> >
>
>
>
> --
> ~/William
>

Re: Orphaned Server processes

[Jianxia Chen]

Hi Darrel,

How to configure a colocated locator in the same server process? Just
curious. What I understand is that the locator is in its own process.

Thanks,
Jianxia

On Wed, Apr 5, 2017 at 10:36 AM, Darrel Schneider 
wrote:

> I like the idea of servers failing to start if no locator exists.
> But does a use case for a server with no locator exist? What about ease of
> development?
>
> I could see that it would be easier to start just a single server process
> instead of two (locator and server). But for this use case couldn't the
> developer just configure a colocated locator in the same server process?
> This would have the benefit of the clients during development and
> production using a locator consistently.
>
> Is it true that the server with no locator will never have any peer members
> in its cluster?
> Clients can still connect to this singleton server by being configured with
> the server host and port instead of the locator.
>
>
> On Wed, Apr 5, 2017 at 10:24 AM, Jinmei Liao  wrote:
>
> > Without connecting to the server, I think you can still stop it by
> > specifying --pid or --dir in "stop server" command.
> >
> > On Wed, Apr 5, 2017 at 10:15 AM, Udo Kohlmeyer 
> > wrote:
> >
> > > Hey there,
> > >
> > > Current Geode allows a user to start a server without being linked to a
> > > Locator. Which in itself is not incorrect, but once started there is no
> > way
> > > to connect to that server to manage it.
> > >
> > > I know that we have taken an opinionated view that member discovery can
> > > only now happen through a locator and that multicast is an option
> > anymore.
> > >
> > > Can we take the same opinionated view where we either state that unless
> > > your server is connecting to a locator, it cannot be started OR we fix
> > the
> > > default behavior where we can start a server but cannot connect to it,
> > and
> > > have to resort to "kill -9" commands to kill the server.
> > >
> > > --Udo
> > >
> > >
> >
> >
> > --
> > Cheers
> >
> > Jinmei
> >
>

gfsh question

[Jianxia Chen]

Does gfsh support PUT with user defined class? For example, if I have a
Parent class, and I do the following:

```
put --key=10 --key-class=java.math.BigInteger --value-class=demo.entity.Parent
--value=('id':10, 'name':'jun', 'income':123) --region=/Parent
```

which gives the following error:

```
Message : Error in converting JSON Couldn't convert JSON to Object of type
class java.math.BigInteger
Result  : false
```

Thanks,
Jianxia

Re: Top-Level Project Tasks Completed

[Jianxia Chen]

Great!

On Tue, Dec 6, 2016 at 10:34 AM, Mark Bretl  wrote:

> As an update, the GitHub mirror is online and available at
> https://github.com/apache/geode.
>
> --Mark
>
> On Mon, Dec 5, 2016 at 5:13 PM, Mark Bretl  wrote:
>
> > Hi Everyone,
> >
> > The Apache INFRA team has completed the Top-Level Project for Apache
> Geode.
> >
> > Summary of Changes:
> > - Website is https://geode.apache.org/
> > - Mailing lists (dev, user, private) now have suffix of '@
> geode.apache.org
> > '
> > - GitHub URL is now https://github.com/apache/geode (It has error of 404
> > now, but should resolve in about 7 hours)
> >
> > If you have any issues, please email the Dev list at '
> dev@geode.apache.org'
> > so we can investigate.
> >
> > Thanks to everyone for their patience. Now, let's move forward with
> > growing this community and completing another release!
> >
> > Best Regards,
> >
> > Mark Bretl
> > V.P. Apache Geode
> >
>