Re: [DISCUSS] - Create new repository for geode benchmarks

[Juan José Ramos]

+1

On Thu, Nov 15, 2018 at 8:22 PM Udo Kohlmeyer  wrote:

> +1, never thought there was any other option...
>
>
> On 11/15/18 10:47, Dan Smith wrote:
> > Hi all,
> >
> > We (Naba, Sean, Brian and I) would like to add some benchmarks for geode,
> > with a goal of eventually running them as part of our concourse build and
> > detecting performance changes.
> >
> > We think it makes sense to put these benchmarks in a separate
> > geode-benchmarks repository. That will make them less tightly coupled to
> a
> > specific revision of geode. What do you all think? If folks are okay with
> > this, I will go ahead and create the repository.
> >
> > We have some prototype code in this repository with a simple
> client/server
> > put benchmark:  https://github.com/upthewaterspout/geode-performance.
> >
> > -Dan
> >
>
>

-- 
Juan José Ramos Cassella
Senior Technical Support Engineer
Email: jra...@pivotal.io
Office#: +353 21 4238611
Mobile#: +353 87 2074066
After Hours Contact#: +1 877 477 2269
Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
How to upload artifacts:
https://support.pivotal.io/hc/en-us/articles/204369073
How to escalate a ticket:
https://support.pivotal.io/hc/en-us/articles/203809556

[image: support]  [image: twitter]
 [image: linkedin]
 [image: facebook]
 [image: google plus]
 [image: youtube]

Re: [DISCUSS] - Create new repository for geode benchmarks

[Kirk Lund]

That makes sense for some benchmarks but not others. For example, while
working on the Logging changes, I wrote a some benchmarks that directly use
some new internal code to ensure that the new changes perform well.

+1 to creating a benchmarks repo that has general perf tests that will be
run in the pipelines

-1 to getting rid of benchmarks from geode-core or any other submodule
because this will discourage developers from writing benchmarks specific to
new code as they write it -- we shouldn't be forced to write benchmarks
AFTER we commit to the main geode repo (or worse, after a release)

On Thu, Nov 15, 2018 at 10:47 AM Dan Smith  wrote:

> Hi all,
>
> We (Naba, Sean, Brian and I) would like to add some benchmarks for geode,
> with a goal of eventually running them as part of our concourse build and
> detecting performance changes.
>
> We think it makes sense to put these benchmarks in a separate
> geode-benchmarks repository. That will make them less tightly coupled to a
> specific revision of geode. What do you all think? If folks are okay with
> this, I will go ahead and create the repository.
>
> We have some prototype code in this repository with a simple client/server
> put benchmark:  https://github.com/upthewaterspout/geode-performance.
>
> -Dan
>

Re: Questions about Poms and Publishing

[Robert Houghton]

Thanks John.

Do you foresee the native Gradle DSL
https://docs.gradle.org/current/userguide/managing_transitive_dependencies.html
as an *eventual* replacement for the dependency-management-plugin you
reference?

On Tue, Nov 13, 2018 at 9:09 AM John Blum  wrote:

