Jira Permission Request

Hi, I would like to request permission to create and edit tickets and assign them to myself on the following JIRA: https://issues.apache.org/jira/ Thanks, Aaron Lindsey

Permission request

Hi, I would like to be able to edit the wiki here: https://cwiki.apache.org/confluence/display/GEODE My username is aaronlindsey. Thanks, Aaron Lindsey

Re: Jira Permission Request

Sorry, I forgot to add that my username is aaronlindsey On Wed, Apr 10, 2019 at 3:17 PM Aaron Lindsey wrote: > Hi, > > I would like to request permission to create and edit tickets and assign > them to myself on the following JIRA: > https://issues.apache.org/jira/ > > Th

Re: what is the best way to update a geode pull request

+1 to updating the PR template. I've noticed that few people actually follow it and sometimes they just remove it altogether. +1 to pushing PR changes as separate commits. This makes PR review easier. Sometimes it's helpful to me as a reviewer for the initial PR to be split into multiple commits

Re: [PROPOSAL] Instrumenting Geode Code

+1 I like this approach compared to the previous proposals because it's simpler (doesn't require a custom registry) and makes it more straightforward to replace stats with Micrometer meters in the future. - Aaron On Fri, Jun 7, 2019 at 4:58 PM Dale Emery wrote: > Proposal for instrumenting

Re: [DISCUSS] RFC 0: Lightweight RFC Process

+1 looks good to me - Aaron On Tue, Jun 25, 2019 at 8:52 AM Jacob Barrett wrote: > > > > On Jun 24, 2019, at 3:42 PM, Dan Smith wrote: > > > >> > >> Just to make sure I got this 100% right, you mean the work related as > part > >> of the proposal would be under development, correct? > > > >

Propose GEODE-6544 fix for release 1.9.0

We'd like to propose including this fix into 1.9.0 as well: https://github.com/apache/geode/pull/3362 https://jira.apache.org/jira/browse/GEODE-6544 This fixes a memory leak caused by a thread leak in Pulse. Every time a user signs out, a thread is left running. The fix for GEODE-6544 stops that

Re: [DISCUSS] Adoption of a Coding Standard

+1 to having a recommended reading list. At first glance, the SEI standard seems like an extremely useful resource, but I am hesitant to adopt it as our "coding standard" without carefully reading all the way through it. I would, however, be comfortable adding it to a recommended reading list. -

Re: [PROPOSAL]: Improve OQL Method Invocation Security

+1 I just re-reviewed this proposal and it looks good to me. - Aaron > On Jul 12, 2019, at 6:29 AM, Juan José Ramos wrote: > > Hello Mike, > > Agreed, we'll probably need to create an enhancement request for this > feature in JIRA. > Cheers. > > On Thu, Jul 11, 2019 at 5:37 PM Michael Stolz

Re: [DISCUSS] RFC 0: Lightweight RFC Process

This is great! Thanks! - Aaron > On Jul 12, 2019, at 1:43 PM, Alexander Murmann wrote: > > Thanks, Dan! > > On Fri, Jul 12, 2019 at 1:35 PM Mark Hanson wrote: > >> Thanks for taking the initiative Dan! >> >>> On Jul 12, 2019, at 12:57 PM, Dan Smith wrote: >>> >>> Following up on this, I

Re: [DISCUSS] Geode dependency update process (review by 8/28/2019)

I like the idea of proactively updating dependencies after each release. For this to work we would have to know whether the next release will be a major or minor release directly after each GA release (so that we can bump either major or minor versions, as appropriate). How and when do we

Re: Fix for NPE during forceDisconnect candidate for 1.10.0

+1 > On Aug 13, 2019, at 9:59 AM, Kirk Lund wrote: > > I guess we need at least one more vote to get this fix copied to the 1.10.0 > release branch. We just confirmed that this fix is NOT on that branch yet. > > On Thu, Aug 8, 2019 at 11:03 AM Juan José Ramos wrote: > >> +1 >> >> On Thu,

Re: [DISCUSS] Release Geode 1.9.1 with logging improvements

