Re: Update on CI migration

Hi Sai, I'd like to help out on this or take it over. If you have time, please loop me in with any contact info for the infra team, details about what is currently disabled, details about what is currently blocked (just running Windows tests?), and I'll try reaching out to them again for some

spotlessGroovyGradleCheck failures in clean checkout on windows

Anyone know why a fresh checkout of develop has all of the following failures on Windows? > ./gradlew clean > ./gradlew build -x test > Task :geode-cq:spotlessGroovyGradleCheck FAILED > Task :geode-server-all:spotlessGroovyGradleCheck FAILED > Task :geode-membership:spotlessGroovyGradleCheck

Re: Update on DUnit test pipeline on Github actions

on. > > On Thu, 13 Apr 2023 at 15:08, Kirk Lund wrote: > > > I see that there is at least one person concerned about DUnit tests > > requiring longer timeouts. This is the current situation with an unknown > > number of the DUnit tests. One possibility is to mov

Re: Update on DUnit test pipeline on Github actions

commitment from contributors that might not be an option for some time. -Kirk On Thu, Apr 13, 2023 at 3:02 PM Kirk Lund wrote: > Is the coreDistributedTests the only dunit job that currently takes too > long? If it is we may want to split that into more than one job. > > -Kirk > &

Re: Update on DUnit test pipeline on Github actions