> If you'd like Maven dependencyManagement like behavior in Gradle, then you
> should have a look at...
>
> https://github.com/spring-gradle-plugins/dependency-management-plugin
>
> -j
>
> On Tue, Nov 13, 2018 at 8:10 AM, Bill Burcham  wrote:
>
> > @Patrick Rhomberg  I've never seen the
> > dependencyManagement element survive in a published POM before.
> >
> > Since it sounds like you're asserting that you saw that element in a
> > published POM (published by Gradle), I decided to verify that. I ran this
> > from the Geode develop branch just now:
> >
> > ./gradlew build publishMavenPublicationToMavenLocal -x javadoc
> > -Dskip.tests=true
> >
> > When I look
> > at ~/.m2/repository/org/apache/geode/geode-core/1.9.0-
> > SNAPSHOT/geode-core-1.9.0-SNAPSHOT.pom
> > I see no dependencyManagement section.
> >
> > The absence of that element comports with my experience. My experience w/
> > the dependencyManagement element is that it is used when you're using
> Maven
> > to manage your build. It is wonderful for DRYing up what would otherwise
> be
> > unmanageable version information spread among lots of pom.xml (source)
> > file.
> >
> > "dependency constraints" in Gradle sounds like it'd be a big step forward
> > for similar reasons. I'd assume that "dependency constraints" don't
> result
> > in a dependencyManagement element in any published POM file though.
> >
> >
> > On Wed, Nov 7, 2018 at 10:00 AM Jacob Barrett 
> wrote:
> >
> > > The dependency management element applies dependency constraints to
> first
> > > class dependencies and transitive dependencies. For example in
> dependency
> > > management of this say A:1 and B:2 it does not mean your module will
> > > necessarily depend on A:1 and B:2 but if the module or transitive
> module
> > > does that the versions will be nudged to match these constraints. So
> then
> > > if you module you have a dependency section that includes A it will
> > become
> > > A:1 and if A:1 depends on B:1 then B:1 will be nudged to B:2.
> > >
> > > -Jake
> > >
> > >
> > > > On Nov 6, 2018, at 3:25 PM, Anthony Baker  wrote:
> > > >
> > > > I want reproducible builds.  If dependency locking [1] works I would
> be
> > > open to dynamic versions [2].
> > > >
> > > > Anthony
> > > >
> > > > [1]
> https://docs.gradle.org/current/userguide/dependency_locking.html
> > > > [2]
> > > https://docs.gradle.org/current/userguide/declaring_
> > dependencies.html#sub:declaring_dependency_with_dynamic_version
> > > >
> > > >
> > > >
> > > >> On Nov 6, 2018, at 3:02 PM, Patrick Rhomberg 
> > > wrote:
> > > >>
> > > >> My current question surrounds the structure of POMs in specifying
> > > version
> > > >> information.  Gradle supports `dependency constraints` to unify
> > library
> > > >> versioning.  This seems to me to be a clean, concise alternative to
> > our
> > > >> current approach of cluttering the project property space with
> > > >> project.'library.version', with mixed adherence throughout our build
> > > files.
> > > >
> > >
> >
>
>
>
> --
> -John
> john.blum10101 (skype)
>

Re: [DISCUSS] - Create new repository for geode benchmarks

[Dan Smith]

Hi Kirk,

What we're thinking of putting in geode-benchmarks are new, multi host
benchmarks of the full system with the public APIs, not microbenchmarks. We
weren't planning on doing anything with the JMH benchmarks at the moment. I
agree with you those should stay in the geode module they are testing,
since they generally are microbenchmarking internal APIs of that module.

I appreciate you bringing those up though - I would like to get to the
point where we are running those microbenchmarks in CI as well!

-Dan

On Fri, Nov 16, 2018 at 9:07 AM Kirk Lund  wrote:

> That makes sense for some benchmarks but not others. For example, while
> working on the Logging changes, I wrote a some benchmarks that directly use
> some new internal code to ensure that the new changes perform well.
>
> +1 to creating a benchmarks repo that has general perf tests that will be
> run in the pipelines
>
> -1 to getting rid of benchmarks from geode-core or any other submodule
> because this will discourage developers from writing benchmarks specific to
> new code as they write it -- we shouldn't be forced to write benchmarks
> AFTER we commit to the main geode repo (or worse, after a release)
>
> On Thu, Nov 15, 2018 at 10:47 AM Dan Smith  wrote:
>
> > Hi all,
> >
> > We (Naba, Sean, Brian and I) would like to add some benchmarks for geode,
> > with a goal of eventually running them as part of our concourse build and
> > detecting performance changes.
> >
> > We think it makes sense to put these benchmarks in a separate
> > geode-benchmarks repository. That will make them less tightly coupled to
> a
> > specific revision of geode. What do you all think? If folks are okay with
> > this, I will go ahead and create the repository.
> >
> > We have some prototype code in this repository with a simple
> client/server
> > put benchmark:  https://github.com/upthewaterspout/geode-performance.
> >
> > -Dan
> >
>

