Help With ClusterStartupRuleCanSpecifyOlderVersionsDUnitTest

Hello all, Working through GEODE-5739 I've modified *ServerStarterRule* and *LocatorStarterRule* to use the public *ServerLauncher* and *LocatorLauncher* classes respectively, instead of the internal APIs to start up the members. As part of the ch

Re: [Discuss] Where should simple classes for tests belong?

For testing functionality like 'gfsh deploy' one has to be aware of classloading issues. Specifically, when writing dunit tests, classes are compiled from java resource files so that they are guaranteed not to be on the classpath during testing. This is less of an issue for gfsh acceptance tests wh

Re: [Discuss] Where should simple classes for tests belong?

+1 to what Jens said. The test jar is very specific to the test itself. Does not need to be in the src at all. It should disappear when the test finishes. There is no need for it to be in the build process at all. Producing it inside the test itself is a much cleaner way for the developer/maintaine

Re: [Discuss] Where should simple classes for tests belong?

+1 to what Jens & Jinmei & Kirk have said. It is far easier to have a local definition of the "toy" classes. Yes, it makes the code base "larger" and most good editors would flag it as duplicate code, BUT it is about localization and making sure that one can easily see what classes are part of

Re: Queries on key fields

Jason, We are using the Map feature of GemFire and update throws CommitComflict exceptions when the same key is updated from multiple places at the same time, how can this be resolved ? This happens only at high contention though. We are retrying , but still even after a couple of retries it does

Re: Queries on key fields

Hello Siby, I think we should keep this conversation based on Geode if possible. I think GemFire has their own support channels that you might be able to contact for help specific to GemFire... As for the commit conflicts, I assume you are using transactions? Also, I am not aware of a specific M

Pipeline names changing shortly

In order to standardize CI deployment and to improve quality of life around running pipelines for forks, we've merged a number of changes to the ci/ directory which will create new pipelines for the develop branch. If you have direct links to specific pipelines (specifically develop ones) those lin

[Spring CI] Spring Data GemFire > Nightly-ApacheGeode > #1071 was SUCCESSFUL (with 2456 tests). Change made by Mark Paluch.

--- Spring Data GemFire > Nightly-ApacheGeode > #1071 was successful. --- Scheduled with changes by Mark Paluch. 2458 tests in total. https://build.spring.io/bro

Re: Pipeline names changing shortly

New pipelines for develop (apache-develop-main) and PR (apache-develop-pr) are up. We'll bring up the rest of the pipelines (metrics, examples, etc.) tomorrow. On Mon, Oct 15, 2018 at 3:03 PM Sean Goller wrote: > In order to standardize CI deployment and to improve quality of life > around runni