Is the coreDistributedTests the only dunit job that currently takes too long? If it is we may want to split that into more than one job. -Kirk On Wed, Apr 12, 2023 at 7:58 PM Sai Boorlagadda wrote: > All, > > There is an upper bound for job execution time on free workers (set to 6 > hours

Approved your PR Sai

Sai, I approved the only non-draft PR you had waiting for review. Feel free to ping slack or email me if you have something waiting on me. Thanks, Kirk

Re: isolated test plugin

Let's have a longer chat about what I know in slack. I think a lot of this was done for running tests in parallel. -Kirk On Mon, Jan 23, 2023 at 9:50 PM Sai Boorlagadda wrote: > Could someone provide context on how integration & dunit tests are run in > CI? > > I remember geode had dockerized

Bad Practice: Static constant values set by system properties

Sai and I worked together yesterday and fixed almost all of the failing unit tests in the new build we're trying to set up. I think we have one failure remaining. Most of the failures we fixed turned out to be caused by new code that was committed to Geode in 2022 that causes values in static

Re: Backport plan for reported CVEs on 1.13.x branch

Hi Ankush, We are in need of more contributors if you're interested in helping! At this point, we're trying to get a new CI up and running. Then we hope to maintain the latest version 1.15.x and eventually discuss the feasibility of new minor or major releases. Regards, Kirk On Tue, Dec 6,

Re: rewrite CI pipeline

to a port. One or two failures appear to be DNS related which may require either editing /etc/hosts or changing the test. Will update again after debugging these more. Cheers, Kirk On Fri, Dec 2, 2022 at 12:58 PM Kirk Lund wrote: > Sai, I'll be able to spend some time this week

Re: rewrite CI pipeline

rent sets of errors. So to see if the devs can shed > some light on JDK dependency or any prior knowledge on choosing > bellsoft distribution. > > Sai > > On Mon, 21 Nov 2022 at 16:25, Kirk Lund wrote: > > > It's also possible that these issues are specific to using OpenJD

Re: rewrite CI pipeline

It's also possible that these issues are specific to using OpenJDK 8 or Ubuntu. I thought we were building and testing with CentOS before. On Mon, Nov 21, 2022 at 4:20 PM Kirk Lund wrote: > Looks like membership errors. Membership went through extensive changes to > be modularized as

Re: rewrite CI pipeline

Looks like membership errors. Membership went through extensive changes to be modularized as geode-membership, and VMware was still fixing some bugs in it when I left. These could be really difficult to solve for those of us who have no experience with the new membership. I wonder if we could

Re: priority list

p > > without too much trouble. I would say if we can get CI running for the > main > > Geode project with a compile in Jenkins, it would be a great first step. > I > > do have quite a bit of Jenkins experience, so I can definitely help out. > > > > --Ma

Re: priority list

Do we know why Geode has such a large CI resource requirement? I would guess that it was partially due to trying to run as many tests in parallel as possible to shorten the feedback cycle. The recent CI pipelines were also built on Pivotal's Concourse which seems to promote a greater number of

Jira Contributors vs Committers vs "Assign User"

Contributors have the "Assignable" permission, but are lacking "Assign User" which despite the text description means that they cannot assign a ticket to themselves. Basically Contributors cannot assign anything to anyone. Ideally, we want to add "Assign User" to Contributors rather than keep

CVE-2022-37023: Apache Geode deserialization of untrusted data flaw when using REST API on Java 8 or Java 11

Severity: high - possible RCE Description: Apache Geode versions prior to 1.15.0 are vulnerable to a deserialization of untrusted data flaw when using REST API on Java 8 or Java 11. Any user wishing to protect against deserialization attacks involving REST APIs should upgrade to Apache Geode

CVE-2022-37022: Apache Geode deserialization of untrusted data flaw when using JMX over RMI on Java 11

Severity: high - possible RCE Description: Apache Geode versions up to 1.12.2 and 1.13.2 are vulnerable to a deserialization of untrusted data flaw when using JMX over RMI on Java 11. Any user wishing to protect against deserialization attacks involving JMX or RMI should upgrade to Apache

CVE-2022-37021: Apache Geode deserialization of untrusted data flaw when using JMX over RMI on Java 8.

Severity: high - possible RCE Description: Apache Geode versions up to 1.12.5, 1.13.4 and 1.14.0 are vulnerable to a deserialization of untrusted data flaw when using JMX over RMI on Java 8. Any user still on Java 8 who wishes to protect against deserialization attacks involving JMX or RMI

Prevent common causes of flaky tests

How to prevent common causes of flakiness in tests: 1. Use the correct timeout a. Always use GeodeAwaitility.getTimeout() for all timeouts in tests even if you think it should be shorter. 2. Use a free port or disable the port instead of using any default ports a. Use AvailablePortHelper to

Re: [PROPOSAL] Remove warning logs from FunctionException

Hi Alberto, I don't really know if this change is good or bad but I do have some thoughts about logging and changing behavior like this. First off, we might think about whether or not logging these warnings is currently expected behavior. Would removing/changing it cause surprise for any users

Writing acceptance tests with a server but no clients

Since the server doesn't have any clients connecting to it, you can simply specify --disable-default-server instead of using --server-port. This reduces the risk of any port conflicts and also speeds up starting that server.

distributedTests should go in src/distributedTest

Just a quick reminder that all distributedTests should go in src/distributedTest. A test should only be considered an acceptanceTest if it uses GfshRule to launch the locator and server processes, and it should only use User APIs for everything (configuration, initiating operations and validating

Re: Commit message review opt-in

So, we just submit edits to COMMITWATCHERS going forward? Thanks Owen! On Tue, Mar 8, 2022 at 11:07 AM Owen Nichols wrote: > To make opt-in and opt-out less noisy for the dev list, the subscription > mechanism has been moved to COMMITWATCHERS file under source control to > provide self-service

Re: Commit message review opt-in

I'd like to opt-in for this Owen. Thanks! -Kirk On Fri, Feb 25, 2022 at 3:43 PM Owen Nichols wrote: > If you received an automated-looking PR review comment from > onichols-pivotal in the past few weeks without consent, I apologize and > have withdrawn it. > > If you would like to continue

Re: Question regarding geode thread priorities

PS: Sorry if I didn't realize what BRs is :D On Wed, Jan 26, 2022 at 3:39 PM Kirk Lund wrote: > Hi BRs/Jakov, > > I'm familiar with most of these threads, and these ones I know of do not > spawn more than one thread total. Most of these are quite old, possibly > predating Execu

Re: Question regarding geode thread priorities

Hi BRs/Jakov, I'm familiar with most of these threads, and these ones I know of do not spawn more than one thread total. Most of these are quite old, possibly predating Executors in Java. I doubt using max priority is important for these threads, but you should probably do some perf testing if

Re: [Suspected Spam] [VOTE] Apache Geode 1.13.7.RC1

+1 same as Naba On Wed, Jan 19, 2022 at 4:26 PM Nabarun Nag wrote: > +1 based on the results of the pipeline tests. > > Regards > Nabarun Nag > > > From: Dick Cavender > Sent: Monday, January 17, 2022 11:20 AM > To: dev@geode.apache.org > Subject: [Suspected

CVE-2021-34797: Apache Geode project log file redaction of sensitive information vulnerability

Severity: low Description: Apache Geode versions up to 1.12.4 and 1.13.4 are vulnerable to a log file redaction of sensitive information flaw when using values that begin with characters other than letters or numbers for passwords and security properties with the prefix "sysprop-",

Re: [DISCUSS] Adding LTGM as gating PR checks

I support making LGTM a gating job on every PR. On Thu, Dec 16, 2021 at 2:46 PM Alexander Murmann wrote: > +1 to adding this. Given it has a low false-positive rate, only checks on > code actually changed in the PR and runs quickly compared to some of our > other steps that already happen for

Re: [VOTE] Apache Geode 1.14.1.RC2

+1 to release 1.14.1.RC2 I reviewed pipeline results and binaries. PS: I'm not sure what the "upthewaterspout" job in https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-14-rc is all about. I'd prefer to have that job renamed for future releases. On Fri, Dec 10, 2021 at

Re: [VOTE] Apache Geode 1.13.5.RC2

+1 to release 1.13.5.RC2 I reviewed pipeline results and binaries. distributed-test-openjdk8 encountered a known JMX bug that exists in all released versions. On Fri, Dec 10, 2021 at 2:09 PM Owen Nichols wrote: > Hello Geode Dev Community, > > This is a release candidate for Apache Geode

Re: [VOTE] Apache Geode 1.12.6.RC2

+1 to release 1.12.6.RC2 I reviewed pipeline results and binaries. 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.12.6.RC2. > Thanks to all the community members for their contributions to this >

Re: @TestOnly or @VisibleForTesting

eded to do the > right thing is a disincentive to writing tests...I'd rather have the > tests... > > > On 11/5/21, 11:37 AM, "Kirk Lund" wrote: > > I'm ok with not using these annotations, but we still need to write > *unit > tests* in addition to end-to-end

Re: @TestOnly or @VisibleForTesting

r to require ALL dependencies. -Kirk On Thu, Nov 4, 2021 at 3:13 PM Kirk Lund wrote: > As everyone thinks about how we want to use these annotations, please keep > this in mind that both *@VisibleForTesting* and *@TestOnly* can be used > on Types (Class/Interface/Enum), Constructors,

Re: Using Ports Safely in Tests

Dale, Thanks for doing this work and especially for adding these guidelines to the Wiki! On Thu, Nov 4, 2021 at 1:08 PM Dale Emery wrote: > As of July, 2021, Geode's build system no longer executes test worker > processes in separate Docker containers. > > This increases the risk of port

Re: @TestOnly or @VisibleForTesting

As everyone thinks about how we want to use these annotations, please keep this in mind that both *@VisibleForTesting* and *@TestOnly* can be used on Types (Class/Interface/Enum), Constructors, Methods and Fields. (not just Methods) On Thu, Nov 4, 2021 at 3:09 PM Kirk Lund wrote: > Hey

@TestOnly or @VisibleForTesting

Hey all, We're introducing a mess to the codebase. It's a small problem, but several small problems become a big problem and one of my missions is to clean up and improve the codebase. I recently started seeing lots of pull requests with usage of @TestOnly. Sometimes it's used instead of

Re: Test failures on Windows with insufficient memory for the JRE while running distributed tests

. On Tue, Oct 26, 2021 at 10:22 AM Kirk Lund wrote: > Hi Alberto, > > 32 kb is a very small amount of memory, so I don't think it's related to > Java Heap. Based on what little I've read today, I think a failure in > ChunkPool::allocate is probably related to either *running out

Re: Test failures on Windows with insufficient memory for the JRE while running distributed tests

Hi Alberto, 32 kb is a very small amount of memory, so I don't think it's related to Java Heap. Based on what little I've read today, I think a failure in ChunkPool::allocate is probably related to either *running out of swap space or running out of address space in a 32 bit JVM*. Since the

Re: Added Support for JUnit 5

Good job Dale and thanks! On Tue, Oct 12, 2021 at 3:37 PM Dale Emery wrote: > In September 2021, Geode added support for writing and running tests using > JUnit 5. > > Most Geode modules now support JUnit 5. For most Geode modules, you can > now write each test class using either JUnit 5's

The Apache Geode dedication to software quality

rs to help educate and guide these contributors in both our process and Code of Conduct [3]. Everyone should be encouraged to ask questions and discuss how we can best deliver high-quality software that will be easy to maintain by all Apache Geode developers in the years to come. Quality impassioned,

Re: Revert GEODE-9486: Fix validate-serializable-objects (#6746)

PS: This PR needs a lot of reviews. Please review as soon as possible so I can merge the revert to develop to restore the CI to green. On Mon, Aug 30, 2021 at 2:42 PM Kirk Lund wrote: > I have submitted PR #6816 to temporarily revert GEODE-9486 until it's > ready to go back in. >

Revert GEODE-9486: Fix validate-serializable-objects (#6746)

I have submitted PR #6816 to temporarily revert GEODE-9486 until it's ready to go back in. https://github.com/apache/geode/pull/6816 Sha 3b2c53 is failing consistently on Windows, so it needs to be reverted. I hope to have a fix ready sometime next week. Thanks, Kirk

Re: Revert "GEODE-9369: Command to copy region entries from a WAN site to… #6811

I've merged the revert to develop. Thanks for all the reviews! On Fri, Aug 27, 2021 at 9:56 AM Kirk Lund wrote: > Please review PR #6811 so we can revert GEODE-9369 to clear up the failing > unit test. Hopefully this will be ready to be reintroduced next week. > > If anyone kno

Revert "GEODE-9369: Command to copy region entries from a WAN site to… #6811

Please review PR #6811 so we can revert GEODE-9369 to clear up the failing unit test. Hopefully this will be ready to be reintroduced next week. If anyone knows of follow-on commits after c9d465, please let me know. Revert "GEODE-9369: Command to copy region entries from a WAN site to… #6811

Re: Revert GEODE-9408: Avoid duplicate events sent by Serial Gateway Sender when group-transaction-events is true (#6663)

On Thu, Aug 26, 2021 at 4:56 PM Kirk Lund wrote: > I have submitted PR #6809 to temporarily revert GEODE-9408 until it's > ready to go back in. > > https://github.com/apache/geode/pull/6809 > > I've reviewed the code that went in with #b377e3, and I think we should >

Revert GEODE-9408: Avoid duplicate events sent by Serial Gateway Sender when group-transaction-events is true (#6663)

I have submitted PR #6809 to temporarily revert GEODE-9408 until it's ready to go back in. https://github.com/apache/geode/pull/6809 I've reviewed the code that went in with #b377e3, and I think we should revert it to rework WanCopyRegionFunction and its unit test. The unit test currently mocks

Re: Annual branch cleanup Aug 17

I confirmed that GEODE-9064-JMX-filter-support_1.12-02 is/was one of my branches. I'm 100% for deleting it and the others. Thanks Owen! On Sun, Aug 1, 2021 at 1:01 AM Owen Nichols wrote: > Reminder to use your personal fork whenever possible. If you do create a > branch in the geode repo,

Re: "create region" cmd stuck on wan setup

Please file a bug for this. Even if that ordering doesn't work, nothing should hang because of it. Thanks, Kirk On Wed, Jul 28, 2021 at 5:27 PM Barrett Oglesby wrote: > I reproduced your issue with your scripts. > > They do: > > create gateway-receiver > create disk-store > create

Re: Member status using working directory

I filed https://issues.apache.org/jira/browse/GEODE-6841 to make this change. We would remove our dependency on the Attach API and Geode would then only use FileProcessController. Once the Attach API is no longer used "status server --pid=###" will no longer work, so I added a comment to

Re: NullPointerException while create region during server restart

Hi Mario, I would guess that *getPdxRegistry()* is returning a null until after the registry has finished initializing. Just a guess though. Here's a spreadsheet a couple of us created and used

ParallelGatewaySenderQueue$BatchRemovalThread prints NPE

Can someone who has been working on GatewaySender please take a look at this NPE? It didn't cause any test failures, but it does show up in the output of my unit-test-openjdk11 task for one of my PRs: https://concourse.apachegeode-ci.info/builds/53189 > Task

Re: [DISCUSS] Remove stress-new-test-openjdk11 requirement from PRs

ced. > > Owen, will it be possible to put out a list of all the flaky tests and > we can try to get these resolved collectively as a community. (results of > the mass tests maybe). Thank you. > > > Regards > Nabarun Nag > > From:

Re: [DISCUSS] Remove stress-new-test-openjdk11 requirement from PRs

Ok, I wanted to give this discussion another night and we still have consensus for making both stress-new-test non-required. I just filed PR #6602 to change stress-new-test from required to non-required. Please review! On Wed, Jun 9, 2021 at 2:11 PM

Re: [DISCUSS] Remove stress-new-test-openjdk11 requirement from PRs

. I don’t have any ideas for how to > declare such an exclusion, but if it could be done via a file it would be > subject to code owner review. > > Dale > > From: Kirk Lund > Date: Tuesday, June 8, 2021 at 9:33 AM > To: dev@geode.apache.org > Subject: [DISCUSS] Remov

Re: [DISCUSS] Remove stress-new-test-openjdk11 requirement from PRs

class > that you can't fix them all in one PR, which might indicate it's too big. > > If we can't get StressNewTest to pass - that means our builds are failing > more than 2% of the time due to this one test failure. Yikes! > > -Dan > ____ > From: Kirk

[DISCUSS] Remove stress-new-test-openjdk11 requirement from PRs

Our requirement for stress-new-test-openjdk11 to pass before allowing merge doesn't really work as intended for fixing distributed tests that contain multiple flaky test methods. In fact, I think it causes contributors to avoid tackling flaky tests. I've been working on GEODE-9103: CI Failure:

Re: [Discuss] New feature work approval state in Geode project?

Anil's thoughts parallel what I was trying to describe as well... On Fri, May 28, 2021 at 2:35 PM Anilkumar Gingade wrote: > My thoughts; I can't make distinction between feature or bug; it’s a > change to the codebase, if it has greater impact, is sensitive and takes > time to build; then it

Re: [Discuss] New feature work approval state in Geode project?

Another thought I have is that if the "fix" for a bug will require any sort of new User API or configuration properties (ie gemfire.properties), then we should always treat that as a new feature that requires going through our RFC process for a new feature. On Fri, May 28, 2021 at 2:

Re: Cleaning up the codebase - use curly braces everywhere

+1 Also, I think if the entire work is done by IntelliJ then just mention that in the PR description and I'm happy to add approval without stepping through every line. I'd probably just pick a dozen random ones to check and then approve it. On Thu, May 27, 2021 at 6:36 PM Darrel Schneider wrote:

Re: [Discuss] New feature work approval state in Geode project?

I think the main problem this discussion thread could solve is when a developer files a Jira ticket as a bug, assigns it to themselves, and begins work on it. After some time (possibly even a month or something significant like that), they submit a PR to fix the ticket, only to find out from

Re: [VOTE] Requiring final keyword on every parameter and local variable

tter) -1: 4 binding votes, 1 advisory vote * Mark Hanson (PMC member) * Patrick Johnson (contributor) * Udo Kohlmeyer (PMC member) * Kirk Lund (PMC member) * John Blum (PMC member) * Bruce Schuchardt (PMC member) - sorry, vote was past deadline The voting fails with a majority of -1 votes. [1] ht

Re: [VOTE] Requiring final keyword on every parameter and local variable

Voting and discussion are closed for now. I'll count up the votes and post a summary soon. -Kirk On Thu, Apr 22, 2021 at 7:54 AM Bruce Schuchardt wrote: > Kirk speaks my mind. -1 on this requirement > > On 4/21/21, 11:29 AM, "Kirk Lund" wrote: > > -1 as I'v

Re: [VOTE] Requiring final keyword on every parameter and local variable

I'm interested in https://projectlombok.org and I remember John Blum using it on some projects. I would like to study it and do some perf testing on it before supporting it for Geode though. In general, I don't like generated code and it looks like at least some of the features involve generated

Re: [VOTE] Requiring final keyword on every parameter and local variable

of it being useless. For example, we would have to agree as a community what the "maximum number of parameters" is for the "Method with too many parameters" inspection. We could even export an inspections profile to be stored in the Geode repo and used by contributors. -Kirk On

Re: [VOTE] Requiring final keyword on every parameter and local variable

I'm planning to leave this VOTE and DISCUSSION open until Wednesday 2400 PM UTC. On Wed, Apr 14, 2021 at 12:55 PM Kirk Lund wrote: > Our coding standard and our Design Decisions does NOT require using final > on parameters and local variables. > > Please do NOT request that I add o

Re: [DISCUSS] Requiring final keyword on every parameter and local variable

, region.getPRId(), processor); partitionedRegion = region; this.operationType = operationType; callbackArgument = event.getRawCallbackArgument(); eventId = event.getEventId(); } And I could rename "region" to "partitionedRegion", etc. On Thu, Apr 15, 2021 at 12:00 PM Kirk Lund wrot

Re: [DISCUSS] Requiring final keyword on every parameter and local variable

Here's a quote about code reviews in Clean Code in Python: We should invest time in code reviews, thinking about what is good code, > and how readable and understandable it is. When looking at the code written > by a peer, you should ask such questions as: > * Is this code easy to understand and

[DISCUSS] Requiring final keyword on every parameter and local variable

Moving the discussion to this thread. Sorry for starting off with a VOTE. I'm primarily interested in Maintainability https://en.wikipedia.org/wiki/Software_quality#Maintainability, and my concern regarding using "final" on method parameters or local variables is about Code Readability:

Re: [VOTE] Requiring final keyword on every parameter and local variable

ach a safe point (see time to safe point issues in Java). > > For this reason I strongly prefer on final everywhere and if you > think you need a variable to not be final you should use that as an > indicator to refractor your code. > > So, +1 for me for fin

[VOTE] Requiring final keyword on every parameter and local variable

Our coding standard and our Design Decisions does NOT require using final on parameters and local variables. Please do NOT request that I add or keep final on parameters or local variables unless the community votes and decides that every parameter and local variable should require the final

Precheckin job failed to fork JVM during compile

https://concourse.apachegeode-ci.info/builds/17742 core dumped during compilation of one of the modules. I believe exit code 134 means that it failed to fork a new Java VM. I wonder what would cause a test job to be unable to fork a process. It seems to have forked processes for compiling all of

Last 3 unit tests using PowerMock

We are down to 3 unit tests that use PowerMock. I'm going to start work on these 3 today. geode-core/src/test/java/org/apache/geode/internal/offheap/OffHeapRegionEntryHelperJUnitTest.java geode-core/src/test/java/org/apache/geode/internal/offheap/ReferenceCountHelperImplTest.java

Re: org.jetbrains.annotations does not exist

File | Invalidate Caches / Restart... fixed it. I haven’t had to invalidate caches for over a year and forgot all about it. Thanks, Kirk On Wed, Mar 17, 2021 at 4:01 PM Kirk Lund wrote: > I'm trying to build in IntelliJ (funny enough) and getting these failures: > > > /Users/klun

org.jetbrains.annotations does not exist

I'm trying to build in IntelliJ (funny enough) and getting these failures: /Users/klund/dev/geode1/geode-core/src/main/java/org/apache/geode/internal/cache/tx/RemoteOperationMessage.java Error:(25, 33) java: package org.jetbrains.annotations does not exist Error:(299, 4) java: cannot find symbol

Avoid PowerMockito

I just reviewed a PR that was adding a unit test using PowerMockito. We've had lots of problems with PowerMockito leaving the unit testing JVM corrupted for later tests. Using PowerMockito also discourages us from refactoring product code to have better design and be easier to unit test. So in

Re: [Proposal] Backport GEODE-8886 to 1.14

+1 On Fri, Mar 5, 2021 at 3:58 PM Owen Nichols wrote: > Added to blocker board, thanks > > On 3/5/21, 3:15 PM, "Jianxia Chen" wrote: > > +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

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

+1 On Wed, Mar 3, 2021 at 9:51 AM Jianxia Chen wrote: > +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]

Re: [PROPOSAL] backport fix for GEODE-8920 to 1.14.0

+1 to back-port GEODE-8920 fix On Mon, Mar 1, 2021 at 1:23 PM Owen Nichols wrote: > Sounds reasonable for same reasons as GEODE-8919. I've added it to 1.14.0 > blocker board. > > On 3/1/21, 1:20 PM, "Kamilla Aslami" wrote: > > Hi all, > > I would like to back-port the fix for

Examples of good Mocking in tests

There are quite a few examples of good mocking in both unit tests and integration tests, with the majority being in unit tests. An easy way to find many of these tests in Geode is to grep for uses of MockitoRule with STRICT_STUBS. Also, remember that if the test touches disk or network then it's

Fixed flaky dunit test AsyncInvocationTimeoutDistributedTest

I just merged #5799 to develop. This fixes AsyncInvocationTimeoutDistributedTest which is one of the top 3 flakiest dunit tests. Mass test results: 21% flaky overall, top three offenders: 1) GEODE-8573: SerialGatewaySenderOperationsDistributedTest (8%) 2) GEODE-7710: JMXMBeanReconnectDUnitTest

Committing broken javadocs to develop

Please remember to: * fix all broken javadocs before submitting a PR * always review javadocs when reviewing PRs Thanks, Kirk

Re: PR process and etiquette

How about we make this a recommendation rather than a rule? I'd like to also recommend that contributors consider prefixing the PR title with "DRAFT: " while it is in draft. This just makes it easier to see at a glance that it's a draft. When I change the PR to "ready for review" I edit the title

Full diffs in Jira comments

Anyone else notice that we're getting full diffs as comments to Jira tickets again?

Please review PR #5667

GEODE-8647: Support multiple instances of DistributedMap #5667 https://github.com/apache/geode/pull/5667 Thanks, Kirk

Re: [PROPOSAL] Remove "Fix Version/s" and "Sprint" from Jira "Create Issue" dialogue and include "Affects Version/s"

+1 if it's possible On Mon, Aug 17, 2020 at 12:04 PM Donal Evans wrote: > Looking at the dialogue that opens when you attempt to create a new ticket > in the GEODE Jira[1], there are two fields included that aren't really > necessary and may cause confusion. The "Fix Version/s" field should >

Using IgnoredException in Distributed Tests

Hi Geode devs, I published a short article for Geode developers describing how to use IgnoredException in Distributed Tests (DUnit Tests): https://kirklund.github.io/using-ignoredexception-in-distributed-tests/ Feel free to request topics. I'll try to publish more developer articles on whatever

Re: TimeIntegrationTest is flaky

Thanks guys! On Thu, Aug 13, 2020 at 10:47 AM Raymond Ingles wrote: > Yes, we're on it. Thanks! > > On 8/12/20, 7:25 PM, "Kirk Lund" wrote: > > Since this is a new test, can we please prioritize fixing it? > > > https://nam04.safelinks.prote

TimeIntegrationTest is flaky

Since this is a new test, can we please prioritize fixing it? https://issues.apache.org/jira/browse/GEODE-8379 java.lang.AssertionError: Expecting: <0L> to be greater than: <0L> at

Re: Flaky test caused by missing JDK dependency

suggesting that it was only a momentary problem. I'm not sure how easy or practical it is to turn off Java updates on instances running CI jobs. I'll leave that to others to decide. On Wed, Jul 8, 2020 at 1:30 PM Kirk Lund wrote: > The Attach API is optional for Users running the prod

Re: Flaky test caused by missing JDK dependency

on the Attach API optional when we added > support for JDK 11? > > Anthony > > > > On Jul 8, 2020, at 10:17 AM, Kirk Lund wrote: > > > > To transition away from Attach API, the community needs a proposal to do > so > > and we'll need to deprecate the GFSH

Re: Request for wiki permission

Ok, you should be good to go now, Eric! I added you to Geode AND gave you write permissions. On Wed, Jul 8, 2020 at 1:24 PM Kirk Lund wrote: > I see what's missing! > > On Wed, Jul 8, 2020 at 1:04 PM Eric Shu wrote: > >> Here is what I have when I search the na

Re: Request for wiki permission

> IM > Website > > Not sure what else I supposedly to do. > > Regards, > Eric > > From: Kirk Lund > Sent: Wednesday, July 8, 2020 10:44 AM > To: dev@geode.apache.org > Subject: Re: Request for wiki permission >

Re: Request for wiki permission

Hi Eric, I can't find the "eshu" account on https://cwiki.apache.org/. Please make sure you've created the account on that server first. Then I can add the edit permissions for Geode. Thanks, Kirk On Wed, Jul 8, 2020 at 9:58 AM Eric Shu wrote: > Hi, > > I am trying to comment on a wiki doc

Re: about Liberica JDK

In the future, I think we should discuss and propose changing the JDK on this dev-list before making the changes. On Tue, Jul 7, 2020 at 9:01 AM Anthony Baker wrote: > Liberica is an OpenJDK distribution like AdoptOpenJDK, Oracle, RedHat, > Amazon, Azul, etc. I have yet to find a behavioral

Re: Flaky test caused by missing JDK dependency

we transition away > from using it. > ____ > From: Kirk Lund > Sent: Monday, July 6, 2020 10:36 AM > To: dev@geode.apache.org > Subject: Flaky test caused by missing JDK dependency > > CI Failure: > LocatorLauncherRemoteFileI

Flaky test caused by missing JDK dependency

CI Failure: LocatorLauncherRemoteFileIntegrationTest.startDeletesStaleControlFiles failed with ConditionTimeoutException https://issues.apache.org/jira/browse/GEODE-6183 I've debugged the latest occurrence of GEODE-6183 (intermittent failure CI):

Re: Question about gateway sender stopped and memory consumption

I would have expected unsent events to be stored in a queue that is backed by a persistent region or something on disk. If that's not currently true, then it seems like a good direction might be to make tmpDroppedEvents use a durable queue of some sort that overflows to disk. On Thu, Jul 2,

Re: Us vs Docker vs Gradle vs JUnit

I'm not a big fan of forking the Docker plugin and making it a new Geode submodule. This approach kind of flies in the face of the intentions of OSS in general. For example, we want folks contributing to Apache Geode rather than forking Geode to create their own new project while never giving back

  1   2   3   4   5   6   7   8   9   10   >