Re: Questions about Poms and Publishing

[John Blum]

Good question, and that may be a better question for Andy Wilkinson to
answer since Andy created the Gradle dependencyManagement plugin.  We/I use
it quite extensively and with good results.

On Fri, Nov 16, 2018 at 9:38 AM Robert Houghton 
wrote:

> Thanks John.
>
> Do you foresee the native Gradle DSL
>
> https://docs.gradle.org/current/userguide/managing_transitive_dependencies.html
> as an *eventual* replacement for the dependency-management-plugin you
> reference?
>
> On Tue, Nov 13, 2018 at 9:09 AM John Blum  wrote:
>
> > If you'd like Maven dependencyManagement like behavior in Gradle, then
> you
> > should have a look at...
> >
> > https://github.com/spring-gradle-plugins/dependency-management-plugin
> >
> > -j
> >
> > On Tue, Nov 13, 2018 at 8:10 AM, Bill Burcham 
> wrote:
> >
> > > @Patrick Rhomberg  I've never seen the
> > > dependencyManagement element survive in a published POM before.
> > >
> > > Since it sounds like you're asserting that you saw that element in a
> > > published POM (published by Gradle), I decided to verify that. I ran
> this
> > > from the Geode develop branch just now:
> > >
> > > ./gradlew build publishMavenPublicationToMavenLocal -x javadoc
> > > -Dskip.tests=true
> > >
> > > When I look
> > > at ~/.m2/repository/org/apache/geode/geode-core/1.9.0-
> > > SNAPSHOT/geode-core-1.9.0-SNAPSHOT.pom
> > > I see no dependencyManagement section.
> > >
> > > The absence of that element comports with my experience. My experience
> w/
> > > the dependencyManagement element is that it is used when you're using
> > Maven
> > > to manage your build. It is wonderful for DRYing up what would
> otherwise
> > be
> > > unmanageable version information spread among lots of pom.xml (source)
> > > file.
> > >
> > > "dependency constraints" in Gradle sounds like it'd be a big step
> forward
> > > for similar reasons. I'd assume that "dependency constraints" don't
> > result
> > > in a dependencyManagement element in any published POM file though.
> > >
> > >
> > > On Wed, Nov 7, 2018 at 10:00 AM Jacob Barrett 
> > wrote:
> > >
> > > > The dependency management element applies dependency constraints to
> > first
> > > > class dependencies and transitive dependencies. For example in
> > dependency
> > > > management of this say A:1 and B:2 it does not mean your module will
> > > > necessarily depend on A:1 and B:2 but if the module or transitive
> > module
> > > > does that the versions will be nudged to match these constraints. So
> > then
> > > > if you module you have a dependency section that includes A it will
> > > become
> > > > A:1 and if A:1 depends on B:1 then B:1 will be nudged to B:2.
> > > >
> > > > -Jake
> > > >
> > > >
> > > > > On Nov 6, 2018, at 3:25 PM, Anthony Baker 
> wrote:
> > > > >
> > > > > I want reproducible builds.  If dependency locking [1] works I
> would
> > be
> > > > open to dynamic versions [2].
> > > > >
> > > > > Anthony
> > > > >
> > > > > [1]
> > https://docs.gradle.org/current/userguide/dependency_locking.html
> > > > > [2]
> > > > https://docs.gradle.org/current/userguide/declaring_
> > > dependencies.html#sub:declaring_dependency_with_dynamic_version
> > > > >
> > > > >
> > > > >
> > > > >> On Nov 6, 2018, at 3:02 PM, Patrick Rhomberg <
> prhomb...@apache.org>
> > > > wrote:
> > > > >>
> > > > >> My current question surrounds the structure of POMs in specifying
> > > > version
> > > > >> information.  Gradle supports `dependency constraints` to unify
> > > library
> > > > >> versioning.  This seems to me to be a clean, concise alternative
> to
> > > our
> > > > >> current approach of cluttering the project property space with
> > > > >> project.'library.version', with mixed adherence throughout our
> build
> > > > files.
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> > -John
> > john.blum10101 (skype)
> >
>