4jProvider. >> >> For example, Log4j uses SLF4JProvider when log4j-to-slf4j is in the >>classpath. >> >> By disabling Log4jAgent when other Log4j Providers are in use, this >> prevents problems such as ClassCastExceptions when attemping to cast

Failing LGTM Check

My PR has a LGTM check that shows “Failing” on the PR and LGTM site, but the LGTM logs say “Succeeded”: Failing PR check: https://github.com/apache/geode/pull/3913/checks Failing check on LGTM site:

Re: [DISCUSS] Release Geode 1.9.1 with logging improvements

ike to >>> point out that all testing of SBDG will be against a named supported >>> version of Geode / GemFire. Which means, if failures arise using SBDG / >>> SDG with a non-supported version of Geode / GemFire would effectively be >>> unsupported. (due diligence t

Propose fix for 1.10 release: Prevent NPE in getLocalSize()

I’d like to propose including https://github.com/apache/geode/pull/3913/commits/6f1814d1f719cc06b13769c40a9d6d01f99f927c in the Geode 1.10 release. This commit fixes an issue where a

Re: New release branch for Apache Geode 1.10.0

+1 to including this PR in the 1.10.0 release. Just to elaborate on the issue: If the stats sampler calls LocalRegion.getLocalSize before that region is initialized, it will throw a NullPointerException. This can happen because we have escaping references to “this” in the LocalRegion

Re: Propose fix for 1.10 release: Prevent NPE in getLocalSize()

be more effort :) > > --Udo > > On 8/14/19 9:25 AM, Aaron Lindsey wrote: >> @Udo, I think Kirk explained it well — This issue was introduced very >> recently (right before we cut the release branch) and it has serious >> consequences (requires restarting the server).

Re: Draft of Apache Geode Quarterly Report (Aug 2019) for your review

Kind of a small thing, but the Committer-to-PMC ratio seems more like 2:1 based on the numbers of committers and PMC members below. - Aaron > On Aug 12, 2019, at 2:22 PM, Dave Barnes wrote: > > Reformatted for more amenable viewing: > > ## Description: > > The mission of Apache Geode is the

Re: Propose fix for 1.10 release: Prevent NPE in getLocalSize()

uced in a >> current refactor)? >>> >>> If the answer is anything other that "This will make the system stop >> working", I would vote: -1 >>> >>> If this is an existing issue and has been around for a while, I think we >> hold off includi

Re: [DISCUSS] Add a public API to add endpoints to Geode's HTTP server

