Re: [VOTE] Apache Geode 1.14.1.RC2

+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

Concourse permissions

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

+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

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

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

+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

Re: [PROPOSAL] backport GEODE-8998 to 1.14

+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

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

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

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

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

+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

Re: [DISCUSS] Geode 1.14

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

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

+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

+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

+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

+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

+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

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

+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 >

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

+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

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

+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

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

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

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

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

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

+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

Re: Weird (Memcached) IntegrationJUnitTest failure

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 envir

Re: Weird (Memcached) IntegrationJUnitTest failure

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

Re: Reconfiguring our notifications and more

+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

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

+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

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

+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

Re: Release 1.8.0 pipeline issue

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

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

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. > >

Re: Instructions for Setting Up IntelliJ

+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. > >

Re: Revert recent Gradle upgrade

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

Re: [DISCUSS] CI improvements

+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

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

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

Re: Orphaned Server processes

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 C

Re: Orphaned Server processes

; > 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 colocate

Re: Orphaned Server processes

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

gfsh question

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:

Re: Top-Level Project Tasks Completed

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