-- 
-John
john.blum10101 (skype)

Spring detecting MockPluginCommand and logging WARN in integration tests

[Kirk Lund]

The new logging tests assert that when you create a Cache, there are no
WARN log statements being logged.

Unfortunately, src/tests (unit tests) is in the classpath of integration
tests (CacheWithCustomLogConfigIntegrationTest is an integration test).
Apparently springshell gets kicked on when we create a cache, it finds
org.apache.geode.management.internal.cli.CommandManagerJUnitTest$MockPluginCommand
because it's annotated as a springshell Command and then Spring logs this:

[Logger=org.apache.geode Level=WARN Message=(tid=25 msgId=0) Could not load
plugin command: org.springframework.shell.core.CommandMarker: Provider
org.apache.geode.management.internal.cli.CommandManagerJUnitTest$MockPluginCommand
not found]

My test is NOT logging that, Spring is. So how do we fix this? Should I try
to ignore WARN log statements in my logging tests that involve Spring?

org.apache.geode.internal.logging.log4j.CacheWithCustomLogConfigIntegrationTest
> cacheLogWriterInfoMessageIsSuppressed FAILED
java.lang.AssertionError:
Expecting empty but was:<[Logger=org.apache.geode Level=WARN
Message=(tid=25 msgId=0) Could not load plugin command:
org.springframework.shell.core.CommandMarker: Provider
org.apache.geode.management.internal.cli.CommandManagerJUnitTest$MockPluginCommand
not found]>
at
org.apache.geode.internal.logging.log4j.CacheWithCustomLogConfigIntegrationTest.cacheLogWriterInfoMessageIsSuppressed(CacheWithCustomLogConfigIntegrationTest.java:134)

Re: Spring detecting MockPluginCommand and logging WARN in integration tests

[Kirk Lund]

I checked the DUnit grep for suspect strings and it's ignore WARNING log
level. So we may DUnit tests that are generating the same warning log from
org.springframework.shell.core.CommandMarker without causing any tests to
fail.

On Fri, Nov 16, 2018 at 12:43 PM Kirk Lund  wrote:

> The new logging tests assert that when you create a Cache, there are no
> WARN log statements being logged.
>
> Unfortunately, src/tests (unit tests) is in the classpath of integration
> tests (CacheWithCustomLogConfigIntegrationTest is an integration test).
> Apparently springshell gets kicked on when we create a cache, it finds
> org.apache.geode.management.internal.cli.CommandManagerJUnitTest$MockPluginCommand
> because it's annotated as a springshell Command and then Spring logs this:
>
> [Logger=org.apache.geode Level=WARN Message=(tid=25 msgId=0) Could not
> load plugin command: org.springframework.shell.core.CommandMarker: Provider
> org.apache.geode.management.internal.cli.CommandManagerJUnitTest$MockPluginCommand
> not found]
>
> My test is NOT logging that, Spring is. So how do we fix this? Should I
> try to ignore WARN log statements in my logging tests that involve Spring?
>
> org.apache.geode.internal.logging.log4j.CacheWithCustomLogConfigIntegrationTest
> > cacheLogWriterInfoMessageIsSuppressed FAILED
> java.lang.AssertionError:
> Expecting empty but was:<[Logger=org.apache.geode Level=WARN
> Message=(tid=25 msgId=0) Could not load plugin command:
> org.springframework.shell.core.CommandMarker: Provider
> org.apache.geode.management.internal.cli.CommandManagerJUnitTest$MockPluginCommand
> not found]>
> at
> org.apache.geode.internal.logging.log4j.CacheWithCustomLogConfigIntegrationTest.cacheLogWriterInfoMessageIsSuppressed(CacheWithCustomLogConfigIntegrationTest.java:134)
>