Would it be practical to remove the dependency on Jetty from the HttpService interface? I admit that I don't know a lot about this area of the code, but I noticed that the current HttpService public interface doesn't have any dependencies on Jetty (except the getHttpService() method, which would

Re: [DISCUSS] RFC - Move membership code to a separate gradle sub-project

+1 — I'm happy to see us move toward better testability for the membership code! I also left my "+1" on the wiki page comments. I noticed that the "Lightweight RFC Process" document states that we're supposed to have discussions on the [DISCUSS] thread: In addition a [DISCUSS] email should be

Re: [VOTE] Apache Geode 1.10.0.RC1

+1 - Built from source and ran unit tests - Used GFSH to create a locator and server and do some puts/gets - Checked version in GFSH - Built and ran all of the examples - Verified SHAs and signatures - Aaron On Thu, Sep 5, 2019 at 10:16 AM Nabarun Nag wrote: > Hello, > > I was

Question about excluding serialized classes

As part of a PR to add Micrometer timers for function executions , we implemented a decorator Function that wraps all registered non-internal functions and adds instrumentation. This PR is failing AnalyzeSerializablesJUnitTest.testSerializables because

Re: Question about excluding serialized classes

also get registered function objects directly from the function > service using FunctionService.getFunction(String) and do whatever they want > with them, which I guess could include serializing them. > > Hope that helps! > -Dan > > On Wed, Sep 11, 2019 at 10:27 AM Aaron Lindsey

Re: Question about excluding serialized classes

t;> > >> I think the Decorator approach you outlined could have other impacts as > well. Would I still be able to see specific function executions in > statistics or would they all become “TImingFunction”? > >> > >> Anthony > >> > >> > >>

Re: Question about excluding serialized classes

> > Not all functions are registered. I can invoke a function with > Execution.execute(Function) from the client, the Function is serialized and > executed on the server, the class need only exist on the server for > deserialization. Must a function be registered now to get metrics? > For this

Re: Question about excluding serialized classes

Hi Jake, I think this thread has moved a bit off-topic, but I appreciate you pointing out that scenario. We'll have to consider that when re-working this PR. - Aaron On Tue, Sep 17, 2019 at 9:42 AM Jacob Barrett wrote: > > > On Sep 17, 2019, at 9:36 AM, Aaron Linds

PR Reviews

Would anyone be able to review and/or merge the following 2 PRs? GEODE-6298: Fix flaky test scanMovesRecentlyUsedNodeToTail GEODE-7003: Fix flaky tests in GemFireTransactionDataSourceIntegrationTest Thanks,

Re: IntelliJ setup for develop

I had the same issue. Now I use the same configuration as Jens and that fixed the issue. The only problem is that I feel the Gradle build takes longer than IntelliJ’s build. - Aaron > On Jul 24, 2019, at 2:12 PM, Jens Deppe wrote: > > I'd suggest not trying to build with IntelliJ, but

Re: [VOTE] Apache Geode 1.10.0.RC2

The luceneSpatial project in geode-examples fails for me when running: ./gradlew -PgeodeReleaseUrl= https://dist.apache.org/repos/dist/dev/geode/1.10.0.RC2 -PgeodeRepositoryUrl= https://repository.apache.org/content/repositories/orgapachegeode-1059 :luceneSpatial:build :luceneSpatial:runAll In

Re: [VOTE] Apache Geode 1.10.0.RC2

+1 - Built from source and ran unit tests - Used GFSH to create a locator and server and do some puts/gets - Checked version in GFSH - Built and ran all of the examples - Verified SHAs and signatures The luceneSpatial project in geode-examples fails for me when running... > To

Re: [DISCUSS] Tweak to branch protection rules

+1 - Aaron On Wed, Oct 30, 2019 at 8:02 AM Ju@N wrote: > Perfect Naba, thanks for answering this. > My vote is +1 then. > > On Wed, Oct 30, 2019 at 2:37 PM Nabarun Nag wrote: > > > The check box Dan is mentioning will just not invalidate any approved > > review if the code is changed. > > If

Re: [DISCUSS] is overriding a PR check ever justified?

One case when it might be acceptable to overrule a PR check is reverting a commit. Before the branch protection was enabled, a committer could revert a commit without a PR. Now that PRs are mandatory, we have to wait for the checks to run in order to revert a commit. Usually we are reverting a

Re: [DISCUSS] Replacing singleton PoolManager

+1 Aaron > On Dec 6, 2019, at 10:49 AM, Jacob Barrett wrote: > > > >> On Dec 6, 2019, at 9:40 AM, Dan Smith wrote: >> >> Regarding changing PoolManager to >> an interface, I guess originally I wasn't thinking we would still be >> backwards compatible if we did that. But as I think about it

Re: [DISCUSS] Blocking merge button in PR

+1 - Aaron On Mon, Oct 21, 2019 at 11:53 AM Udo Kohlmeyer wrote: > BIG +1 (Yes, I'm changing my -1) > > @Naba, thank you for the offline chat. It seems that the proposal of > Github enforcing our good practices is a great option. > > 2 merged PR's without a full green pipeline, since 18 Oct

Changes to recorded execution times for function stats

Hi Geode devs, This PR makes small changes to the execution times recorded by function stats. I wanted to run this by the dev list to make sure this will not cause problems for users who rely on these stats: - In ServerFunctionExecutor and

Re: [PSA] Github branch protection

@Naba That's the one. It was approved shortly after I sent that message though. It should be reproducible by requesting changes on a PR with no other reviews. @Owen It's unclear to me whether "requesting changes" is the same thing as a -1 vote. I had previously discussed this with some other

Re: [PSA] Github branch protection

Thanks, Naba. Are we now blocking merges for PRs that have changes requested? I have a PR right now where instead of the merge button it has the message, "Merging can be performed automatically once the requested changes are addressed." It also happens to not have any approvals, so it's possible

Reviewers for GEODE-7184: Fix failing Windows acceptance tests

Could one or two others please review and/or merge this PR? It fixes failures in Windows acceptance test jobs in the develop CI pipeline. https://github.com/apache/geode/pull/4192 - Aaron

Re: Changes to recorded execution times for function stats

I haven't heard any objections to this, so we plan to move forward with these changes. - Aaron On Tue, Oct 15, 2019 at 4:29 PM Aaron Lindsey wrote: > Hi Geode devs, > > This PR <https://github.com/apache/geode/pull/4135> makes small changes > to the execution times recorded

Re: [PSA] Github branch protection

@Owen I'm fine with following the "requesting changes is the same as -1" rule, but I don't think there is consensus from the whole community on this yet. I was previously told that contributors should make every effort to address the requested changes, but unless a committer actually comments "-1"

Re: [DISCUSS] Proposal to require linear commit history on develop

Just to be clear, this proposal wouldn't require anyone to squash their commits before merging a PR. All it’s saying is that if you do have multiple commits in your PR, you would have to rebase those commits onto develop before merging to ensure a linear commit history. - Aaron > On Dec 20,

Re: Review for #4387

I added a review, but mostly from a code cleanliness and testing perspective. I hope someone with more knowledge of the use case and WAN can provide their feedback. - Aaron > On Dec 16, 2019, at 1:14 AM, Mario Ivanac wrote: > > Hi all, > > please could someone review

Re: [DISCUSS] Proposal to require linear commit history on develop

+1 to (1) and (3) I’m on board with (1). I’m hesitant about agreeing to (2) because it seems harder to “accidentally” do a merge commit via the command line, and I don’t want to add unnecessary restrictions. (3) has needed to be done for some time now, so I’m happy to see a proposal to change

Re: Let's Deprecate the SECURITY_UDP_DHALGO Configuration Property

+1 to deprecating this feature in 1.12 As to whether we should remove this feature in a minor release, I think that, as Alexander pointed out, it hinges on the question of whether we perceive there to be some security issue in the feature’s implementation. This statement from the proposal

Re: [DISCUSS] RFC: Shipping Geode patch releases

+1 to the proposal as it’s written. I’m not sure about setting regular intervals for patch releases vs sticking with our current “on-demand” process. I don’t think this has to be spelled out in this proposal. I’d be fine with sticking to “on-demand” patch releases as we’ve been doing for now

Re: [DISCUSS] Proposal to require linear commit history on develop

-0.9 I’m not in favor of the revised proposal that disallows rebase-and-merge. Say I am working on a PR and I have a refactor commit and another commit which implements a new feature. I don’t want those commits to get squashed because that makes it hard to understand the diff. However, if I

Re: [DISCUSS] Proposal to require linear commit history on develop

er rebase!). I wonder if this > points out an opportunity for a “tips and tricks” page on the Geode wiki. > > On Tue, Dec 31, 2019 at 5:22 PM Aaron Lindsey > wrote: > >> -0.9 >> >> I’m not in favor of the revised proposal that disallows rebase-and-merge. >> Say I am wor

Re: [DISCUSS] What should we do with @Ignore tests?

I’m in favor of deleting all except the ones that have JIRA tickets open for them, like Bruce said. Also going forward I’d like to see us not be checking in @Ignored tests — just delete them instead. If we need to get it back we have revision history. Just my two cents. Aaron > On Dec 31,

Re: [DISCUSS] Proposal to require linear commit history on develop

Is it not the case currently? If I am working on a feature modifying > > class > > > X and another developer makes some refactoring changes on class X and > > > pushes it to develop, won't I have to resolve the merge commits anyway. > > > > > > > > >

Re: [VOTE] Apache Geode 1.11.0.RC4

The release notes section on the wiki just says "tbd". Also, I cannot find Mark’s public key in any of the public PGP key servers (such as https://keyserver.ubuntu.com), but I did verify that the signatures in the source and binary distributions match the key that is listed in the geode KEYS

Re: [DISCUSS] Replace UDP messaging for membership with TCP

This proposal sounds good to me. +1 to using standard security implementation based on TLS > On Apr 1, 2020, at 3:20 PM, Dan Smith wrote: > >> When we move from a reliable UDP implementation to one based on TCP, we >> need to think about how to provide reliability on top of TCP. If you dig >>

Re: WAN replication issue in cloud native environments

I thought the deadline for comments was extended until today (27th), so I added a new comment on the RFC. I’m confused about the direction we are taking with this proposal. - Aaron > On Mar 27, 2020, at 11:14 AM, Dan Smith wrote: > > With this PR, it would be possible to identify servers

Re: [VOTE] Apache Geode 1.12.0.RC4

+1 (non-binding) Steps I took: - Built from source and ran unit tests - Used GFSH to create a locator and server and do some puts/gets - Checked version in GFSH - Built and ran all of the examples - Verified SHAs and signatures Aaron > On Mar 30, 2020, at 7:54 AM, Dave Barnes wrote: > > +1 >

Re: [DISCUSS] Redundancy Gfsh Commands

> If at least one redundant copy exists for every bucket in the specified > regions, the status of the command will be success. If at least one bucket in > a region has zero redundant copies, if there is a member in the system with > an older version of Geode or if the restore redundancy

Re: [DISCUSS] Redundancy Gfsh Commands

> Would it be reasonable to return error in the case that > all explicitly included region aren't found? Yes, this sounds reasonable. Thanks for pointing out that subtlety and for updating the RFC. From the RFC: > The command will return error status if: I assume this means ERROR or FAILURE

Re: [DISCUSS] Redundancy Gfsh Commands

> some other relatively benign problem, and "we encountered an exception > while attempting to restore redundancy and were unable to complete the > operation," which could be indicative of a more serious issue. > > I hope this clarifies things somewhat. > > On T

Re: RFC - Logging to Standard Out

I think this could be moved to "In Development" since there is consensus. I created a JIRA for it: https://issues.apache.org/jira/browse/GEODE-8077

Re: [VOTE] Using Github issues and wiki for geode-kafka-connector project

YES +1 > On Mar 23, 2020, at 7:42 AM, Bruce Schuchardt wrote: > > +1 > > On 3/21/20, 5:17 PM, "Nabarun Nag" wrote: > >Hello team, > >We are planning to experiment with using Github issues and wiki for the >Apache project *Geode-Kafka-Connector. *(not Apache Geode project).

Re: [DISCUSS] proposal for WAN support of an ingress proxy

Sounds good to me. I like the idea of using a proxy instead of the --hostname-for-clients solution where you cannot specify the particular server of which to connect. And it seems good to use the same approach that was used for "off platform" clients. Aaron

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

Re: Member that is shutting down initiate removal of other members from the cluster

Hi Jakov, Do you see this issue if you drain the worker node before shutting it down? For reference: https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/. I know this doesn’t directly answer your questions, but it seems like draining the node first would help the members

Re: [PROPOSAL] Backport fix for GEODE-8620 to 1.13.1

+1 Aaron > On Oct 21, 2020, at 9:00 AM, Donal Evans wrote: > > Hi Geode dev, > > I would like to backport the fix for >

Re: Different binding addresses for traffic & membership

> Is there any way to configure a bind address to be used only for membership? To your first question, I asked around but I’m not aware of anything like what you are looking for. What you are describing does seem like it could become a common setup on Kubernetes, but I personally haven’t tried

Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop

+1 to keep only "Squash and merge" and "Rebase and merge". Aaron Lindsey From: Robert Houghton Sent: Monday, June 28, 2021 2:31 PM To: dev@geode.apache.org Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop I

Re: [DISCUSS] - RFC make key and trust stores reload automatically upon change

It doesn't look like this RFC has received any comments after being open for more than 2 weeks. As a reminder, if anyone has feedback on our approach please reach out as we are planning to start implementing the solution described. Thanks, Aaron From:

Re: [discuss] RFC for Geode Authentication Expiation and Re-Authentication

Hi Jinmei, I read through the proposal a few days ago and it sounded good to me. I didn't have any questions or concerns. Aaron From: Jinmei Liao Sent: Tuesday, July 27, 2021 2:26 PM To: dev@geode.apache.org Subject: Re: [discuss] RFC for Geode