Re: [DISCUSS] - Create new repository for geode benchmarks

[Kenneth Howe]

+1 to Dan’s proposal - just makes sense

> On Nov 16, 2018, at 10:05 AM, Dan Smith  wrote:
> 
> Hi Kirk,
> 
> What we're thinking of putting in geode-benchmarks are new, multi host
> benchmarks of the full system with the public APIs, not microbenchmarks. We
> weren't planning on doing anything with the JMH benchmarks at the moment. I
> agree with you those should stay in the geode module they are testing,
> since they generally are microbenchmarking internal APIs of that module.
> 
> I appreciate you bringing those up though - I would like to get to the
> point where we are running those microbenchmarks in CI as well!
> 
> -Dan
> 
> On Fri, Nov 16, 2018 at 9:07 AM Kirk Lund  wrote:
> 
>> That makes sense for some benchmarks but not others. For example, while
>> working on the Logging changes, I wrote a some benchmarks that directly use
>> some new internal code to ensure that the new changes perform well.
>> 
>> +1 to creating a benchmarks repo that has general perf tests that will be
>> run in the pipelines
>> 
>> -1 to getting rid of benchmarks from geode-core or any other submodule
>> because this will discourage developers from writing benchmarks specific to
>> new code as they write it -- we shouldn't be forced to write benchmarks
>> AFTER we commit to the main geode repo (or worse, after a release)
>> 
>> On Thu, Nov 15, 2018 at 10:47 AM Dan Smith  wrote:
>> 
>>> Hi all,
>>> 
>>> We (Naba, Sean, Brian and I) would like to add some benchmarks for geode,
>>> with a goal of eventually running them as part of our concourse build and
>>> detecting performance changes.
>>> 
>>> We think it makes sense to put these benchmarks in a separate
>>> geode-benchmarks repository. That will make them less tightly coupled to
>> a
>>> specific revision of geode. What do you all think? If folks are okay with
>>> this, I will go ahead and create the repository.
>>> 
>>> We have some prototype code in this repository with a simple
>> client/server
>>> put benchmark:  https://github.com/upthewaterspout/geode-performance.
>>> 
>>> -Dan
>>> 
>> 

Re: Spring detecting MockPluginCommand and logging WARN in integration tests

[Jens Deppe]

If this test is already applying a custom log configuration, could it not
also turn down the logging for org.springframework.shell?

--Jens

On Fri, Nov 16, 2018 at 12:53 PM Kirk Lund  wrote:

> I checked the DUnit grep for suspect strings and it's ignore WARNING log
> level. So we may DUnit tests that are generating the same warning log from
> org.springframework.shell.core.CommandMarker without causing any tests to
> fail.
>
> On Fri, Nov 16, 2018 at 12:43 PM Kirk Lund  wrote:
>
> > The new logging tests assert that when you create a Cache, there are no
> > WARN log statements being logged.
> >
> > Unfortunately, src/tests (unit tests) is in the classpath of integration
> > tests (CacheWithCustomLogConfigIntegrationTest is an integration test).
> > Apparently springshell gets kicked on when we create a cache, it finds
> >
> org.apache.geode.management.internal.cli.CommandManagerJUnitTest$MockPluginCommand
> > because it's annotated as a springshell Command and then Spring logs
> this:
> >
> > [Logger=org.apache.geode Level=WARN Message=(tid=25 msgId=0) Could not
> > load plugin command: org.springframework.shell.core.CommandMarker:
> Provider
> >
> org.apache.geode.management.internal.cli.CommandManagerJUnitTest$MockPluginCommand
> > not found]
> >
> > My test is NOT logging that, Spring is. So how do we fix this? Should I
> > try to ignore WARN log statements in my logging tests that involve
> Spring?
> >
> >
> org.apache.geode.internal.logging.log4j.CacheWithCustomLogConfigIntegrationTest
> > > cacheLogWriterInfoMessageIsSuppressed FAILED
> > java.lang.AssertionError:
> > Expecting empty but was:<[Logger=org.apache.geode Level=WARN
> > Message=(tid=25 msgId=0) Could not load plugin command:
> > org.springframework.shell.core.CommandMarker: Provider
> >
> org.apache.geode.management.internal.cli.CommandManagerJUnitTest$MockPluginCommand
> > not found]>
> > at
> >
> org.apache.geode.internal.logging.log4j.CacheWithCustomLogConfigIntegrationTest.cacheLogWriterInfoMessageIsSuppressed(CacheWithCustomLogConfigIntegrationTest.java:134)
> >
>

Re: Spring detecting MockPluginCommand and logging WARN in integration tests

[Kirk Lund]

Yep! I have a fixed version now that will not fail due to springshell.

On Fri, Nov 16, 2018 at 1:07 PM Jens Deppe  wrote:

> If this test is already applying a custom log configuration, could it not
> also turn down the logging for org.springframework.shell?
>
> --Jens
>
> On Fri, Nov 16, 2018 at 12:53 PM Kirk Lund  wrote:
>
> > I checked the DUnit grep for suspect strings and it's ignore WARNING log
> > level. So we may DUnit tests that are generating the same warning log
> from
> > org.springframework.shell.core.CommandMarker without causing any tests to
> > fail.
> >
> > On Fri, Nov 16, 2018 at 12:43 PM Kirk Lund  wrote:
> >
> > > The new logging tests assert that when you create a Cache, there are no
> > > WARN log statements being logged.
> > >
> > > Unfortunately, src/tests (unit tests) is in the classpath of
> integration
> > > tests (CacheWithCustomLogConfigIntegrationTest is an integration test).
> > > Apparently springshell gets kicked on when we create a cache, it finds
> > >
> >
> org.apache.geode.management.internal.cli.CommandManagerJUnitTest$MockPluginCommand
> > > because it's annotated as a springshell Command and then Spring logs
> > this:
> > >
> > > [Logger=org.apache.geode Level=WARN Message=(tid=25 msgId=0) Could not
> > > load plugin command: org.springframework.shell.core.CommandMarker:
> > Provider
> > >
> >
> org.apache.geode.management.internal.cli.CommandManagerJUnitTest$MockPluginCommand
> > > not found]
> > >
> > > My test is NOT logging that, Spring is. So how do we fix this? Should I
> > > try to ignore WARN log statements in my logging tests that involve
> > Spring?
> > >
> > >
> >
> org.apache.geode.internal.logging.log4j.CacheWithCustomLogConfigIntegrationTest
> > > > cacheLogWriterInfoMessageIsSuppressed FAILED
> > > java.lang.AssertionError:
> > > Expecting empty but was:<[Logger=org.apache.geode Level=WARN
> > > Message=(tid=25 msgId=0) Could not load plugin command:
> > > org.springframework.shell.core.CommandMarker: Provider
> > >
> >
> org.apache.geode.management.internal.cli.CommandManagerJUnitTest$MockPluginCommand
> > > not found]>
> > > at
> > >
> >
> org.apache.geode.internal.logging.log4j.CacheWithCustomLogConfigIntegrationTest.cacheLogWriterInfoMessageIsSuppressed(CacheWithCustomLogConfigIntegrationTest.java:134)
> > >
> >
>

Re: [DISCUSS] - Create new repository for geode benchmarks

[Kirk Lund]

+1 total agreement then!

On Fri, Nov 16, 2018 at 10:05 AM Dan Smith  wrote:

> Hi Kirk,
>
> What we're thinking of putting in geode-benchmarks are new, multi host
> benchmarks of the full system with the public APIs, not microbenchmarks. We
> weren't planning on doing anything with the JMH benchmarks at the moment. I
> agree with you those should stay in the geode module they are testing,
> since they generally are microbenchmarking internal APIs of that module.
>
> I appreciate you bringing those up though - I would like to get to the
> point where we are running those microbenchmarks in CI as well!
>
> -Dan
>
> On Fri, Nov 16, 2018 at 9:07 AM Kirk Lund  wrote:
>
> > That makes sense for some benchmarks but not others. For example, while
> > working on the Logging changes, I wrote a some benchmarks that directly
> use
> > some new internal code to ensure that the new changes perform well.
> >
> > +1 to creating a benchmarks repo that has general perf tests that will be
> > run in the pipelines
> >
> > -1 to getting rid of benchmarks from geode-core or any other submodule
> > because this will discourage developers from writing benchmarks specific
> to
> > new code as they write it -- we shouldn't be forced to write benchmarks
> > AFTER we commit to the main geode repo (or worse, after a release)
> >
> > On Thu, Nov 15, 2018 at 10:47 AM Dan Smith  wrote:
> >
> > > Hi all,
> > >
> > > We (Naba, Sean, Brian and I) would like to add some benchmarks for
> geode,
> > > with a goal of eventually running them as part of our concourse build
> and
> > > detecting performance changes.
> > >
> > > We think it makes sense to put these benchmarks in a separate
> > > geode-benchmarks repository. That will make them less tightly coupled
> to
> > a
> > > specific revision of geode. What do you all think? If folks are okay
> with
> > > this, I will go ahead and create the repository.
> > >
> > > We have some prototype code in this repository with a simple
> > client/server
> > > put benchmark:  https://github.com/upthewaterspout/geode-performance.
> > >
> > > -Dan
> > >
> >
>

GEODE Slack?

[Ernest Burghardt]

Hi Geode,

Will there be a GEODE Slack in the near future?

Thanks,
EB

Re: GEODE Slack?

[Nabarun Nag]

It’s already present. You can find it at
http://the-asf.slack.com/

On Fri, Nov 16, 2018 at 3:22 PM Ernest Burghardt 
wrote:

> Hi Geode,
>
> Will there be a GEODE Slack in the near future?
>
> Thanks,
> EB
>
-- 
Regards
Nabarun Nag

Re: GEODE Slack?

[Kirk Lund]

https://join.slack.com/t/the-asf/shared_invite/enQtNDQ3OTEwNzE1MDg5LWY2NjkwMTEzMGI2ZTI1NzUzMDk0MzJmMWM1NWVmODg0MzBjNjAxYzUwMjIwNDI3MjlhZWRjNmNhOTM5NmIxNDk

#geode

On Fri, Nov 16, 2018 at 3:22 PM Ernest Burghardt 
wrote:

> Hi Geode,
>
> Will there be a GEODE Slack in the near future?
>
> Thanks,
> EB
>

Re: [DISCUSS] Deprecating JUnit4CacheTestCase (and maybe JUnit4DistributedTestCase?)

[Galen O'Sullivan]

I have a PR up to deprecate these classes and several other distributed
test classes that use inheritance (I actually forgot to mention it here
when I first put it up, whoops): https://github.com/apache/geode/pull/2841
I intend to merge it Monday evening if there are no objections.

I think I'll try to use the public facing APIs the next time I write a new
test and see how it goes.

Thanks,
Galen

On Mon, Nov 12, 2018 at 8:41 AM Jinmei Liao  wrote:

> I feel like we are mixing two topic in this discussion. One is to improve
> our user API, and one is to write clean tests. Doing one doesn't have to
> sacrifice the other. If our rules are using internal APIs, then it's a
> chance to check if we can improve our APIs like Kirk has done. But stop
> using the rules or change the rules to use a more verbose API should not
> the way to go. My 2 cents.
>
> On Mon, Nov 12, 2018 at 4:22 AM Juan José Ramos  wrote:
>
> > Hello all,
> >
> > What about mixing both approaches?.
> > We can use the *Rules* to avoid duplication of code *but re-write them*
> to
> > directly use the Geode User APIs instead of the Geode Internal API.
> > Just for the record, https://issues.apache.org/jira/browse/GEODE-5739
> was
> > created for something similar (use [Server|Locator]Launcher instead of
> > internal API in [Server|Locator]StarterRule), but it didn't get enough
> > consent to be merged (leaving aside the huge amount of unrelated changes
> in
> > the PR, the idea itself was rejected).
> > Cheers.
> >
> >
> > On Fri, Nov 9, 2018 at 11:55 PM Jinmei Liao  wrote:
> >
> > > Yeah, I guess. But why going out of this way to avoid using rules? Why
> > > rules are bad? Rules just encapsulate common befores and afters to
> avoid
> > > duplicate code in every tests. I don't see why we should avoid using
> it.
> > >
> > > On Fri, Nov 9, 2018, 3:44 PM Galen O'Sullivan  > > wrote:
> > >
> > > > I wonder if we could use some sort of assertions to validate that
> that
> > > > tests have cleaned up, at least in a few ways? For example, if a
> > > > Cache/Locator/DistributedSystem is still running after a test has
> > > finished,
> > > > that's a good sign of a dirty environment. If system properties are
> > still
> > > > set, that's a good sign of a dirty environment. We could use a custom
> > > test
> > > > runner, or even add a rule to all our tests en masse that checks that
> > > > things are cleaned up.
> > > >
> > > > Jinmei, for single-JVM tests, you could write a method for your test
> > (or
> > > > test class) that sets whatever properties you need and returns a
> Cache
> > > > constructed with those properties. Then you can use
> try-with-resources
> > to
> > > > make sure that the Cache is properly closed. Is that a good
> alternative
> > > to
> > > > using a rule?
> > > >
> > > > On Fri, Nov 9, 2018 at 3:28 PM Helena Bales 
> wrote:
> > > >
> > > > > +1 for deprecating old test bases. Many of the tests that gave me
> the
> > > > most
> > > > > trouble this summer were because of JUnit4CacheTestCase.
> > > > > Also +1 for pulling out Blackboard into a rule.
> > > > >
> > > > > I will, however, argue for continuing to use ClusterStartupRule.
> The
> > > > > benefit of that is that it makes sure that all JVMs started for
> > servers
> > > > and
> > > > > locators are cleaned up at the end of the tests, even if the tests
> > > fail.
> > > > We
> > > > > could certainly spend time making that code easier to understand,
> > but I
> > > > > don't think that starting clusters is straightforward enough to
> have
> > > > > confidence that it will get done correctly every time.
> Multi-threaded
> > > > tests
> > > > > should be a cautionary tale for this; some implementations were
> fine,
> > > but
> > > > > many polluted the system with threads that never stopped and tests
> > that
> > > > > didn't actually test anything.
> > > > > As I see it, we are paying in readability for tests that do things
> > the
> > > > > right way.
> > > > >
> > > > > On Fri, Nov 9, 2018 at 2:31 PM Kirk Lund  wrote:
> > > > >
> > > > > > I would love to see you apply some of your passion for that to
> > > > improving
> > > > > > the User APIs so there's less boiler plate code for the Users as
> > > well.
> > > > > >
> > > > > > Please don't forget that to Developers who are not familiar with
> > our
> > > > > Rules
> > > > > > such as ClusterStarterRule, that it can be very difficult to
> > > understand
> > > > > > what it has done and how it has configured Geode. The more the
> Rule
> > > > does,
> > > > > > the greater this problem. The fact that most of these Rules use
> > > > Internal
> > > > > > APIs instead of User APIs is also a problem in my opinion because
> > > we're
> > > > > not
> > > > > > testing exactly what a User would do or can do.
> > > > > >
> > > > > > To many of us Developers, figuring out what all the rules have
> > > > configured
> > > > > > and done is a much bigger problem than it is to deal with verbose
> > > code
> > > > > in a
> > > > > > se