Re: Dependency review for release 1.9.0

[John Blum]

Well, that just requires that you appropriately declare dependencies with
the "optionality" and "scope" (e.g. "compile", "test", "provided", etc).

Additionally, Geode modules could selectively pull in the required deps as
needed.  For example, `geode-lucene` would only pull in the Apache Lucene
dependencies if the `geode-lucene` module is used.

No brainer.

On Thu, Feb 28, 2019 at 9:47 AM Charlie Black  wrote:

> Hopefully, we are thinking about classpath of the server and lazily adding
> these jars only when a feature is turned on.
>
> On Thu, Feb 28, 2019 at 9:45 AM Dan Smith  wrote:
>
> > I see that geo, grumpy-core, and commons math came from adding geospatial
> > support to redis -
> >
> >
> https://github.com/apache/geode/commit/7bf02251fd047cb1cf575c01b80a9807108618da
> >
> > -Dan
> >
> > On Thu, Feb 28, 2019 at 9:41 AM Anthony Baker  wrote:
> >
> > > Looks a number of the new dependencies came in transitively with the
> > guava
> > > version bump.
> > >
> > > > On Feb 27, 2019, at 5:32 PM, Anthony Baker 
> wrote:
> > > >
> > > > I was reviewing the release branch and noticed a number of new
> > > dependencies have been added since the last release.  When you add a
> new
> > > dependency, please review and follow the project license guide [1].  In
> > > particular, update the LICENSE file in geode-assembly/src/main/dist
> > > depending on the license type.
> > > >
> > > > Currently we need to update the LICENSE file with the additional
> > > MIT/BSD/CDDL dependencies.  We may also need to update NOTICE files.
> > > There’s also a version conflict with multiple versions of Jackson in
> use
> > > (2.9.6 / 2.9.8).
> > > >
> > > > @Sai - these need to be fixed on release/1.9.0
> > > >
> > > > Here’s the list of additions:
> > > >
> > > >   animal-sniffer-annotations-1.17.jar
> > > >   checker-qual-2.5.2.jar
> > > >   commons-math3-3.2.jar
> > > >   error_prone_annotations-2.2.0.jar
> > > >   failureaccess-1.0.jar
> > > >   geo-0.7.1.jar
> > > >   grumpy-core-0.2.2.jar
> > > >   istack-commons-runtime-2.2.jar
> > > >   j2objc-annotations-1.1.jar
> > > >   javax.activation-1.2.0.jar
> > > >   javax.activation-api-1.2.0.jar
> > > >   jsr305-3.0.2.jar
> > > >   listenablefuture-.0-empty-to-avoid-conflict-with-guava.jar
> > > >
> > > > Removed:
> > > >
> > > >   activation-1.1.1
> > > >   jaxb-core-2.2.11.jar
> > > >
> > > > Anthony
> > > >
> > > > [1]
> > >
> >
> https://cwiki.apache.org/confluence/display/GEODE/License+Guide+for+Contributors
> > > <
> > >
> >
> https://cwiki.apache.org/confluence/display/GEODE/License+Guide+for+Contributors
> > > >
> > > >
> > >
> > >
> >
>
>
> --
> Charlie Black | cbl...@pivotal.io
>


-- 
-John
john.blum10101 (skype)

Re: Dependency review for release 1.9.0

[John Blum]

Dan-

2 things:

1) Users and customers (alike), in certain cases, do launch Geode Servers
using Spring Boot, either with java -jar and a FAT JAR or other ways.

2) I have been saying for sometime now that I think it would be nice to be
able to launch a server using a classpath configured with a Maven POM file,
sort of like...

gfsh> start server --name=X --maven-pom=/path/to/maven/pom.xml

--mave-pom would set the server classpath accordingly and reliably.  All
too often, users/customers miss critical dependencies on the cluster
servers' classpath, especially transitive dependencies, that are required
by their application artifacts: custom CacheLoaders, Functions, etc.

Food for thought.

-John




On Thu, Feb 28, 2019 at 10:22 AM Dan Smith  wrote:

> Currently, geode servers just have a flat classpath with all of the
> dependencies of all of the modules. Having the ability to add optional
> modules sounds like a good feature, though.
>
> John - what you are describing applies to maven dependencies - and I do
> think that we should isolate optional features into separate maven
> dependencies like geode-lucene. But that doesn't help with servers launched
> through gfsh start server unless we provide a way to configure which geode
> modules are present on the server's classpath.
>
> -Dan
>
> On Thu, Feb 28, 2019 at 10:03 AM John Blum  wrote:
>
> > Well, that just requires that you appropriately declare dependencies with
> > the "optionality" and "scope" (e.g. "compile", "test", "provided", etc).
> >
> > Additionally, Geode modules could selectively pull in the required deps
> as
> > needed.  For example, `geode-lucene` would only pull in the Apache Lucene
> > dependencies if the `geode-lucene` module is used.
> >
> > No brainer.
> >
> > On Thu, Feb 28, 2019 at 9:47 AM Charlie Black  wrote:
> >
> > > Hopefully, we are thinking about classpath of the server and lazily
> > adding
> > > these jars only when a feature is turned on.
> > >
> > > On Thu, Feb 28, 2019 at 9:45 AM Dan Smith  wrote:
> > >
> > > > I see that geo, grumpy-core, and commons math came from adding
> > geospatial
> > > > support to redis -
> > > >
> > > >
> > >
> >
> https://github.com/apache/geode/commit/7bf02251fd047cb1cf575c01b80a9807108618da
> > > >
> > > > -Dan
> > > >
> > > > On Thu, Feb 28, 2019 at 9:41 AM Anthony Baker 
> > wrote:
> > > >
> > > > > Looks a number of the new dependencies came in transitively with
> the
> > > > guava
> > > > > version bump.
> > > > >
> > > > > > On Feb 27, 2019, at 5:32 PM, Anthony Baker 
> > > wrote:
> > > > > >
> > > > > > I was reviewing the release branch and noticed a number of new
> > > > > dependencies have been added since the last release.  When you add
> a
> > > new
> > > > > dependency, please review and follow the project license guide [1].
> > In
> > > > > particular, update the LICENSE file in geode-assembly/src/main/dist
> > > > > depending on the license type.
> > > > > >
> > > > > > Currently we need to update the LICENSE file with the additional
> > > > > MIT/BSD/CDDL dependencies.  We may also need to update NOTICE
> files.
> > > > > There’s also a version conflict with multiple versions of Jackson
> in
> > > use
> > > > > (2.9.6 / 2.9.8).
> > > > > >
> > > > > > @Sai - these need to be fixed on release/1.9.0
> > > > > >
> > > > > > Here’s the list of additions:
> > > > > >
> > > > > >   animal-sniffer-annotations-1.17.jar
> > > > > >   checker-qual-2.5.2.jar
> > > > > >   commons-math3-3.2.jar
> > > > > >   error_prone_annotations-2.2.0.jar
> > > > > >   failureaccess-1.0.jar
> > > > > >   geo-0.7.1.jar
> > > > > >   grumpy-core-0.2.2.jar
> > > > > >   istack-commons-runtime-2.2.jar
> > > > > >   j2objc-annotations-1.1.jar
> > > > > >   javax.activation-1.2.0.jar
> > > > > >   javax.activation-api-1.2.0.jar
> > > > > >   jsr305-3.0.2.jar
> > > > > >
> >  listenablefuture-.0-empty-to-avoid-conflict-with-guava.jar
> > > > > >
> > > > > > Removed:
> > > > > >
> > > > > >   activation-1.1.1
> > > > > >   jaxb-core-2.2.11.jar
> > > > > >
> > > > > > Anthony
> > > > > >
> > > > > > [1]
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/GEODE/License+Guide+for+Contributors
> > > > > <
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/GEODE/License+Guide+for+Contributors
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > > Charlie Black | cbl...@pivotal.io
> > >
> >
> >
> > --
> > -John
> > john.blum10101 (skype)
> >
>


-- 
-John
john.blum10101 (skype)

Re: Dependency review for release 1.9.0

[John Blum]

As an example of #1...

I could use *Gfsh* (and, in certain cases, myself and other users/customers
alike do start servers with *Gfsh*, [1]) , but alternatively and
conveniently I could launch my servers with (preferably) *Spring Boot* [2]
or even using the GemFire API [3].

All that is needed for [2] and [3] is a Maven POM, like so...

https://github.com/jxblum/spring-session-data-gemfire-serialization-example/blob/master/native-gemfire-server/pom.xml#L24-L50

As you can see, to launch [1], I need to figure out my classpath (which is
entirely possible using the Maven POM) but cumbersome and a real PITA...

https://github.com/jxblum/spring-session-data-gemfire-serialization-example/blob/master/native-gemfire-server/src/main/resources/geode/bin/start-cluster.gfsh#L13-L28

Additionally, this is rather small and simple example.  A true enterprise
application has literally hundreds of dependencies, not all of which would
be required on the server classpath, but depending on the "feature" used, a
fair amount would need to be on the servers' classpath for any reasonably
practical/realistic application.

-John


[1]
https://github.com/jxblum/spring-session-data-gemfire-serialization-example/blob/master/native-gemfire-server/src/main/resources/geode/bin/start-cluster.gfsh
[2]
https://github.com/jxblum/spring-session-data-gemfire-serialization-example/blob/master/spring-gemfire-server/src/main/java/example/app/gemfire/server/SpringGemFireServerApplication.java#L44-L61
[3]
https://github.com/jxblum/spring-session-data-gemfire-serialization-example/blob/master/native-gemfire-server/src/main/java/example/app/gemfire/server/NativeGemFireServerApplication.java


On Thu, Feb 28, 2019 at 10:35 AM John Blum  wrote:

> Dan-
>
> 2 things:
>
> 1) Users and customers (alike), in certain cases, do launch Geode Servers
> using Spring Boot, either with java -jar and a FAT JAR or other ways.
>
> 2) I have been saying for sometime now that I think it would be nice to be
> able to launch a server using a classpath configured with a Maven POM file,
> sort of like...
>
> gfsh> start server --name=X --maven-pom=/path/to/maven/pom.xml
>
> --mave-pom would set the server classpath accordingly and reliably.  All
> too often, users/customers miss critical dependencies on the cluster
> servers' classpath, especially transitive dependencies, that are required
> by their application artifacts: custom CacheLoaders, Functions, etc.
>
> Food for thought.
>
> -John
>
>
>
>
> On Thu, Feb 28, 2019 at 10:22 AM Dan Smith  wrote:
>
>> Currently, geode servers just have a flat classpath with all of the
>> dependencies of all of the modules. Having the ability to add optional
>> modules sounds like a good feature, though.
>>
>> John - what you are describing applies to maven dependencies - and I do
>> think that we should isolate optional features into separate maven
>> dependencies like geode-lucene. But that doesn't help with servers
>> launched
>> through gfsh start server unless we provide a way to configure which geode
>> modules are present on the server's classpath.
>>
>> -Dan
>>
>> On Thu, Feb 28, 2019 at 10:03 AM John Blum  wrote:
>>
>> > Well, that just requires that you appropriately declare dependencies
>> with
>> > the "optionality" and "scope" (e.g. "compile", "test", "provided", etc).
>> >
>> > Additionally, Geode modules could selectively pull in the required deps
>> as
>> > needed.  For example, `geode-lucene` would only pull in the Apache
>> Lucene
>> > dependencies if the `geode-lucene` module is used.
>> >
>> > No brainer.
>> >
>> > On Thu, Feb 28, 2019 at 9:47 AM Charlie Black 
>> wrote:
>> >
>> > > Hopefully, we are thinking about classpath of the server and lazily
>> > adding
>> > > these jars only when a feature is turned on.
>> > >
>> > > On Thu, Feb 28, 2019 at 9:45 AM Dan Smith  wrote:
>> > >
>> > > > I see that geo, grumpy-core, and commons math came from adding
>> > geospatial
>> > > > support to redis -
>> > > >
>> > > >
>> > >
>> >
>> https://github.com/apache/geode/commit/7bf02251fd047cb1cf575c01b80a9807108618da
>> > > >
>> > > > -Dan
>> > > >
>> > > > On Thu, Feb 28, 2019 at 9:41 AM Anthony Baker 
>> > wrote:
>> > > >
>> > > > > Looks a number of the new dependencies came in transitively with
>> the
>> > > > guava
>> > > > > version bump.
>

Re: Dependency review for release 1.9.0

[John Blum]

s/5.1.5.RELEASE/spring-beans-5.1.5.RELEASE.jar
  /Users/jblum/.m2/repository/commons-io/commons-io/2.4/commons-io-2.4.jar

/Users/jblum/pivdev/spring-data-examples-workspace/spring-session-data-gemfire-serialization-example/application-core-enums/target/classes

/Users/jblum/pivdev/spring-data-examples-workspace/spring-session-data-gemfire-serialization-example/application-core-model/target/classes

/Users/jblum/pivdev/spring-data-examples-workspace/spring-session-data-gemfire-serialization-example/application-ext-model/target/classes

/Users/jblum/.m2/repository/org/assertj/assertj-core/3.11.1/assertj-core-3.11.1.jar

/Users/jblum/.m2/repository/org/projectlombok/lombok/1.18.6/lombok-1.18.6.jar
  /Applications/IntelliJ IDEA 17 CE.app/Contents/lib/idea_rt.jar
Library Path:
  /Users/jblum/Library/Java/Extensions
  /Library/Java/Extensions
  /Network/Library/Java/Extensions
  /System/Library/Java/Extensions
  /usr/lib/java
  .
System Properties:
PID = 16326
awt.toolkit = sun.lwawt.macosx.LWCToolkit
...






On Thu, Feb 28, 2019 at 10:52 AM John Blum  wrote:

> As an example of #1...
>
> I could use *Gfsh* (and, in certain cases, myself and other
> users/customers alike do start servers with *Gfsh*, [1]) , but
> alternatively and conveniently I could launch my servers with (preferably) 
> *Spring
> Boot* [2] or even using the GemFire API [3].
>
> All that is needed for [2] and [3] is a Maven POM, like so...
>
>
> https://github.com/jxblum/spring-session-data-gemfire-serialization-example/blob/master/native-gemfire-server/pom.xml#L24-L50
>
> As you can see, to launch [1], I need to figure out my classpath (which is
> entirely possible using the Maven POM) but cumbersome and a real PITA...
>
>
> https://github.com/jxblum/spring-session-data-gemfire-serialization-example/blob/master/native-gemfire-server/src/main/resources/geode/bin/start-cluster.gfsh#L13-L28
>
> Additionally, this is rather small and simple example.  A true enterprise
> application has literally hundreds of dependencies, not all of which would
> be required on the server classpath, but depending on the "feature" used, a
> fair amount would need to be on the servers' classpath for any reasonably
> practical/realistic application.
>
> -John
>
>
> [1]
> https://github.com/jxblum/spring-session-data-gemfire-serialization-example/blob/master/native-gemfire-server/src/main/resources/geode/bin/start-cluster.gfsh
> [2]
> https://github.com/jxblum/spring-session-data-gemfire-serialization-example/blob/master/spring-gemfire-server/src/main/java/example/app/gemfire/server/SpringGemFireServerApplication.java#L44-L61
> [3]
> https://github.com/jxblum/spring-session-data-gemfire-serialization-example/blob/master/native-gemfire-server/src/main/java/example/app/gemfire/server/NativeGemFireServerApplication.java
>
>
> On Thu, Feb 28, 2019 at 10:35 AM John Blum  wrote:
>
>> Dan-
>>
>> 2 things:
>>
>> 1) Users and customers (alike), in certain cases, do launch Geode Servers
>> using Spring Boot, either with java -jar and a FAT JAR or other ways.
>>
>> 2) I have been saying for sometime now that I think it would be nice to
>> be able to launch a server using a classpath configured with a Maven POM
>> file, sort of like...
>>
>> gfsh> start server --name=X --maven-pom=/path/to/maven/pom.xml
>>
>> --mave-pom would set the server classpath accordingly and reliably.  All
>> too often, users/customers miss critical dependencies on the cluster
>> servers' classpath, especially transitive dependencies, that are required
>> by their application artifacts: custom CacheLoaders, Functions, etc.
>>
>> Food for thought.
>>
>> -John
>>
>>
>>
>>
>> On Thu, Feb 28, 2019 at 10:22 AM Dan Smith  wrote:
>>
>>> Currently, geode servers just have a flat classpath with all of the
>>> dependencies of all of the modules. Having the ability to add optional
>>> modules sounds like a good feature, though.
>>>
>>> John - what you are describing applies to maven dependencies - and I do
>>> think that we should isolate optional features into separate maven
>>> dependencies like geode-lucene. But that doesn't help with servers
>>> launched
>>> through gfsh start server unless we provide a way to configure which
>>> geode
>>> modules are present on the server's classpath.
>>>
>>> -Dan
>>>
>>> On Thu, Feb 28, 2019 at 10:03 AM John Blum  wrote:
>>>
>>> > Well, that just requires that you appropriately declare dependencies
>>> with
>>> > the "optionality" and "scope" (e.g. "compile"

Re: [DISCUSS] Moving redis to a separate module

[John Blum]

Definitely a reasonable change.  Perhaps, for consistency sake, the same
should be applied to Geode's Memcached support? (in another PR).


On Tue, Mar 12, 2019 at 4:23 PM Dan Smith  wrote:

> I created a PR to move our redis support to a separate module. Let me know
> what you think:
>
> https://github.com/apache/geode/pull/3284
>
> Geode servers will still include redis on the classpath, so the only effect
> of this is that if you are launching a server based on the maven
> dependencies, you will need geode-core and geode-redis to launch a server
> with redis.
>
> In addition to making it easier to find the redis specific code this also
> removes 4 dependencies from geode-core.
>
> -Dan
>


-- 
-John
john.blum10101 (skype)

Re: [DISCUSS] Changing many geode-core dependencies from compile to runtime

[John Blum]

If users will be explicitly declaring such dependencies in their
applications, then I might also suggest declaring/generating a Maven
 section in the POM to ensure that the user is
getting and using the right version of these dependencies, especially when
they don't care about the version (i.e. their applications likely will not
use the same dependency, e.g. org.jgroups:jgroups).  Assuming a version
property is appropriately declared in the POM, then the user can always
override the dependency version.  All too often we running into problems
(e.g. NoSuchMethodError) due to incompatibility with versions.

As fine example of a curated, harmonized, managed set of dependencies, see
the *Spring Boot* Dependency POM

 [1].

This is recommended, not required.  In general, I'd also add that GemFire
should produce a BOM file to manage its dependencies (both owned (e.g.
geode-core, geode-lucene, etc) as well as transitive) so users don't have
to.

Food for thought.



On Fri, Mar 15, 2019 at 4:07 PM Bruce Schuchardt 
wrote:

> That seems like a great idea
>
> On 3/15/19 11:53 AM, Dan Smith wrote:
> > Hi,
> >
> > We would like to start using gradle's new implementation dependency
> > notation in our build files.
> >
> > This will affect downstream consumers of geode-core, hopefully in a good
> > way, in that many of our dependencies will now be marked runtime
> > dependencies in the pom instead of compile. That means it is easier for
> > users to avoid accidentally using one of these dependencies in their
> code.
> > But it also means if they are using one of these dependencies directly,
> > they will have to explicitly add it to their maven/gradle build going
> > forward.
> >
> > Here is a PR for this:
> > https://github.com/apache/geode/pull/3314
> >
> > Are there any concerns with making this switch?
> >
> > These are the dependencies that are being flipped to runtime instead of
> > compile in the pom:
> >
> > com.github.stephenc.findbugs:findbugs-annotations
> > org.jgroups:jgroups
> > antlr:antlr
> > com.fasterxml.jackson.core:jackson-annotations
> > com.fasterxml.jackson.core:jackson-databind
> > commons-io:commons-io
> > commons-validator:commons-validator
> > javax.xml.bind:jaxb-api
> > com.sun.xml.bind:jaxb-impl
> > org.apache.commons:commons-lang3
> > it.unimi.dsi:fastutil
> > net.java.dev.jna:jna
> > net.sf.jopt-simple:jopt-simple
> > org.apache.logging.log4j:log4j-api
> > org.apache.logging.log4j:log4j-core
> > org.eclipse.jetty:jetty-server
> > io.github.classgraph:classgraph
> > com.healthmarketscience.rmiio:rmiio
> >
>


-- 
-John
john.blum10101 (skype)

[ANNOUNCE] Spring Boot for Apache Geode 1.0.0.M4 Available!

[John Blum]

Greetings Apache Geode community and Spring users-

I am pleased to bring you the *Spring Boot for Apache Geode* (SBDG) 1.0.0.M4
release. You can read the official announcement on the Spring Blog [1] to
find out more details.

Next up will be SBDG 1.0.0.RC1 followed shortly by a final 1.0.0.GA as well
as a 1.1.0.M1, which rebases SBDG on Spring Boot 2.1, Spring Framework 5.1
and Spring Data Lovelace.

As always, feedback is appreciated.

Regards,

-- 
-John

[1]
https://spring.io/blog/2019/03/22/spring-boot-for-apache-geode-pivotal-gemfire-1-0-0-m4-released

Re: [Discuss] Removal of Thread Local Connection Pooling

[John Blum]

Well articulated and a wise decision; Jake. +1

On Fri, Apr 5, 2019 at 8:24 AM Anthony Baker  wrote:

> One question:  if I’m using thread-local connections ho does that affect
> pool sizing?  Are thread-local connections included in the overall pool
> size or accounted for separately?
>
> We may want some explicit release notes if a user would need to resize
> their pools during an upgrade.
>
> Anthony
>
>
> > On Apr 5, 2019, at 6:34 AM, Jacob Barrett  wrote:
> >
> > Devs,
> >
> > The current connection pooling implementation contains a setting that
> enables a secondary pool that is thread local. See ClientCacheFactory.
> setPoolThreadLocalConnections method for details. This thread local pooling
> was added to reduce contention on the primary connection pool under high
> thread count or load. As of the completion of GEODE-6515 there is no longer
> a contention issue in the primary pool under high thread count or load,
> effectively rendering thread local pooling a no-op. Thread local pooling
> also introduces many complexities into the primary pool management of
> connections since a connection can either be in the primary pool or a pool
> for each thread. Connection idle timeout, lifetime expiration and load
> conditioning all have to work around thread local connections making for
> some interesting relationships and behavior. Additionally clients of thread
> local connections needed to call Pool.releaseThreadLocalConnections prior
> to the thread terminating or connections would be held until the GC
> finalized the thread local storage. Use of thread local connections
> typically mean significantly high connection counts on the servers since
> each thread could horde connections to each server regardless of current
> workload need.
> >
> > I propose that we deprecate all the public APIs for thread local
> connections and immediately remove the behavior. The API methods will go
> from an effective no-op to an actual no-op. A warning will be logged when
> ClientCacheFactory. setPoolThreadLocalConnections is used. Internally all
> thread local connection implementation will be removed. The net effect to
> the client will be the same as promised with thread local connections, that
> content on the primary pool is reduced for high thread count and load.
> Additionally, the connection count to each server will be reduced since
> threads won’t be holding connections to servers they are not actively
> communicating with. All in all this will be a net-positive improvement for
> the consuming client and the distributed system as a whole. Internally this
> will be huge win as it removes complexity and opens a path to removing even
> more complexity in idle connection timeouts, connection lifetime
> expiration, and load conditioning. Please see GEODE-6594 for more details.
> >
> > I realize this is sort of a grey area. An obvious questions is, “doesn’t
> this violate semver by removing a feature in a minor?” My answer is a
> solid, “nope!” The feature is defined as “reducing contention on the
> connection pool”, which is provided now by default in the refactored
> connection pool. All that is being done is deprecating and warning that a
> useless API is being removed in the next major release. The feature remains
> intact and client code does not need to be re-compiled or changed.
> >
> > I would love to hear if anyone has any concerns, questions or dissenting
> opinions about this proposal. PR 3394 has been opened for review of the
> code changes related to the removal. Please provide feedback in the PR
> relating only to the code and discussions about the merits of he proposal
> here in this email thread.
> >
> > Thanks,
> > Jake
> >
> > GEODE-6515 - https://issues.apache.org/jira/browse/GEODE-6515 <
> https://issues.apache.org/jira/browse/GEODE-6515>
> > GEODE-6594 - https://issues.apache.org/jira/browse/GEODE-6594 <
> https://issues.apache.org/jira/browse/GEODE-6594>
> > PR 3394 - https://github.com/apache/geode/pull/3394 <
> https://github.com/apache/geode/pull/3394>
> >
>
>

-- 
-John
john.blum10101 (skype)

Re: How to publish client stats on server

[John Blum]

Or alternatively, when using Spring, you can just use @EnableStatistics [1].

[1]
https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/config/annotation/EnableStatistics.html

On Tue, Apr 16, 2019 at 10:44 AM Darrel Schneider 
wrote:

> setPoolStatisticInterval does cause the client to send some of its stats
> periodically to the server. But the server puts this information into
> MBeans and does not write them to the server's statistic archive. This is
> why the javadoc's on setPoolStatisticInterval refers to "gfmon".
> Your best bet, as Dan and Anthony pointed out, is to have your client
> generate its own gfs file. You can do this be configuring the geode/gemfire
> properties as documented. You should find documentation about setting the
> following properties: statistic-sampling-enabled, statistic-sample-rate,
> statistic-archive-file, enable-time-statistics.
> One of the ways you can set these properties is using
> ClientCacheFactory.set(String, String)
>
> On Tue, Apr 16, 2019 at 6:29 AM Alberto Bustamante Reyes
>  wrote:
>
> > Hi Geode community,
> >
> > Im trying to run a simple test to check how the client stats are
> published
> > on the server, but I have not been able to do it.
> >
> > The server is started with the statistic sampling enabled, and in the
> > client I set the sending interval with setPoolStatisticInterval, but
> when I
> > open the stats file with VSD, I cannot see any "ClientStat" there. I was
> > expecting to see the stats "Client-to-Server Messaging Performance
> > (ClientStats)".
> >
> > I have checked the code and these two actions (setting time interval and
> > stats sampling) are the two conditions that enable the publishing of the
> > client stats, if Im not wrong.
> >
> > What am I missing? Thanks in advance.
> >
> > BR/
> >
> > Alberto
> >
>


-- 
-John
john.blum10101 (skype)

[ANNOUNCE] Spring Boot for Apache Geode 1.0.0.RC1 Released!

[John Blum]

I am pleased to announce the release of *Spring Boot for Apache Geode*
 (SBDG) 1.0.0.RC1.

You can read more details in the official release announcement on the
spring.io/blog [1].

I have tentatively scheduled the final GA release of SBDG 1.0 on Monday,
April 29th, 2019. Any feedback between now and then is most appreciated.


Regards,

-- 
-John

[1]
https://spring.io/blog/2019/04/24/spring-boot-for-apache-geode-pivotal-gemfire-1-0-0-rc1-released

[ANNOUNCE] Spring Boot for Apache Geode 1.0.0.RC2 Available!

[John Blum]

I am pleased to announce the release of *Spring Boot for Apache Geode*
(SBDG) 1.0.0.RC2.

You can read more details in the official release announcement on the
spring.io/blog [1].

Given feedback from the Boot team, I decided to postpone the 1.0 GA and
push out

1 more release candidate. The final GA is scheduled for Monday, 5/6.

Immediately, following the 1.0 GA, I will push out 1.1.0.M1, which will
rebase SBDG on Spring Framework 5.1, Spring Boot 2.1, Spring Data Lovelace
(2.1) and Spring Session 2.1.


Feedback welcomed.


Regards,

-John

[1]
https://spring.io/blog/2019/05/01/spring-boot-for-apache-geode-pivotal-gemfire-1-0-0-rc2-released

[ANNOUNCE] Spring Boot for Apache Geode 1.0.0.RELEASE Available!

[John Blum]

It is my pleasure to announce the first GA release of Spring Boot for
Apache Geode (SBDG) 1.0.0.RELEASE.

See the official release announcement on spring.io for more details:

https://spring.io/blog/2019/05/07/spring-boot-for-apache-geode-pivotal-gemfire-1-0-0-release-available

Feedback appreciated and welcomed.

Regards,

-- 
-John

Spring Boot for Apache Geode 1.1.0.M1 Released!

[John Blum]

I am pleased to announce the release of *Spring Boot for Apache Geode*
(SBDG) 1.1.0.M1.

See the official release announcement here:
https://spring.io/blog/2019/05/07/spring-boot-for-apache-geode-pivotal-gemfire-1-1-0-m1-released

The 1.1 Milestone 1 (M1) release primarily rebases SBDG on the latest and
current (GA) of Spring Framework 5.1, Spring Boot 2.1, Spring Data
Lovelace/2.1 and Spring Session Bean/2.1.  Additionally, since SDG Lovelace
is based on Apache Geode 1.6, SBDG has been rebased on Apache Geode 1.6.

This 1.1 version will quickly progress to GA by end of May, beginning of
June.  I am planning 1 more milestone (i.e. 1.1 M2), which will include
dedicated support for *Inline Caching*.

After M2, there will be a 1.1 RC1 and then the final GA, again, roughly end
of May, beginning of June timeframe.

At that point, you can expect a early 1.2 M1 release, which will rebase
SBDG on Spring Framework 5.2, Spring Boot 2.2, Spring Data Moore/2.2 and
Spring Session Corn/2.2, all currently in development (i.e. no GA versions
yet).  SD[G] Moore/2.2 is currently based on Apache Geode 1.9.  SBDG will
then be all caught up with the Spring ecosystem.  The 1.2 M1 release will
roughly occur mid-June.

Regards,

-- 
-John

Re: [DISCUSS] Add a test dependency to geode-core - ArchUnit

[John Blum]

Of equal importance to uni-directional dependencies in a "modular" design
is, classes in package A should not refer directly to classes in package B
when A depends on B, or alternately, when module A depends on module B.
All interactions are only ever through interfaces and all implementations
are provided via an SPI, Factory, DI, etc, only.  This makes B swappable
with another implementation similar to B that honors the contract of B.
Nearly all good Java framework are this way, e.g. Logging framework
facades.  1 interface for logging concerns, multiple implementations.

A superset of tangling is coupling and coupling is far worse than
tangling.  Tangling, while discourages, can be manageable where as coupling
is much harder to uncouple.

Still, a huge +1 to uni-directional dependencies, which is often achieved
with organization/structuring and "strong" *Separation of Concerns*.

Cheers!





On Fri, Jun 21, 2019 at 1:04 PM Udo Kohlmeyer  wrote:

> Thank you for the response...
>
> #1 - But isn't cyclical package dependent code not a smell and practice,
> whilst at the same time and uni-directional dependency is preferred.
>
> Soo... I think I see the benefit to be more, that ArchUnit allows the
> untangling of code into a modular way WITHOUT a big bang approach of
> moving the code into modules and then having to be concerned about the
> fallout. But also it allows for the managing of package dependencies
> WITHOUT breaking the code out into different separate modules.
>
> I really like ArchUnit :).. We should prioritize adoption :)
>
> --Udo
>
> On 6/21/19 12:48, Murtuza Boxwala wrote:
> > Two things come to mind:
> >
> > 1) uni-directional dependency
> > Packages can be dependent on each other, because the classes inside of
> them can use each other. e.g.  let’s say package A has class A1 and class
> A2 and package B has class B1 and B2.  A1 can depend on B1, and B2 can
> depend on A2. Hence, the packages are dependent on each other.
> >
> > Modules can only have uni-directional dependency. If Module A depends on
> Module B, then no class in Module B can reference a class in Module A.
> This prevents tangling, i.e. spaghetti
> >
> > 2) Incremental compilation
> > This lack of tangling helps not only developers, but the compiler too.
> In the packages example above, if I change any of the classes, all the code
> has to get recompiled because the dependency lines can go in any direction,
> and the compiler won’t attempt to optimize.  In the modules case, if Module
> A changes, Module B will not recompile, because the dependency guarantees
> that nothing about Module B could have been affected.
> >
> >> On Jun 21, 2019, at 2:14 PM, Udo Kohlmeyer  wrote:
> >>
> >> I know that I'm missing the benefit of physically moving the code from
> the package into its own module.
> >>
> >> Could you possibly explain to me what it is?
> >>
> >> On 6/21/19 07:37, Murtuza Boxwala wrote:
> >>> I think that’s a really clever way to increment toward splitting
> geode-core into more modules. I am excited to see what it looks like 👍
> >>>
>  On Jun 20, 2019, at 7:45 PM, Jacob Barrett 
> wrote:
> 
>  Gotcha! Sounds good.
> 
> > On Jun 20, 2019, at 4:35 PM, Dan Smith  wrote:
> >
> > We don't have a membership gradle module, just a package. We're
> adding this
> > to geode-core.
> >
> > For a little more context - we are thinking about refactoring
> membership
> > (and/or maybe some other pieces) into separate gradle modules -
> proposal
> > forthcoming! However, as a first step we need to untangle those
> pieces of
> > code from the rest of geode-core. Rather than creating some long
> lived
> > branch we can incrementally untangle the code a piece at a time, on
> > develop. Having a way to track progress and enforce the direction of
> > dependencies on the way to a separate gradle module will help with
> that.
> >
> > -Dan
> >
> >> On Thu, Jun 20, 2019 at 4:23 PM Jacob Barrett 
> wrote:
> >>
> >> Are you adding this dependency to just the membership module? I am
> cool
> >> with that.
> >>
> >>> On Jun 20, 2019, at 2:39 PM, Dan Smith  wrote:
> >>>
> >>> Hi all,
> >>>
> >>> Bill, Ernie, and I would like to add a new (apache licensed) test
> >>> dependency to geode-core - https://github.com/TNG/ArchUnit. This
> is a
> >> tool
> >>> that lets you write tests that make assertions about the
> >> interdependencies
> >>> of your code - for example enforcing that package A does not
> depend on
> >>> package B.
> >>>
> >>> Initially we intend to add some tests about what parts of the
> system the
> >>> org.apache.geode.distributed.internal.membership package depends
> on, with
> >>> an eye towards making that code more independently testable
> (proposal on
> >>> that coming soon!).
> >>>
> >>> Does anyone have an issue with adding this test dependency?
> >>>
> >>>

[RELEASE] Spring for Apache Geode Release & Feature Update

[John Blum]

Greetings Apache Geode community-

I wanted to take this opportunity and let you all know about the recent
developments in the *Spring* ecosystem as it relates to Apache Geode for
all you *Spring* users out there.


~~


1. *Spring Data for Apache Geode* (SDG) Lovelace-SR9 (2.1.9.RELEASE) along
with SDG Moore-RC1 (2.2.0.RC1) are now available.  SDG handles all your
data management needs (e.g. data access).

Notable changes include:

1.1. DATAGEODE-168 - Adds support to configure GatewayReceivers with the
Annotation-based configuration model. [1]

-- Thank you *Udo Kohlmeyer* for the PR.

1.2. DATAGEODE-183 - Upgrades SDG Moore to Apache Geode 1.9.0. [2]

1.3. DATAGEODE-184 - Applies RegionConfigurers to Caching-defined *Regions*.
[3]

1.4. DATAGEODE-187 - Ability to configure and bootstrap dedicated
Locator, *Spring
(Boot)* applications using the new @LocatorApplication annotation. [4]

1.5. DATAGEODE-190 - Adds support for configuring the SSL default context
provided by the JRE. [5]

-- Thank you *Srikanth Manvi* for the PR.

1.6. DATAGEODE-192/194 - Adds support for securing (HTTPS) and
authenticating the HTTP connection as well as following HTTP redirects.
[6], [7]

1.7. Usual dependency updates aligning with *Spring Boot* 2.1 and 2.2,
respectively.

See the *changelog* [8] for complete details.



2. *Spring Session for Apache Geode* (SSDG) 2.1.4.RELEASE and 2.2.0.M2
available.  SSDG handles all your (HTTP) Session state caching needs.

Notable changes include:

2.1. Issue #38 - Adds support to disable client subscriptions and interests
registrations to minimize the network traffic between client & server. [9]

2.2. Issue #39 - Adds support for SessionChangeEvents (not provided in the
core Spring Session framework itself).

2.3. The usual dependency updates aligning with *Spring Boot* 2.1 and 2.2,
respectively.



3. *Spring Test for Apache Geode* (STDG) 0.0.5.RELEASE.  STDG can be used
for all your *Unit & Integration* testing needs with Apache Geode in a
*Spring* context.

Notable changes include:

3.1. ICYMI, Adds support for mock *Region* data and mocking basic *Region*
operations (e.g. *get* & *put*). [10]

-- This is particularly useful when testing your application SD[G]
*Repositories* and performing basic CRUD data access operations.

3.2. Adds support for calling your custom application callbacks (e.g.
CacheLoader, CacheWriter and CacheListeners) from a *mock* Region. [11]

3.3. Adds support asserting application log statements. [12]



4. *Spring Boot for Apache Geode* (SBDG) 1.0.1.RELEASE and 1.1.0.M3
available. SBDG just makes everything easier to do when building *Spring*
applications using Apache Geode.

Notable changes include:

4.1. Issue #36 - Adds Spring Boot Starters for STDG. [13]

4.2. Issue #38 - Adds Spring Boot Starters for SSDG. [14]

4.3. Issue #40 - Auto-configuration for logging. [15]

4.4. Issue #26 - Adds dedicated support for *Inline Caching* based on SD
Repositories. [16]

-- See Documentation [17] for more details.

4.5. Issue #31 - Auto-configures templates for all configured Geode
Regions. [18]

-- See Documentation [19] for more details.

4.6. Issue #33 - Adds support to deploy Spring Boot, Apache Geode apps to
Pivotal CloudFoundry, but connect those apps to a externally managed,
standalone Apache Geode cluster. [20]

See *changelog* [21] for complete details.


~~


As you can see, much is happening in the *Spring* ecosystem revolving
around Apache Geode.

If you are wondering where to start, start with Spring Boot (i.e. SBDG).
It is the simplest way to get started quickly and reliably.

As always, feedback is most welcomed and appreciated.

Regards,

-- 
-John

[1] https://jira.spring.io/browse/DATAGEODE-168
[2] https://jira.spring.io/browse/DATAGEODE-183
[3] https://jira.spring.io/browse/DATAGEODE-184
[4] https://jira.spring.io/browse/DATAGEODE-187
[5] https://jira.spring.io/browse/DATAGEODE-190
[6] https://jira.spring.io/browse/DATAGEODE-192
[7] https://jira.spring.io/browse/DATAGEODE-194
[8]
https://github.com/spring-projects/spring-data-geode/blob/master/src/main/resources/changelog.txt
[9] https://github.com/spring-projects/spring-session-data-geode/issues/38
[10] https://github.com/spring-projects/spring-session-data-geode/issues/39
[11]
https://github.com/spring-projects/spring-test-data-geode#mock-region-callbacks
[12]
https://github.com/spring-projects/spring-test-data-geode#asserting-logging-behavior
[13] https://github.com/spring-projects/spring-boot-data-geode/issues/36
[14] https://github.com/spring-projects/spring-boot-data-geode/issues/38
[15] https://github.com/spring-projects/spring-boot-data-geode/issues/40
[16] https://github.com/spring-projects/spring-boot-data-geode/issues/26
[17]
https://docs.spring.io/spring-boot-data-geode-build/1.1.x/reference/html5/#geode-caching-provider-inline-caching
[18] https://github.com/spring-projects/spring-boot-data-geode/issues/31
[19]
https://docs.spring.io/spring-boot-data-geode-build/1.1.x/ref

Re: [DISCUSS] Time to cut Geode 1.10.0?

[John Blum]

A couple of clarifications:


1.  First, and most importantly, Pivotal GemFire, specifically (Apache
Geode was never officially on *Spring Initializer*, actually) was removed
from *Spring Initializer* because *Spring Boot* *1.5.x* has finally
reached *End
of Life*.Pivotal GemFire existed as an "option" on *Spring Initializer*
only because *Spring Boot* *1.5.x* had (primarily) a *Starter
*
[1]
(and there was also an Example

[2]),
compliments of yours truly, ;-), roughly 4 years ago now.

It was *not* because of the *Log4j (core)* dependency.


2. Pivotal GemFire does not exist (as a Starter nor Example) in *Spring
Boot* (core) 2.0 and beyond (e.g. 2.1, 2.2, etc) today, primarily, because
of "licensing" and "legal" reasons.  There are other (technical) reasons
but legal & licensing pretty much trumps everything else.


3. Around the time *Spring Boot* 2.0 started up, Apache Geode had no (1.0)
GA version and had not yet graduated from Apache Incubator.  In short, we
cannot ship non-release, non-GA versions of dependencies with GA versions
of Boot, on *Initializer*.


4. Around this same time, most of the work I did in Boot for GemFire had 1)
already been rebased on Apache Geode and 2) started being migrated to what
you now know as the *Spring Boot for Apache Geode & Pivotal GemFire* (SBDG)
project on *GitHub*
 [3] (
*spring-boot-data-geode* repository).  So, it all depended on me at this
point to get back on *Initializer*.  SBDG needed to be an established
project (with users and few releases, etc).  Sorry for the delay.


5. Finally, yes, there is a problem
 [4]
between Apache Geode's Logging dependency/usage (specifically, on
org.apache.logging.log4j:log4j-core) and logging dependencies declared
by *Spring
Boot* when users declare a dependency on
org.springframework.boot:spring-boot-starter-logging (the "Starter" to
introduce logging into your *Spring Boot* application), which they often do
when building *Spring Boot* applications.

Essentially the problem is that the Log4j dependency versions declared by
Boot 2.2.x (Log4j 2.12

[5])
and used by Geode 1.9 (Log4j 2.11

[6])
do not line up, which causes issues when using the Log4j to SLF4J bridge
dependency (org.apache.logging.log4j:log4j-to-slf4j).  Most likely users
are using SLF4J in their applications and *Logback* as the logging
provider, and also wants all application dependencies (e.g. Geode) logging
to use the same logging configuration (hence the bridge).

I could explain the nuances of which version of all dependencies

[7]
that Spring Boot manages and when those dependencies are "updated" (e.g.
like moving from Log4j 2.11 to 2.12), but that is beyond the scope of this
already long email.



Anyway, sorry to derail the release email.  I just want to make sure we
understand this in no way holding up the *Spring Initializer* work being
done to include SBDG Starters on start.spring.io.  I have already taken the
necessary steps in SBDG to workaround #5.

However, I will say... *Kirk's* work is very important to us because it
makes it much easier and more consistent for users.  So, we highly support
this effort (i.e. the sooner the better).

I hope this helps.

Regards,
John



[1]
https://github.com/spring-projects/spring-boot/tree/1.5.x/spring-boot-starters/spring-boot-starter-data-gemfire
[2]
https://github.com/spring-projects/spring-boot/tree/1.5.x/spring-boot-samples/spring-boot-sample-data-gemfire
[3] https://github.com/spring-projects/spring-boot-data-geode
[4] https://github.com/spring-projects/spring-boot-data-geode/issues/42
[5]
https://github.com/spring-projects/spring-boot/blob/v2.2.0.M5/spring-boot-project/spring-boot-dependencies/pom.xml#L145
[6]
https://github.com/apache/geode/blob/rel/v1.9.0/boms/geode-all-bom/src/test/resources/expected-pom.xml#L461-L469
[7]
https://github.com/spring-projects/spring-boot/blob/v2.2.0.M5/spring-boot-project/spring-boot-dependencies/pom.xml#L37-L238


On Tue, Aug 6, 2019 at 2:21 PM Nabarun Nag  wrote:

> Hi,
>
> The commit mentioned in the earlier email has now been reverted on develop
> and release/1.10.0 branches.
> Thank you for your patience.
>
> Regards
> Nabarun Nag
>
>
> On Tue, Aug 6, 2019 at 2:13 PM Nabarun Nag  wrote:
>
> > Hi Geode Community,
> >
> > After some further analysis, few of the thr

Re: Another change for 1.10.0 release

[John Blum]

+1 for Dan's changes.

On Thu, Aug 8, 2019 at 10:28 AM Owen Nichols  wrote:

> Hi Dan, thank you for bringing your concern.
>
> Our “critical fixes” rule allows critical fixes to be brought to the
> release branch by proposal on the dev list [as you have just done].  If
> there is consensus from the Geode community that this GEODE-7055 fix
> satisfies the “critical fixes” rule, Dick or I will be happy to bring it to
> the 1.10.0 release branch.
>
> -Owen
>
>
> > On Aug 8, 2019, at 10:11 AM, Dan Smith  wrote:
> >
> > Hi all,
> >
> > I'd like to get the fix for GEODE-7055 (Don't send failure replies from a
> > P2P reader thread) into the 1.10.0 release branch.
> >
> > This bug was causing a hang on startup for users of the session
> replication
> > module that didn't put the session jars on the classpath of the locator.
> > The hang doesn't happen with 1.9.0, so I'd I think we should make sure it
> > won't happen with 1.10.0 as well.
> >
> > -Dan
>
>

-- 
-John
john.blum10101 (skype)

Re: Fix for NPE during forceDisconnect candidate for 1.10.0

[John Blum]

+1 for Kirk's changes in 1.10.  This will be critical for SD Neuman and
SBDG 1.3.

On Thu, Aug 8, 2019 at 10:57 AM Owen Nichols  wrote:

> Hi Kirk and Mark, thank you for bringing your concern.
>
> Our “critical fixes” rule allows critical fixes to be brought to the
> release branch by proposal on the dev list, as you have just done.  If
> there is consensus from the Geode community that this NPE fix satisfies the
> “critical fixes” rule, Dick or I will be happy to bring it to the 1.10.0
> release branch.
>
> -Owen
>
> > On Aug 8, 2019, at 10:54 AM, Kirk Lund  wrote:
> >
> > I'd like to propose including the fix for GEODE-6959 in 1.10.0.
> >
> > Spring Boot users are very likely to hit this NPE during forceDisconnect.
> >
> > If a custom log4j2.xml is used without specifying the Geode
> AlertAppender,
> > GMSMembershipManager may throw a NullPointerException when invoking
> > AlertAppender.getInstance().stopSession() during a forceDisconnect. This
> > change prevents the NullPointerException allowing forceDisconnect to
> finish.
> > Tests are included with this fix.
> >
> > PR: https://github.com/apache/geode/pull/3899
> > GEODE-6959: NPE if AlertAppender is not defined
> >
> > Thanks,
> > Kirk and Mark
>
>

-- 
-John
john.blum10101 (skype)

Re: Fix for ClassCastException when using Logback for 1.10.0

[John Blum]

+1

On Thu, Aug 8, 2019 at 11:31 AM Juan José Ramos  wrote:

> +1
>
> On Thu, Aug 8, 2019 at 7:26 PM Mark Hanson  wrote:
>
> > +1
> >
> > I think it is valuable to make life easier for Spring Boot users.
> >
> > Thanks,
> > Mark
> >
> > > On Aug 8, 2019, at 11:24 AM, Kirk Lund  wrote:
> > >
> > > This is the last logging related fix that I'd like to propose adding to
> > > 1.10.0
> > > release branch.
> > >
> > > Spring Boot adds Logback and log4j-to-slf4j to the classpath. This
> > > results in ClassCastExceptions if log4j-core is not excluded.
> > >
> > > This change prevents Geode from using Log4jAgent if Log4j Core is
> > > present but not using Log4jProvider.
> > >
> > > For example, Log4j uses SLF4JProvider instead of Log4jProvider 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 attempting to cast
> > > loggers from org.apache.logging.slf4j.SLF4JLogger to
> > > org.apache.logging.log4j.core.Logger to get the LoggerConfig or
> > > LoggerContext.
> > >
> > > PR: https://github.com/apache/geode/pull/3892
> > > GEODE-7050: Use Log4jAgent only if Log4j is using Log4jProvider
> > > https://issues.apache.org/jira/browse/GEODE-7050
> > >
> > > Thanks,
> > > Kirk and Aaron
> >
> >
>
> --
> Juan José Ramos Cassella
> Senior Software Engineer
> Email: jra...@pivotal.io
>


-- 
-John
john.blum10101 (skype)

Re: [DISCUSS] Release Geode 1.9.1 with logging improvements

[John Blum]

For clarification...

1. SBDG 1.1 is the "*current*" development line (on

master

[1]);
SBDG 1.2 is *not* yet in development.
2. SBDG 1.1 is at RC1
 [2].
3. SBDG 1.1 is based on Spring Boot 2.1

[3]
and Spring Data (Geode) Lovelace

[4]
(or SDG 2.1

[5]);
This is not arbitrary because all the stars (bits, transitive dependency
versions) must "align" as defined by what Spring Boot 2.1 declares, and
Spring Boot 2.1 is based on

[6]
Spring Data Lovelace/2.1.
4. Spring Data Geode (SDG) Lovelace/2.1 is based on

[7]
Apache Geode 1.6.
5. All SDG Lovelace/2.1.x versions will always be based on the latest
Apache Geode 1.6.x anything (currently, 1.6.0) until the rest of time.
This ship has sailed.



6. SBDG 1.2, when it reaches development (soon),will be based on Spring
Boot 2.2

[8],
Spring Data (Geode) Moore

[9]
(or SDG 2.2

[10]);
This is also not arbitrary because Spring Boot 2.2 declares a dependency on

[11]
Spring Data Moore.  Again, the stars must align.
7. Spring Data Geode (SDG) Moore/2.2 is based on

[12]
Apache Geode 1.9.0.
8. As you can see, SDG Moore/2.2 is already in release candidates (i.e. RC2
or the 2nd release candidate), which means SDG cannot be rebased on 1.10 at
this point.  The transitive dependency major.minor versions are now fixed
for SD(G) Moore/2.2.
9. SDG Moore/2.2 can pick up any version of Apache Geode 1.9.x (e.g. 1.9.1
up to  1.9.N where N is 0... infinity).

Finally, SDG's next opportunity to pick up Apache Geode 1.10 or 1.11 or
1.whatever is in the next SD Release Trains, Neuman, or 2.3.  SDG can
continue to pick up new versions of Apache Geode 1.10, 1.11, 1.12, etc
until SDG Neuman/2.3 reaches it's first release candidate (RC) release, at
which point the major.minor becomes fixed in that particular SD Release
Train, until the next SD Release Train (Neuman.next).

Make sense?

So, it is the SDG version (along with Spring Boot core) that SBDG depends
on that determines the version of Apache Geode that SBDG pulls in.

Hope this helps!

Regards,
John


[1]
https://github.com/spring-projects/spring-boot-data-geode/blob/master/gradle.properties#L17
[2] https://github.com/spring-projects/spring-boot-data-geode/releases
[3]
https://github.com/spring-projects/spring-boot-data-geode/blob/1.1.0.RC1/gradle.properties#L8
[4]
https://github.com/spring-projects/spring-boot-data-geode/blob/1.1.0.RC1/gradle.properties#L12
[5]
https://github.com/spring-projects/spring-boot-data-geode/blob/1.1.0.RC1/gradle.properties#L10
[6]
https://github.com/spring-projects/spring-boot/blob/v2.1.7.RELEASE/spring-boot-project/spring-boot-dependencies/pom.xml#L169
[7]
https://github.com/spring-projects/spring-data-geode/blob/2.1.10.RELEASE/pom.xml#L25
[8]
https://github.com/jxblum/spring-boot-data-geode/blob/1.2.x/gradle.properties#L8
[9]
https://github.com/jxblum/spring-boot-data-geode/blob/1.2.x/gradle.properties#L12
[10]
https://github.com/jxblum/spring-boot-data-geode/blob/1.2.x/gradle.properties#L10
[11]
https://github.com/spring-projects/spring-boot/blob/v2.2.0.M5/spring-boot-project/spring-boot-dependencies/pom.xml#L185
[12]
https://github.com/spring-projects/spring-data-geode/blob/2.2.0.RC2/pom.xml#L25


On Tue, Aug 13, 2019 at 12:40 PM Aaron Lindsey  wrote:

> Thanks, Udo.
>
> +1 for doing a 1.9.1 patch release, assuming there is enough time for SBDG
> to include it in their 1.2.x line.
>
> - Aaron
>
> > On Aug 13, 2019, at 12:38 PM, Udo Kohlmeyer  wrote:
> >
> > No, 1.9.1 IS something we require. SBDG 1.2 CAN use 1.9.1, we'd have to
> wait for SBDG 1.3 to use 1.10 or 1.11
> >
> > SBDG 1.3 is still a few months off, so maybe getting critical fixes in
> patch versions is required.
> >
> > On 8/13/19 11:26 AM, Kirk Lund wrote:
> >> Udo, Thanks for the info! Sounds like we shouldn't bother with Geode
> 1.9.1
> >> then. If 

Re: [DISCUSS] Release Geode 1.9.1 with logging improvements

[John Blum]

Stated slightly a different way...

If *SBDG 1.2 *were to be (re)based on *Apache Geode 1.10* directly, then it
would *defy* the dependency on Apache Geode pulled in by SDG Moore/2.2
(which is and can only be Geode 1.9) for which SBDG is also based, along
with Spring Boot 2.2, which pulls in SD Moore/2.2 and therefore Geode 1.9
as well.  As such, the stars would not align and it would cause issues (or
unexpected surprises, possibly conflicts) for users of Spring Boot when
also using SBDG.  With SBDG, users of Spring Boot would get Geode 1.9 due
to the SD Moore/2.2 dependency, but with SBDG on the classpath, it would
suddenly (possibly) change the Geode version to 1.10.  That is definitively
bad.

Therefore, SBDG 1.2 based on Boot 2.2, Data 2.2 will get Geode 1.9.

SBDG 1.3 will be based on Boot 2.3 (not available), Data 2.3 (not
available) which will pull in the latest version of Geode at that time
(e.g. 1.10, maybe 1.11) and continue to be upgraded until 2.3 reaches RC
status.

Cheers,
John




On Tue, Aug 13, 2019 at 1:45 PM John Blum  wrote:

> For clarification...
>
> 1. SBDG 1.1 is the "*current*" development line (on
> <https://github.com/spring-projects/spring-boot-data-geode/blob/master/gradle.properties#L17>
> master
> <https://github.com/spring-projects/spring-boot-data-geode/blob/master/gradle.properties#L17>
>  [1]);
> SBDG 1.2 is *not* yet in development.
> 2. SBDG 1.1 is at RC1
> <https://github.com/spring-projects/spring-boot-data-geode/releases> [2].
> 3. SBDG 1.1 is based on Spring Boot 2.1
> <https://github.com/spring-projects/spring-boot-data-geode/blob/1.1.0.RC1/gradle.properties#L8>
>  [3]
> and Spring Data (Geode) Lovelace
> <https://github.com/spring-projects/spring-boot-data-geode/blob/1.1.0.RC1/gradle.properties#L12>
>  [4]
> (or SDG 2.1
> <https://github.com/spring-projects/spring-boot-data-geode/blob/1.1.0.RC1/gradle.properties#L10>
>  [5]);
> This is not arbitrary because all the stars (bits, transitive dependency
> versions) must "align" as defined by what Spring Boot 2.1 declares, and
> Spring Boot 2.1 is based on
> <https://github.com/spring-projects/spring-boot/blob/v2.1.7.RELEASE/spring-boot-project/spring-boot-dependencies/pom.xml#L169>
>  [6]
> Spring Data Lovelace/2.1.
> 4. Spring Data Geode (SDG) Lovelace/2.1 is based on
> <https://github.com/spring-projects/spring-data-geode/blob/2.1.10.RELEASE/pom.xml#L25>
>  [7]
> Apache Geode 1.6.
> 5. All SDG Lovelace/2.1.x versions will always be based on the latest
> Apache Geode 1.6.x anything (currently, 1.6.0) until the rest of time.
> This ship has sailed.
>
> 
>
> 6. SBDG 1.2, when it reaches development (soon),will be based on Spring
> Boot 2.2
> <https://github.com/jxblum/spring-boot-data-geode/blob/1.2.x/gradle.properties#L8>
>  [8],
> Spring Data (Geode) Moore
> <https://github.com/jxblum/spring-boot-data-geode/blob/1.2.x/gradle.properties#L12>
>  [9]
> (or SDG 2.2
> <https://github.com/jxblum/spring-boot-data-geode/blob/1.2.x/gradle.properties#L10>
>  [10]);
> This is also not arbitrary because Spring Boot 2.2 declares a dependency
> on
> <https://github.com/spring-projects/spring-boot/blob/v2.2.0.M5/spring-boot-project/spring-boot-dependencies/pom.xml#L185>
>  [11]
> Spring Data Moore.  Again, the stars must align.
> 7. Spring Data Geode (SDG) Moore/2.2 is based on
> <https://github.com/spring-projects/spring-data-geode/blob/2.2.0.RC2/pom.xml#L25>
>  [12]
> Apache Geode 1.9.0.
> 8. As you can see, SDG Moore/2.2 is already in release candidates (i.e.
> RC2 or the 2nd release candidate), which means SDG cannot be rebased on
> 1.10 at this point.  The transitive dependency major.minor versions are now
> fixed for SD(G) Moore/2.2.
> 9. SDG Moore/2.2 can pick up any version of Apache Geode 1.9.x (e.g. 1.9.1
> up to  1.9.N where N is 0... infinity).
>
> Finally, SDG's next opportunity to pick up Apache Geode 1.10 or 1.11 or
> 1.whatever is in the next SD Release Trains, Neuman, or 2.3.  SDG can
> continue to pick up new versions of Apache Geode 1.10, 1.11, 1.12, etc
> until SDG Neuman/2.3 reaches it's first release candidate (RC) release, at
> which point the major.minor becomes fixed in that particular SD Release
> Train, until the next SD Release Train (Neuman.next).
>
> Make sense?
>
> So, it is the SDG version (along with Spring Boot core) that SBDG depends
> on that determines the version of Apache Geode that SBDG pulls in.
>
> Hope this helps!
>
> Regards,
> John
>
>
> [1]
> https://github.com/spring-projects/spring-boot-data-geode/blob/master/gradle.properties#L17
> [2] https://github.com/spring-projects/spring-boot-data-geode/releases
> [3]
> https://github

Re: [DISCUSS] Release Geode 1.9.1 with logging improvements

[John Blum]

Sorry, corrections below...

On Tue, Aug 13, 2019 at 1:54 PM John Blum  wrote:

> Stated slightly a different way...
>
> If *SBDG 1.2 *were to be (re)based on *Apache Geode 1.10* directly, then
> it would *defy* the dependency on Apache Geode pulled in by SDG Moore/2.2
> (which is and can only be Geode 1.9 *at this point*) for which SBDG is
> also based, along with Spring Boot 2.2, which pulls in SD Moore/2.2 and
> therefore Geode 1.9, *indirectly (i.e. transitively)*, as well.  As such,
> the stars would not align and it would cause issues (or unexpected
> surprises, possibly conflicts) for users of Spring Boot when also using
> SBDG.  *With**out* SBDG, users of Spring Boot would get Geode 1.9 due to
> the SD Moore/2.2 dependency, but with SBDG on the classpath, it would
> suddenly (possibly) change the Geode version to 1.10.  That is definitively
> bad.
>
> Therefore, SBDG 1.2 based on Boot 2.2, Data 2.2 will get Geode 1.9.
>
> SBDG 1.3 will be based on Boot 2.3 (not available), Data 2.3 (not
> available) which will pull in the latest version of Geode at that time
> (e.g. 1.10, maybe 1.11) and continue to be upgraded until 2.3 reaches RC
> status.
>
> Cheers,
> John
>
>
>
>
> On Tue, Aug 13, 2019 at 1:45 PM John Blum  wrote:
>
>> For clarification...
>>
>> 1. SBDG 1.1 is the "*current*" development line (on
>> <https://github.com/spring-projects/spring-boot-data-geode/blob/master/gradle.properties#L17>
>> master
>> <https://github.com/spring-projects/spring-boot-data-geode/blob/master/gradle.properties#L17>
>>  [1]);
>> SBDG 1.2 is *not* yet in development.
>> 2. SBDG 1.1 is at RC1
>> <https://github.com/spring-projects/spring-boot-data-geode/releases> [2].
>> 3. SBDG 1.1 is based on Spring Boot 2.1
>> <https://github.com/spring-projects/spring-boot-data-geode/blob/1.1.0.RC1/gradle.properties#L8>
>>  [3]
>> and Spring Data (Geode) Lovelace
>> <https://github.com/spring-projects/spring-boot-data-geode/blob/1.1.0.RC1/gradle.properties#L12>
>>  [4]
>> (or SDG 2.1
>> <https://github.com/spring-projects/spring-boot-data-geode/blob/1.1.0.RC1/gradle.properties#L10>
>>  [5]);
>> This is not arbitrary because all the stars (bits, transitive dependency
>> versions) must "align" as defined by what Spring Boot 2.1 declares, and
>> Spring Boot 2.1 is based on
>> <https://github.com/spring-projects/spring-boot/blob/v2.1.7.RELEASE/spring-boot-project/spring-boot-dependencies/pom.xml#L169>
>>  [6]
>> Spring Data Lovelace/2.1.
>> 4. Spring Data Geode (SDG) Lovelace/2.1 is based on
>> <https://github.com/spring-projects/spring-data-geode/blob/2.1.10.RELEASE/pom.xml#L25>
>>  [7]
>> Apache Geode 1.6.
>> 5. All SDG Lovelace/2.1.x versions will always be based on the latest
>> Apache Geode 1.6.x anything (currently, 1.6.0) until the rest of time.
>> This ship has sailed.
>>
>> 
>>
>> 6. SBDG 1.2, when it reaches development (soon),will be based on Spring
>> Boot 2.2
>> <https://github.com/jxblum/spring-boot-data-geode/blob/1.2.x/gradle.properties#L8>
>>  [8],
>> Spring Data (Geode) Moore
>> <https://github.com/jxblum/spring-boot-data-geode/blob/1.2.x/gradle.properties#L12>
>>  [9]
>> (or SDG 2.2
>> <https://github.com/jxblum/spring-boot-data-geode/blob/1.2.x/gradle.properties#L10>
>>  [10]);
>> This is also not arbitrary because Spring Boot 2.2 declares a dependency
>> on
>> <https://github.com/spring-projects/spring-boot/blob/v2.2.0.M5/spring-boot-project/spring-boot-dependencies/pom.xml#L185>
>>  [11]
>> Spring Data Moore.  Again, the stars must align.
>> 7. Spring Data Geode (SDG) Moore/2.2 is based on
>> <https://github.com/spring-projects/spring-data-geode/blob/2.2.0.RC2/pom.xml#L25>
>>  [12]
>> Apache Geode 1.9.0.
>> 8. As you can see, SDG Moore/2.2 is already in release candidates (i.e.
>> RC2 or the 2nd release candidate), which means SDG cannot be rebased on
>> 1.10 at this point.  The transitive dependency major.minor versions are now
>> fixed for SD(G) Moore/2.2.
>> 9. SDG Moore/2.2 can pick up any version of Apache Geode 1.9.x (e.g.
>> 1.9.1 up to  1.9.N where N is 0... infinity).
>>
>> Finally, SDG's next opportunity to pick up Apache Geode 1.10 or 1.11 or
>> 1.whatever is in the next SD Release Trains, Neuman, or 2.3.  SDG can
>> continue to pick up new versions of Apache Geode 1.10, 1.11, 1.12, etc
>> until SDG Neuman/2.3 reaches it's first release candidate (RC) release, at
>> which point the major.minor becomes fixed i

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

[John Blum]

+1 to Nick's proposal!

While you cannot always guarantee that a dependency for whatever version,
whether a new major, an updated minor or simply a patch release won't
introduce problems (regressions, performance issues, or worse, CVEs), it is
extremely important to keep dependencies up-to-date, proactively, as much
as possible.

More often than not, they fix the very problems (bugs, CVEs, performance
issues) they introduced in the first place while also provide enhancements.

The bottom-line is, any project with transitive dependencies is responsible
for "managing" those dependencies.

-j


On Wed, Aug 14, 2019 at 6:43 AM Anthony Baker  wrote:

> Usually there’s a bit of manual “art” to updating dependencies.  You can’t
> always rely on stuff not breaking in minor releases.  The best example is
> JUnitParams.  Updating that breaks most of our tests since we use the test
> name for many things like region names and the new format is incompatible.
>
> The proposal seems reasonable.
>
> Anthony
>
>
> > On Aug 13, 2019, at 9:47 AM, Jacob Barrett  wrote:
> >
> > We can simply update all dependencies to their latest as long as within
> a major it doesn’t change the public API. We have tried to do this after
> releases, though sometimes that PR languishes for a while. There is no
> formal process though so formalizing it would be great. The release manager
> could just open a ticket that requests that all dependencies be updated,
> then anyone could jump on that ticket.
> >
> > -Jake
> >
> >
> >> On Aug 13, 2019, at 9:38 AM, Aaron Lindsey  wrote:
> >>
> >> 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 currently determine our major release cycle? Would we know at the time
> of a GA release whether the next release would be a major or minor release?
> >>
> >> - Aaron
> >>
> >>> On Aug 13, 2019, at 9:22 AM, Nicholas Vallely 
> wrote:
> >>>
> >>>
> https://cwiki.apache.org/confluence/display/GEODE/%5BDraft%5D+Geode+dependency+update+process
> >>>
> >>> Here is the content of the wiki proposal above for a discussion:
> >>> Problem
> >>>
> >>> We recently updated the dependencies for the log4j version used in
> Geode to
> >>> keep up with Spring Boot Data Geode's logging dependencies. As far as I
> >>> know, we do not have a process to keep dependencies up to date or
> regularly
> >>> scheduled updates to them. Currently, I believe this is handled ad-hoc
> >>> which hasn't necessarily caused any major issues but could.
> >>> Anti-GoalsSolution
> >>>
> >>> *Directly after GA release of Geode minor version:*
> >>> The release manager for the most recently released version of Geode
> would
> >>> review any dependencies in the Geode project (presumably this
> will/could be
> >>> automated).
> >>>
> >>> - For a minor release, only minor version dependency updates should be
> >>> considered
> >>> - For a major release, major versions should be considered
> >>>
> >>> The release manager would submit a PR to update dependencies and then
> the
> >>> community should pitch in to tackle any subsequent issues that arise
> from
> >>> the updating of dependencies. *Note the first time this happens maybe
> >>> painful*
> >>>
> >>> *In-between releases:*
> >>> We keep doing what we are doing:
> >>>
> >>> - Ad-hoc dependency updates as necessary
> >>>
> >>> *When a new release manager is chosen:*
> >>> The release manager would send out an email as the last call for
> dependency
> >>> updates that would coincide with a proposed release branch cut date.
> This
> >>> would give everyone a reminder that if they need to update a dependency
> >>> prior to the release there is limited time left in order to do so.
> >>> Changes and Additions to Public Interfaces
> >>>
> >>> *n/a*
> >>> Performance Impact
> >>>
> >>> *Potentially a new version of a dependency could cause a performance
> impact
> >>> and we should run a performance test suite on the recently released
> version
> >>> vs the updated dependency version*
> >>> Backwards Compatibility and Upgrade Path
> >>>
> >>> *In a minor release, minor version dependency updates shouldn't cause
> >>> compatibility issues.*
> >>> Prior Art
> >>>
> >>> *What would be the alternatives to the proposed solution? What would
> happen
> >>> if we don’t solve the problem? Why should this proposal be preferred?*
> >>>
> >>> *If we continue to do this ad-hoc, there is a greater likelihood of
> CVE's
> >>> or mismatching versions of conflicts between Geode and dependent
> projects.*
> >>>
> >>>
> >>> *Nick*
> >>
> >
>
>

-- 
-John
john.blum10101 (skype)

Re: Proposal to Include GEODE-7079 in 1.10.0

[John Blum]

+1

On Thu, Aug 15, 2019 at 5:30 AM Ju@N  wrote:

> Hello team,
>
> I'd like to propose including the *fix [1]* for *GEODE-7079 [2]* in release
> 1.10.0.
> Long story short: a *NullPointerException* can be continuously thrown
> and flood the member's logs if a serial event processor (either
> *async-event-queue* or *gateway-sender*) starts processing events from a
> recovered persistent queue before the actual region to which it was
> attached is fully operational.
> Note: *no events are lost (even without the fix)* but, if the region takes
> a while to recover, the logs  for the member can grow pretty quickly due to
> the continuously thrown *NPEs.*
> Best regards.
>
> [1]:
>
> https://github.com/apache/geode/commit/6f4bbbd96bcecdb82cf7753ce1dae9fa6baebf9b
> [2]: https://issues.apache.org/jira/browse/GEODE-7079
>
> --
> Ju@N
>


-- 
-John
john.blum10101 (skype)

Re: [DISCUSS] Controlling event dispatch to AsyncEventListener (review by Aug 22)

[John Blum]

After talking with *Alexander* this morning (and taking *Mike's* concerns
into consideration), and to not adversely affect users/customers today, I
think...

1). AEQ's can (should) have a configuration setting to "manually" start the
queue's background processor (i.e. Thread) to begin processing (existing,
persistent) events. This would be consistent with GatewaySender processing.

2) I think that the default behavior should remain as is, the AEQ starts
automatically, as before...
2.1) As such, this will not present any surprises for existing
users/customers that expect the AEQ to start processing automatically as it
currently does.
2.2) If users wants to have the AEQ start manually, then they must
"explicitly" configure it to do so (as with GatewaySenders today), which is
a "conscious" choice since they probably have encountered some
non-apparent, distributed, cyclic dependency (e.g. Region A -> AEQ -> AEQ
Listener -> Region B) which could cause initialization safety problems,
race conditions or other distributed deadlock problems (e.g. deadly
embrace) if not properly coordinated, and perhaps the only way to achieve
that arrangement reliably is by starting an AEQ manually in these
situations.  Either way, it is an explicit/conscious choice by the user.

3) If we are talking about API, then I would envision a very "consistent"
and "familiar" API to the GatewaySenderFactory API already, i.e.
GatewaySenderFactory.setManualStart(start:boolean).

You could possibly provide an overloaded AsyncEventQueueFactory.create(..)
method, such as create(id:String, :AsyncEventListener, manualStart:boolean),
but meh.


Food for thought,
John




On Tue, Aug 20, 2019 at 2:01 PM Nabarun Nag  wrote:

> Hi Anil,
>
> Will it be possible to explain to the community how the starting AEQ in a
> paused state is different from creating gateway senders with manual start
> set to true. It may be of concern as  'manual start'  for gateways is a
> deprecated.
>
> Just thinking out loud, will it be more feasible if we can set the flag at
> cache level. Any framework that is starting up Apache Geode (E.g: Spring) ,
> creates the cache -> cache.pauseProcessing(); -> create regions -> create
> AEQs -> cache.unpauseProcessing()
>
> We can gate the processing of all event listener at dispatchBatch().
>
> The advantage I feel is that
>  - we avoid introducing a new API to the AEQ creation factory.
>  - if we created 100 AEQs in paused state then we avoid having to have 100
> AEQ.unpause calls.
>
>
> Regards
> Naba
>
>
> On Tue, Aug 20, 2019 at 9:07 AM Michael Stolz  wrote:
>
> > Manual start has caused a lot of trouble over the years. We should
> > definitely circle back on those issues before traveling very far down
> this
> > road.
> >
> > --
> > Mike Stolz
> > Principal Engineer, Pivotal Cloud Cache
> > Mobile: +1-631-835-4771
> >
> >
> >
> > On Tue, Aug 20, 2019 at 11:56 AM Juan José Ramos 
> > wrote:
> >
> > > Hello Anil,
> > >
> > > +1 for the proposed solution.
> > > I'd change the method name from *pauseEventDispatchToListener* to
> > something
> > > more meaningful and understandable for our users, maybe *startPaused*?,
> > > *setManualStart* (as we currently have for the
> *GatewaySenderFactory*)?,
> > > *startWithEventDispatcherPaused*?.
> > > Best regards.
> > >
> > >
> > >
> > > On Sat, Aug 17, 2019 at 12:55 AM Anilkumar Gingade <
> aging...@pivotal.io>
> > > wrote:
> > >
> > > > I have updated the wiki based on Dan's comment.
> > > > Changes with api:
> > > >
> > > > *On "AsyncEventQueueFactory" interface - *
> > > >
> > > > *AsyncEventQueueFactory pauseEventDispatchToListener();  *// This
> > causes
> > > > AEQ to be created with paused state.
> > > >
> > > >
> > > >
> > > >
> > > > On Fri, Aug 16, 2019 at 4:36 PM Anilkumar Gingade <
> aging...@pivotal.io
> > >
> > > > wrote:
> > > >
> > > > > Dan,
> > > > >
> > > > > If you look into the API; the AEQ will be created with the pause
> > state.
> > > > > The user (application) has to call resume to dispatch the events.
> > > > >
> > > > > It will be slightly different from GatewaySender behavior; where
> > > > > GatewaySender will be created with run mode and then application
> has
> > to
> > > > > call pause on it. Here in this case AEQ will be created with paused
> > > > state.
> > > > >
> > > > > -Anil.
> > > > >
> > > > >
> > > > > On Fri, Aug 16, 2019 at 4:31 PM Dan Smith 
> wrote:
> > > > >
> > > > >> Hi Anil,
> > > > >>
> > > > >> While I like the idea of matching the API of GatewaySender, I'm
> not
> > > > sure I
> > > > >> see how this solves the problem. Is it required of the user to
> call
> > > > pause
> > > > >> on the AsyncEventQueue as soon as it is created? How would someone
> > do
> > > > that
> > > > >> when creating AEQs with xml or cluster configuration? Maybe it
> would
> > > be
> > > > >> better to not dispatch any events until we are done creating all
> > > > regions?
> > > > >>
> > > > >> -Dan
> > > > >>
> > > > >> On Fri, Aug 16, 2019 at 2:31 PM Anilkumar 

Re: [DISCUSS] Controlling event dispatch to AsyncEventListener (review by Aug 22)

[John Blum]

FTR, I am not opposed to *Naba's* idea either.   +1

I kind of like the idea of having a global, cache-wide call that can
coordinate the background initialization/processing of all other Geode
objects that have lifecycle processes starting in the background  (e.g.
Gateways, AEQs, etc).



On Tue, Aug 20, 2019 at 2:38 PM Kirk Lund  wrote:

> If we need to add pause/resume processing to Cache, I suggest adding
> setAutostart(boolean) to CacheFactory and start() to Cache to do something
> like this:
>
> Cache cache = new CacheFactory()
> *.setAutostart(false)*
> .create();
> cache.createRegionFactory(...)...
> cache.createAsyncEventQueueFactory(...)...
> cache.addCacheServer()...
> cache.*start()*;
>
> AEQs, CacheServers, GatewaySenders/Receivers and any other endpoints that
> are created would not be started until invoking cache.start().
>
> Cheers,
> Kirk
>
> On Tue, Aug 20, 2019 at 2:01 PM Nabarun Nag  wrote:
>
> > Hi Anil,
> >
> > Will it be possible to explain to the community how the starting AEQ in a
> > paused state is different from creating gateway senders with manual start
> > set to true. It may be of concern as  'manual start'  for gateways is a
> > deprecated.
> >
> > Just thinking out loud, will it be more feasible if we can set the flag
> at
> > cache level. Any framework that is starting up Apache Geode (E.g:
> Spring) ,
> > creates the cache -> cache.pauseProcessing(); -> create regions -> create
> > AEQs -> cache.unpauseProcessing()
> >
> > We can gate the processing of all event listener at dispatchBatch().
> >
> > The advantage I feel is that
> >  - we avoid introducing a new API to the AEQ creation factory.
> >  - if we created 100 AEQs in paused state then we avoid having to have
> 100
> > AEQ.unpause calls.
> >
> >
> > Regards
> > Naba
> >
> >
> > On Tue, Aug 20, 2019 at 9:07 AM Michael Stolz  wrote:
> >
> > > Manual start has caused a lot of trouble over the years. We should
> > > definitely circle back on those issues before traveling very far down
> > this
> > > road.
> > >
> > > --
> > > Mike Stolz
> > > Principal Engineer, Pivotal Cloud Cache
> > > Mobile: +1-631-835-4771
> > >
> > >
> > >
> > > On Tue, Aug 20, 2019 at 11:56 AM Juan José Ramos 
> > > wrote:
> > >
> > > > Hello Anil,
> > > >
> > > > +1 for the proposed solution.
> > > > I'd change the method name from *pauseEventDispatchToListener* to
> > > something
> > > > more meaningful and understandable for our users, maybe
> *startPaused*?,
> > > > *setManualStart* (as we currently have for the
> > *GatewaySenderFactory*)?,
> > > > *startWithEventDispatcherPaused*?.
> > > > Best regards.
> > > >
> > > >
> > > >
> > > > On Sat, Aug 17, 2019 at 12:55 AM Anilkumar Gingade <
> > aging...@pivotal.io>
> > > > wrote:
> > > >
> > > > > I have updated the wiki based on Dan's comment.
> > > > > Changes with api:
> > > > >
> > > > > *On "AsyncEventQueueFactory" interface - *
> > > > >
> > > > > *AsyncEventQueueFactory pauseEventDispatchToListener();  *// This
> > > causes
> > > > > AEQ to be created with paused state.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Fri, Aug 16, 2019 at 4:36 PM Anilkumar Gingade <
> > aging...@pivotal.io
> > > >
> > > > > wrote:
> > > > >
> > > > > > Dan,
> > > > > >
> > > > > > If you look into the API; the AEQ will be created with the pause
> > > state.
> > > > > > The user (application) has to call resume to dispatch the events.
> > > > > >
> > > > > > It will be slightly different from GatewaySender behavior; where
> > > > > > GatewaySender will be created with run mode and then application
> > has
> > > to
> > > > > > call pause on it. Here in this case AEQ will be created with
> paused
> > > > > state.
> > > > > >
> > > > > > -Anil.
> > > > > >
> > > > > >
> > > > > > On Fri, Aug 16, 2019 at 4:31 PM Dan Smith 
> > wrote:
> > > > > >
> > > > > >> Hi Anil,
> > > > > >>
> > > > > >> While I like the idea of matching the API of GatewaySender, I'm
> > not
> > > > > sure I
> > > > > >> see how this solves the problem. Is it required of the user to
> > call
> > > > > pause
> > > > > >> on the AsyncEventQueue as soon as it is created? How would
> someone
> > > do
> > > > > that
> > > > > >> when creating AEQs with xml or cluster configuration? Maybe it
> > would
> > > > be
> > > > > >> better to not dispatch any events until we are done creating all
> > > > > regions?
> > > > > >>
> > > > > >> -Dan
> > > > > >>
> > > > > >> On Fri, Aug 16, 2019 at 2:31 PM Anilkumar Gingade <
> > > > aging...@pivotal.io>
> > > > > >> wrote:
> > > > > >>
> > > > > >> > Proposal to support controlling capability with event dispatch
> > to
> > > > > >> > AsyncEventQueue Listener.
> > > > > >> >
> > > > > >> > Wiki proposal page:
> > > > > >> >
> > > > > >> >
> > > > > >>
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/GEODE/%5BDraft%5D+Controlling+event+dispatch+to+AsyncEventListener
> > > > > >> >
> > > > > >> > Here is the details from the wiki page:
> > > > > >> > *Problem*
> 

Re: [DISCUSS] Release Geode 1.9.1 with logging improvements

[John Blum]

+1 Yes!

SBDG needs the Apache Geode 1.9.1 release with the Logging changes if you
want to see Apache Geode on *Spring Initializer*.  The Logging issues are
impeding the presence of Apache Geode on *Initializer* at start.spring.io.


On Wed, Aug 28, 2019 at 4:48 PM Anthony Baker  wrote:

> I think it makes sense to do a 1.9.1 release for the same reasons that we
> proposed it originally.  It looks like we all missed the VOTE thread (it
> was on my // todo list).In the past when we’ve had insufficient votes,
> we've extended the deadline and asked for help reviewing the release.
>
> Anthony
>
>
> > On Aug 28, 2019, at 1:38 PM, Owen Nichols  wrote:
> >
> > The VOTE for 1.9.1.RC1 failed due to lack of quorum, so re-opening this
> thread to continue the discussion.
> >
> > Is there still a need for a 1.9 patch release (especially given that
> 1.10.0.RC1 is expected later this week)?
> >
> > If so, perhaps we should back up a step or two and first:
> > 1) come to rough consensus that 1.9.1 is still desired (and what should
> be in it)
> > 2) ensure that we have Geode PMC support for this release
> > 3) go through the formal process of voting each cherry-pick in the patch
> release
> >
> > This could result in a recommendation to re-vote on RC1, a
> recommendation to produce a new RC2, a recommendation to pull the plug (or
> no recommendation).
> >
> > As a failsafe, I hereby invoke lazy consensus: In the event that no
> explicit decision to move forward with 1.9.1 is reached by 3pm PDT Wed Sep
> 4, I will dismantle the current 1.9.1 branch, pipeline and nexus staging
> repo and remove 1.9.1 from the release notes wiki.
> >
> > -Owen
> >
> >
> >> On Aug 18, 2019, at 7:52 AM, Anthony Baker  wrote:
> >>
> >> Yep. Get a release manager, identify and cherry pick all the changes,
> then do the release.
> >>
> >> Anthony
> >>
> >>> On Aug 16, 2019, at 4:21 PM, Kirk Lund  wrote:
> >>>
> >>> Does anyone know what the next step is? Do we need a release manager to
> >>> proceed?
> >>>
> >>>> On Tue, Aug 13, 2019 at 1:57 PM John Blum  wrote:
> >>>>
> >>>> Sorry, corrections below...
> >>>>
> >>>>> On Tue, Aug 13, 2019 at 1:54 PM John Blum  wrote:
> >>>>>
> >>>>> Stated slightly a different way...
> >>>>>
> >>>>> If *SBDG 1.2 *were to be (re)based on *Apache Geode 1.10* directly,
> then
> >>>>> it would *defy* the dependency on Apache Geode pulled in by SDG
> Moore/2.2
> >>>>> (which is and can only be Geode 1.9 *at this point*) for which SBDG
> is
> >>>>> also based, along with Spring Boot 2.2, which pulls in SD Moore/2.2
> and
> >>>>> therefore Geode 1.9, *indirectly (i.e. transitively)*, as well.  As
> such,
> >>>>> the stars would not align and it would cause issues (or unexpected
> >>>>> surprises, possibly conflicts) for users of Spring Boot when also
> using
> >>>>> SBDG.  *With**out* SBDG, users of Spring Boot would get Geode 1.9
> due to
> >>>>> the SD Moore/2.2 dependency, but with SBDG on the classpath, it would
> >>>>> suddenly (possibly) change the Geode version to 1.10.  That is
> >>>> definitively
> >>>>> bad.
> >>>>>
> >>>>> Therefore, SBDG 1.2 based on Boot 2.2, Data 2.2 will get Geode 1.9.
> >>>>>
> >>>>> SBDG 1.3 will be based on Boot 2.3 (not available), Data 2.3 (not
> >>>>> available) which will pull in the latest version of Geode at that
> time
> >>>>> (e.g. 1.10, maybe 1.11) and continue to be upgraded until 2.3
> reaches RC
> >>>>> status.
> >>>>>
> >>>>> Cheers,
> >>>>> John
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>> On Tue, Aug 13, 2019 at 1:45 PM John Blum  wrote:
> >>>>>>
> >>>>>> For clarification...
> >>>>>>
> >>>>>> 1. SBDG 1.1 is the "*current*" development line (on
> >>>>>> <
> >>>>
> https://github.com/spring-projects/spring-boot-data-geode/blob/master/gradle.properties#L17
> >>>>>
> >>>>>> master
> >>>>>> <
> >>>>
> https://github.com/spring-projects/spring-boot-da

Re: [VOTE] Apache Geode 1.9.1 RC1

[John Blum]

+1

On Wed, Aug 28, 2019 at 2:51 PM Dan Smith  wrote:

> I missed this vote email as well - if we reopen the vote I'll cast one. I
> don't really have much context on why we want a 1.9.1 but I'm happy to
> double check the bits.
>
> One comment on this RC - I noticed that we bumped the ordinal in
> Version.java - is that what we actually want to do? That implies a new
> version of our communications protocol, which 1.10 will have to understand.
> Did we actually change the communication protocol in this release?
>
> -Dan
>
> On Wed, Aug 28, 2019 at 2:42 PM Kirk Lund  wrote:
>
> > SBDG 1.2 is currently in RC and cannot be changed to depend on Geode
> 1.10.
> > It must depend on Geode 1.9 or 1.9.1.
> >
> > So if we want to provide the logging fixes for SBDG 1.2 then we must
> > release Geode 1.9.1.
> >
> > Let's open a new vote for releasing Geode 1.9.1.
> >
> > On Wed, Aug 28, 2019 at 1:37 PM Owen Nichols 
> wrote:
> >
> > > It's past the announced deadline and the vote has failed to due to lack
> > of
> > > quorum.
> > >
> > > Voting status
> > > ==
> > > +1: zero votes
> > >
> > > +0: zero votes
> > >
> > > -0: zero votes
> > >
> > > -1: zero votes
> > >
> > > The voting does not meet the requirements <
> > > https://www.apache.org/foundation/voting.html> of at least 3 PMC
> members
> > > with +1 votes and a majority of +1 votes.
> > >
> > > The matter of what to do next is referred back to the original DISCUSS
> > > thread that proposed 1.9.1.
> > >
> > > -Owen & Kirk
> > >
> > > > On Aug 22, 2019, at 6:10 PM, Owen Nichols 
> wrote:
> > > >
> > > > Hello Geode dev community,
> > > >
> > > > This is a release candidate for Apache Geode, version 1.9.1.RC1.
> > > > Thanks to all the community members for their contributions to this
> > > release!
> > > >
> > > > Please do a review and give your feedback. The deadline is 3PM PST
> Tue,
> > > August 27 2019.
> > > > Release notes can be found at:
> > >
> >
> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.9.1
> > > <
> > >
> >
> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.9.1
> > >
> > >
> > > >
> > > > Please note that we are voting on the source tag: rel/v1.9.1.RC1
> > > >
> > > > Apache Geode:
> > > > https://github.com/apache/geode/tree/rel/v1.9.1.RC1 <
> > > https://github.com/apache/geode/tree/rel/v1.9.1.RC1>
> > > > Apache Geode examples:
> > > > https://github.com/apache/geode-examples/tree/rel/v1.9.1.RC1 <
> > > https://github.com/apache/geode-examples/tree/rel/v1.9.1.RC1>
> > > > Apache Geode native:
> > > > https://github.com/apache/geode-native/tree/rel/v1.9.1.RC1 <
> > > https://github.com/apache/geode-native/tree/rel/v1.9.1.RC1>
> > > >
> > > > Source and binary files:
> > > > https://dist.apache.org/repos/dist/dev/geode/1.9.1.RC1/ <
> > > https://dist.apache.org/repos/dist/dev/geode/1.9.1.RC1/>
> > > >
> > > > Maven staging repo:
> > > >
> https://repository.apache.org/content/repositories/orgapachegeode-1055
> > <
> > > https://repository.apache.org/content/repositories/orgapachegeode-1055
> >
> > > >
> > > > Geode's KEYS file containing PGP keys we use to sign the release:
> > > > https://github.com/apache/geode/blob/develop/KEYS <
> > > https://github.com/apache/geode/blob/develop/KEYS>
> > > >
> > > > PS: Command to run geode-examples: ./gradlew -PgeodeReleaseUrl=
> > > https://dist.apache.org/repos/dist/dev/geode/1.9.1.RC1 <
> > > https://dist.apache.org/repos/dist/dev/geode/1.9.1.RC1>
> > > -PgeodeRepositoryUrl=
> > > https://repository.apache.org/content/repositories/orgapachegeode-1055
> <
> > > https://repository.apache.org/content/repositories/orgapachegeode-1055
> >
> > > build runAll
> > > >
> > > > Regards
> > > > Owen Nichols & Kirk Lund
> > > >
> > >
> > >
> >
>


-- 
-John
john.blum10101 (skype)

Re: [VOTE] Apache Geode 1.9.1 RC1 (new vote)

[John Blum]

+1

On Thu, Aug 29, 2019 at 9:41 AM Kirk Lund  wrote:

> +1 (just in case my vote counts)
>
> On Thu, Aug 29, 2019 at 9:02 AM Kirk Lund  wrote:
>
> > Hello Geode dev community,
> >
> > This is a release candidate for Apache Geode, version 1.9.1.RC1.
> > Thanks to all the community members for their contributions to this
> > release!
> >
> > Please do a review and give your feedback. The deadline is 3PM PST Tue,
> > August 27 2019.
> > Release notes can be found at:
> >
> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.9.1
> >  <
> >
> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.9.1
> > >
> >
> > Please note that we are voting on the source tag: rel/v1.9.1.RC1
> >
> > Apache Geode:
> > https://github.com/apache/geode/tree/rel/v1.9.1.RC1 <
> > https://github.com/apache/geode/tree/rel/v1.9.1.RC1>
> > Apache Geode examples:
> > https://github.com/apache/geode-examples/tree/rel/v1.9.1.RC1 <
> > https://github.com/apache/geode-examples/tree/rel/v1.9.1.RC1>
> > Apache Geode native:
> > https://github.com/apache/geode-native/tree/rel/v1.9.1.RC1 <
> > https://github.com/apache/geode-native/tree/rel/v1.9.1.RC1>
> >
> > Source and binary files:
> > https://dist.apache.org/repos/dist/dev/geode/1.9.1.RC1/ <
> > https://dist.apache.org/repos/dist/dev/geode/1.9.1.RC1/>
> >
> > Maven staging repo:
> > https://repository.apache.org/content/repositories/orgapachegeode-1055 <
> > https://repository.apache.org/content/repositories/orgapachegeode-1055>
> >
> > Geode's KEYS file containing PGP keys we use to sign the release:
> > https://github.com/apache/geode/blob/develop/KEYS <
> > https://github.com/apache/geode/blob/develop/KEYS>
> >
> > PS: Command to run geode-examples: ./gradlew -PgeodeReleaseUrl=
> > https://dist.apache.org/repos/dist/dev/geode/1.9.1.RC1
> >  -PgeodeRepositoryUrl=
> > https://repository.apache.org/content/repositories/orgapachegeode-1055
> build
> > runAll
> >
> > Regards
> > Owen Nichols & Kirk Lund
> >
>


-- 
-John
john.blum10101 (skype)

Re: [VOTE] Apache Geode 1.9.1 RC1

[John Blum]

FWIW, I don't think 1.9.1 clients (or any combination of patch versions)
should be incompatible with servers 1.9.patch-1 (e.g. 1.9.0).  IMO, that
would be very bad!

major.minor client/servers, regardless of patch versions, should remain
interoperable.

On Thu, Aug 29, 2019 at 11:41 AM Owen Nichols  wrote:

> 1.9.1 was added to 1.10 and develop as well, so will need to be reverted
> everywhere and will not be able to do the 1.10.0 RC1 today
>
> > On Aug 29, 2019, at 11:35 AM, Dan Smith  wrote:
> >
> > From my reading, bumping the ordinal in 1.9.1 will make 1.9.1
> incompatible
> > with 1.10, unless we also fix 1.10 to know about 1.9.1's ordinal. It will
> > also make 1.9.1 clients incompatible with 1.9.0 servers, which may not be
> > desired?
> >
> > I guess we just need to settle on a process. It sounds like maybe the
> > process should be always bump on minor releases, but don't bump the
> version
> > on patch releases unless we really need to change the protocol for a
> patch
> > release. Previous geode patch releases (1.2.1, 1.1.1) did not change
> > Version.java. If that's the case, I think we should go ahead and revert
> the
> > changes to Version.java for 1.9.1 and create a new RC.
> >
> > -Dan
> >
> > On Thu, Aug 29, 2019 at 10:35 AM Anthony Baker 
> wrote:
> >
> >> I see there’s a VOTE thread for 1.9.1.  Do you suggest to -1 that
> release
> >> candidate?
> >>
> >> Anthony
> >>
> >>
> >>> On Aug 29, 2019, at 8:53 AM, Bruce Schuchardt 
> >> wrote:
> >>>
> >>> I also missed this vote email.  Dan is right that creating the v1.9.1
> >> Version instance was unnecessary.  I don't think it hurts anything per
> se
> >> but it does unnecessarily consume a serialization version ordinal.  That
> >> will leave us with only 3 (102, 103 and 104) if we *ever* need to issue
> >> more 1.9 patches.  I recommend removing that Version and leaving the
> >> serialization version at 1.9.0 for this release.
> >>>
> >>> On 8/28/19 2:51 PM, Dan Smith wrote:
>  I missed this vote email as well - if we reopen the vote I'll cast
> one.
> >> I
>  don't really have much context on why we want a 1.9.1 but I'm happy to
>  double check the bits.
> 
>  One comment on this RC - I noticed that we bumped the ordinal in
>  Version.java - is that what we actually want to do? That implies a new
>  version of our communications protocol, which 1.10 will have to
> >> understand.
>  Did we actually change the communication protocol in this release?
> 
>  -Dan
> 
>  On Wed, Aug 28, 2019 at 2:42 PM Kirk Lund  wrote:
> 
> > SBDG 1.2 is currently in RC and cannot be changed to depend on Geode
> >> 1.10.
> > It must depend on Geode 1.9 or 1.9.1.
> >
> > So if we want to provide the logging fixes for SBDG 1.2 then we must
> > release Geode 1.9.1.
> >
> > Let's open a new vote for releasing Geode 1.9.1.
> >
> > On Wed, Aug 28, 2019 at 1:37 PM Owen Nichols 
> >> wrote:
> >
> >> It's past the announced deadline and the vote has failed to due to
> >> lack
> > of
> >> quorum.
> >>
> >> Voting status
> >> ==
> >> +1: zero votes
> >>
> >> +0: zero votes
> >>
> >> -0: zero votes
> >>
> >> -1: zero votes
> >>
> >> The voting does not meet the requirements <
> >> https://www.apache.org/foundation/voting.html> of at least 3 PMC
> >> members
> >> with +1 votes and a majority of +1 votes.
> >>
> >> The matter of what to do next is referred back to the original
> DISCUSS
> >> thread that proposed 1.9.1.
> >>
> >> -Owen & Kirk
> >>
> >>> On Aug 22, 2019, at 6:10 PM, Owen Nichols 
> >> wrote:
> >>>
> >>> Hello Geode dev community,
> >>>
> >>> This is a release candidate for Apache Geode, version 1.9.1.RC1.
> >>> Thanks to all the community members for their contributions to this
> >> release!
> >>> Please do a review and give your feedback. The deadline is 3PM PST
> >> Tue,
> >> August 27 2019.
> >>> Release notes can be found at:
> >
> >>
> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.9.1
> >> <
> >>
> >
> >>
> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.9.1
> >>
> >>> Please note that we are voting on the source tag: rel/v1.9.1.RC1
> >>>
> >>> Apache Geode:
> >>> https://github.com/apache/geode/tree/rel/v1.9.1.RC1 <
> >> https://github.com/apache/geode/tree/rel/v1.9.1.RC1>
> >>> Apache Geode examples:
> >>> https://github.com/apache/geode-examples/tree/rel/v1.9.1.RC1 <
> >> https://github.com/apache/geode-examples/tree/rel/v1.9.1.RC1>
> >>> Apache Geode native:
> >>> https://github.com/apache/geode-native/tree/rel/v1.9.1.RC1 <
> >> https://github.com/apache/geode-native/tree/rel/v1.9.1.RC1>
> >>> Source and binary files:
> >>> https://dist.apache.org/repos/dist/dev/geode/1.9.1.RC1/ <
> >> h

Re: [VOTE] Apache Geode 1.9.1 RC1 (new vote)

[John Blum]

Final SD[G] Moore-RELEASE/2.2 GA is (tentatively) scheduled for Thurs, Sept
19th.  Even still, any SD[G] Moore service release post GA (e.g. 2.2.1,
2.2.2, ..., 2.2.N) can pick up any patch release of Apache Geode 1.9.x
(e.g. 1.9.1, 1.9.2, ..., 1.9.N).  Additionally, SBDG 1.2 cannot go GA
before *Spring Boot* 2.2, which cannot GA before SD[G] Moore (and same
level dependencies, e.g. *Spring Batch*, *Spring Integration*, etc), which
cannot GA before *Spring Framework* 5.2 GA.

All this is to say that it is still worth doing a 1.9.1 patch release and
even a 1.9.2, and so on, as necessary for as long as SD[G] Moore is
supported, which is 1.5 years from initial GA, again Sept 19th.

In general, I would like to see LTS versions of 'Apache Geode, with patch
releases, in the same manner that the Java platform itself has LTS versions
(e.g. 1.8, 1.11(?)) unlike the non-LTS versions (e.g. 1.9, 1.10).

Food for thought.

-j


On Thu, Aug 29, 2019 at 2:33 PM Kirk Lund  wrote:

> We submitted a PR against release/1.9.1 to remove 1.9.1 from Version:
>
> https://github.com/apache/geode/pull/3989
>
> Please review. After we merge this in, we'll create RC2 and start a vote
> for it.
>
> Thanks,
> Kirk and Owen
>
> On Thu, Aug 29, 2019 at 1:53 PM Kirk Lund  wrote:
>
> > Anyone want to help me revert these Version changes and make an RC2? I'm
> > not sure how to do this correctly.
> >
> > On Thu, Aug 29, 2019 at 1:48 PM Kirk Lund  wrote:
> >
> >> Deadline for voting is Sept 5th. However, we have two -1 votes so RC1 is
> >> dead.
> >>
> >> @John I'm not sure we can make the deadline for SB2 now? Is it still
> >> worth trying to create RC2 for SB?
> >>
> >> On Thu, Aug 29, 2019 at 12:34 PM Bruce Schuchardt <
> bschucha...@pivotal.io>
> >> wrote:
> >>
> >>> -1 we should revert the 1.9.1 Version.java change on this branch and on
> >>> develop
> >>>
> >>>
> >>> On 8/29/19 9:02 AM, Kirk Lund wrote:
> >>> > Hello Geode dev community,
> >>> >
> >>> > This is a release candidate for Apache Geode, version 1.9.1.RC1.
> >>> > Thanks to all the community members for their contributions to this
> >>> release!
> >>> >
> >>> > Please do a review and give your feedback. The deadline is 3PM PST
> Tue,
> >>> > August 27 2019.
> >>> > Release notes can be found at:
> >>> >
> >>>
> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.9.1
> >>> >   <
> >>> >
> >>>
> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.9.1
> >>> > Please note that we are voting on the source tag: rel/v1.9.1.RC1
> >>> >
> >>> > Apache Geode:
> >>> > https://github.com/apache/geode/tree/rel/v1.9.1.RC1 <
> >>> > https://github.com/apache/geode/tree/rel/v1.9.1.RC1>
> >>> > Apache Geode examples:
> >>> > https://github.com/apache/geode-examples/tree/rel/v1.9.1.RC1 <
> >>> > https://github.com/apache/geode-examples/tree/rel/v1.9.1.RC1>
> >>> > Apache Geode native:
> >>> > https://github.com/apache/geode-native/tree/rel/v1.9.1.RC1 <
> >>> > https://github.com/apache/geode-native/tree/rel/v1.9.1.RC1>
> >>> >
> >>> > Source and binary files:
> >>> > https://dist.apache.org/repos/dist/dev/geode/1.9.1.RC1/ <
> >>> > https://dist.apache.org/repos/dist/dev/geode/1.9.1.RC1/>
> >>> >
> >>> > Maven staging repo:
> >>> >
> https://repository.apache.org/content/repositories/orgapachegeode-1055
> >>> <
> >>> >
> https://repository.apache.org/content/repositories/orgapachegeode-1055
> >>> >
> >>> >
> >>> > Geode's KEYS file containing PGP keys we use to sign the release:
> >>> > https://github.com/apache/geode/blob/develop/KEYS <
> >>> > https://github.com/apache/geode/blob/develop/KEYS>
> >>> >
> >>> > PS: Command to run geode-examples: ./gradlew -PgeodeReleaseUrl=
> >>> > https://dist.apache.org/repos/dist/dev/geode/1.9.1.RC1
> >>> -PgeodeRepositoryUrl=
> >>> >
> https://repository.apache.org/content/repositories/orgapachegeode-1055
> >>> build
> >>> > runAll
> >>> >
> >>> > Regards
> >>> > Owen Nichols & Kirk Lund
> >>> >
> >>>
> >>
>


-- 
-John
john.blum10101 (skype)

Re: [VOTE] Apache Geode 1.9.1 RC2

[John Blum]

+1

On Thu, Aug 29, 2019 at 5:40 PM Udo Kohlmeyer  wrote:

> +1
>
> On 8/29/19 5:02 PM, Owen Nichols wrote:
> > Hello Geode dev community,
> >
> > This is a release candidate for Apache Geode, version 1.9.1.RC2.
> > Thanks to all the community members for their contributions to this
> release!
> >
> > Please do a review and give your feedback. The deadline is 3PM PST Wed,
> September 04 2019.
> > Release notes can be found at:
> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.9.1
> <
> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.9.1
> >
> >
> > Please note that we are voting upon the source tags: rel/v1.9.1.RC2
> >
> > Apache Geode:
> > https://github.com/apache/geode/tree/rel/v1.9.1.RC2 <
> https://github.com/apache/geode/tree/rel/v1.9.1.RC2>
> > Apache Geode examples:
> > https://github.com/apache/geode-examples/tree/rel/v1.9.1.RC2 <
> https://github.com/apache/geode-examples/tree/rel/v1.9.1.RC2>
> > Apache Geode native:
> > https://github.com/apache/geode-native/tree/rel/v1.9.1.RC2 <
> https://github.com/apache/geode-native/tree/rel/v1.9.1.RC2>
> >
> > Source and binary files:
> > https://dist.apache.org/repos/dist/dev/geode/1.9.1.RC2/ <
> https://dist.apache.org/repos/dist/dev/geode/1.9.1.RC2/>
> >
> > Maven staging repo:
> > https://repository.apache.org/content/repositories/orgapachegeode-1056 <
> https://repository.apache.org/content/repositories/orgapachegeode-1056>
> >
> > Geode's KEYS file containing PGP keys we use to sign the release:
> > https://github.com/apache/geode/blob/develop/KEYS <
> https://github.com/apache/geode/blob/develop/KEYS>
> >
> > PS: Command to run geode-examples: ./gradlew -PgeodeReleaseUrl=
> https://dist.apache.org/repos/dist/dev/geode/1.9.1.RC2
> -PgeodeRepositoryUrl=
> https://repository.apache.org/content/repositories/orgapachegeode-1056
> build runAll
> >
> > Regards
> > Owen & Kirk
>


-- 
-John
john.blum10101 (skype)

Re: [VOTE] Apache Geode 1.9.1.RC3

[John Blum]

+1

Ran SDG build against Apache Geode 1.9.1 build snapshots (for RC3).

However, can we seriously reconsider logging the follow message at ERROR?
Ugh!

ERROR StatusLogger Log4j2 could not find a logging implementation. Please
add log4j-core to the classpath. Using SimpleLogger to log to the console...

WARN is more than sufficient.  If no logging provider is on the CLASSPATH,
it creates a lot of noise!

-John


On Fri, Aug 30, 2019 at 12:27 PM Dave Barnes  wrote:

> +1
> Checked the docs: Successfully built viewed the Geode User Guide and the
> Javadocs.
>
> On Fri, Aug 30, 2019 at 11:11 AM Owen Nichols  wrote:
>
> > Hello Geode dev community,
> >
> > This is a release candidate for Apache Geode, version 1.9.1.RC3.
> > Thanks to all the community members for their contributions to this
> > release!
> >
> > Please do a review and give your feedback. The deadline is 3PM PST Thu,
> > September 05 2019.
> > Release notes can be found at:
> >
> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.9.1
> >
> > Please note that we are voting upon the source tags: rel/v1.9.1.RC3
> >
> > Apache Geode:
> > https://github.com/apache/geode/tree/rel/v1.9.1.RC3
> > Apache Geode examples:
> > https://github.com/apache/geode-examples/tree/rel/v1.9.1.RC3
> > Apache Geode native:
> > https://github.com/apache/geode-native/tree/rel/v1.9.1.RC3
> >
> > Source and binary files:
> > https://dist.apache.org/repos/dist/dev/geode/1.9.1.RC3/
> >
> > Maven staging repo:
> > https://repository.apache.org/content/repositories/orgapachegeode-1057
> >
> > Geode's KEYS file containing PGP keys we use to sign the release:
> > https://github.com/apache/geode/blob/develop/KEYS
> >
> > PS: Command to run geode-examples: ./gradlew -PgeodeReleaseUrl=
> > https://dist.apache.org/repos/dist/dev/geode/1.9.1.RC3
> > -PgeodeRepositoryUrl=
> > https://repository.apache.org/content/repositories/orgapachegeode-1057
> > build runAll
> >
> > Regards
> > Owen & Kirk
> >
> >
>


-- 
-John
john.blum10101 (skype)

Re: [VOTE] Apache Geode 1.9.1.RC3

[John Blum]

1 more thing...

I would additionally advise rewording the sentence...

*> Please add log4j-core to the classpath.*

To read...

"*Please consider adding log4j-core, or another Logging provider (e.g.
Logback), to your classpath.  Apache Geode works best with Log4j.*"

Food for thought.

-John


On Tue, Sep 3, 2019 at 10:40 AM John Blum  wrote:

> +1
>
> Ran SDG build against Apache Geode 1.9.1 build snapshots (for RC3).
>
> However, can we seriously reconsider logging the follow message at ERROR?
> Ugh!
>
> ERROR StatusLogger Log4j2 could not find a logging implementation. Please
> add log4j-core to the classpath. Using SimpleLogger to log to the console...
>
> WARN is more than sufficient.  If no logging provider is on the CLASSPATH,
> it creates a lot of noise!
>
> -John
>
>
> On Fri, Aug 30, 2019 at 12:27 PM Dave Barnes  wrote:
>
>> +1
>> Checked the docs: Successfully built viewed the Geode User Guide and the
>> Javadocs.
>>
>> On Fri, Aug 30, 2019 at 11:11 AM Owen Nichols 
>> wrote:
>>
>> > Hello Geode dev community,
>> >
>> > This is a release candidate for Apache Geode, version 1.9.1.RC3.
>> > Thanks to all the community members for their contributions to this
>> > release!
>> >
>> > Please do a review and give your feedback. The deadline is 3PM PST Thu,
>> > September 05 2019.
>> > Release notes can be found at:
>> >
>> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.9.1
>> >
>> > Please note that we are voting upon the source tags: rel/v1.9.1.RC3
>> >
>> > Apache Geode:
>> > https://github.com/apache/geode/tree/rel/v1.9.1.RC3
>> > Apache Geode examples:
>> > https://github.com/apache/geode-examples/tree/rel/v1.9.1.RC3
>> > Apache Geode native:
>> > https://github.com/apache/geode-native/tree/rel/v1.9.1.RC3
>> >
>> > Source and binary files:
>> > https://dist.apache.org/repos/dist/dev/geode/1.9.1.RC3/
>> >
>> > Maven staging repo:
>> > https://repository.apache.org/content/repositories/orgapachegeode-1057
>> >
>> > Geode's KEYS file containing PGP keys we use to sign the release:
>> > https://github.com/apache/geode/blob/develop/KEYS
>> >
>> > PS: Command to run geode-examples: ./gradlew -PgeodeReleaseUrl=
>> > https://dist.apache.org/repos/dist/dev/geode/1.9.1.RC3
>> > -PgeodeRepositoryUrl=
>> > https://repository.apache.org/content/repositories/orgapachegeode-1057
>> > build runAll
>> >
>> > Regards
>> > Owen & Kirk
>> >
>> >
>>
>
>
> --
> -John
> john.blum10101 (skype)
>


-- 
-John
john.blum10101 (skype)

Re: [ANNOUNCE] Apache Geode 1.9.1

[John Blum]

Congrats Geode Community!

On Fri, Sep 6, 2019 at 11:04 AM Owen Nichols  wrote:

> The Apache Geode community is pleased to announce the availability of
> Apache Geode 1.9.1.
>
> Apache Geode is a data management platform that provides a database-like
> consistency model, reliable transaction processing and a shared-nothing
> architecture to maintain very low latency performance with high concurrency
> processing.
>
> Geode 1.9.1 improves compatibility with the Spring Data project and fixes a
> performance issue when SSL is enabled.  Users are encouraged to upgrade to
> the latest release.  For the full list of changes please review the release
> notes:
>
> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.9.1
>
> The release artifacts can be downloaded from the project website:
> http://geode.apache.org/releases/
>
> The release documentation is available at:
> http://geode.apache.org/docs/guide/19/about_geode.html
>
> We would like to thank all the contributors that made the release possible.
> Regards,
> Owen Nichols and Kirk Lund on behalf of the Apache Geode team
>


-- 
-John
john.blum10101 (skype)

Re: [Proposal] Make gfsh "stop server" command synchronous

[John Blum]

`stop server` is synchronous (with an option to break out of the wait using
CTRL^C) AFAIR.

Way deep down inside, it simply relies on GemFireCache.close() to return
(in-process).

As Darrel mentioned, there is not "true" signal the the server was
successfully stopped.

-j


On Tue, Sep 10, 2019 at 3:23 PM Darrel Schneider 
wrote:

> I think it would be good for stop server to confirm in some way that the
> server has stopped before returning.
>
> On Tue, Sep 10, 2019 at 3:08 PM Mark Hanson  wrote:
>
> > Hello All,
> >
> > I would like to propose that we make the gfsh “stop server” command
> > synchronous. It is causing some issues with some tests as the rest of the
> > calls are blocking. Stop on the other hand immediately returns by
> > comparison.
> > This causes issues as shown in GEODE-7017 specifically.
> >
> > GEODE:7017 CI failure:
> > org.apache.geode.launchers.ServerStartupValueRecoveryNotificationTest >
> > startupReportsOnlineOnlyAfterRedundancyRestored
> > https://issues.apache.org/jira/browse/GEODE-7017 <
> > https://issues.apache.org/jira/browse/GEODE-7017>
> >
> >
> > What do people think?
> >
> > Thanks,
> > Mark
>


-- 
-John
john.blum10101 (skype)

Re: [Proposal] Make gfsh "stop server" command synchronous

[John Blum]

@Anil-  I hear your argument when you are "scripting" with *Gfsh*, but
blocking absolutely maybe less desirable when using *Gfsh* interactively.
There are, after all, many non-cluster based commands.

@Mark - I see.  I have generally found in my own testing purposes,
especially automated, that a cache instance is not fully closed and has not
properly released all it's resource even after cache.close() returns.

-j

On Tue, Sep 10, 2019 at 5:02 PM Mark Hanson  wrote:

> Hi John,
>
> Kirk and I found that in our testing it was returning before it was fully
> stopped. I have a change that seems viable that waits for the pid file to
> disappear from the subdirectory of the server. I am not a fan. I would
> prefer to wait for the pid to disappear, but that doesn’t seem like it will
> be cross-platform friendly.
>
> Thanks,
> Mark
>
> > On Sep 10, 2019, at 3:31 PM, John Blum  wrote:
> >
> > `stop server` is synchronous (with an option to break out of the wait
> using
> > CTRL^C) AFAIR.
> >
> > Way deep down inside, it simply relies on GemFireCache.close() to return
> > (in-process).
> >
> > As Darrel mentioned, there is not "true" signal the the server was
> > successfully stopped.
> >
> > -j
> >
> >
> > On Tue, Sep 10, 2019 at 3:23 PM Darrel Schneider 
> > wrote:
> >
> >> I think it would be good for stop server to confirm in some way that the
> >> server has stopped before returning.
> >>
> >> On Tue, Sep 10, 2019 at 3:08 PM Mark Hanson  wrote:
> >>
> >>> Hello All,
> >>>
> >>> I would like to propose that we make the gfsh “stop server” command
> >>> synchronous. It is causing some issues with some tests as the rest of
> the
> >>> calls are blocking. Stop on the other hand immediately returns by
> >>> comparison.
> >>> This causes issues as shown in GEODE-7017 specifically.
> >>>
> >>> GEODE:7017 CI failure:
> >>> org.apache.geode.launchers.ServerStartupValueRecoveryNotificationTest >
> >>> startupReportsOnlineOnlyAfterRedundancyRestored
> >>> https://issues.apache.org/jira/browse/GEODE-7017 <
> >>> https://issues.apache.org/jira/browse/GEODE-7017>
> >>>
> >>>
> >>> What do people think?
> >>>
> >>> Thanks,
> >>> Mark
> >>
> >
> >
> > --
> > -John
> > john.blum10101 (skype)
>
>

-- 
-John
john.blum10101 (skype)

Re: [Proposal] Make gfsh "stop server" command synchronous

[John Blum]

@Mike - Who said anything about...

"*masking it in an early return from the shutdown command doesn't seem like
the appropriate action.*"

I think you missed the point.  You explicitly have to break out of the
wait, which is a conscious decision when *Gfsh* is run interactively.

The command as I previously stated, is "blocking", or "synchronous" with
respect to cache.close(), which is "ultimately" what gets called whether
the stop happens in-process or out-of-process (for that matter).  So, in a
non-interactive mode, the real issue is, why is the cache not completely
and properly closed/shutdown after a cache.close() call then?

Fix cache.close() then!  Don't simply bandaid this thing with yet another
unreliable means to ascertain whether the cache was completely and properly
shutdown.  And, don't put responsibility on the user to have register and
receive notification on complete shutdown, or some other ridiculous means,
either.


On Tue, Sep 10, 2019 at 6:15 PM Michael Stolz  wrote:

> I understand that issue John, but masking it in an early return from the
> shutdown command doesn't seem like the appropriate action.
> Maybe we should consider that nearly all gfsh commands are not blocking,
> and rather, have a way to determine which ones are still waiting for
> completion?
>
> --
> Mike Stolz
> Principal Engineer, Pivotal Cloud Cache
> Mobile: +1-631-835-4771
>
>
>
> On Tue, Sep 10, 2019 at 9:13 PM John Blum  wrote:
>
> > @Anil-  I hear your argument when you are "scripting" with *Gfsh*, but
> > blocking absolutely maybe less desirable when using *Gfsh* interactively.
> > There are, after all, many non-cluster based commands.
> >
> > @Mark - I see.  I have generally found in my own testing purposes,
> > especially automated, that a cache instance is not fully closed and has
> not
> > properly released all it's resource even after cache.close() returns.
> >
> > -j
> >
> > On Tue, Sep 10, 2019 at 5:02 PM Mark Hanson  wrote:
> >
> > > Hi John,
> > >
> > > Kirk and I found that in our testing it was returning before it was
> fully
> > > stopped. I have a change that seems viable that waits for the pid file
> to
> > > disappear from the subdirectory of the server. I am not a fan. I would
> > > prefer to wait for the pid to disappear, but that doesn’t seem like it
> > will
> > > be cross-platform friendly.
> > >
> > > Thanks,
> > > Mark
> > >
> > > > On Sep 10, 2019, at 3:31 PM, John Blum  wrote:
> > > >
> > > > `stop server` is synchronous (with an option to break out of the wait
> > > using
> > > > CTRL^C) AFAIR.
> > > >
> > > > Way deep down inside, it simply relies on GemFireCache.close() to
> > return
> > > > (in-process).
> > > >
> > > > As Darrel mentioned, there is not "true" signal the the server was
> > > > successfully stopped.
> > > >
> > > > -j
> > > >
> > > >
> > > > On Tue, Sep 10, 2019 at 3:23 PM Darrel Schneider <
> > dschnei...@pivotal.io>
> > > > wrote:
> > > >
> > > >> I think it would be good for stop server to confirm in some way that
> > the
> > > >> server has stopped before returning.
> > > >>
> > > >> On Tue, Sep 10, 2019 at 3:08 PM Mark Hanson 
> > wrote:
> > > >>
> > > >>> Hello All,
> > > >>>
> > > >>> I would like to propose that we make the gfsh “stop server” command
> > > >>> synchronous. It is causing some issues with some tests as the rest
> of
> > > the
> > > >>> calls are blocking. Stop on the other hand immediately returns by
> > > >>> comparison.
> > > >>> This causes issues as shown in GEODE-7017 specifically.
> > > >>>
> > > >>> GEODE:7017 CI failure:
> > > >>>
> > org.apache.geode.launchers.ServerStartupValueRecoveryNotificationTest >
> > > >>> startupReportsOnlineOnlyAfterRedundancyRestored
> > > >>> https://issues.apache.org/jira/browse/GEODE-7017 <
> > > >>> https://issues.apache.org/jira/browse/GEODE-7017>
> > > >>>
> > > >>>
> > > >>> What do people think?
> > > >>>
> > > >>> Thanks,
> > > >>> Mark
> > > >>
> > > >
> > > >
> > > > --
> > > > -John
> > > > john.blum10101 (skype)
> > >
> > >
> >
> > --
> > -John
> > john.blum10101 (skype)
> >
>


-- 
-John
john.blum10101 (skype)

Re: [Proposal] Make gfsh "stop server" command synchronous

[John Blum]

+1 to Bruce's comments as well.

This is exactly the kind of thing I needed to do (handle) inside of the *Spring
Test for Apache Geode* (STDG) project from a framework perspective, to
ensure that other projects relying on STDG (e.g. SBDG, SSDG) for their
integration testing purposes (e.g. client/server integration test cases)
with Apache Geode, were reliable, in an automated fashion.  This meant
ensuring things like the Apache Geode process is completely and properly
shutdown (using the appropriate checks) all all resource used by a cache
instance are released before another test class is allowed to continue and
do its work.  FWIW.

-j

On Wed, Sep 11, 2019 at 10:28 AM Mark Hanson  wrote:

> The idea I am working with at the moment that Kirk pointed me at was to
> use the pid file in the directory as indicator. Once that file disappears
> the server is stopped.
>
> That seems to work in my testing.
>
> Thoughts?
>
> Thanks,
> Mark
>
> > On Sep 11, 2019, at 10:23 AM, Dan Smith  wrote:
> >
> > It does seem like we should make stop synchronous, or at least make start
> > wait for the old process to die as Bruce suggested. Otherwise it is
> > difficult for someone to script the restart of a server.
> >
> > Looking at the code, it does look like gfsh stop is asynchronous. There
> are
> > multiple ways to stop a server:
> > * gfsh stop --dir - it looks like we write out some stop file and return
> > immediately. Or, if we can connect over JMX, we invoke the
> > MemberMBean.shutDownMember method, which launches a thread to close the
> > cache, which is also asynchronous.
> > * gfsh stop --pid - this seems to be similar to --dir
> > * With a member name - this appears to go to the
> MemberMBean.shutDownMember
> > method as well.
> >
> > I think one issue is that the JMX methods to stopping the server may be
> > hard to ensure the process is really gone, because they can be invoked
> > remotely. That may be why they are asynchronous - they need to return
> > something to the caller before shutting down. So maybe Bruce's suggestion
> > is better.
> >
> > As Jens pointed out - tests should generally just use port 0 for servers.
> >
> > -Dan
> >
> > On Wed, Sep 11, 2019 at 8:46 AM Jens Deppe  wrote:
> >
> >> To circle back to the original test failure that prompted this
> discussion -
> >> the failing test was getting intermittent bind exceptions on subsequent
> >> server restarts.
> >>
> >> I believe it's quite likely that a process' ports will remain
> unavailable
> >> even after it is gone (I'm not sure if we create listening sockets with
> >> SO_REUSEADDR). So, as to John's comment that gfsh is already
> synchronous, I
> >> don't think that adding extra functionality to gfsh, to ultimately just
> >> wait longer before exiting, is really solving the problem. I'd suggest
> you
> >> adjust the tests to always start servers with `--server-port=0` so that
> >> there are no port conflicts and let the OS handle it.
> >>
> >> --Jens
> >>
> >> On Wed, Sep 11, 2019 at 8:17 AM Bruce Schuchardt <
> bschucha...@pivotal.io>
> >> wrote:
> >>
> >>> Blocking or non-blocking, I don't have a strong opinion.  What I'd
> >>> really like to have gfsh ensure, though, is that no-one is able to
> start
> >>> a new instance of a server while the old process is still around.
> Maybe
> >>> the PID file is the way to do that.
> >>>
> >>> On 9/10/19 3:08 PM, Mark Hanson wrote:
>  Hello All,
> 
>  I would like to propose that we make the gfsh “stop server” command
> >>> synchronous. It is causing some issues with some tests as the rest of
> the
> >>> calls are blocking. Stop on the other hand immediately returns by
> >>> comparison.
>  This causes issues as shown in GEODE-7017 specifically.
> 
>  GEODE:7017 CI failure:
> >>> org.apache.geode.launchers.ServerStartupValueRecoveryNotificationTest >
> >>> startupReportsOnlineOnlyAfterRedundancyRestored
>  https://issues.apache.org/jira/browse/GEODE-7017 <
> >>> https://issues.apache.org/jira/browse/GEODE-7017>
> 
> 
>  What do people think?
> 
>  Thanks,
>  Mark
> >>>
> >>
>
>

-- 
-John
john.blum10101 (skype)

Re: [DISCUSS] - Cutting of release 1.9.2

[John Blum]

Hi Kirk - SDG 2.3/Neuman, which is only after SDG 2.2/Moore GAs, which is
tentatively scheduled for Monday, Sept. 30th.

On Fri, Sep 20, 2019 at 1:01 PM Kirk Lund  wrote:

> Hi Udo, SDG cannot upgrade to Geode 1.10.x until which version? SDG 2.2.0?
>
> On Fri, Sep 20, 2019 at 12:45 PM Udo Kohlmeyer  wrote:
>
> > Hi there Geode Dev's,
> >
> > I would like to propose a release for Geode 1.9.x that includes
> > https://issues.apache.org/jira/browse/GEODE-7121.
> >
> > This is an issue that is current in the 1.9.x branch, which is used by
> > Spring Data Geode 2.1.10 .
> >
> > This issue can cause an application using Spring Data Geode to bootstrap
> > GEODE to deadlock upon start up.
> >
> > This is critical system's issue and given that Spring Data Geode cannot
> > change its underlying dependency to 1.10+, would require this fix to be
> > back-ported to the 1.9 branch.
> >
> > --Udo
> >
> >
>


-- 
-John
john.blum10101 (skype)

Re: [DISCUSS] - Cutting of release 1.9.2

[John Blum]

Correction to *Udo's* comments!

SDG Moore/2.2 is based on Apache Geode 1.9, NOT SDG Lovelace/2.1 (which is
based on Apache Geode 1.6).

You can review the version compatibility matrix beginning with SBDG, here (
https://github.com/spring-projects/spring-boot-data-geode/wiki/Spring-Boot-for-Apache-Geode-and-Pivotal-GemFire-Version-Compatibility-Matrix
).

On Fri, Sep 20, 2019 at 1:09 PM John Blum  wrote:

> Hi Kirk - SDG 2.3/Neuman, which is only after SDG 2.2/Moore GAs, which is
> tentatively scheduled for Monday, Sept. 30th.
>
> On Fri, Sep 20, 2019 at 1:01 PM Kirk Lund  wrote:
>
>> Hi Udo, SDG cannot upgrade to Geode 1.10.x until which version? SDG 2.2.0?
>>
>> On Fri, Sep 20, 2019 at 12:45 PM Udo Kohlmeyer  wrote:
>>
>> > Hi there Geode Dev's,
>> >
>> > I would like to propose a release for Geode 1.9.x that includes
>> > https://issues.apache.org/jira/browse/GEODE-7121.
>> >
>> > This is an issue that is current in the 1.9.x branch, which is used by
>> > Spring Data Geode 2.1.10 <https://spring.io/projects/spring-data-geode
>> >.
>> >
>> > This issue can cause an application using Spring Data Geode to bootstrap
>> > GEODE to deadlock upon start up.
>> >
>> > This is critical system's issue and given that Spring Data Geode cannot
>> > change its underlying dependency to 1.10+, would require this fix to be
>> > back-ported to the 1.9 branch.
>> >
>> > --Udo
>> >
>> >
>>
>
>
> --
> -John
> john.blum10101 (skype)
>


-- 
-John
john.blum10101 (skype)

Re: [DISCUSS] - Cutting of release 1.9.2

[John Blum]

+1 for releasing Apache Geode 1.9.2 and including the fix for GEDOE-7121.

On Fri, Sep 20, 2019 at 1:11 PM Kirk Lund  wrote:

> +1 for creating 1.9.x with the fix for GEODE-7121
>
>
> On Fri, Sep 20, 2019 at 1:09 PM John Blum  wrote:
>
> > Hi Kirk - SDG 2.3/Neuman, which is only after SDG 2.2/Moore GAs, which is
> > tentatively scheduled for Monday, Sept. 30th.
> >
> > On Fri, Sep 20, 2019 at 1:01 PM Kirk Lund  wrote:
> >
> > > Hi Udo, SDG cannot upgrade to Geode 1.10.x until which version? SDG
> > 2.2.0?
> > >
> > > On Fri, Sep 20, 2019 at 12:45 PM Udo Kohlmeyer  wrote:
> > >
> > > > Hi there Geode Dev's,
> > > >
> > > > I would like to propose a release for Geode 1.9.x that includes
> > > > https://issues.apache.org/jira/browse/GEODE-7121.
> > > >
> > > > This is an issue that is current in the 1.9.x branch, which is used
> by
> > > > Spring Data Geode 2.1.10 <
> https://spring.io/projects/spring-data-geode
> > >.
> > > >
> > > > This issue can cause an application using Spring Data Geode to
> > bootstrap
> > > > GEODE to deadlock upon start up.
> > > >
> > > > This is critical system's issue and given that Spring Data Geode
> cannot
> > > > change its underlying dependency to 1.10+, would require this fix to
> be
> > > > back-ported to the 1.9 branch.
> > > >
> > > > --Udo
> > > >
> > > >
> > >
> >
> >
> > --
> > -John
> > john.blum10101 (skype)
> >
>


-- 
-John
john.blum10101 (skype)

Re: [DISCUSS] GEODE-7241 - make Jar not War?

[John Blum]

Bundling "all" dependencies in a WAR file is a rather subjective topic
since, typically, in practice developers did not bundle things like JDBC
drivers in a WAR file for their Web app.  Common practice was to put
"shared" libs in the Servlet Containers global libs directory (using the
Common ClassLoader) for shared consumption by all Web apps, for better or
worse.

WAR files (like JAR and EAR) are based on "format" (e.g. containing a
WEB-INF/web.xml file, with WEB-INF/classes of the app and possibly libs in
WEB-INF/lib), not simply just deps. As such, by following this format, the
container will consider this a "valid" WAR file.

However, if we are just basing it on libs, then none of the WAR files are
valid by that definition (not even Pulse) because none contain the
necessary Apache Geode libs (e.g. geode-core).  Therefore, none of the WAR
files could stand on their own, not even Pulse.


On Wed, Sep 25, 2019 at 8:17 AM Udo Kohlmeyer  wrote:

> Seems these should have been Jars all along...
>
> On 9/24/19 8:09 PM, Jacob Barrett wrote:
> > Why publish them as WAR files at all? As they are currently packaged
> they can't be deployed in just any J2EE web container because they lack all
> the dependencies. Sure they look like WAR files internally but they are
> really modules that expect to run in and only in the Geode server.
> Publishing them as a WAR file gives the false impression that they can be
> consumed by any project as a full fledged WAR.
> >
> > We should make up our own JAR spec based on WAR, perhaps calling it
> Geode Web ARchive or GWAR for short. Yes, I just went there… GWAR!!!
> 🤘🎸🤘🎸🤘🎸🤘🎸
> >
> > But seriously, unless it can be deployed in any J2EE web container it
> shouldn’t be considered a WAR.
> >
> > -Jake
> >
> >> On Sep 24, 2019, at 3:34 PM, Robert Houghton 
> wrote:
> >>
> >> I am working on the change to get the geode-web and geode-web-api war
> >> artifacts published instead of the jars. I have found the
> >> geode-web-management project is also producing a war artifact, in
> addition
> >> to a jar. Do we want it to be published as well? What is the criterion
> we
> >> use to decide?
> >>
> >> I think this problem was an oversight from the changes PurelyApplied
> and I
> >> made to the build when we made the publish plugin 'opt-in' instead of
> >> forced by the root project. Easy to publish one or the other, but I am
> not
> >> qualified to decide whether a war or jar is more appropriate for these
> >> modules.
> >>
> >> Thank you,
> >> -Robert
>


-- 
-John
john.blum10101 (skype)

Re: [DISCUSS] GEODE-7241 - make Jar not War?

[John Blum]

Actually, to clarify 2 points.

1. Technically, it is a bit more involved than simply just validating the
"format".  For instance, the web.xml file must be valid and well-formed.
2. There was a reason why the geode-core and other Apache Geode libs were
not bundled in WEB-INF/lib of the WAR files, since then it would create
duplication on the global as well as the WAR file's (isolated) ClassLoader
classpath, particularly for the "embedded" Geode Servlet Container case,
and as such, ClassLoader problems would occur.



On Wed, Sep 25, 2019 at 8:33 AM Anthony Baker  wrote:

> Udo,
>
> Can you update GEODE-7241 to help us understand the reason why we need to
> publish geode-web* WARs to maven?  I get that we used to do this but I
> can’t recall why we choose that approach.
>
> There is one request for Pulse on maven (GEODE-6208).
>
> Anthony
>
>
> > On Sep 24, 2019, at 3:44 PM, Udo Kohlmeyer  wrote:
> >
> > Maybe the better question is, WHY are we publishing geode-web and
> geode-web-api.
> >
> > Pulse, from what I remember, could be a standalone deployment. At least
> that is what I remember.
> >
> > Most likely an oversight...
> >
> > --Udo
> >
> > On 9/24/19 3:38 PM, Robert Houghton wrote:
> >> The geode-pulse module also builds a war, but does not publish it. Is
> this
> >> an oversight, or by design?
> >>
> >> On Tue, Sep 24, 2019 at 3:34 PM Robert Houghton 
> >> wrote:
> >>
> >>> I am working on the change to get the geode-web and geode-web-api war
> >>> artifacts published instead of the jars. I have found the
> >>> geode-web-management project is also producing a war artifact, in
> addition
> >>> to a jar. Do we want it to be published as well? What is the criterion
> we
> >>> use to decide?
> >>>
> >>> I think this problem was an oversight from the changes PurelyApplied
> and I
> >>> made to the build when we made the publish plugin 'opt-in' instead of
> >>> forced by the root project. Easy to publish one or the other, but I am
> not
> >>> qualified to decide whether a war or jar is more appropriate for these
> >>> modules.
> >>>
> >>> Thank you,
> >>> -Robert
> >>>
>
>

-- 
-John
john.blum10101 (skype)

Re: [DISCUSS] GEODE-7241 - make Jar not War?

[John Blum]

It occurred to me after *Charlie* shared the link to installing *Pulse* in
a standalone Servlet Container (e.g. Apache Tomcat) that we don't properly
describe how to handle the Geode dependencies (e.g. geode-core).  Again,
this is not bundled as part of the Geode WAR files.

-1 to publishing a GWAR file.  These are still valid WAR files regardless
of the dependencies they provide or don't provide (which is a documentation
concern in my mind).


On Wed, Sep 25, 2019 at 10:53 AM Anthony Baker  wrote:

> Thanks for the reminder.  If these files are required to start a geode
> member, I agree they should be published artifacts.  Perhaps there’s a
> better way to pull them in…but this seems like the best option for now.
>
> Anthony
>
>
> > On Sep 25, 2019, at 10:22 AM, Udo Kohlmeyer 
> wrote:
> >
> > @Anthony. Ticket was updated.. In a nutshell, to run integration tests,
> using the REST endpoints, requires the starting of the server with and
> embedded web-server.
> >
> > As all tests run on dependency management only and don't have access to
> a downloaded product, the HTTP endpoints are not part of the dependency.
> These are added in by including the WAR files from mavenCentral.
> >
> > As @Dan pointed out, GEODE-5660 enabled this behavior.
> >
> > I think this approach might actually even help with the testing of the
> REST Controller in the Geode codebase itself.
> >
> > --Udo
>
>

-- 
-John
john.blum10101 (skype)

Re: [DISCUSS] GEODE-7241 - make Jar not War?

[John Blum]

@Jake - Ah, indeed it was https://en.wikipedia.org/wiki/Gwar.  I never
heard of them until now. Gotta love the 80s Rock/Heavy Metal Era.

On Wed, Sep 25, 2019 at 12:22 PM Jacob Barrett  wrote:

> Udo,
>
> I didn’t say we shouldn’t fix it for the future. I said I don’t believe it
> warrants a backport and a patch release.
>
> -Jake
>
>

-- 
-John
john.blum10101 (skype)

Re: Spring Boot with Geode 1.10

[John Blum]

There is no version of Spring Boot (SBDG) currently built on Apache Geode
1.10 at the moment.

In general, you should understand 2 things.


1. First, the Apache Geode version that Spring Boot, or SBDG, is dependent
on is indirectly (transitively) determined by upstream dependencies.

SBDG -> Spring Boot -> SDG -> Apache Geode.

E.g. SDG Moore/2.2 pulls in Apache Geode 1.9.x.  SBDG 1.2 pulls in SDG
Moore/2.2.  Spring Boot 2.2 also pulls in SD[G] Moore/2.2. Both SBDG and
Spring Boot must agree on the version of SD[G] that they use.  So, it is
not a coincidence that both SBDG (1.2) and Spring Boot (2.2) pull in SD
Moore/2.2 and are therefore both (indirectly) dependent on Apache Geode 1.9.

E.g. SDG Lovelace/2.1 pulls in Apache Geode 1.6.  SBDG 1.1 pulls in SDG
Lovelace/2.1.  Spring Boot 2.1 also pulls in SD[G] Lovelace/2.2.  Both SBDG
and Spring Boot must agree on the version of SD[G] that they use in 1.1/2.1
respectively.


2. Next, Spring Boot's dependency management extends beyond simply Spring
Data, to other (upstream, from Boot) Spring projects/dependencies (e.g.
Spring Framework, Spring Batch, Spring Integration, Spring Security, etc)
as well as 3rd party libraries.


Any, and I mean ANY (!) properly managed Java project, not just Spring,
must manage dependencies in a consistent and responsible way to avoid
conflicts that would cause end users issues (especially with their
applications that consume our dependencies) given multiple transitive
dependencies are likely to share the same dependencies (e.g. logging is
always usually the most common example).

You should not assume you can just simply change dependencies at random
(e.g. I will use Spring Boot 2.2 with SBDG 1.1, or change the Micrometer
versions, or whatever).  The stars must align so to speak, and for good
reason.  Again, this is why tools like Apache Maven exists in the first
place.

In some cases, this might work, but it is not normal to think you can do
this in general, and most of the Java community understands this.  It must
be a conscious choice and users are aware that they must manually
exclude/override a dependency and/or declare their own dependencyManagement
section in their application POM to declare their choices.

Anyway, this 1 of the many reasons why Spring Boot so eloquently handles
this concern for you.

SDG Neuman/2.3 will be based on Apache Geode 1.10 after SD Moore reaches
GA.  Most likely, Spring Boot 2.3 will pull in SD Moore/2.3 and Spring Boot
2.3 will review all of it's "managed" [1] (fro instance [2]) dependencies
at that time.

The fact that Micrometer 1.0.3 was mention would mean that you are using
`spring-geode-starter` 1.0.x since Spring Boot has not be based on
Micrometer 1.0.x since 2.0 [3], which is now EOL.

-j

[1]
https://github.com/spring-projects/spring-boot/blob/v2.2.0.M6/spring-boot-project/spring-boot-dependencies/pom.xml#L34-L243
[2]
https://github.com/spring-projects/spring-boot/blob/v2.2.0.M6/spring-boot-project/spring-boot-dependencies/pom.xml#L153
[3]
https://github.com/spring-projects/spring-boot/blob/v2.0.9.RELEASE/spring-boot-project/spring-boot-dependencies/pom.xml#L127


On Wed, Sep 25, 2019 at 1:14 PM Jacob Barrett  wrote:

> Offline discovery…
>
> Looking at ./gradlew dependencies shows that micrometer is being
> downgraded by spring dependency plugin to 1.0.3. Attempting different
> versions of spring boot.
>
> -Jake
>
>
> > On Sep 25, 2019, at 1:04 PM, Owen Nichols  wrote:
> >
> > This still pulls in micrometer 1.0.3
> >
> > dependencies {
> >  compile('org.springframework.boot:spring-boot-starter')
> >
> >  implementation(platform('org.apache.geode:geode-client-bom:1.10.0'))
> >  implementation('org.apache.geode:geode-core')
> >  implementation('org.apache.geode:geode-cq')
> >
> >  testCompile('org.springframework.boot:spring-boot-starter-test')
> >  testCompile 'junit:junit:4.+'
> > }
> >
> >
> >> On Sep 25, 2019, at 12:43 PM, Jacob Barrett 
> wrote:
> >>
> >> Changing subject…
> >>
> >>
> >> Try
> >> dependencies {
> >>
> implementation(platform(‘org.apache.geode:geode-client-bom:1.10.0’))
> >>  implementation(‘org.apache.geode:geode-core’)
> >>  implementation('org.apache.geode:geode-cq’)
> >> }
> >>
> >> Does that make a difference?
> >>
> >>
> >>> On Sep 25, 2019, at 12:35 PM, Owen Nichols 
> wrote:
> >>>
> >>> My build.gradle is pretty simple:
> >>>
> >>> repositories {
> >>> mavenCentral()
> >>> maven {
> >>>  url '
> https://repository.apache.org/content/repositories/orgapachegeode-1059'
> >>> }
> >>> }
> >>>
> >>> dependencies {
> >>> compile('org.springframework.boot:spring-boot-starter')
> >>> compile 'org.apache.geode:geode-core:1.10.0'
> >>> compile 'org.apache.geode:geode-cq:1.10.0'
> >>> }
> >>>
> >>>
>  On Sep 25, 2019, at 12:29 PM, Jacob Barrett 
> wrote:
> 
> 
> 
> > On Sep 25, 2019, at 12:26 PM, Owen Nichols 
> wrote:
> >
> > ⚠️ to run my spring boot client for above test, I had to manually
> add compile 'io.micrometer:micrometer-c

Re: Spring Boot with Geode 1.10

[John Blum]

Additionally, I would encourage others to read...

https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#build-tool-plugins-maven-plugin

And, when using Gradle (instead)...

https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#build-tool-plugins-gradle-plugin

This section of Spring Boot's Maven/Gradle Plugin explains it best...

https://docs.spring.io/spring-boot/docs/2.1.7.RELEASE/gradle-plugin/reference/html/#managing-dependencies

-j


On Wed, Sep 25, 2019 at 1:24 PM John Blum  wrote:

> There is no version of Spring Boot (SBDG) currently built on Apache Geode
> 1.10 at the moment.
>
> In general, you should understand 2 things.
>
>
> 1. First, the Apache Geode version that Spring Boot, or SBDG, is dependent
> on is indirectly (transitively) determined by upstream dependencies.
>
> SBDG -> Spring Boot -> SDG -> Apache Geode.
>
> E.g. SDG Moore/2.2 pulls in Apache Geode 1.9.x.  SBDG 1.2 pulls in SDG
> Moore/2.2.  Spring Boot 2.2 also pulls in SD[G] Moore/2.2. Both SBDG and
> Spring Boot must agree on the version of SD[G] that they use.  So, it is
> not a coincidence that both SBDG (1.2) and Spring Boot (2.2) pull in SD
> Moore/2.2 and are therefore both (indirectly) dependent on Apache Geode 1.9.
>
> E.g. SDG Lovelace/2.1 pulls in Apache Geode 1.6.  SBDG 1.1 pulls in SDG
> Lovelace/2.1.  Spring Boot 2.1 also pulls in SD[G] Lovelace/2.2.  Both SBDG
> and Spring Boot must agree on the version of SD[G] that they use in 1.1/2.1
> respectively.
>
>
> 2. Next, Spring Boot's dependency management extends beyond simply Spring
> Data, to other (upstream, from Boot) Spring projects/dependencies (e.g.
> Spring Framework, Spring Batch, Spring Integration, Spring Security, etc)
> as well as 3rd party libraries.
>
>
> Any, and I mean ANY (!) properly managed Java project, not just Spring,
> must manage dependencies in a consistent and responsible way to avoid
> conflicts that would cause end users issues (especially with their
> applications that consume our dependencies) given multiple transitive
> dependencies are likely to share the same dependencies (e.g. logging is
> always usually the most common example).
>
> You should not assume you can just simply change dependencies at random
> (e.g. I will use Spring Boot 2.2 with SBDG 1.1, or change the Micrometer
> versions, or whatever).  The stars must align so to speak, and for good
> reason.  Again, this is why tools like Apache Maven exists in the first
> place.
>
> In some cases, this might work, but it is not normal to think you can do
> this in general, and most of the Java community understands this.  It must
> be a conscious choice and users are aware that they must manually
> exclude/override a dependency and/or declare their own dependencyManagement
> section in their application POM to declare their choices.
>
> Anyway, this 1 of the many reasons why Spring Boot so eloquently handles
> this concern for you.
>
> SDG Neuman/2.3 will be based on Apache Geode 1.10 after SD Moore reaches
> GA.  Most likely, Spring Boot 2.3 will pull in SD Moore/2.3 and Spring Boot
> 2.3 will review all of it's "managed" [1] (fro instance [2]) dependencies
> at that time.
>
> The fact that Micrometer 1.0.3 was mention would mean that you are using
> `spring-geode-starter` 1.0.x since Spring Boot has not be based on
> Micrometer 1.0.x since 2.0 [3], which is now EOL.
>
> -j
>
> [1]
> https://github.com/spring-projects/spring-boot/blob/v2.2.0.M6/spring-boot-project/spring-boot-dependencies/pom.xml#L34-L243
> [2]
> https://github.com/spring-projects/spring-boot/blob/v2.2.0.M6/spring-boot-project/spring-boot-dependencies/pom.xml#L153
> [3]
> https://github.com/spring-projects/spring-boot/blob/v2.0.9.RELEASE/spring-boot-project/spring-boot-dependencies/pom.xml#L127
>
>
> On Wed, Sep 25, 2019 at 1:14 PM Jacob Barrett  wrote:
>
>> Offline discovery…
>>
>> Looking at ./gradlew dependencies shows that micrometer is being
>> downgraded by spring dependency plugin to 1.0.3. Attempting different
>> versions of spring boot.
>>
>> -Jake
>>
>>
>> > On Sep 25, 2019, at 1:04 PM, Owen Nichols  wrote:
>> >
>> > This still pulls in micrometer 1.0.3
>> >
>> > dependencies {
>> >  compile('org.springframework.boot:spring-boot-starter')
>> >
>> >  implementation(platform('org.apache.geode:geode-client-bom:1.10.0'))
>> >  implementation('org.apache.geode:geode-core')
>> >  implementation('org.apache.geode:geode-cq')
>> >
>> >  testCompile('org.springframework.boot:spring-boot-starter-test')
>> >  testCompil

Re: [DISCUSS] Geode 1.11.0 dependency update

[John Blum]

Hi Dick-

Thanks for the reminder on an important topic.

On quick review of *Nick's* proposal, which I like (well done), I would
only add that if a patch release is cut (e.g. 1.9.1, 1.9.2) that
dependencies be reviewed for updated patch releases as well.

While different patch versions of dependency major.minor version SHOULD NOT
cause issues, it is also a nice thing to do since critical bugs, or CVEs,
may be resolved in a patch release of a dependency.

Cheers,
John


On Thu, Sep 26, 2019 at 2:59 PM Jacob Barrett  wrote:

> Yes please!
>
> > On Sep 26, 2019, at 2:46 PM, Dick Cavender  wrote:
> >
> > With the release of Geode 1.10.0 the window opens to apply Nick's Geode
> > dependency update process with time to shake it out before the 1.11.0
> > release.
> >
> > His proposal can be found here:
> >
> https://cwiki.apache.org/confluence/display/GEODE/%5BDiscussion%5D+Geode+dependency+update+process
> >
> >
> > Additionally the original email discuss thread can be found searching for
> > subject: "[DISCUSS] Geode dependency update process (review by
> 8/28/2019)"
> >
> > His proposal suggests that the dependency update task be something that
> the
> > Geode Release Manager would do post release. While it may be that a RM
> can
> > eventually do this until the actual update process, verification and
> > documenting is defined it seems like this should be a geode community
> > effort the first time around.
> >
> > Nick has generously offered to head up the initial process and to use the
> > Geode 1.10.0 release as an opportunity to kickoff his proposal. Thanks
> Nick!
>
>

-- 
-John
john.blum10101 (skype)

Re: [ANNOUNCE] Apache Geode 1.10.0

[John Blum]

Congrats!!!  Nice work!

On Thu, Sep 26, 2019 at 2:08 PM Dick Cavender  wrote:

> The Apache Geode community is pleased to announce the availability of
> Apache Geode 1.10.0.
>
> Apache Geode is a data management platform that provides a database-like
> consistency model, reliable transaction processing and a shared-nothing
> architecture to maintain very low latency performance with high concurrency
> processing.
>
> This Geode 1.10.0 quarterly release contains a number of improvements and bug 
> fixes.
>
> Users are encouraged to upgrade to the latest release.
>
> For the full list of changes please review the release notes:
>
> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.10.0
>
>
> The release artifacts can be downloaded from the project 
> website:http://geode.apache.org/releases/
>
> The release documentation is available at:
>
> https://geode.apache.org/docs/guide/110/about_geode.html
>
>
> We would like to thank all the contributors that made the release possible.
>
> Regards,
>
> Dick Cavender on behalf of the Apache Geode team
>
>
>

-- 
-John
john.blum10101 (skype)

Re: [DISCUSS] Support For LTS Version Of Geode

[John Blum]

Put simply, from my perspective, I would like to see LTS versions of Apache
Geode align with the *Spring Data* (*Release Trains*) support for Apache
Geode.

For example:

SDG Lovelace/2.1 is based on Apache Geode 1.6.x.
SDG Moore/2.2 is based on Apache Geode 1.9.x.

Therefore, both Apache Geode 1.6 and 1.9 would be LTS versions, with patch
releases.

The upcoming SD Neuman/2.3 (now in development given Moore has just went GA
(i.e. 2.2.0.RELEASE) as of today), is currently based on 1.10, but is
likely to move Apache Geode versions (e.g. 1.11, 1.12, or even 1.13) before
SD Neuman reaches RC1.

SD has longer lifecycles between release trains (1 to 1.5 years per SD
Release Train) than Apache Geode's support cycle, on a particular
major.minor version (e.g. 1.9), which always puts us in a
precarious position.

$0.02
-John



On Mon, Sep 30, 2019 at 3:55 PM Mark Bretl  wrote:

> Hi All,
>
> It has come up a few times in recent weeks about the possibility of an LTS
> version of Geode. Is this something the community would be interested in?
>
> There are advantages and disadvantages to supporting an LTS. Some
> advantages may include:
> - Stable release for downstream projects
> - Include security and other maintenance related patches
>
> Disadvantages:
> - Additional support for multiple distributions/versions
> - Release management overhead
>
> Thoughts/Comments/Concerns?
>
> --Mark
>


-- 
-John
john.blum10101 (skype)

Re: [DISCUSS] Support For LTS Version Of Geode

[John Blum]

Well, release durations are subjective to begin with.  What makes a 3 month
cycle any better than a 6 month cycle or vice versa?

For one, I think it is very project dependent.  Rather, SD strives to
achieve a predictable release cycle (i.e. fixed duration over X amount of
scope, e.g. every 6 months, from M1 to final GA where we might have any
number of Milestones and Release Candidates between M1 and final GA).
Also, there is a commitment to our customers, so the 1 year cycle is not
arbitrary.

The entire SD Release Train also encompass 14 different modules
(GemFire/Geode, JPA, MongoDB, Redis, Cassandra, etc) so there are a lot
more moving parts to coordinate with different intended feature sets per
module (some of it aligning with SD Commons while other bits are very store
specific) over the course of arriving at the final GA.

Finally, I'd say that what is the point of having a patch version (i.e. in
major.minor.patch) if the only intent to use is to fix CVEs.  You could
simply force users to the new minor version containing the fixes.

However, I am very much in favor having patch releases, particularly for
data products where upgrading is not a trivial task, and not simply a
technical one, either.

Again, $0.02,

-John


On Mon, Sep 30, 2019 at 5:48 PM Michael Stolz  wrote:

> I agree.
>
> This is the most sensible way to achieve release alignment.
>
>
> --
> Mike Stolz
> Principal Engineer, Pivotal Cloud Cache
> Mobile: +1-631-835-4771
>
> On Mon, Sep 30, 2019, 8:09 PM John Blum  wrote:
>
> > Put simply, from my perspective, I would like to see LTS versions of
> Apache
> > Geode align with the *Spring Data* (*Release Trains*) support for Apache
> > Geode.
> >
> > For example:
> >
> > SDG Lovelace/2.1 is based on Apache Geode 1.6.x.
> > SDG Moore/2.2 is based on Apache Geode 1.9.x.
> >
> > Therefore, both Apache Geode 1.6 and 1.9 would be LTS versions, with
> patch
> > releases.
> >
> > The upcoming SD Neuman/2.3 (now in development given Moore has just went
> GA
> > (i.e. 2.2.0.RELEASE) as of today), is currently based on 1.10, but is
> > likely to move Apache Geode versions (e.g. 1.11, 1.12, or even 1.13)
> before
> > SD Neuman reaches RC1.
> >
> > SD has longer lifecycles between release trains (1 to 1.5 years per SD
> > Release Train) than Apache Geode's support cycle, on a particular
> > major.minor version (e.g. 1.9), which always puts us in a
> > precarious position.
> >
> > $0.02
> > -John
> >
> >
> >
> > On Mon, Sep 30, 2019 at 3:55 PM Mark Bretl  wrote:
> >
> > > Hi All,
> > >
> > > It has come up a few times in recent weeks about the possibility of an
> > LTS
> > > version of Geode. Is this something the community would be interested
> in?
> > >
> > > There are advantages and disadvantages to supporting an LTS. Some
> > > advantages may include:
> > > - Stable release for downstream projects
> > > - Include security and other maintenance related patches
> > >
> > > Disadvantages:
> > > - Additional support for multiple distributions/versions
> > > - Release management overhead
> > >
> > > Thoughts/Comments/Concerns?
> > >
> > > --Mark
> > >
> >
> >
> > --
> > -John
> > john.blum10101 (skype)
> >
>


-- 
-John
john.blum10101 (skype)

Re: [DISCUSS] Support For LTS Version Of Geode

[John Blum]

1 more thing...

I am also not saying all Apache Geode LTS versions (e.g. 1.9) need to
perfectly align with the SD Release Train for which the SD Release Train is
based (e.g. SD Moore/2.2 <-> 1.9), release by release, especially given we
have quite a few service/patch releases per SD Release Train (e.g. SD
Lovelace is already at SR10/2.1.10.RELEASE or 10 service/patch releases
beyond the 2.1 GA version, i.e. 2.1.0.RELEASE).  Just that, enhancements,
important bug fixes, and CVEs (patches) are back ported to an LTS version
of Apache Geode from time to time up to, say, 1 year (or 3 or 4 patches).

This may have the effect that Apache Geode users might not upgrade until a
new LTS version becomes available.  However, for those that want to stay
ion the cutting edge, they are free to do so.  It also allows the Apache
Geode product to take more risk between LTS versions and really stabilize
for an LTS version.

To Owen's point, I am also wondering why it is so important that users
always pick up the latest bits?  I think this is much more problematic to
do on the server-side, plus newer clients cannot talk to older servers,
so...

And, of course, there is no reason why Apache Geode needs to do any of what
I am suggesting just for the Spring Data bits.  But, it would make our
lives simpler overall, which is why I am advocating for it.

Final $0.02,

-j



On Mon, Sep 30, 2019 at 6:13 PM John Blum  wrote:

> Well, release durations are subjective to begin with.  What makes a 3
> month cycle any better than a 6 month cycle or vice versa?
>
> For one, I think it is very project dependent.  Rather, SD strives to
> achieve a predictable release cycle (i.e. fixed duration over X amount of
> scope, e.g. every 6 months, from M1 to final GA where we might have any
> number of Milestones and Release Candidates between M1 and final GA).
> Also, there is a commitment to our customers, so the 1 year cycle is not
> arbitrary.
>
> The entire SD Release Train also encompass 14 different modules
> (GemFire/Geode, JPA, MongoDB, Redis, Cassandra, etc) so there are a lot
> more moving parts to coordinate with different intended feature sets per
> module (some of it aligning with SD Commons while other bits are very store
> specific) over the course of arriving at the final GA.
>
> Finally, I'd say that what is the point of having a patch version (i.e. in
> major.minor.patch) if the only intent to use is to fix CVEs.  You could
> simply force users to the new minor version containing the fixes.
>
> However, I am very much in favor having patch releases, particularly for
> data products where upgrading is not a trivial task, and not simply a
> technical one, either.
>
> Again, $0.02,
>
> -John
>
>
> On Mon, Sep 30, 2019 at 5:48 PM Michael Stolz  wrote:
>
>> I agree.
>>
>> This is the most sensible way to achieve release alignment.
>>
>>
>> --
>> Mike Stolz
>> Principal Engineer, Pivotal Cloud Cache
>> Mobile: +1-631-835-4771
>>
>> On Mon, Sep 30, 2019, 8:09 PM John Blum  wrote:
>>
>> > Put simply, from my perspective, I would like to see LTS versions of
>> Apache
>> > Geode align with the *Spring Data* (*Release Trains*) support for Apache
>> > Geode.
>> >
>> > For example:
>> >
>> > SDG Lovelace/2.1 is based on Apache Geode 1.6.x.
>> > SDG Moore/2.2 is based on Apache Geode 1.9.x.
>> >
>> > Therefore, both Apache Geode 1.6 and 1.9 would be LTS versions, with
>> patch
>> > releases.
>> >
>> > The upcoming SD Neuman/2.3 (now in development given Moore has just
>> went GA
>> > (i.e. 2.2.0.RELEASE) as of today), is currently based on 1.10, but is
>> > likely to move Apache Geode versions (e.g. 1.11, 1.12, or even 1.13)
>> before
>> > SD Neuman reaches RC1.
>> >
>> > SD has longer lifecycles between release trains (1 to 1.5 years per SD
>> > Release Train) than Apache Geode's support cycle, on a particular
>> > major.minor version (e.g. 1.9), which always puts us in a
>> > precarious position.
>> >
>> > $0.02
>> > -John
>> >
>> >
>> >
>> > On Mon, Sep 30, 2019 at 3:55 PM Mark Bretl  wrote:
>> >
>> > > Hi All,
>> > >
>> > > It has come up a few times in recent weeks about the possibility of an
>> > LTS
>> > > version of Geode. Is this something the community would be interested
>> in?
>> > >
>> > > There are advantages and disadvantages to supporting an LTS. Some
>> > > advantages may include:
>> > > - Stable release for downstream projects
>> > > - Include security and other maintenance related patches
>> > >
>> > > Disadvantages:
>> > > - Additional support for multiple distributions/versions
>> > > - Release management overhead
>> > >
>> > > Thoughts/Comments/Concerns?
>> > >
>> > > --Mark
>> > >
>> >
>> >
>> > --
>> > -John
>> > john.blum10101 (skype)
>> >
>>
>
>
> --
> -John
> john.blum10101 (skype)
>


-- 
-John
john.blum10101 (skype)

Re: Token based authentication support added in Geode Develop

[John Blum]

So application developer's will need to know to code their application
client's to lookup the JWT token (from some store) and set HTTP request
headers to send the token, or will this be handled automatically by a geode
client?

On Fri, Oct 4, 2019 at 11:37 AM Jinmei Liao  wrote:

> yes, correct,  we are assuming the client will have the token available
> somehow and send in the token in the authentication header. We are not
> doing anything with actual token management.
>
> On Fri, Oct 4, 2019 at 11:34 AM Jens Deppe  wrote:
>
> > So, to be clear, we're providing the ability to recognize a HTTP
> > authentication header containing 'Bearer ' and
> > then handing that to the Security Manager to do with as it pleases?
> >
> > We're not doing anything with actual token management? (i.e. generating,
> > revoking, etc.).
> >
> > --Jens
> >
> > On Fri, Oct 4, 2019 at 10:59 AM Jinmei Liao  wrote:
> >
> > > Hi, all
> > >
> > > JWT token based authentication support is added to Geode develop
> branch.
> > > Currently only management v2 rest api can use this (we can add dev rest
> > > there too if requested). In order to turn on token based auth for
> > > management rest api, you will need to do these two things:
> > > 1. start your locator with this property:
> > >  *security-auth-token-enabled-components = all (or management)*
> > > 2. implement your SecurityManager to authenticate the jwt token passed
> > in.
> > > The jwt token will be available in the properties using the key
> > > "security-token".
> > >
> > > Let me know if you have any questions.
> > >
> > > --
> > > Cheers
> > >
> > > Jinmei
> > >
> >
>
>
> --
> Cheers
>
> Jinmei
>


-- 
-John
john.blum10101 (skype)

Re: Token based authentication support added in Geode Develop

[John Blum]

got it

On Mon, Oct 7, 2019 at 10:33 AM Joris Melchior  wrote:

> Yes, at the moment the we only support receiving a token provided in the
> Authentication header field. We don't provide the standard endpoints for
> token acquisition and refresh.
>
> On Fri, Oct 4, 2019 at 4:14 PM John Blum  wrote:
>
> > So application developer's will need to know to code their application
> > client's to lookup the JWT token (from some store) and set HTTP request
> > headers to send the token, or will this be handled automatically by a
> geode
> > client?
> >
> > On Fri, Oct 4, 2019 at 11:37 AM Jinmei Liao  wrote:
> >
> > > yes, correct,  we are assuming the client will have the token available
> > > somehow and send in the token in the authentication header. We are not
> > > doing anything with actual token management.
> > >
> > > On Fri, Oct 4, 2019 at 11:34 AM Jens Deppe  wrote:
> > >
> > > > So, to be clear, we're providing the ability to recognize a HTTP
> > > > authentication header containing 'Bearer '
> > and
> > > > then handing that to the Security Manager to do with as it pleases?
> > > >
> > > > We're not doing anything with actual token management? (i.e.
> > generating,
> > > > revoking, etc.).
> > > >
> > > > --Jens
> > > >
> > > > On Fri, Oct 4, 2019 at 10:59 AM Jinmei Liao 
> wrote:
> > > >
> > > > > Hi, all
> > > > >
> > > > > JWT token based authentication support is added to Geode develop
> > > branch.
> > > > > Currently only management v2 rest api can use this (we can add dev
> > rest
> > > > > there too if requested). In order to turn on token based auth for
> > > > > management rest api, you will need to do these two things:
> > > > > 1. start your locator with this property:
> > > > >  *security-auth-token-enabled-components = all (or management)*
> > > > > 2. implement your SecurityManager to authenticate the jwt token
> > passed
> > > > in.
> > > > > The jwt token will be available in the properties using the key
> > > > > "security-token".
> > > > >
> > > > > Let me know if you have any questions.
> > > > >
> > > > > --
> > > > > Cheers
> > > > >
> > > > > Jinmei
> > > > >
> > > >
> > >
> > >
> > > --
> > > Cheers
> > >
> > > Jinmei
> > >
> >
> >
> > --
> > -John
> > john.blum10101 (skype)
> >
>
>
> --
> *Joris Melchior *
> CF Engineering
> Pivotal Toronto
> 416 877 5427
>
> “Programs must be written for people to read, and only incidentally for
> machines to execute.” – *Hal Abelson*
> <https://en.wikipedia.org/wiki/Hal_Abelson>
>


-- 
-John
john.blum10101 (skype)

Re: [DISCUSS] Add GEODE-7261 and GEODE-7241 to release/1.9.2

[John Blum]

+1

On Mon, Oct 14, 2019 at 11:19 AM Udo Kohlmeyer  wrote:

> +1 to including both.
>
> On 10/14/19 10:52 AM, Dick Cavender wrote:
> > +1 for both fixes and the original list
> >
> >
> > On Mon, Oct 7, 2019 at 5:00 PM Owen Nichols  wrote:
> >
> >> Sounds like a big win for convenience, and clearly a regression relative
> >> to the last release of Geode that SBDG picked up (1.6).  Thanks for
> >> clarifying what is at stake.
> >>
> >> +1 for including both fixes
> >>
> >>> On Oct 7, 2019, at 4:50 PM, Udo Kohlmeyer  wrote:
> >>>
> >>> Hi there Owen,
> >>>
> >>> I apologize if it is not clear.
> >>>
> >>> GEODE-7241 is a regression where the published artifact "geode-web" and
> >> "geode-web-api" were published as jars and not wars.
> >>> NOW, why is it critical for 1.9.x... Well, the answer is fairly short.
> >> In Spring Data Geode, there is an ability to start/bootstrap a server
> using
> >> Spring Data Geode(SDG) only. This feature can be used for testing as
> well
> >> as starting a Server using SDG. In order to start the server using SDG,
> all
> >> that is required is to add the geode-web + geode-web-api artifacts onto
> the
> >> classpath as a maven/gradle dependency. There is no more requirement to
> >> download the project and reference libs or using GFSH to start the
> server.
> >>> WHEN the extension went from war -> jar, this functionality was broken.
> >> The latest version of SDG (2.2.x) will be based on Geode 1.9. and not
> 1.10+
> >> which means that SDG will not gain that functionality. SDG would have to
> >> wait for its next release 2.3.x, which is still quite some way off.
> >>> Usually this is not a big thing, but given Spring's prescribed manner
> of
> >> handling versions of dependent libraries, the version of Geode cannot be
> >> changed and only patch versions are allowed. So, in order to address the
> >> regression, a patch to 1.9.x is requested.
> >>> Hope that this explains it a little better.
> >>>
> >>> --Udo
> >>>
> >>> On 10/7/19 3:50 PM, Owen Nichols wrote:
>  I don’t yet have a clear understanding of what makes these critical,
>  especially GEODE-7241. Can you elaborate, including:
>  * Are these fixes already in 1.10?  If not, would a 1.10.1 patch be
>  required as well?
>  * What is the impact of not including each of these fixes?  Is there a
>  workaround?
> 
>  On Fri, Oct 4, 2019 at 10:44 AM Jens Deppe  wrote:
> 
> > I'd like to propose adding these two fixes to release/1.9.2
> >
> > GEODE-7261 ensures that the Admin REST service can start when Spring
> >> Boot
> > Data Geode is used to launch a server.
> >
> > GEODE-7241 publishes our various war artifacts to maven. This ensures
> >> that,
> > in the context of starting a SBDG server, the necessary REST wars can
> >> be
> > made available in order to start the required REST services.
> >
> > Thanks
> >
> > --Jens
> >
> >>
>


-- 
-John
john.blum10101 (skype)

Re: [DISCUSS] log4j errors/warnings

[John Blum]

Be careful to only add logging dependencies as testRuntime dependencies.
Do not add any logger implementation/provider (e.g. log4j-core, or
otherwise) in either the compile-time or runtime scope.

This also means that when users are using and running Apache Geode
applications (regardless of context), they will need to explicitly choose
and declare a logging implementation, otherwise they will see the same
ERROR message logged.  For example, when using Spring Boot, users
would declare a runtime dependency on
org.springframework.boot:spring-boot-starter-logging.  This uses Logback as
the logging provider and adapts Log4j with SLF4J using the bridge.

To make matters worse, unfortunately, this message is logged by the logging
facade as an error when it should rather be logged as WARN instead, or
arguably less.

Technically, you should also be able to quiet down the "internal" Logging
facade messaging using a no-op status listener, e.g. ...

https://github.com/spring-projects/spring-boot-data-geode/blob/master/spring-geode-tests/smoke-tests/spring-initializer/src/test/resources/logback.xml#L4

I not sure what that is for Log4j2 (but there should be an equivalent).



On Fri, Oct 18, 2019 at 1:26 PM Bruce Schuchardt 
wrote:

> Not long ago changes were made to the sub-projects that introduced a lot
> of build noise.  In gradle builds we see a lot of this:
>
> ERROR StatusLogger Log4j2 could not find a logging implementation. Please
> add log4j-core to the classpath. Using SimpleLogger to log to the console...
>
> and in IntelliJ unit test runs we get this:
>
> ERROR StatusLogger No Log4j 2 configuration file found. Using default
> configuration (logging only errors to the console), or user
> programmatically provided configurations. Set system property
> 'log4j2.debug' to show Log4j 2 internal initialization logging. Seehttps://
> logging.apache.org/log4j/2.x/manual/configuration.html  for instructions
> on how to configure Log4j 2
>
> That's really annoying and it looks like Geode is broken.  To fix this
> it was suggested that "we would have to add log4j-core to the classpath
> of unit tests to get log4j-api to stop complaining".
>
> I think this should be done.  Any objections?
>
>
>

-- 
-John
john.blum10101 (skype)

Re: [DISCUSS] log4j errors/warnings

[John Blum]

There are other ways of controlling the Log4j2 Status Logger other than
adding test dependencies.


For instance, you can:

1. Set the JVM System property
org.apache.logging.log4j.simplelog.StatusLogger.level to "OFF".

2. Theoretically, when Lo4j2 finds a log4j2 or log4j2-test Properties,
YAML, JSON or XML file on the classpath, it should honor the following
configuration setting, e.g. in log4j2.xml:



This is described in the Log4j documentation at
https://logging.apache.org/log4j/2.x/manual/configuration.html in
section "*Status
Messages*".

Also see the section "*Automatic Configuration*" for more details on how
Log4j2 resolves configuration metadata (e.g. log4j2.xml).

3. There are also programmatical ways to control status logging by
acquiring the StatusLogger and removing all StatusListeners prior to the
Log4j2 logging system being initialized, or alternatively setting a no-op
StatusListener implementation, which you would need to implement yourself
since, seemingly, *Log4j2* does not provide an implementation unlike
*Logback*. (e.g. [1])

StatusLogger.getLogger().getListeners().forEach(StatusLogger.getLogger
()::removeListener);


Quickly experimenting, the only approach I got working in my *Spring Boot*
application using Apache Geode was #1.  I suspect there was other things
running interference, but I did not investigate further.

Anyway, I would error on the side of caution and use 1 of the approaches
above rather than simply throwing in another dependency, testRuntime or
otherwise.  It is too easy for that to be inadvertently and incorrectly
changed by some maintainer later on.

$0.02

-j


[1]
https://github.com/spring-projects/spring-boot-data-geode/blob/master/spring-geode-docs/src/main/resources/logback.xml#L4


On Tue, Oct 22, 2019 at 9:57 AM Xiaojian Zhou  wrote:

> I hit this problem in PR. I am just curious why it did not happen before?
>
>
> On Tue, Oct 22, 2019 at 9:44 AM Kirk Lund  wrote:
>
> > I'm ok with adding log4j-core to the testRuntime for all unit test
> targets
> > to prevent the ERROR message. Any other input?
> >
> > On Fri, Oct 18, 2019 at 3:10 PM John Blum  wrote:
> >
> > > Be careful to only add logging dependencies as testRuntime
> dependencies.
> > > Do not add any logger implementation/provider (e.g. log4j-core, or
> > > otherwise) in either the compile-time or runtime scope.
> > >
> > > This also means that when users are using and running Apache Geode
> > > applications (regardless of context), they will need to explicitly
> choose
> > > and declare a logging implementation, otherwise they will see the same
> > > ERROR message logged.  For example, when using Spring Boot, users
> > > would declare a runtime dependency on
> > > org.springframework.boot:spring-boot-starter-logging.  This uses
> Logback
> > as
> > > the logging provider and adapts Log4j with SLF4J using the bridge.
> > >
> > > To make matters worse, unfortunately, this message is logged by the
> > logging
> > > facade as an error when it should rather be logged as WARN instead, or
> > > arguably less.
> > >
> > > Technically, you should also be able to quiet down the "internal"
> Logging
> > > facade messaging using a no-op status listener, e.g. ...
> > >
> > >
> > >
> >
> https://github.com/spring-projects/spring-boot-data-geode/blob/master/spring-geode-tests/smoke-tests/spring-initializer/src/test/resources/logback.xml#L4
> > >
> > > I not sure what that is for Log4j2 (but there should be an equivalent).
> > >
> > >
> > >
> > > On Fri, Oct 18, 2019 at 1:26 PM Bruce Schuchardt <
> bschucha...@pivotal.io
> > >
> > > wrote:
> > >
> > > > Not long ago changes were made to the sub-projects that introduced a
> > lot
> > > > of build noise.  In gradle builds we see a lot of this:
> > > >
> > > > ERROR StatusLogger Log4j2 could not find a logging implementation.
> > Please
> > > > add log4j-core to the classpath. Using SimpleLogger to log to the
> > > console...
> > > >
> > > > and in IntelliJ unit test runs we get this:
> > > >
> > > > ERROR StatusLogger No Log4j 2 configuration file found. Using default
> > > > configuration (logging only errors to the console), or user
> > > > programmatically provided configurations. Set system property
> > > > 'log4j2.debug' to show Log4j 2 internal initialization logging.
> > > Seehttps://
> > > > logging.apache.org/log4j/2.x/manual/configuration.html  for
> > instructions
> > > > on how to configure Log4j 2
> > > >
> > > > That's really annoying and it looks like Geode is broken.  To fix
> this
> > > > it was suggested that "we would have to add log4j-core to the
> classpath
> > > > of unit tests to get log4j-api to stop complaining".
> > > >
> > > > I think this should be done.  Any objections?
> > > >
> > > >
> > > >
> > >
> > > --
> > > -John
> > > john.blum10101 (skype)
> > >
> >
>


-- 
-John
john.blum10101 (skype)

Re: [VOTE] Apache Geode 1.9.2.RC1

[John Blum]

+1

Built Spring Data for Apache Geode on 1.9.2 with success.

On Tue, Oct 22, 2019 at 1:28 PM Jinmei Liao  wrote:

> +1
>
> On Tue, Oct 22, 2019 at 11:47 AM Dave Barnes  wrote:
>
> > +1
> > Downloaded, successfully built Geode and Geode-Native docs form source.
> >
> > On Tue, Oct 22, 2019 at 2:17 AM Ju@N  wrote:
> >
> > > +1,
> > >
> > > Downloaded and built from source, created two clusters with multiple
> > > members and verified WAN replication (along with some gateway related
> > > commands) work properly.
> > > Best regards.
> > >
> > >
> > > On Mon, Oct 21, 2019 at 8:04 PM Udo Kohlmeyer  wrote:
> > >
> > > > +1,
> > > >
> > > > Checked that WAR's are generated for geode-web and geode-web-api.
> > > >
> > > > Also ran set of examples and tests from Spring Data Geode (Moore), to
> > > > confirm that it has not broken functionality.
> > > >
> > > > --Udo
> > > >
> > > > On 10/21/19 8:20 AM, Jens Deppe wrote:
> > > > > Since the deadline has expired without enough votes, I am going to
> > > extend
> > > > > it for another 48(ish) hours until 8am PST, Wednesday , 23rd
> October.
> > > > >
> > > > > Thanks
> > > > > --Jens
> > > > >
> > > > > On Tue, Oct 15, 2019 at 10:47 AM Jens Deppe 
> > > > wrote:
> > > > >
> > > > >> Hello Geode Dev Community,
> > > > >>
> > > > >> This is a release candidate for Apache Geode version 1.9.2.RC1.
> > > > >> Thanks to all the community members for their contributions to
> this
> > > > >> release!
> > > > >>
> > > > >> Please do a review and give your feedback, including the checks
> you
> > > > >> performed.
> > > > >>
> > > > >> Voting deadline:
> > > > >> 3PM PST Sun, October 20 2019.
> > > > >>
> > > > >> Please note that we are voting upon the source tag:
> > > > >> rel/v1.9.2.RC1
> > > > >>
> > > > >> Release notes:
> > > > >>
> > > > >>
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.9.2
> > > > >>
> > > > >> Source and binary distributions:
> > > > >> https://dist.apache.org/repos/dist/dev/geode/1.9.2.RC1/
> > > > >>
> > > > >> Maven staging repo:
> > > > >>
> > > https://repository.apache.org/content/repositories/orgapachegeode-1060
> > > > >>
> > > > >> GitHub:
> > > > >> https://github.com/apache/geode/tree/rel/v1.9.2.RC1
> > > > >> https://github.com/apache/geode-examples/tree/rel/v1.9.2.RC1
> > > > >> https://github.com/apache/geode-native/tree/rel/v1.9.2.RC1
> > > > >>
> > > > >> Pipelines:
> > > > >>
> > > > >>
> > > >
> > >
> >
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-9-2-main
> > > > >>
> > > > >>
> > > >
> > >
> >
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-9-2-rc
> > > > >>
> > > > >> Geode's KEYS file containing PGP keys we use to sign the release:
> > > > >> https://github.com/apache/geode/blob/develop/KEYS
> > > > >>
> > > > >> Command to run geode-examples:
> > > > >> ./gradlew -PgeodeReleaseUrl=
> > > > >> https://dist.apache.org/repos/dist/dev/geode/1.9.2.RC1
> > > > >> -PgeodeRepositoryUrl=
> > > > >>
> > > https://repository.apache.org/content/repositories/orgapachegeode-1060
> > > > >> build runAll
> > > > >>
> > > > >> Regards
> > > > >> --Jens
> > > > >>
> > > >
> > >
> > >
> > > --
> > > Ju@N
> > >
> >
>
>
> --
> Cheers
>
> Jinmei
>


-- 
-John
john.blum10101 (skype)

Re: Adding GEODE-7412 to 1.11 release

[John Blum]

+1

On Fri, Nov 8, 2019 at 10:59 AM Patrick Johnson  wrote:

> +1
>
> > On Nov 8, 2019, at 10:56 AM, Udo Kohlmeyer  wrote:
> >
> > Hi there Geode Dev,
> >
> > I would like to request that we add
> https://issues.apache.org/jira/browse/GEODE-7412 <
> https://issues.apache.org/jira/browse/GEODE-7412> to the 1.11 release.
> >
> > This change is a build change that has crept in since 1.8. The issue
> that is to be fixed is that the web archive, (geode-pulse) has since 1.8
> been uploaded as a jar file to maven central.
> >
> > I would like to fix this by having the WAR artifact being pushed to
> maven central again.
> >
> > --Udo
> >
>
>

-- 
-John
john.blum10101 (skype)

Re: Proposal to modify Servlet spec support for the HTTP Session Management Module for AppServers

[John Blum]

Since the Servlet 3.1 spec is available and the current version is 4.0, why
not consider 3.1 or even 4.0, actually?

-j

On Fri, Nov 15, 2019 at 8:59 AM Jens Deppe  wrote:

> Hello Charles; thanks very much for bringing this up.
>
> I vote +1 on this proposal.
>
> Just to add a bit more details for others:
>
> The 3.0 Servlet Spec was finalized at the end of 2009. The *earliest*
> versions of various containers that supported it are:
>
>- Jetty 8 (EOL'd since 11/2014) [1]
>- Tomcat 7 (Version 6 EOL'd 2017) [2]
>- JBoss Web 3.0.0 (version 2.x reached End of Maintenance 11/2017) [3]
>- Websphere 8.0 (End of support 4/2018) [4]
>- Weblogic 12cR1 (Extended Support until 12/2019) [5]
>
> The implication is that, of these products, there are *no* currently
> supported versions that *do not* support the Servlet 3.0 spec. I believe it
> is quite safe for us to indicate that the Session Modules are now only
> supported on 3.0 compliant containers.
>
> --Jens
>
> [1] -
> https://www.eclipse.org/jetty/documentation/current/what-jetty-version.html
> [2] - http://tomcat.apache.org/whichversion.html
> [3] - https://access.redhat.com/support/policy/updates/jboss_notes
> [4] - https://en.wikipedia.org/wiki/IBM_WebSphere_Application_Server
> [5] -
>
> https://www.solstice.com/fwd/survival-guide-to-webspheres-and-weblogics-end-of-life
>
> On Fri, Nov 15, 2019 at 8:11 AM Charles Smith  wrote:
>
> > Hello,
> >
> > The Geode HTTP Session Management Module for AppServers currently states:
> > This approach is a generic solution, which is supported by any container
> > that implements the Servlet 2.4 specification.
> > I would like to suggest that this official support be bumped up to the
> > Servlet 3.0 specification.
> >
> > There are some important cookie security features missing in the ancient
> > Servlet 2.4 spec, namely the secure and httpOnly flags. Bumping support
> to
> > Servlet 3.0 would allow the Geode AppServer session module to inherently
> > support these session cookie security features.
> >
> > I have logged the following Jira issue:
> >
> > https://issues.apache.org/jira/browse/GEODE-7438
> >
> > and submitted a pull request that provides the necessary support if the
> > Geode community agrees this is a good idea.
> >
> > And thank you for the excellent Apache Geode project!
> >
> > --
> >
> > Charles Smith
> >
> > Developer/Analyst
> >
> > Web Architecture and Development
> > MacEwan University
> > smith...@macewan.ca
> >
> >
>


-- 
-John
john.blum10101 (skype)

Re: Proposal to modify Servlet spec support for the HTTP Session Management Module for AppServers

[John Blum]

I would minimally bump it to 3.1 then.  Not only does Servlet 3.1 open up
more doors (e.g. NIO), but is also implemented by all current Servlet
Container providers (Tomcat, Jetty, etc).  Additionally, given all the
Servlet Containers Jens mentioned at the version that started supporting
Servlet 3.0 are no longer supported, then 3.1 seems like a good/reasonable
target.

-j

On Fri, Nov 15, 2019 at 12:49 PM Dan Smith  wrote:

> +1 to bumping to servlet 3.0.
>
> -Dan
>
> On Fri, Nov 15, 2019 at 12:16 PM Charles Smith 
> wrote:
>
> > Seems to me as long as newer Servlet specs do not deprecate
> > functionality/api that the session module requires AND that the session
> > module is not missing any important functionality provided by newer
> Servlet
> > specs that it's best to base support the oldest Servlet spec that is
> still
> > supported by active container versions. As Jens nicely enumerated, this
> > seems to be Servlet 3.0 right now.
> >
> > At least that's the approach that would give the session management
> > modules the widest audience. I am currently writing a Servlet 4.0 web app
> > and the Geode session module is working great except that I need to layer
> > on an additional filter to ensure my session cookies are secure.
> >
> >
> > --
> >
> > Charles Smith
> >
> > Developer/Analyst
> >
> > Web Architecture and Development
> > MacEwan University
> > smith...@macewan.ca
> >
> >
> > 
> > From: John Blum 
> > Sent: Friday, November 15, 2019 11:17 AM
> > To: geode 
> > Subject: Re: Proposal to modify Servlet spec support for the HTTP Session
> > Management Module for AppServers
> >
> > Since the Servlet 3.1 spec is available and the current version is 4.0,
> why
> > not consider 3.1 or even 4.0, actually?
> >
> > -j
> >
> > On Fri, Nov 15, 2019 at 8:59 AM Jens Deppe  wrote:
> >
> > > Hello Charles; thanks very much for bringing this up.
> > >
> > > I vote +1 on this proposal.
> > >
> > > Just to add a bit more details for others:
> > >
> > > The 3.0 Servlet Spec was finalized at the end of 2009. The *earliest*
> > > versions of various containers that supported it are:
> > >
> > >- Jetty 8 (EOL'd since 11/2014) [1]
> > >- Tomcat 7 (Version 6 EOL'd 2017) [2]
> > >- JBoss Web 3.0.0 (version 2.x reached End of Maintenance 11/2017)
> [3]
> > >- Websphere 8.0 (End of support 4/2018) [4]
> > >- Weblogic 12cR1 (Extended Support until 12/2019) [5]
> > >
> > > The implication is that, of these products, there are *no* currently
> > > supported versions that *do not* support the Servlet 3.0 spec. I
> believe
> > it
> > > is quite safe for us to indicate that the Session Modules are now only
> > > supported on 3.0 compliant containers.
> > >
> > > --Jens
> > >
> > > [1] -
> > >
> >
> https://www.eclipse.org/jetty/documentation/current/what-jetty-version.html
> > > [2] - http://tomcat.apache.org/whichversion.html
> > > [3] - https://access.redhat.com/support/policy/updates/jboss_notes
> > > [4] - https://en.wikipedia.org/wiki/IBM_WebSphere_Application_Server
> > > [5] -
> > >
> > >
> >
> https://www.solstice.com/fwd/survival-guide-to-webspheres-and-weblogics-end-of-life
> > >
> > > On Fri, Nov 15, 2019 at 8:11 AM Charles Smith 
> > wrote:
> > >
> > > > Hello,
> > > >
> > > > The Geode HTTP Session Management Module for AppServers currently
> > states:
> > > > This approach is a generic solution, which is supported by any
> > container
> > > > that implements the Servlet 2.4 specification.
> > > > I would like to suggest that this official support be bumped up to
> the
> > > > Servlet 3.0 specification.
> > > >
> > > > There are some important cookie security features missing in the
> > ancient
> > > > Servlet 2.4 spec, namely the secure and httpOnly flags. Bumping
> support
> > > to
> > > > Servlet 3.0 would allow the Geode AppServer session module to
> > inherently
> > > > support these session cookie security features.
> > > >
> > > > I have logged the following Jira issue:
> > > >
> > > > https://issues.apache.org/jira/browse/GEODE-7438
> > > >
> > > > and submitted a pull request that provides the necessary support if
> the
> > > > Geode community agrees this is a good idea.
> > > >
> > > > And thank you for the excellent Apache Geode project!
> > > >
> > > > --
> > > >
> > > > Charles Smith
> > > >
> > > > Developer/Analyst
> > > >
> > > > Web Architecture and Development
> > > > MacEwan University
> > > > smith...@macewan.ca
> > > >
> > > >
> > >
> >
> >
> > --
> > -John
> > john.blum10101 (skype)
> >
>


-- 
-John
john.blum10101 (skype)

Re: Proposal to modify Servlet spec support for the HTTP Session Management Module for AppServers

[John Blum]

1 more thing...

You can provide additional/dedicated support for newer versions (e.g.
Servlet 4.0) without (unduly) sacrificing backwards compatibility.  This is
done by many popular Java frameworks in fact, which also simultaneously
constitute a minimum baseline (e.g. Servlet 3.1).  Be current and
compatible where it makes sense.  Servlet 3.1 is a very powerful and
logical choice at this particular point in time.

FYR...

Apache Tomcat:
https://docs.spring.io/spring-boot-data-geode-build/1.2.x/reference/html5/
Eclipse Jetty:
https://www.eclipse.org/jetty/documentation/current/what-jetty-version.html
Undertow:
http://undertow.io/undertow-docs/undertow-docs-1.3.0/index.html#getting-undertow
... http://undertow.io/



On Fri, Nov 15, 2019 at 2:57 PM John Blum  wrote:

> I would minimally bump it to 3.1 then.  Not only does Servlet 3.1 open up
> more doors (e.g. NIO), but is also implemented by all current Servlet
> Container providers (Tomcat, Jetty, etc).  Additionally, given all the
> Servlet Containers Jens mentioned at the version that started supporting
> Servlet 3.0 are no longer supported, then 3.1 seems like a good/reasonable
> target.
>
> -j
>
> On Fri, Nov 15, 2019 at 12:49 PM Dan Smith  wrote:
>
>> +1 to bumping to servlet 3.0.
>>
>> -Dan
>>
>> On Fri, Nov 15, 2019 at 12:16 PM Charles Smith 
>> wrote:
>>
>> > Seems to me as long as newer Servlet specs do not deprecate
>> > functionality/api that the session module requires AND that the session
>> > module is not missing any important functionality provided by newer
>> Servlet
>> > specs that it's best to base support the oldest Servlet spec that is
>> still
>> > supported by active container versions. As Jens nicely enumerated, this
>> > seems to be Servlet 3.0 right now.
>> >
>> > At least that's the approach that would give the session management
>> > modules the widest audience. I am currently writing a Servlet 4.0 web
>> app
>> > and the Geode session module is working great except that I need to
>> layer
>> > on an additional filter to ensure my session cookies are secure.
>> >
>> >
>> > --
>> >
>> > Charles Smith
>> >
>> > Developer/Analyst
>> >
>> > Web Architecture and Development
>> > MacEwan University
>> > smith...@macewan.ca
>> >
>> >
>> > 
>> > From: John Blum 
>> > Sent: Friday, November 15, 2019 11:17 AM
>> > To: geode 
>> > Subject: Re: Proposal to modify Servlet spec support for the HTTP
>> Session
>> > Management Module for AppServers
>> >
>> > Since the Servlet 3.1 spec is available and the current version is 4.0,
>> why
>> > not consider 3.1 or even 4.0, actually?
>> >
>> > -j
>> >
>> > On Fri, Nov 15, 2019 at 8:59 AM Jens Deppe  wrote:
>> >
>> > > Hello Charles; thanks very much for bringing this up.
>> > >
>> > > I vote +1 on this proposal.
>> > >
>> > > Just to add a bit more details for others:
>> > >
>> > > The 3.0 Servlet Spec was finalized at the end of 2009. The *earliest*
>> > > versions of various containers that supported it are:
>> > >
>> > >- Jetty 8 (EOL'd since 11/2014) [1]
>> > >- Tomcat 7 (Version 6 EOL'd 2017) [2]
>> > >- JBoss Web 3.0.0 (version 2.x reached End of Maintenance 11/2017)
>> [3]
>> > >- Websphere 8.0 (End of support 4/2018) [4]
>> > >- Weblogic 12cR1 (Extended Support until 12/2019) [5]
>> > >
>> > > The implication is that, of these products, there are *no* currently
>> > > supported versions that *do not* support the Servlet 3.0 spec. I
>> believe
>> > it
>> > > is quite safe for us to indicate that the Session Modules are now only
>> > > supported on 3.0 compliant containers.
>> > >
>> > > --Jens
>> > >
>> > > [1] -
>> > >
>> >
>> https://www.eclipse.org/jetty/documentation/current/what-jetty-version.html
>> > > [2] - http://tomcat.apache.org/whichversion.html
>> > > [3] - https://access.redhat.com/support/policy/updates/jboss_notes
>> > > [4] - https://en.wikipedia.org/wiki/IBM_WebSphere_Application_Server
>> > > [5] -
>> > >
>> > >
>> >
>> https://www.solstice.com/fwd/survival-guide-to-webspheres-and-weblogics-end-of-life
>> > >
>> &

Re: Cache.close is not synchronous?

[John Blum]

+1 ^ 64!

I found this out the hard way some time ago and is why STDG exists in the
first place (i.e. usability issues, particularly with testing).

On Mon, Nov 25, 2019 at 1:41 PM Kirk Lund  wrote:

> I found a test that closes the cache and then recreates the cache multiple
> times with 2 second sleep between each. I tried to remove the Thread.sleep
> and found that recreating the cache
> throws DistributedSystemDisconnectedException (see below).
>
> This seems like a usability nightmare. Anyone have any ideas WHY it's this
> way?
>
> Personally, I want Cache.close() to block until both Cache and
> DistributedSystem are closed and the API is ready to create a new Cache.
>
> org.apache.geode.distributed.DistributedSystemDisconnectedException: This
> connection to a distributed system has been disconnected.
> at
>
> org.apache.geode.distributed.internal.InternalDistributedSystem.checkConnected(InternalDistributedSystem.java:945)
> at
>
> org.apache.geode.distributed.internal.InternalDistributedSystem.getDistributionManager(InternalDistributedSystem.java:1665)
> at
>
> org.apache.geode.internal.cache.GemFireCacheImpl.(GemFireCacheImpl.java:791)
> at
>
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:187)
> at
>
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:158)
> at
> org.apache.geode.cache.CacheFactory.create(CacheFactory.java:142)
>


-- 
-John
john.blum10101 (skype)

Re: IndexType deprecation question

[John Blum]

FYI... if you are using *Spring Data for Apache Geode* (SDG;
spring-data-geode), then there is an SDG Index enum type

[1]
wrapping the deprecated Apache Geode Index enum type

 [2].



[1]
https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/IndexType.html
[2]
https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/query/IndexType.html


On Fri, Nov 29, 2019 at 8:17 AM Joris Melchior  wrote:

> Hi All,
>
> I notice that the ENUM
>
> org.apache.geode.cache.query.IndexType has been deprecated but can't
> find what to use instead of this ENUM if I wanted to use a
> non-deprecated alternative.
>
> I understand that HASH indexes are no longer recommended but the other
> types (PRIMARY_KEY, FUNCTIONAL) are still valid and I believe we
> should be able to use them without using deprecated code.
>
> Can anyone tell me how this is accomplished?
>
> Thanks, Joris.
>
>
> --
> *Joris Melchior *
> CF Engineering
> Pivotal Toronto
> 416 877 5427
>
> “Programs must be written for people to read, and only incidentally for
> machines to execute.” – *Hal Abelson*
> 
>


-- 
-John
john.blum10101 (skype)

Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.

[John Blum]

+0

After some modifications to Spring Data for Apache Geode (Spring Data
Geode; SDG), I was finally able to build SDG with Apache Geode 1.11.

While I support the modularization effort, I would make it very clear (in
documentation) now that both geode-logging and geode-serialization are
required on the application classpath when using Apache Geode.

Technically, I am not entirely certain about geode-serialization (yet), but
geode-logging is strictly required to use Apache Geode.  I need to run some
more tests.

-j


On Tue, Nov 26, 2019 at 11:46 AM Blake Bender  wrote:

> -1 from native client as well, sorry.  RC3 mistakenly picked up an
> unnecessary commit, and left out the crash fix I needed.  If you revert
> commit 5d012199055a9a7657563727f6e26a406b287fc3 and
> cherry-pick 55da853760c200c53568fe2e6549c912ec26cc27, "GEODE-7426: Fixes
> segfault in log message.", native client should be good to go.
>
> Thanks,
>
> Blake
>
>
>
> On Tue, Nov 26, 2019 at 11:35 AM Lynn Hughes-Godfrey <
> lhughesgodf...@pivotal.io> wrote:
>
> > -1: Analyzing a hang that looks similar to GEODE-5307: Hang with servers
> > all in waitForPrimaryMember and one server in NO_PRIMARY_HOSTING state
> > https://issues.apache.org/jira/browse/GEODE-5307
> >
> > On Mon, Nov 25, 2019 at 9:13 PM Mark Hanson  wrote:
> >
> > > Hello Geode Dev Community,
> > >
> > > This is a release candidate for Apache Geode version 1.11.0.RC3.
> > > Thanks to all the community members for their contributions to this
> > > release!
> > >
> > > Please do a review and give your feedback, including the checks you
> > > performed.
> > >
> > > Voting deadline:
> > > 11AM PST Monday December 2 2019.
> > >
> > > Please note that we are voting upon the source tag:
> > > rel/v1.11.0.RC3
> > >
> > > Release notes:
> > >
> > >
> >
> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.11.0
> > >
> > > Source and binary distributions:
> > > https://dist.apache.org/repos/dist/dev/geode/1.11.0.RC3/
> > >
> > > Maven staging repo:
> > > https://repository.apache.org/content/repositories/orgapachegeode-1063
> > >
> > > GitHub:
> > > https://github.com/apache/geode/tree/rel/v1.11.0.RC3
> > > https://github.com/apache/geode-examples/tree/rel/v1.11.0.RC3
> > > https://github.com/apache/geode-native/tree/rel/v1.11.0.RC3
> > >
> > > Pipelines:
> > >
> > >
> >
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-11-0-main
> > >
> > >
> >
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-11-0-rc
> > >
> > > Geode's KEYS file containing PGP keys we use to sign the release:
> > > https://github.com/apache/geode/blob/develop/KEYS
> > >
> > > Command to run geode-examples:
> > > ./gradlew -PgeodeReleaseUrl=
> > > https://dist.apache.org/repos/dist/dev/geode/1.11.0.RC3
> > > -PgeodeRepositoryUrl=
> > > https://repository.apache.org/content/repositories/orgapachegeode-1063
> > > build runAll
> > >
> > > Regards
> > > Mark Hanson
> >
>


-- 
-John
john.blum10101 (skype)

Re: IndexType deprecation question

[John Blum]

My vote would be to UNDEPRECATE the IndexType in Apache Geode.  There are
several codepaths in SDG that use the IndexType to make certain decisions.

I also think having an Enum is much more flexible than having a method per
Index type, particularly since you can use Enum values in switch
statements.  I do like the createXyzIndex methods (e.g. createKeyIndex) for
common OQL Indexes, however.  I do think the createIndex for
FUNCTIONAL/RANGE OQL Indexes should be renamed (rather, the old method
deprecated and a new method introduced, i.e. createRangeIndex or
createFunctionalIndex).

-j


On Mon, Dec 2, 2019 at 9:44 AM Jason Huynh  wrote:

> Hi Joris,
>
> Just some guesses and no actual answer from me here:
>
> The deprecation of the index type was before HASH indexes were created, and
> my guess was due to the introduction of the "new at the time" query service
> apis (the javadoc:@deprecated As of 6.6.1. Check {@link QueryService} for
> changes.)
>
> The internals still use the IndexType as you have pointed out and maybe the
> deprecation was more intended for the end user (since it's not an internal
> type) and perhaps it was intended to have been moved internal at some
> point?
>
> There is some weirdness with the index types and actually having multiple
> implementations for the Functional type.  Under the covers we create a
> memory-optimized version based on the indexed expression.
>
> Things have changed since deprecation, so maybe it should be
> un/de-deprecated or an alternative solution can probably be thought up...
>
> -Jason
>
>
> On Mon, Dec 2, 2019 at 9:13 AM Joris Melchior 
> wrote:
>
> > Hi Jason,
> >
> > At this point it is not about creating but returning the Region with an
> > indicator in the management API without using deprecated parts. Under the
> > covers the QueryService java api still uses the IndexType ENUM and had
> > assumed that an alternative would be provided when something is marked as
> > deprecated.
> >
> > I can of course create a new ENUM to return but prefer not to take this
> > step before ensuring that we don't have something in place already.
> >
> > I'm also wondering if the deprecation should have been limited to the
> HASH
> > type on the IndexType ENUM instead of deprecating the complete ENUM.
> >
> > Thanks, Joris.
> >
> > On Mon, Dec 2, 2019 at 12:05 PM Jason Huynh  wrote:
> >
> > > Hi Joris,
> > >
> > > How are you creating the index?  If using the QueryService java api,
> > there
> > > should be createKeyIndex() and createIndex() methods.  These methods
> > should
> > > create the primary key index and the functional index.
> > >
> > > I am not sure if there is an alternative in gfsh... it might still be
> > using
> > > the IndexType enum or something similar.
> > >
> > >
> > >
> > >
> > > On Fri, Nov 29, 2019 at 12:18 PM Joris Melchior 
> > > wrote:
> > >
> > > > Thanks John.
> > > >
> > > > I'm trying to use it on the server side for the management API so
> > > > unfortunately the Spring wrapper is not an option. Hopefully someone
> > can
> > > > provide some insight into the deprecation background once all the
> > turkey
> > > > and stuffing has been digested.
> > > >
> > > > On Fri, Nov 29, 2019 at 2:16 PM John Blum  wrote:
> > > >
> > > > > FYI... if you are using *Spring Data for Apache Geode* (SDG;
> > > > > spring-data-geode), then there is an SDG Index enum type
> > > > > <
> > > > >
> > > >
> > >
> >
> https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/IndexType.html
> > > > > >
> > > > > [1]
> > > > > wrapping the deprecated Apache Geode Index enum type
> > > > > <
> > > > >
> > > >
> > >
> >
> https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/query/IndexType.html
> > > > > >
> > > > >  [2].
> > > > >
> > > > >
> > > > >
> > > > > [1]
> > > > >
> > > > >
> > > >
> > >
> >
> https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/IndexType.html
> > > > > [2]
> > > > >
> > > > >
> > > >
> > >
> >
> https://geode.apache.org/releases/latest/javado

Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.

[John Blum]

Indeed, both dependencies (geode-logging & geode-serialization) are listed
as runtime dependencies.

*> Is SDG creating its dependencies manually?*

I am not quite following your thinking on this question.  Of course SDG
uses transitive dependencies. SDG must declare direct dependencies on
geode-core, geode-cq, geode-lucene and geode-wan., as it is using those
features API to implement the functionality provided by SDG.

Anyway, it because Apache Geode's public API is broken/incomplete
(especially from a framework/tooling perspective, but even an application
perspective in many cases) that SDG must rely on certain (non-protected)
"internal" APIs.  It turns out that those "internal" classes have hard
(i.e. compile-time) dependencies on geode-logging & geode-serialization to
even build a project (application, framework or otherwise) using those
classes with Apache Geode.

I am currently exploring whether I can alter the use of the "internal"
class(es) to avoid forcing a compile-time dependency.

-j


On Mon, Dec 2, 2019 at 12:42 PM Jacob Barrett  wrote:

>
>
> > On Dec 1, 2019, at 2:40 PM, John Blum  wrote:
> >
> > After some modifications to Spring Data for Apache Geode (Spring Data
> > Geode; SDG), I was finally able to build SDG with Apache Geode 1.11.
> >
> > While I support the modularization effort, I would make it very clear (in
> > documentation) now that both geode-logging and geode-serialization are
> > required on the application classpath when using Apache Geode.
> >
> > Technically, I am not entirely certain about geode-serialization (yet),
> but
> > geode-logging is strictly required to use Apache Geode.  I need to run
> some
> > more tests.
>
> Both are properly listed as runtime scope in the geode-core POM. Is SDG
> creating its dependencies manually or using the transitive dependencies
> from the Geode POMs?
>
> -Jake
>
>
>
>

-- 
-John
john.blum10101 (skype)

Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.

[John Blum]

I am changing my vote to -1!

I have filed GEODE-7531 <https://issues.apache.org/jira/browse/GEODE-7531> [1],
which is a serious blocking issue for all things *Spring* for Apache
Geode.  This issue alone is currently preventing me from upgrading *Spring
Boot for Apache Geode* (SBDG) to Apache Geode 1.10, which I plan to do in
SBDG 1.3, which is based on *Spring Data for Apache Geode* (SDG)
Neumann/2.3, which is currently already pulling in Apache Geode 1.10, soon
to be upgraded to 1.11 once this issue is resolved and 1.11 is available.

If you need further explanation, you don't need to look any further than
the description as well as my comment
<https://issues.apache.org/jira/browse/GEODE-7531?focusedCommentId=16988096&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16988096>
 [2].

-j

[1] https://issues.apache.org/jira/browse/GEODE-7531
[2]
https://issues.apache.org/jira/browse/GEODE-7531?focusedCommentId=16988096&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16988096


On Wed, Dec 4, 2019 at 9:24 AM John Blum  wrote:

> Indeed, both dependencies (geode-logging & geode-serialization) are
> listed as runtime dependencies.
>
> *> Is SDG creating its dependencies manually?*
>
> I am not quite following your thinking on this question.  Of course SDG
> uses transitive dependencies. SDG must declare direct dependencies on
> geode-core, geode-cq, geode-lucene and geode-wan., as it is using those
> features API to implement the functionality provided by SDG.
>
> Anyway, it because Apache Geode's public API is broken/incomplete
> (especially from a framework/tooling perspective, but even an application
> perspective in many cases) that SDG must rely on certain (non-protected)
> "internal" APIs.  It turns out that those "internal" classes have hard
> (i.e. compile-time) dependencies on geode-logging & geode-serialization
> to even build a project (application, framework or otherwise) using those
> classes with Apache Geode.
>
> I am currently exploring whether I can alter the use of the "internal"
> class(es) to avoid forcing a compile-time dependency.
>
> -j
>
>
> On Mon, Dec 2, 2019 at 12:42 PM Jacob Barrett  wrote:
>
>>
>>
>> > On Dec 1, 2019, at 2:40 PM, John Blum  wrote:
>> >
>> > After some modifications to Spring Data for Apache Geode (Spring Data
>> > Geode; SDG), I was finally able to build SDG with Apache Geode 1.11.
>> >
>> > While I support the modularization effort, I would make it very clear
>> (in
>> > documentation) now that both geode-logging and geode-serialization are
>> > required on the application classpath when using Apache Geode.
>> >
>> > Technically, I am not entirely certain about geode-serialization (yet),
>> but
>> > geode-logging is strictly required to use Apache Geode.  I need to run
>> some
>> > more tests.
>>
>> Both are properly listed as runtime scope in the geode-core POM. Is SDG
>> creating its dependencies manually or using the transitive dependencies
>> from the Geode POMs?
>>
>> -Jake
>>
>>
>>
>>
>
> --
> -John
> john.blum10101 (skype)
>


-- 
-John
Spring Data Team

Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.

[John Blum]

This is not a test failure in SDG.  SDG builds fine with Apache Geode 1.11
(and all tests pass), as I indicated above in my origin +0 vote.

This is a definitive problem for SBDG when using STDG to mock Apache Geode
resources/objects, which is caused by GEODE-7531.

Either way, the design/code changes made in GEODE-6759 were poor and should
be fixed regardless which GEODE-7531 describes.

-j


On Wed, Dec 4, 2019 at 2:04 PM Dan Smith  wrote:

> On Wed, Dec 4, 2019 at 11:16 AM John Blum  wrote:
>
> > I am changing my vote to -1!
> >
> > I have filed GEODE-7531 <
> https://issues.apache.org/jira/browse/GEODE-7531>
> > [1],
> > which is a serious blocking issue for all things *Spring* for Apache
> > Geode.  This issue alone is currently preventing me from upgrading
> *Spring
> > Boot for Apache Geode* (SBDG) to Apache Geode 1.10, which I plan to do in
> > SBDG 1.3, which is based on *Spring Data for Apache Geode* (SDG)
> > Neumann/2.3, which is currently already pulling in Apache Geode 1.10,
> soon
> > to be upgraded to 1.11 once this issue is resolved and 1.11 is available.
> >
>
>
> I commented on the above JIRA. While we definitely don't want to break
> spring data geode, it looks like maybe the issue is just with one unit test
> in Spring Data Geode using an internal geode API to inject something into a
> singleton? If that's the case, I think it would be better to fix that one
> test in SDG.
>
> -Dan
>


-- 
-John
Spring Data Team

Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.

[John Blum]

See comment
<https://issues.apache.org/jira/browse/GEODE-7531?focusedCommentId=16988282&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16988282>
[1]
on ticket, GEODE-7531 <https://issues.apache.org/jira/browse/GEODE-7531>
 [2].

Quite frankly the reasons STDG (or dependent projects downstream like SDG,
SBDG, SSDG) are doing what it is (they are) doing is irrelevant to point
articulated in the description of GEODE-753.

[1]
https://issues.apache.org/jira/browse/GEODE-7531?focusedCommentId=16988282&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16988282
[2] https://issues.apache.org/jira/browse/GEODE-7531

On Wed, Dec 4, 2019 at 4:06 PM Dan Smith  wrote:

> On Wed, Dec 4, 2019 at 2:11 PM John Blum  wrote:
>
> > This is not a test failure in SDG.  SDG builds fine with Apache Geode
> 1.11
> > (and all tests pass), as I indicated above in my origin +0 vote.
> >
> > This is a definitive problem for SBDG when using STDG to mock Apache
> Geode
> > resources/objects, which is caused by GEODE-7531.
> >
>
> Hmm, looks like STDG is also using an internal API to inject a mock into
> the PoolManager singleton:
>
> https://github.com/spring-projects/spring-test-data-geode/blob/9a091376528cd79c978bc5b3019d30256fcf3fd5/spring-data-geode-test/src/main/java/org/springframework/data/gemfire/tests/mock/GemFireMockObjectsSupport.java#L1750
>
> Maybe it would be better to fix that? I don't think injecting anything into
> Geode singletons is a good approach - it will likely lead to mysterious
> errors in future tests. And using internal APIs tends to result in breakage
> while upgrading, as evidenced here.
>
> A more complete fix to Geode might be deprecate the static PoolManager
> entirely and move the pool management functionality to ClientCache. That
> might make it easier for you to mock the whole system? In the short term
> perhaps SDG, STDG, etc. can wrap the PoolManager in something that can have
> a mock injected into it, without using internal APIs?
>
> -Dan
>


-- 
-John
Spring Data Team

Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.

[John Blum]

If you must know, there are important test cases in both SBDG and SSDG to
be able to register (and subsequently unregister) the "mock" Pool with the
PoolManager, which unfortunately is a consequence of the SDG
PoolFactoryBean's design being reliant on the PoolManager (to resolve the
Pool), and to some extent, the PoolFactory API (to create the Pool)  in the
first place.  Of course, there is no other way to "resolve" a reference to
a Pool from Geode (other than ClientCache.geDefaultPool()), AFAIK.

Unfortunately, STDG (or SDG) would not need to import "internal" APIs if
Apache Geode's public API was properly maintained and evolved to address a
new use cases.  For example (and again), see GEODE-7532
 [1].

It turns out, there are many, many cases like GEODE-7532
 [1], with classes and
methods containing useful functions buried deep down inside Geode
"internal" packages.  The o.a.g.distributed.internal.MemberListener
interface comes to mind.  It is not difficult to see how his interface
would be useful in both frameworks & tooling (e.g. for management &
monitoring).

Or, how about the poor resource management/cleanup Apache Geode fails to do
properly w.r.t. SSL Sockets, that STDG now needs to account for

[2]
when running automated integration tests.

I think there was another example
 [3] recently, which STDG
must account for  [4] as
well.

Serializer registration/unregistration is yet another area.  The laundry
list is quite long!

The whole notion of Apache Geode's "internal" API is horribly broken,
especially when the public API often comes up short.

What troubles me is that we see the recommended changes in GEODE-7532 as a
"bandaid".  Really?

It does not matter whether these classes are "internal" or not, nor whether
they are used (externally) or not, so long as they are used properly.  If
they are "public" there is simply no guarantee they won't be used, and you
cannot expect "internal" problems to not have external consequences.

SIDE NOTE: Of course, this is further predicated on the fact those
"internal" classes were designed/implemented correctly in the first place,
which they also, were not!

I down voted for several reasons:

1. First, YES, because this blocks SBDG from moving to Apache Geode 1.11,
and perhaps, more importantly...
2. Because the Pool management in PoolManagerImpl A) refers to the Pool as
PoolImpl despite taking a reference to Pool, and B) exposes the
implementation of the usage tracking logic (which is a clear violation of
"encapsulation" and a series code smell)
3. And because the IllegalStateException message is not accurate nor was it
very informative (e.g. "what Regions").
4. Or because 2A by (along with GEODE-7159
 [5]) will most
definitely cause problems for us later, especially since these problems
will be time delayed (invoked during resource cleanup) making them hard to
pinpoint and very confusing to users.

Also, imagine a scenario where Geode offers different Pool implementations,
beyond PoolImpl.  Why else would Geode provide a PoolFactory interface if
not to encapsulate creation, configuration and initialization of different
types of Pools part of that *Open/Closed* principle.  There is no point
to have a PoolFactory otherwise since the PoolManager could have simply
created Pools.  Ironically, the PoolFactory is not something that is used
in this way and therefore became an unnecessary layer of indirection.  #sigh

In addition, the recommended changes in GEODE-7531 are not invasive
what-so-ever, and will not adversely affect Geode 1 way or another.

In closing, anytime the overall code quality of Geode comes into question
(and there is a lot to question with this codebase), which can, and most
likely will affect our end-users experience, and it HAS and DOES, you
better believe and I am going to call this out.

-j


[1] https://issues.apache.org/jira/browse/GEODE-7532
[2]
https://github.com/spring-projects/spring-test-data-geode/blob/master/spring-data-geode-test/src/main/java/org/springframework/data/gemfire/tests/integration/IntegrationTestsSupport.java#L119-L139
[3] https://markmail.org/message/5juxxnkttzjndidg
[4] https://markmail.org/message/5juxxnkttzjndidg
[5] https://issues.apache.org/jira/browse/GEODE-7159

On Wed, Dec 4, 2019 at 6:12 PM Robert Houghton  wrote:

> @udo, if one needs to use a strong word like 'offender', then the offender
> is the one using an internal API. Geode is under no obligation to maintain
> or "fix" these for any project.
>
> Is there a Jira, github issue, or pull-request to promote the internal

Re: [VOTE] Inclusion of GEODE-7159 into 1.11

[John Blum]

+1

On Tue, Dec 17, 2019 at 3:25 PM Dick Cavender  wrote:

> +1
>
> On Tue, Dec 17, 2019 at 3:01 PM Patrick Johnson 
> wrote:
>
> > +1
> >
> > > On Dec 17, 2019, at 2:59 PM, Owen Nichols  wrote:
> > >
> > > +1
> > >
> > >> On Dec 17, 2019, at 2:58 PM, Udo Kohlmeyer  wrote:
> > >>
> > >> Hi there Apache Devs.
> > >>
> > >> I can we please vote on the inclusion of GEODE-7159. This issue is to
> > fix an bug which assumes that all `Pool` objects are of type `PoolImpl`
> and
> > immediately casts Pool -> PoolImpl. This issue is related to GEODE-7531,
> > and is specific to the emergencyClose method.
> > >>
> > >> In the case of testing with Mocks, the type casts fail, because the
> > Pool-mocks are not of type PoolImpl. The simplest fix (for now) was to
> type
> > check before the cast.
> > >>
> > >>
> > >> Regards
> > >>
> > >> Udo
> > >>
> > >
> >
> >
>


-- 
-John
Spring Data Team

Re: [VOTE] Inclusion of GEODE-7531 into 1.11

[John Blum]

+1

On Tue, Dec 17, 2019 at 3:25 PM Dick Cavender  wrote:

> +1
>
> On Tue, Dec 17, 2019 at 3:03 PM Patrick Johnson 
> wrote:
>
> > +1
> >
> > > On Dec 17, 2019, at 3:01 PM, Owen Nichols  wrote:
> > >
> > > +1
> > >
> > >> On Dec 17, 2019, at 2:57 PM, Udo Kohlmeyer  wrote:
> > >>
> > >> Hi there Apache Devs.
> > >>
> > >> I can we please vote on the inclusion of GEODE-7531. This issue is to
> > fix an bug which assumes that all `Pool` objects are of type `PoolImpl`
> and
> > immediately casts Pool -> PoolImpl.
> > >>
> > >> In the case of testing with Mocks, the type casts fail, because the
> > Pool-mocks are not of type PoolImpl. The simplest fix (for now) was to
> type
> > check before the cast.
> > >>
> > >>
> > >> Regards
> > >>
> > >> Udo
> > >>
> > >
> >
> >
>


-- 
-John
Spring Data Team

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

[John Blum]

+1 to Kirk's comments.

Also, regarding (c), using AssumeThat [1] (or, alternatively & IMO
preferrably, [2]) might provide some temporary relief.


[1] https://junit.org/junit4/javadoc/latest/org/junit/Assume.html
[2]
https://joel-costigliola.github.io/assertj/core-8/api/org/assertj/core/api/Assumptions.html


On Thu, Jan 2, 2020 at 11:46 AM Kirk Lund  wrote:

> The Geode code base has 328 tests across 145 files with @Ignore. The vast
> majority of these were disabled pre-Geode because the previous group's
> policy was to disable any test that failed in CI, then file a bug system
> ticket, fix it, and re-enable it. However, the process never followed
> through beyond disabling the test and filing a ticket. Since that was the
> old pre-Apache bug system, most of us don't have access to it.
>
> From a Pivotal point-of-view, it's possible that every Geode commit that
> passes precheckin but then breaks a Pivotal Hydra test could have been
> caught by one of those disabled tests. So we are probably already
> experiencing pain and paying the price for not re-enabling these tests (in
> at least some cases).
>
> @Ignore was introduced in JUnit 4, but most of these tests were JUnit 3
> style. After I upgraded us to JUnit 4, I found every JUnit 3 style of test
> that had been disabled by renaming the test, fixed the name of the test,
> and added @Test plus @Ignore so that we can at least be aware of how many
> tests are disabled and actively search for them. I tried to add include a
> comment in the annotation if I could figure out why it was disabled. Some
> of these comments are things like (a) TRAC ticket # if known, (b) not yet
> implemented, (c) skip test for this configuration, (d) not yet implemented
> for partitioned region, etc. Sometimes I just reused a java comment that
> the disabler left above the disabled test.
>
> More info on some of those @Ignore comments:
>
> (b) not yet implemented -- this means probably means the test was never
> finished and should just be deleted but it might also be another example of
> (c) or (d) in certain test classes
>
> (c) skip test for this configuration -- this is a class that extends
> another test class but one or more test methods are overridden with @Ignore
> to prevent the test from running in the subclass because it's invalid for
> that configuration -- we can't just delete these, we have to remove
> class-hierarchy (stop extending test classes!) which will result in some
> redundancy between two test classes
>
> I do not think we should blindly delete them all, and I think we need to
> spend time studying each one individually to determine what the state of
> the test is and what should be done for it. So even if many in our
> community want to just delete all tests with @Ignore, that's not going to
> work in at least half of the test classes. You'll have to tease apart
> sub-classes from super-classes.
>
> Plus you won't actually know that the test has other coverage unless you
> spend the time analyzing it, which is what I think we should do.
>
> Some quick examples:
>
> *1) ClientServerTimeSyncDUnitTest*
>
> Notes: this test class has only two tests and both are @Ignored, so maybe
> deleting them isn't the best answer.
>
> testClientTimeAdvances is marked with @Ignore("Bug 52327"). #52327 is
> "ClientServerTimeSyncDUnitTest.testClientTimeAdvances fails intermittently"
>
> testClientTimeSlowsDown is marked with @Ignore("not yet implemented") which
> either means the test was never finished or the functionality it's trying
> to test was never finished in the product code. It looks like the test
> never had any assertions.
>
> Personally, I don't think I'd want to delete either of these tests. I would
> prefer to fix them up.
>
> If we really care about Apache Geode, our test coverage, and the quality of
> the product, then I think we should separate super-sub classes that force
> us to disable test in sub-class that are invalid test cases and fix analyze
> each test on a case-by-case basis to determine what should be done. And I
> believe that the default approach for each test should be to fix it rather
> than delete it.
>
> *2) DistributedAckPersistentRegionCCEDUnitTest*
>
>
> geode-core/src/distributedTest/java/org/apache/geode/cache30/DistributedAckPersistentRegionCCEDUnitTest.java:41:
>  @Ignore("Skip test for this configuration")
>
> geode-core/src/distributedTest/java/org/apache/geode/cache30/DistributedAckPersistentRegionCCEDUnitTest.java:46:
>  @Ignore("Skip test for this configuration")
>
> geode-core/src/distributedTest/java/org/apache/geode/cache30/DistributedAckPersistentRegionCCEDUnitTest.java:51:
>  @Ignore("Skip test for this configuration")
>
> geode-core/src/distributedTest/java/org/apache/geode/cache30/DistributedAckRegionCCEDUnitTest.java:110:
>  @Ignore("replicates don't allow local destroy")
>
> geode-core/src/distributedTest/java/org/apache/geode/cache30/DistributedAckRegionCCEDUnitTest.java:117:
>  @Ignore("replicates don't allow local 

Re: [DISCUSSION] De/un-deprecate IndexType ENUM

[John Blum]

I thought I recall that the IndexType

[1]
was *deprecated* in favor of specific methods on the QueryService

interface
[2] used to create Indexes of a specific type, e.g. like a Key Index using
QueryService.createKeyIndex(..)

[3]
(or one of the "overloaded" variants), which is in contrast to the generic
createIndex(..)

method [4] that accepted the (now deprecated) IndexType Enum as an argument.

However, I still feel that the IndexType Enum should NOT be deprecated,
especially given that the Index.getType():IndexType

method [5] is quite useful to assess an Index (e.g. think
Management/Monitoring tools or other analysis tools to ascertain the
state/configuration of the system).

-j


[1]
https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/query/IndexType.html
[2]
https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/query/QueryService.html
[3]
https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/query/QueryService.html#createKeyIndex-java.lang.String-java.lang.String-java.lang.String-
[4]
https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/query/QueryService.html#createIndex-java.lang.String-org.apache.geode.cache.query.IndexType-java.lang.String-java.lang.String-java.lang.String-
[5]
https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/query/Index.html#getType--


On Thu, Jan 2, 2020 at 1:26 PM Joris Melchior  wrote:

> Hi Kirk,
>
> No, I've tried to figure that out but was unsuccessful in doing so. It
> would be helpful if someone would be able to shed some light on that.
>
>
> On Thu, Jan 2, 2020 at 1:34 PM Kirk Lund  wrote:
>
> > Hi Joris, I've read the proposal and reviewed the code some. It's not
> clear
> > to me why it was originally deprecated or what the intended new direction
> > (instead of IndexType) was ever going to be. Do you know more about why
> it
> > was deprecated or what the devs were going to replace it with?
> >
> > On Thu, Jan 2, 2020 at 6:31 AM Joris Melchior 
> > wrote:
> >
> > > Apart from Bruce's response (thanks!) it's been very quiet on this
> item.
> > >
> > > I'll extend the response time to Jan 10.
> > >
> > > Details at
> > >
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=135863477
> > >
> > > Thanks, Joris.
> > >
> > > On Wed, Dec 4, 2019 at 1:03 PM Bruce Schuchardt <
> bschucha...@pivotal.io>
> > > wrote:
> > >
> > > > This proposal seems reasonable to me
> > > >
> > > > On 12/3/19 10:19 AM, Joris Melchior wrote:
> > > > > Ah, that makes sense. I will update!
> > > > >
> > > > >
> > > > > On Tue, Dec 3, 2019 at 12:41 PM Alexander Murmann <
> > amurm...@pivotal.io
> > > >
> > > > > wrote:
> > > > >
> > > > >> Joris, the "to be reviewed by" field is for a target date by which
> > to
> > > > wrap
> > > > >> up the discussion. Do you mind updating the field and letting the
> > > > mailing
> > > > >> list know what timeframe you envision?
> > > > >>
> > > > >> Thanks!
> > > > >>
> > > > >> On Mon, Dec 2, 2019 at 1:41 PM Joris Melchior <
> jmelch...@pivotal.io
> > >
> > > > >> wrote:
> > > > >>
> > > > >>> Hi All,
> > > > >>>
> > > > >>> Looking for feedback on the proposal to [un/de]deprecate the
> > > IndexType
> > > > >> ENUM
> > > > >>> on Geode.
> > > > >>>
> > > > >>>
> > > > >>
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=135863477
> > > > >>> Thanks, Joris.
> > > > >>>
> > > > >>> --
> > > > >>> *Joris Melchior *
> > > > >>> CF Engineering
> > > > >>> Pivotal Toronto
> > > > >>> 416 877 5427
> > > > >>>
> > > > >>> “Programs must be written for people to read, and only
> incidentally
> > > for
> > > > >>> machines to execute.” – *Hal Abelson*
> > > > >>> 
> > > > >>>
> > > > >
> > > >
> > >
> > >
> > > --
> > > *Joris Melchior *
> > > CF Engineering
> > > Pivotal Toronto
> > > 416 877 5427
> > >
> > > “Programs must be written for people to read, and only incidentally for
> > > machines to execute.” – *Hal Abelson*
> > > 
> > >
> >
>
>
> --
> *Joris Melchior *
> CF Engineering
> Pivotal Toronto
> 416 877 5427
>
> “Programs must be written for people to read, and only incidentally for
> machines to execute.” – *Hal Abelson*
> 

Re: [Vote] Include GEODE-7752 into 1.12

[John Blum]

+1

On Wed, Feb 5, 2020 at 1:54 PM Patrick Johnson 
wrote:

> +1
>
> On 2/5/20, 1:53 PM, "Udo Kohlmeyer"  wrote:
>
> Hi there Geode dev,
>
> I would like to request that GEODE-7752
> (7028f601680fee3f57cbdff63951128d7180ca13) gets included into 1.12.
>
> This piece of code is a refactor of work done in GEODE-7715. This
> refactor specializes Builders and simplifies Builder behavior for
> better
> user experience.
>
> --Udo
>
>
>
>

-- 
-John
Spring Data Team

Re: OQL Method Authorizer Blog

[John Blum]

+1 Good read, Juan.  Nice job!

On Fri, Feb 14, 2020 at 9:59 AM Jason Huynh  wrote:

> Great job Juan!  Very informative and detailed read.
>
> On Fri, Feb 14, 2020 at 4:43 AM Nabarun Nag  wrote:
>
> > Hi Geode Community,
> >
> > Please do visit the blog that Juan Ramos has put up on the OQL Method
> > Authorizer :
> >
> >
> https://jujoramos.blogspot.com/2020/02/pluggable-oql-method-authorization.html
> >
> > Thank you Juan for this effort.
> >
> > Regards
> > Nabarun Nag
> >
>


-- 
-John
Spring Data Team

Re: [DISCUSS] RFC: Shipping Geode patch releases

[John Blum]

Real quick thought... IMO:

1. There should be patch (maintenance) releases for each major.minor, up to
N-2 for a set period of time (e.g. 1.5 years), or until N-2 becomes N-3
where N-3 is no longer supported.
2. All important changes should be backported.  I say "important" loosely
since that should be decided by the community, but in general, that means
Blocker, Critical, Security fixes or other changes that can impact the
contract, functionality or proper behavior of Apache Geode in whatever
context.
3. Patch (maintenance) releases should occur at a regular, "predictable"
intervals (e.g. every 6 weeks), not on an adhoc basis.

$0.02
-John


On Tue, Feb 25, 2020 at 11:23 AM Alexander Murmann 
wrote:

> >
> > Or, we could emphasize the shift in process with bigger changes:
> > i. Instead of cutting "release/1.13.0" on May 4, we could instead cut
> > "support/1.13"
> > ii instead of creating "apache-release-1-13-0-main" pipeline, we would
> > instead create "apache-release-1-13-main"
> > iii. Instead of cleaning up the pipeline and branch after 1.13.0 was
> > released, we could keep it around for 9 months and re-use it for
> collecting
> > patches and making patch releases during that time.
> >
> +1 I cannot see any argument against cutting a release branch for the minor
> version and keeping it around.
>
> The community process around deciding how long to gather fixes before
> > shipping a patch release isn’t any easier either way.
>
> How about we wait for someone to call out the need to ship a patch
> release.  At
> that point we use the rule of thumb "aim for no more than 1 patch release
> per minor per month" to guide our community discussion.
>
> I would like to see more discussion on the community impact of increasing
> > the commitment required of a release manager.  In the short term it would
> > be good for Geode to have someone focused on improving the release
> process
> > for a longer period of time than a single release.  But in the long term,
> > people may be less likely to volunteer, and release experience will be
> > concentrated in fewer members of the community...
>
> Are there more things that could be automated? When I filled the role ~1
> year ago there was lots of copying and pasting of scripts and I even wrote
> one to help validate fixVersions. Although release process automation
> should probably be taken to a different discussion, since it's mostly
> separate form Anthony's proposal.
>
>
> On Tue, Feb 25, 2020 at 11:06 AM Owen Nichols  wrote:
>
> > These concerns make sense.  We could satisfy them within our existing
> > “on-demand” process:
> >
> > 1) the first time there is a change to backport to support branches,
> > propose the patch release.  Now we have a branch.  Decide as a community
> > how urgently it needs to be released vs how long to hold it open for
> other
> > potential fixes.
> >
> > Or, we could emphasize the shift in process with bigger changes:
> > i. Instead of cutting "release/1.13.0" on May 4, we could instead cut
> > "support/1.13"
> > ii instead of creating "apache-release-1-13-0-main" pipeline, we would
> > instead create "apache-release-1-13-main"
> > iii. Instead of cleaning up the pipeline and branch after 1.13.0 was
> > released, we could keep it around for 9 months and re-use it for
> collecting
> > patches and making patch releases during that time.
> >
> > The community process around deciding how long to gather fixes before
> > shipping a patch release isn’t any easier either way.
> >
> > One advantage of our current process is that a release doesn’t happen
> > until someone volunteers to make it happen.  We can do as many or as few
> > patch releases as the community is willing -- a release always has a
> > champion.
> >
> > I would like to see more discussion on the community impact of increasing
> > the commitment required of a release manager.  In the short term it would
> > be good for Geode to have someone focused on improving the release
> process
> > for a longer period of time than a single release.  But in the long term,
> > people may be less likely to volunteer, and release experience will be
> > concentrated in fewer members of the community...
> >
> >
> > > On Feb 25, 2020, at 9:29 AM, Anthony Baker  wrote:
> > >
> > > Here’s a couple things I’d like to avoid:
> > >
> > > 1) Issuing a patch release for every single commit that we back port
> > onto a supported minor version.  This seems like a high cost approach.
> Of
> > course, some issues may be important enough to require that.
> > >
> > > 2) Merging a change to develop, and then having to come back weeks
> later
> > and back porting the change to a release branch.  It just seems less
> > optimal since I’ll have lost the context on the changes, particularly if
> > the cherry-pick is non-trivial.
> > >
> > > More comments below.
> > >
> > > Anthony
> > >
> > >
> > >> On Feb 24, 2020, at 2:16 PM, Owen Nichols 
> wrote:
> > >>
> > >> Hi Alexander, currently we don’t start a patch 

Re: [DISCUSS] RFC: Shipping Geode patch releases

[John Blum]

NOTE: Sorry Udo, you caught me mid-flight in my response to Alexander...

Alexander-

Certainly there are circumstances (e.g. Security vulnerabilites) which may
warrant a patch/maintenance release sooner than 6 weeks, along with other
circumstances may cause a release to take longer than 6 weeks, if
"important" changes, as called out in #2, take a bit longer to complete
than expected.

Sometimes this might be dictated by upstream dependencies as well (e.g.
Apache Lucene).  You should take the 6 week window to mean a general
guideline, and not an absolute, in order to have predictability so users
can plan upgrades, even for patch releases, which is the best interest of
everyone to stay current with.

I would find it unlikely that there would not be a need for regular patches
~every 6 weeks to N, N-1 and N-2 versions.  This is not to say is "always"
going to be "important" changes, but I suspect most of the time, certain
things probably can and should be backported, regardless of "our workload
effort" that I am quite certain our users are not as concerned about.

-j

On Tue, Feb 25, 2020 at 1:42 PM Udo Kohlmeyer  wrote:

>  From the proposal it seems we are departing from the initial delivery
> paradigm of "always upgrade to the latest version, because all fixes are
> going in there", to the more product orientated approach of, there is a
> support lifespan for each {major}-{minor} version. Which is a more
> traditional product approach.
>
> Is there a specific reason we advocating for moving away from "the fix
> will be in the latest release X:Y:Z" ?
>
> The current methodology or the community voting on changes being
> cherry-picked is related to fixes making it into an unreleased version
> of Geode. From the proposal, are we advocating for extra voting "Do we
> include fix GEODE-, into N , N-1 or N-2? " This does seem to be
> something that might be more work for the community, rather than just
> updating to latest RELEASE. Or is the suggestion that closer to each
> release period, a list of candidate tickets are proposed for back
> porting? Or is the back porting and vote on inclusion done based on
> discretion and on a ticket by ticket basis?
>
> With the reduced scope of supported versions, does this also mean we
> reduce scope of backward compatibility testing between versions? i.e can
> we now change our backward compatibility testing to mimic the same
> behavior where we only test compatibility between, HEAD,N,N-1 and N-2?
>
> --Udo
>
> On 2/25/20 11:51 AM, Alexander Murmann wrote:
> > Hi John,
> >
> > I think what you are calling out in 1. and 2. matches what was discussed
> in
> > the proposal and thread. Please call out if you disagree on a detail.
> >
> > What's your reasoning behind 3?
> > I see little reason to ship a patch release (which is significant work)
> if
> > there was no important fix.
> > Likewise I am concerned about waiting to ship a critical fix to our users
> > or leave them with gaping security vulnerabilities when we have a fix,
> but
> > the next patch release train doesn't depart for several weeks.
> >
> > On Tue, Feb 25, 2020 at 11:41 AM John Blum  wrote:
> >
> >> Real quick thought... IMO:
> >>
> >> 1. There should be patch (maintenance) releases for each major.minor,
> up to
> >> N-2 for a set period of time (e.g. 1.5 years), or until N-2 becomes N-3
> >> where N-3 is no longer supported.
> >> 2. All important changes should be backported.  I say "important"
> loosely
> >> since that should be decided by the community, but in general, that
> means
> >> Blocker, Critical, Security fixes or other changes that can impact the
> >> contract, functionality or proper behavior of Apache Geode in whatever
> >> context.
> >> 3. Patch (maintenance) releases should occur at a regular, "predictable"
> >> intervals (e.g. every 6 weeks), not on an adhoc basis.
> >>
> >> $0.02
> >> -John
> >>
> >>
> >> On Tue, Feb 25, 2020 at 11:23 AM Alexander Murmann  >
> >> wrote:
> >>
> >>>> Or, we could emphasize the shift in process with bigger changes:
> >>>> i. Instead of cutting "release/1.13.0" on May 4, we could instead cut
> >>>> "support/1.13"
> >>>> ii instead of creating "apache-release-1-13-0-main" pipeline, we would
> >>>> instead create "apache-release-1-13-main"
> >>>> iii. Instead of cleaning up the pipeline and branch after 1.13.0 was
> >>>> released, we could keep it around for 

Re: [DISCUSSION] - ClassLoader Isolation

[John Blum]

Bruce - The primary gist of it is, client applications do not use the
preconfigured classpath determined by Geode itself, such as would be the
case when you start servers using *Gfsh*.  Clients are not started with
*Gfsh*, or any other Geode script for that matter.

On Thu, Feb 27, 2020 at 8:53 AM Udo Kohlmeyer  wrote:

> @Bruce, Thank you for bringing this up. The first iteration of this
> would specifically target only the server-side. BUT, I do agree, that
> clients could suffer similar problems. Yet, from experience, I (and many
> other users) have deployed different versions of the Spring Framework
> (compared to Geode) with success.
>
> Generally it is easier to resolve client-side dependencies than server,
> as one has more control over the client than a deployed (managed) server
> instance.
>
> But if we think that there is a specific scenario that a client is
> suffering from, I would be more than happy to make sure that this is
> rolled out to the client shortly after having delivered it into the server.
>
> --Udo
>
> On 2/27/20 8:45 AM, Bruce Schuchardt wrote:
> > Udo, how does this relate to the client cache?  I assume people have the
> same problems with dependencies in client-cache applications that they have
> in functions that they deploy on a server-cache.
> >
> > On 2/26/20, 10:10 AM, "Udo Kohlmeyer"  wrote:
> >
> >  Hi there Geode Dev's.
> >
> >  There is a new RFC proposal on ClassLoader Isolation. The review end
> >  date is 13 Feb 2020.
> >
> >
> https://cwiki.apache.org/confluence/display/GEODE/ClassLoader+Isolation
> >  <
> https://cwiki.apache.org/confluence/display/GEODE/ClassLoader+Isolation>
> >
> >  Please review and discuss in this thread.
> >
> >  --Udo
> >
> >
> >
> >
>


-- 
-John
Spring Data Team

Re: [DISCUSS] RFC: Shipping Geode patch releases

[John Blum]

By sticking to the "on-demand" patch release process, then there is no
difference to the current release process, and this proposal adds nothing
of value.

On Tue, Mar 3, 2020 at 12:44 AM Aaron Lindsey 
wrote:

> +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 and seeing how that goes. If
> needed we could follow that up with a proposal for regular patch release
> intervals.
>
> - Aaron
>
> > On Feb 26, 2020, at 8:45 AM, Anthony Baker  wrote:
> >
> >
> >
> >> On Feb 25, 2020, at 1:42 PM, Udo Kohlmeyer  wrote:
> >>
> >> From the proposal it seems we are departing from the initial delivery
> paradigm of "always upgrade to the latest version, because all fixes are
> going in there", to the more product orientated approach of, there is a
> support lifespan for each {major}-{minor} version. Which is a more
> traditional product approach.
> >>
> >> Is there a specific reason we advocating for moving away from "the fix
> will be in the latest release X:Y:Z" ?
> >>
> >
> > From the proposal:
> >
> > "The Geode project has been following a model of shipping releases
> quarterly [1][2].  Using the SemVer [3] approach, these quarterly releases
> are labeled as minor versions.  Occasionally, the project has shipped patch
> releases [4] to address security vulnerabilities or really critical bugs.
> However, on the whole the project has asked users to wait until the next
> quarterly minor release to receive improvements and fixes.
> >
> > It would benefit our user community if we supported our releases for a
> period of time by back porting important fixes and providing patch
> releases.”
> >
> > I believe that taking this approach will clarify expectations and make
> it easier for users to rely on Geode for their projects.
> >
> >
> >> The current methodology or the community voting on changes being
> cherry-picked is related to fixes making it into an unreleased version of
> Geode. From the proposal, are we advocating for extra voting "Do we include
> fix GEODE-, into N , N-1 or N-2? " This does seem to be something that
> might be more work for the community, rather than just updating to latest
> RELEASE. Or is the suggestion that closer to each release period, a list of
> candidate tickets are proposed for back porting? Or is the back porting and
> vote on inclusion done based on discretion and on a ticket by ticket basis?
> >
> > I think the process will follow our approach to back porting fixes onto
> a release branch:
> >
> > 1) When you fix an “important” issue, note that it will need to be back
> ported onto the correct set of support branches.
> > 2) The assigned release manager for the support branch will coordinate
> community consensus and help with cherry-picking the change as well as
> ensuring the pipelines are staying green.
> >
> >>
> >> With the reduced scope of supported versions, does this also mean we
> reduce scope of backward compatibility testing between versions? i.e can we
> now change our backward compatibility testing to mimic the same behavior
> where we only test compatibility between, HEAD,N,N-1 and N-2?
> >>
> >
> > Great question.  I think we continue to follow our SerVer approach to
> naming versions, as well as following the backwards compatibility
> guidelines described in [1[.  In short, I don’t think this N-2 changes our
> requirements—this idea is more about what versions we will patch.
> >
> >
> > Anthony
> >
> > [1]
> https://cwiki.apache.org/confluence/display/GEODE/Managing+Backward+Compatibility
> >
> >
> >
> >
> >> --Udo
> >>
> >> On 2/25/20 11:51 AM, Alexander Murmann wrote:
> >>> Hi John,
> >>>
> >>> I think what you are calling out in 1. and 2. matches what was
> discussed in
> >>> the proposal and thread. Please call out if you disagree on a detail.
> >>>
> >>> What's your reasoning behind 3?
> >>> I see little reason to ship a patch release (which is significant
> work) if
> >>> there was no important fix.
> >>> Likewise I am concerned about waiting to ship a critical fix to our
> users
> >>> or leave them with gaping security vulnerabilities when we have a fix,
> but
> >>> the next patch r

Re: RFC - Client side configuration for a SNI proxy

[John Blum]

+1 to using an Enum over separate methods.  Less is more and having a
smaller footprint (API) is better than an overloaded one where the number
of methods could easily explode.  That is smart design.

Additionally, it is not hard to introduce a bit more abstraction if the
parameters might vary by ProxyType.

For example:

setProxy(ProxyConfiguration config)

Where ProxyConfiguration is defined as...

interface ProxyConfiguration {

  ProxyType getType();

}

Then:

interface SniProxyConfiguration extends ProxyConfiguration {

  String getHost();

  int getPort();

}

Food for thought,

-j


On Mon, Mar 9, 2020 at 11:21 AM Dan Smith  wrote:

> > What is your thinking about using the enum vs specific named API’s (e.g.
> setPoolProxyWithSNI).
>
> I think the nice thing about the enum is over separate methods is that it's
> strongly typed, but it might still allow us to support additional proxy
> types in the future with less modifications for code that wraps the API
> (eg, cache.xml), or Spring Data Geode. It also makes it clear you can only
> set one type of proxy.
>
> +1 to what Bill said. I could be convinced to use setProxy(ProxyType,
> String host, int port) however.
>
> -Dan
>
>
> On Mon, Mar 9, 2020 at 10:54 AM Bill Burcham 
> wrote:
>
> > By popular demand we are extending the RFC review period. I know Udo
> asked
> > for Friday (and Joris +1'd it), but since this is a small RFC, we'd like
> to
> > try to close it by Wednesday, March 11, ok?
> >
> > On Mon, Mar 9, 2020 at 10:39 AM Jacob Barrett 
> wrote:
> >
> > > I raised similar concerns as a comment in the RFC.
> > >
> > > > On Mar 9, 2020, at 10:29 AM, Anthony Baker 
> wrote:
> > > >
> > > > Given this new API:
> > > >
> > > >setPoolProxy(ProxyType type, String proxyAddress)
> > > >
> > > > The ProxyType enum seems to be a look ahead at supporting other kinds
> > of
> > > proxies.  What is your thinking about using the enum vs specific named
> > > API’s (e.g. setPoolProxyWithSNI).
> > > >
> > > > Currently the definition of the proxyAddress seems to be dependent of
> > > the proxy type.  Did you consider stronger typing using an URI
> parameter
> > > type?
> > > >
> > > > Anthony
> > > >
> > > >
> > > >
> > > >> On Mar 6, 2020, at 11:04 AM, Bill Burcham 
> > > wrote:
> > > >>
> > > >> Please review the RFC for *Client side configuration for a SNI
> proxy*:
> > > >>
> > > >>
> > >
> >
> https://cwiki.apache.org/confluence/display/GEODE/Client+side+configuration+for+a+SNI+proxy
> > > >>
> > > >> Please comment by Monday, March 9, 2020.
> > > >>
> > > >> Regards,
> > > >> Bill and Ernie
> > > >
> > >
> >
>


-- 
-John
Spring Data Team

Re: RFC - Client side configuration for a SNI proxy

[John Blum]

Actually, a modification and note...

NOTE: Obviously, host/port might apply to more than 1 ProxyType or all.
This is just example.

And, I would define SniProxyConfiguration as...

interface SniProxyConfiguration {

  default ProxyType getType() {
return ProxyType.SNI;
  }

  String getHost();

  int getPort();

}

-j

On Mon, Mar 9, 2020 at 11:29 AM John Blum  wrote:

> +1 to using an Enum over separate methods.  Less is more and having a
> smaller footprint (API) is better than an overloaded one where the number
> of methods could easily explode.  That is smart design.
>
> Additionally, it is not hard to introduce a bit more abstraction if the
> parameters might vary by ProxyType.
>
> For example:
>
> setProxy(ProxyConfiguration config)
>
> Where ProxyConfiguration is defined as...
>
> interface ProxyConfiguration {
>
>   ProxyType getType();
>
> }
>
> Then:
>
> interface SniProxyConfiguration extends ProxyConfiguration {
>
>   String getHost();
>
>   int getPort();
>
> }
>
> Food for thought,
>
> -j
>
>
> On Mon, Mar 9, 2020 at 11:21 AM Dan Smith  wrote:
>
>> > What is your thinking about using the enum vs specific named API’s (e.g.
>> setPoolProxyWithSNI).
>>
>> I think the nice thing about the enum is over separate methods is that
>> it's
>> strongly typed, but it might still allow us to support additional proxy
>> types in the future with less modifications for code that wraps the API
>> (eg, cache.xml), or Spring Data Geode. It also makes it clear you can only
>> set one type of proxy.
>>
>> +1 to what Bill said. I could be convinced to use setProxy(ProxyType,
>> String host, int port) however.
>>
>> -Dan
>>
>>
>> On Mon, Mar 9, 2020 at 10:54 AM Bill Burcham 
>> wrote:
>>
>> > By popular demand we are extending the RFC review period. I know Udo
>> asked
>> > for Friday (and Joris +1'd it), but since this is a small RFC, we'd
>> like to
>> > try to close it by Wednesday, March 11, ok?
>> >
>> > On Mon, Mar 9, 2020 at 10:39 AM Jacob Barrett 
>> wrote:
>> >
>> > > I raised similar concerns as a comment in the RFC.
>> > >
>> > > > On Mar 9, 2020, at 10:29 AM, Anthony Baker 
>> wrote:
>> > > >
>> > > > Given this new API:
>> > > >
>> > > >setPoolProxy(ProxyType type, String proxyAddress)
>> > > >
>> > > > The ProxyType enum seems to be a look ahead at supporting other
>> kinds
>> > of
>> > > proxies.  What is your thinking about using the enum vs specific named
>> > > API’s (e.g. setPoolProxyWithSNI).
>> > > >
>> > > > Currently the definition of the proxyAddress seems to be dependent
>> of
>> > > the proxy type.  Did you consider stronger typing using an URI
>> parameter
>> > > type?
>> > > >
>> > > > Anthony
>> > > >
>> > > >
>> > > >
>> > > >> On Mar 6, 2020, at 11:04 AM, Bill Burcham 
>> > > wrote:
>> > > >>
>> > > >> Please review the RFC for *Client side configuration for a SNI
>> proxy*:
>> > > >>
>> > > >>
>> > >
>> >
>> https://cwiki.apache.org/confluence/display/GEODE/Client+side+configuration+for+a+SNI+proxy
>> > > >>
>> > > >> Please comment by Monday, March 9, 2020.
>> > > >>
>> > > >> Regards,
>> > > >> Bill and Ernie
>> > > >
>> > >
>> >
>>
>
>
> --
> -John
> Spring Data Team
>


-- 
-John
Spring Data Team

Re: RFC - Client side configuration for a SNI proxy

[John Blum]

Yes, it's redundant (i.e. Enum + class type).

However, having an Enum in addition to a specific type (1 reason I
defaulted the getType() method) can still be useful, such as in a switch
statement for example.  Enums are, well, easier to enumerate (useful in
Streams with filters).  Maybe you are going to classify certain Proxy's by
Enum type, for example:

enum ProxyType {

ONE,
TWO,
THREE;

// Contrived example
public boolean isSecure() {
return Arrays.asList(ONE, THREE).contains(this);
}
}

Then:

Iterable proxyConfigurations = ...;

StreamSupport.stream(proxyConfiguration.spilterator(), false)
.filter(config -> config.getType.isSecure())
.ifPresent(config -> // do something with secure proxy).


Food for thought.

-j



On Mon, Mar 9, 2020 at 7:11 PM Jacob Barrett  wrote:

> Yes it’s redundant.
>
> > On Mar 9, 2020, at 5:08 PM, Bill Burcham  wrote:
> >
> > What I like about John's full-fledged-class-per-proxy-kind is that
> > everything that can potentially vary with proxy kind is all together in a
> > single object.
> >
> > That being said, John, in your SniProxyConfiguration, it seems to me that
> > the class itself (SniProxyConfiguration) could easily stand for the proxy
> > "type". If that's true then we could view ProxyType as redundant and
> simply
> > eliminate it right?
> >
> >> On Mon, Mar 9, 2020 at 2:41 PM Jacob Barrett 
> wrote:
> >>
> >> +1 to Anthony and John. See similar comments in the RFC.
> >>
>  On Mar 9, 2020, at 12:08 PM, Anthony Baker  wrote:
> >>>
> >>> I’m not suggesting encoding the the proxy type in the URI.  Just
> >> wondering if we can support stronger typing than String for defining
> >> host/port/url configuration.  As John notes, later in the thread,
> perhaps
> >> using a configuration interface may help.
> >>>
> >>> Anthony
> >>>
> >>>
>  On Mar 9, 2020, at 11:11 AM, Bill Burcham 
> >> wrote:
> 
>  Anthony and Jacob, I can see how the proposed ProxyType parameter
> could
> >> fit
>  into the scheme part of a a URI. However, the problem that introduces
> is
>  that we would then have to pick (named) URL schemes to support. But
> URL
>  schemes are standardized and it's not obvious which of the standard
> ones
>  might apply here.
> 
>  If we couldn't adopt a standard scheme, we'd have to make one up. At
> >> that
>  point I question the value of putting the (made-up) scheme into a URI
>  string.
> 
>  For this reason, I am a fan of the ProxyType parameter over a made-up
> >> URL
>  scheme.
> 
>  That leaves open Anthony's other idea: eliminating the ProxyType
> >> parameter
>  in favor of a separate method to set each kind of proxy. In the
> current
>  RFC, that's just one, e.g. setPoolProxyWithSNI. I guess that comes
> down
> >> to:
>  what's the likelihood of us supporting other proxy types soon, and
> then
>  what's the value of having a single method (and multiple enums) versus
>  multiple methods (and no enum). If we thought the proxyAddress
> parameter
>  would carry different information across proxy types that might tilt
> us
>  toward the separate methods. The two on the table, however, (SNI,
> >> SOCKS5)
>  both have identical proxyAddress information.
> 
>  On Mon, Mar 9, 2020 at 10:54 AM Bill Burcham 
> >> wrote:
> 
> > By popular demand we are extending the RFC review period. I know Udo
> >> asked
> > for Friday (and Joris +1'd it), but since this is a small RFC, we'd
> >> like to
> > try to close it by Wednesday, March 11, ok?
> >
> > On Mon, Mar 9, 2020 at 10:39 AM Jacob Barrett 
> >> wrote:
> >
> >> I raised similar concerns as a comment in the RFC.
> >>
> >>> On Mar 9, 2020, at 10:29 AM, Anthony Baker 
> >> wrote:
> >>>
> >>> Given this new API:
> >>>
> >>> setPoolProxy(ProxyType type, String proxyAddress)
> >>>
> >>> The ProxyType enum seems to be a look ahead at supporting other
> kinds
> >> of proxies.  What is your thinking about using the enum vs specific
> >> named
> >> API’s (e.g. setPoolProxyWithSNI).
> >>>
> >>> Currently the definition of the proxyAddress seems to be dependent
> of
> >> the proxy type.  Did you consider stronger typing using an URI
> >> parameter
> >> type?
> >>>
> >>> Anthony
> >>>
> >>>
> >>>
>  On Mar 6, 2020, at 11:04 AM, Bill Burcham  >
> >> wrote:
> 
>  Please review the RFC for *Client side configuration for a SNI
> >> proxy*:
> 
> 
> >>
> >>
> https://cwiki.apache.org/confluence/display/GEODE/Client+side+configuration+for+a+SNI+proxy
> 
>  Please comment by Monday, March 9, 2020.
> 
>  Regards,
>  Bill and Ernie
> >>>
> >>
> >
> >>>
> >>
> >>
>


-- 
-John
Spring Data Team

Re: RFC - Client side configuration for a SNI proxy

[John Blum]

Corrections ( :-P ), my apologies...

Iterable proxyConfigurations = ...;

StreamSupport.stream(proxyConfiguration*s*.*spliterator*(), false)
.filter(config -> config.getType.isSecure()) *// This could be
improved; see below...*
.*forEach*(config -> // do something with *each* secure proxy *config*).

Although, I am sure you got the point, ;-)

With improvement:

interface ProxyConfiguration {

  ProxyType getType();

  // null-safe!
  default boolean isSecure() {
ProxyType type = getType();
return type != null && type.isSecure();
  }
}

Then:

StreamSupport.stream(..)
*.filter(ProxyConfiguration::isSecure)*
.forEach(...);


Again, completely contrived.

Cheers!
-j



On Mon, Mar 9, 2020 at 11:14 PM John Blum  wrote:

> Yes, it's redundant (i.e. Enum + class type).
>
> However, having an Enum in addition to a specific type (1 reason I
> defaulted the getType() method) can still be useful, such as in a switch
> statement for example.  Enums are, well, easier to enumerate (useful in
> Streams with filters).  Maybe you are going to classify certain Proxy's
> by Enum type, for example:
>
> enum ProxyType {
>
> ONE,
> TWO,
> THREE;
>
> // Contrived example
> public boolean isSecure() {
> return Arrays.asList(ONE, THREE).contains(this);
> }
> }
>
> Then:
>
> Iterable proxyConfigurations = ...;
>
> StreamSupport.stream(proxyConfiguration.spilterator(), false)
> .filter(config -> config.getType.isSecure())
> .ifPresent(config -> // do something with secure proxy).
>
>
> Food for thought.
>
> -j
>
>
>
> On Mon, Mar 9, 2020 at 7:11 PM Jacob Barrett  wrote:
>
>> Yes it’s redundant.
>>
>> > On Mar 9, 2020, at 5:08 PM, Bill Burcham 
>> wrote:
>> >
>> > What I like about John's full-fledged-class-per-proxy-kind is that
>> > everything that can potentially vary with proxy kind is all together in
>> a
>> > single object.
>> >
>> > That being said, John, in your SniProxyConfiguration, it seems to me
>> that
>> > the class itself (SniProxyConfiguration) could easily stand for the
>> proxy
>> > "type". If that's true then we could view ProxyType as redundant and
>> simply
>> > eliminate it right?
>> >
>> >> On Mon, Mar 9, 2020 at 2:41 PM Jacob Barrett 
>> wrote:
>> >>
>> >> +1 to Anthony and John. See similar comments in the RFC.
>> >>
>> >>>> On Mar 9, 2020, at 12:08 PM, Anthony Baker 
>> wrote:
>> >>>
>> >>> I’m not suggesting encoding the the proxy type in the URI.  Just
>> >> wondering if we can support stronger typing than String for defining
>> >> host/port/url configuration.  As John notes, later in the thread,
>> perhaps
>> >> using a configuration interface may help.
>> >>>
>> >>> Anthony
>> >>>
>> >>>
>> >>>> On Mar 9, 2020, at 11:11 AM, Bill Burcham 
>> >> wrote:
>> >>>>
>> >>>> Anthony and Jacob, I can see how the proposed ProxyType parameter
>> could
>> >> fit
>> >>>> into the scheme part of a a URI. However, the problem that
>> introduces is
>> >>>> that we would then have to pick (named) URL schemes to support. But
>> URL
>> >>>> schemes are standardized and it's not obvious which of the standard
>> ones
>> >>>> might apply here.
>> >>>>
>> >>>> If we couldn't adopt a standard scheme, we'd have to make one up. At
>> >> that
>> >>>> point I question the value of putting the (made-up) scheme into a URI
>> >>>> string.
>> >>>>
>> >>>> For this reason, I am a fan of the ProxyType parameter over a made-up
>> >> URL
>> >>>> scheme.
>> >>>>
>> >>>> That leaves open Anthony's other idea: eliminating the ProxyType
>> >> parameter
>> >>>> in favor of a separate method to set each kind of proxy. In the
>> current
>> >>>> RFC, that's just one, e.g. setPoolProxyWithSNI. I guess that comes
>> down
>> >> to:
>> >>>> what's the likelihood of us supporting other proxy types soon, and
>> then
>> >>>> what's the value of having a single method (and multiple enums)
>> versus
>> >>>> multiple methods (and no enum). If we thought the proxyA

Re: RFC - Client side configuration for a SNI proxy

[John Blum]

Again, we should keep the API footprint *small* and quit adding overrides
for every type of Proxy we would (potentially) support.  What is the point
of an abstraction/type-hierarchy if you don't use it?

The Enum would give users the possible range of currently supported Proxies
anyway.

Additionally, if you wanted something more specific, then you could
introduce a generic type signature, which is more useful for return types,
but work equally well for parameters as well...

interface PoolFactory {

  void setProxy(P config);

}

Of course, this assumes you would have multiple different types of
PoolFactory, which Geode does not currently, but could.

Generic parameters are more useful for return types, and the entire
PoolFactory, and don't necessarily need a generic type signature on the
enclosing type, for example:

interface PoolFactory {

 P getProxy();

}

-j


On Tue, Mar 10, 2020 at 10:38 AM Udo Kohlmeyer  wrote:

> I disagree.
>
> I think /setProxy(ProxyConfiguration)/ is 1st prize.
>
> If we are concerned that users will not know WHAT options are
> available.. We could always have a static builder for our supported
> options.
>
> --Udo
>
> On 3/10/20 10:07 AM, Dan Smith wrote:
> > Ok, how about this?
> >
> > setProxy(SniProxyConfiguration config)
> >
> > interface SniProxyConfiguration extends ProxyConfiguration {
> > static SniProxyConfiguration create(String host, int port);
> > String getHost();
> > int getPort()
> > }
> >
> > The main difference here from John's proposal being that setProxy takes a
> > SniProxyConfiguration, rather than the base ProxyConfiguration. We can
> > overload setProxy later if needed.
> >
> > The reason I'm not as keen on setProxy(ProxyConfiguration) is that it is
> > hard for the user to discover the different types of ProxyConfiguration
> > subclasses and know what is supported.
> >
> > -Dan
> >
> > On Mon, Mar 9, 2020 at 11:23 PM John Blum  wrote:
> >
> >> Corrections ( :-P ), my apologies...
> >>
> >> Iterable proxyConfigurations = ...;
> >>
> >> StreamSupport.stream(proxyConfiguration*s*.*spliterator*(), false)
> >>  .filter(config -> config.getType.isSecure()) *// This could be
> >> improved; see below...*
> >>  .*forEach*(config -> // do something with *each* secure proxy
> >> *config*).
> >>
> >> Although, I am sure you got the point, ;-)
> >>
> >> With improvement:
> >>
> >> interface ProxyConfiguration {
> >>
> >>ProxyType getType();
> >>
> >>// null-safe!
> >>default boolean isSecure() {
> >>  ProxyType type = getType();
> >>  return type != null && type.isSecure();
> >>}
> >> }
> >>
> >> Then:
> >>
> >> StreamSupport.stream(..)
> >> *.filter(ProxyConfiguration::isSecure)*
> >>  .forEach(...);
> >>
> >>
> >> Again, completely contrived.
> >>
> >> Cheers!
> >> -j
> >>
> >>
> >>
> >> On Mon, Mar 9, 2020 at 11:14 PM John Blum  wrote:
> >>
> >>> Yes, it's redundant (i.e. Enum + class type).
> >>>
> >>> However, having an Enum in addition to a specific type (1 reason I
> >>> defaulted the getType() method) can still be useful, such as in a
> switch
> >>> statement for example.  Enums are, well, easier to enumerate (useful in
> >>> Streams with filters).  Maybe you are going to classify certain Proxy's
> >>> by Enum type, for example:
> >>>
> >>> enum ProxyType {
> >>>
> >>>  ONE,
> >>>  TWO,
> >>>  THREE;
> >>>
> >>>  // Contrived example
> >>>  public boolean isSecure() {
> >>>  return Arrays.asList(ONE, THREE).contains(this);
> >>>  }
> >>> }
> >>>
> >>> Then:
> >>>
> >>> Iterable proxyConfigurations = ...;
> >>>
> >>> StreamSupport.stream(proxyConfiguration.spilterator(), false)
> >>>  .filter(config -> config.getType.isSecure())
> >>>  .ifPresent(config -> // do something with secure proxy).
> >>>
> >>>
> >>> Food for thought.
> >>>
> >>> -j
> >>>
> >>>
> >>>
> >>> On Mon, Mar 9, 2020 at 7:11 PM Jacob Barrett 
> >> wrote:
> >>>> Yes it’s 

Re: Discussion on Deprecation

[John Blum]

Additionally, it'd be ideal if the deprecated method were then adapted to
delegate to the new approach.  This will cut down on the number of required
tests since then you only need a Unit Tests asserting the method performs
the translation/delegating appropriately, unless of course the behavior is
changing too.

On Tue, Mar 17, 2020 at 8:57 AM Udo Kohlmeyer  wrote:

> I think we are also missing the other side of the coin.
>
> Once we deprecate something and we now need a equivalent test that tests
> the same behavior using the new method/approach. i.e now we have to
> double up on the testing of said deprecated method/feature/class. First
> we have to keep the tests around that use the deprecated and now we need
> the same test for the new. Otherwise we cannot ever be certain that both
> approaches work.
>
> In addition to this, if we don't create both tests, we have to create
> all the tests at the time of removal, otherwise we lose coverage.
>
> --Udo
>
> On 3/16/20 9:27 AM, Joris Melchior wrote:
> > +1 on leaving testing of deprecated functionality in place
> >
> > On Mon, Mar 16, 2020 at 11:50 AM Dan Smith  wrote:
> >
> >> +1
> >>
> >> One point though - we do need to leave some tests that specifically test
> >> the deprecated method(s), since we still support the deprecated APIs
> until
> >> we remove them. Everything else should be converted.
> >>
> >> -Dan
> >>
> >> On Sun, Mar 15, 2020 at 6:41 PM Jacob Barrett 
> wrote:
> >>
> >>> Hey Team,
> >>>
> >>> When deprecating a symbol, like class or method, please included a
> >>> reference to the replacement in the java docs. Also please include an
> >>> example of converting from the old API to the new. I am finding many
> many
> >>> places in the source where deprecated code has no hints at all. As many
> >> of
> >>> us don’t take the effort to immediately convert old tests over to the
> new
> >>> APIs the context is lost when someone finally does get around to it.
> For
> >>> public APIs this is extremely important so that users know how to
> migrate
> >>> their code with as few roadblocks as possible.
> >>>
> >>> Here is an example of something that is much better than most of what I
> >> am
> >>> seeing.
> >>>
> >>> /**
> >>>   * @deprecated Replaced with something better and safer.
> >>>   * Replaced by {@link Bar}.
> >>>   */
> >>> @Deprecated
> >>> class Foo {
> >>>/**
> >>> * Do something.
> >>> *
> >>> * @deprecated Replaced with something better.
> >>> * Replaced by {@link Bar#doSomethingBetter()}
> >>> */
> >>>@Deprecated
> >>>public void doSomething() {}
> >>>
> >>>/**
> >>> * Do something.
> >>> *
> >>> * @deprecated Implementation is not safe.
> >>> * Replaced with {@link Bar#doSomethingBetter()} and {@link
> >>> Bar#doSomethingElse()}.
> >>> * Migration example, replace:
> >>> * {@code
> >>> *   Foo foo = new Foo();
> >>> *   foo.doSomethingAndSomethingElse();
> >>> * }
> >>> * with:
> >>> * {@code
> >>> *   Bar bar = Bar();
> >>> *   bar.doSomethingBetter();
> >>> *   bar.doSomethingElse();
> >>> * }
> >>> */
> >>>@Deprecated
> >>>public void doSomethingAndSomethingElse() {}
> >>> }
> >>>
> >>> class Bar {
> >>>public void doSomethingBetter() {}
> >>>public void doSomethingElse() {}
> >>> }
> >>>
> >>> -Jake
> >>>
> >>>
> >
>


-- 
-John
Spring Data Team

Re: [PROPOSAL] Include fix for GEODE-7763 into release 1.12.0

[John Blum]

+1

On Wed, Mar 18, 2020 at 11:52 AM Owen Nichols  wrote:

> +1
>
> > On Mar 18, 2020, at 11:49 AM, Dick Cavender 
> wrote:
> >
> > +1
> >
> > On Wed, Mar 18, 2020 at 11:43 AM Nabarun Nag  wrote:
> >
> >> +1
> >>
> >> On Wed, Mar 18, 2020 at 11:41 AM Jason Huynh  wrote:
> >>
> >>> Hello Dev list,
> >>>
> >>> I'd like to include a fix for GEODE-7763 in release 1.12.0.
> >>> The change removes the call to exportValue, preventing a serialization,
> >>> when no clients are waiting for the specific event.
> >>> The reason why I think it should be in the release is that we noticed a
> >>> negative effect on performance for a specific use case, in 1.12 from a
> >>> change that made us more "consistent" in that use case.  This change
> >>> doesn't modify the fix much, but does bring performance back inline (if
> >> not
> >>> better) than before.
> >>>
> >>> The sha is b4c3e9413f0008635b0a0c9116c96147d1e4ceec
> >>>
> >>> Thanks,
> >>> -Jason
> >>>
> >>
>
>

-- 
-John
Spring Data Team

Re: [VOTE] Apache Geode 1.12.0.RC1

[John Blum]

SDG builds successfully with the Apache Geode 1.12.0 RC bits.

It is a +1 from me when the rest of the problems are addressed.

SDG build for Apache Geode (next), is here [1].

[1] https://jenkins.spring.io/job/spring-data-geode/job/master-next/


On Thu, Mar 26, 2020 at 10:28 AM Anthony Baker  wrote:

> >
> > iii) As long as we need to make an RC2 anyway, I personally feel that it
> would be nice to align geode-native to its recent milestone
> (build/v10.1.0-build.254 / commit hash 35fcb1a66).  The current release
> branch is about half-a-dozen fixes behind this milestone.
>
> I’m not seeing the milestone you mentioned above.  Anyway, is there a
> critical need to pull in these changes?  Given that we’re (hopefully) on
> the eve of getting this release shipped I’m not sure we should reset the
> release branch.
>
> Anthony
>
>

-- 
-John
Spring Data Team

Re: [VOTE] Apache Geode 1.12.0.RC4

[John Blum]

SDG continues to build with the Apache Geode 1.12.0 RC4 bits.

https://jenkins.spring.io/job/spring-data-geode/job/master-next/16/
https://github.com/spring-projects/spring-data-geode/commits/master-next

+1


On Fri, Mar 27, 2020 at 1:23 PM Anthony Baker  wrote:

> +1
>
> Things I checked:
> - expected files present
> - hashes and signatures present and valid
> - geode, geode-benchmarks, and geode-examples build from source
> - no binaries present in source distributions
> - verified that geode source and binary distributions have the correct
> SHA's
> - able to create a cluster and do region operations using gfsh
> - brief license review, no Cat X dependencies found
>
> Nitpicking:
>
> 1) Let's be consistent with names of source distribution and extensions.
> 2) NOTICE file copyright date needs to be updated for -native,
> -benchmark, -examples.
> 3) Some of the version numbers in LICENSE need to updated to match,
> also need to add asm-5.0.4.jar
>
> Anthony
>
> On Fri, Mar 27, 2020 at 11:37 AM Ernest Burghardt 
> wrote:
> >
> > Hello Geode Dev Community,
> >
> > This is a release candidate for Apache Geode version 1.12.0.RC4.
> > Thanks to all the community members for their contributions to this
> release!
> >
> > Please do a review and give your feedback, including the checks you
> > performed.
> >
> > Voting deadline:
> > 3PM PST Mon, March 30, 2020.
> >
> > Please note that we are voting upon the source tag:
> > rel/v1.12.0.RC4
> >
> > Release notes:
> >
> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.12.0
> >
> > Source and binary distributions:
> > https://dist.apache.org/repos/dist/dev/geode/1.12.0.RC4/
> >
> > Maven staging repo:
> > https://repository.apache.org/content/repositories/orgapachegeode-1068
> >
> > GitHub:
> > https://github.com/apache/geode/tree/rel/v1.12.0.RC4
> > https://github.com/apache/geode-examples/tree/rel/v1.12.0.RC4
> > https://github.com/apache/geode-native/tree/rel/v1.12.0.RC4
> > https://github.com/apache/geode-benchmarks/tree/rel/v1.12.0.RC4
> >
> > Pipelines:
> >
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-12-0-main
> >
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-12-0-rc
> >
> > Geode's KEYS file containing PGP keys we use to sign the release:
> > https://github.com/apache/geode/blob/develop/KEYS
> >
> > Command to run geode-examples:
> > ./gradlew -PgeodeReleaseUrl=
> > https://dist.apache.org/repos/dist/dev/geode/1.12.0.RC4
> > -PgeodeRepositoryUrl=
> > https://repository.apache.org/content/repositories/orgapachegeode-1068
> > build runAll
> >
> > Regards
> > Ernie Burghardt
>


-- 
-John
Spring Data Team

Re: [Discuss] Cache.close synchronous is not synchronous, but code still expects it to be....

[John Blum]

My first thought is cache close (i.e. RegionService.close()  should be
synchronous (by default), perhaps, with non-blocking options or options to
wait for a set timeout as Jake suggested.

This is a problem for *Integration Tests* (that start a peer cache
instance, in-process or standalone) in general and not simply just
"distributed" tests!  This is the reason I built support for this in *Spring
Test for Apache Geode* (STDG) since subsequent tests requiring a peer cache
instance (or CacheServer) may conflict with each other, especially given 1)
the cache instance is a *Singleton* and 2) it is ideal to not have to
restart the JVM between, even for *Integration Tests*, however, turns out
to be a really common practice. *#ugh*  However, without proper
coordination this can be a real problem, hence STDG's support.  Even when
forking JVMs, you still have to be careful to wait in certain cases, as you
could run into other conflicts (e.g. BindExceptions if not varying port
numbers and such).  For all these reasons and more, it is important that
the cache has fully shutdown and released all its resources.

Also, while we are on this topic, I think it would be useful to have a
dedicated interface for the cache instance lifecycle.  It's unfortunate the
CacheListener interface is already taken for Region events. *#sigh*

The interface might be something like...

interface CacheLifecycleListener {

  default void isStarting(CacheEvent event) {}

  default void onStart(CacheEvent event) {}

  default void isClosing(CacheEvent event) {}

  default void onClose(CacheEvent event) {}

  ...

}

-j

On Tue, Apr 14, 2020 at 3:21 PM Jason Huynh  wrote:

> The isClosed flag and method might be used currently more as an isClosing.
> The GemFireCacheImpl.isClosed() method is actually returning isClosing.
> Whatever change to isClosed that will be made, will have to properly handle
> cases where it's meant to be treated as isClosing().
>
> On Tue, Apr 14, 2020 at 3:09 PM Mark Hanson  wrote:
>
> > Hi Jake,
> >
> > For Option 6: We could fix isClosed as well. That is a great suggestion.
> > Currently, it returns almost immediately.
> > I like your options though
> >
> > Any other thoughts?
> >
> > Any preferences? It think any of the current options seem better than the
> > current situation as long as we fix isClosed.
> >
> > Thanks,
> > Mark
> > 
> > From: Jacob Barrett 
> > Sent: Tuesday, April 14, 2020 2:30 PM
> > To: dev@geode.apache.org 
> > Subject: Re: [Discuss] Cache.close synchronous is not synchronous, but
> > code still expects it to be
> >
> > Option 4: Cache.closeAndWait(long timeout, TimeUnit unit) - Closes and
> > waits until it is really closed.
> > Option 5: Cache.close(Runnable closedCalleback) - Runs callback after
> > cache is really close.
> > Option 6: cache.close(); while (!cache.isClosed());
> >
> >
> > > On Apr 14, 2020, at 2:11 PM, Mark Hanson  wrote:
> > >
> > > Hi All,
> > >
> > > I know that we have discussed this once before, but I think it bears
> > repeating. We have test code that assumes cache.close is synchronous. It
> is
> > not. Not even close. I would like discuss some possible changes.
> > >
> > > Option 1. Call it what it is.  Deprecate Cache.close and create a new
> > method called asyncClose to replace it. Simple and descriptive.
> > > Option 2. Fix cache close so it is synchronous. Some might say that we
> > are going to break behavior, but I doubt any user relies on the fact that
> > it is asynchronous. That would be dangerous in and of itself. Obviously,
> we
> > don’t want to change behavior, but there have been a number of
> distributed
> > tests that have failed for this. If internal to the code devs don’t get
> it
> > right, where does that leave users.
> > > Option 3. Status quo.
> > >
> > > What do you think? Are there other options I am missing?
> > >
> > > Thanks,
> > > Mark
> > >
> >
> >
>


-- 
-John
Spring Data Team

Re: [Discuss] Cache.close synchronous is not synchronous, but code still expects it to be....

[John Blum]

Among other problems I encountered, 1 problem that seemed to affect
*Integration
Tests* as I described was that the *Singleton* cache reference was not
cleaned up in a timely manner. Therefore, starting a fresh cache instance
(without coordination) in another *Integration Tests* would occasionally
throw a CacheExistsException (IIRC).

It would be roughly equivalent to ...

Cache cache = new CacheFactory().create();
// create more cache objects (Regions, Indexes, etc)
cache.close();
cache = new CacheFactory().create();  // EXCEPTION!!!

There is a lot of stuff (even asynchronous things) going on inside cache
close that can take time.  Even deallocation of system resources does not
always happen in a timely manner.

Kirk will undoubtedly remember other things he encountered as well.

-j


On Tue, Apr 14, 2020 at 3:45 PM Mark Hanson  wrote:

> I believe it is because of disk persistence among other things. Kirk would
> know for sure. He fixed the issue and his PR got shutdown.
> I totally support just fixing the bug.
>
> Let’s give Kirk a chance to chime in.
>
> Thanks,
> Mark
>
> > On Apr 14, 2020, at 3:39 PM, Dan Smith  wrote:
> >
> > IMO if it's not currently synchronous, that's just a bug that needs to be
> > fixed. If folks can provide details on what actually was asynchronous or
> > the particular test failures they saw, that would be helpful.
> >
> > Previously, when this came up it looks like Kirk found that close would
> not
> > wait for a different call to close() issued by a different thread [1]. Is
> > that still the bug we are running into? One that thread, it seems like we
> > also had a consensus we should just fix bugs with Cache.close:
> >
> > -Dan
> >
> > 1.
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.apache.org%2Fx%2Fthread.html%2Ff385a6dd51209e2706c68c9821412a6f22ebef3e809636060ac0bf55%40%253Cdev.geode.apache.org%253E&data=02%7C01%7Chansonm%40vmware.com%7C7a43463ab53c416234d908d7e0c4cc6b%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637225008165230328&sdata=GD77kAubDDWfP93zjYsNP61VMN4%2FKBAHcq95GwjeMBc%3D&reserved=0
> >
> > On Tue, Apr 14, 2020 at 3:23 PM John Blum  wrote:
> >
> >> My first thought is cache close (i.e. RegionService.close()  should be
> >> synchronous (by default), perhaps, with non-blocking options or options
> to
> >> wait for a set timeout as Jake suggested.
> >>
> >> This is a problem for *Integration Tests* (that start a peer cache
> >> instance, in-process or standalone) in general and not simply just
> >> "distributed" tests!  This is the reason I built support for this in
> >> *Spring
> >> Test for Apache Geode* (STDG) since subsequent tests requiring a peer
> cache
> >> instance (or CacheServer) may conflict with each other, especially
> given 1)
> >> the cache instance is a *Singleton* and 2) it is ideal to not have to
> >> restart the JVM between, even for *Integration Tests*, however, turns
> out
> >> to be a really common practice. *#ugh*  However, without proper
> >> coordination this can be a real problem, hence STDG's support.  Even
> when
> >> forking JVMs, you still have to be careful to wait in certain cases, as
> you
> >> could run into other conflicts (e.g. BindExceptions if not varying port
> >> numbers and such).  For all these reasons and more, it is important that
> >> the cache has fully shutdown and released all its resources.
> >>
> >> Also, while we are on this topic, I think it would be useful to have a
> >> dedicated interface for the cache instance lifecycle.  It's unfortunate
> the
> >> CacheListener interface is already taken for Region events. *#sigh*
> >>
> >> The interface might be something like...
> >>
> >> interface CacheLifecycleListener {
> >>
> >>  default void isStarting(CacheEvent event) {}
> >>
> >>  default void onStart(CacheEvent event) {}
> >>
> >>  default void isClosing(CacheEvent event) {}
> >>
> >>  default void onClose(CacheEvent event) {}
> >>
> >>  ...
> >>
> >> }
> >>
> >> -j
> >>
> >> On Tue, Apr 14, 2020 at 3:21 PM Jason Huynh  wrote:
> >>
> >>> The isClosed flag and method might be used currently more as an
> >> isClosing.
> >>> The GemFireCacheImpl.isClosed() method is actually returning isClosing.
> >>> Whatever change to isClosed that will be made, will have to properly
> >> handle
> >>> cases where it's meant to be treated

Re: Use of default methods in interfaces

[John Blum]

Another way to think about this is:

1. First, default methods are not inherently bad. They are useful in many
situations and can be "overridden" on implementing classes, if necessary.
2. A default method should be provided when the operation is not strictly
required or if the implementation (procedure/algorithm) is rather simple
(e.g. following the template pattern), for example...

@FunctionalInterace {
interface Sorter {

default  Object[] sort(Object... array) {
return convert(Arrays.asList(array)).toArray();
}

> T convert(T collection);

}

3. If the interface footprint is small (as it should be) then it is
possible to use in *Lambda* expressions (and *Method References*), as
proper @FunctionalInterface as shown above, which is very useful when
composing *Streams*, etc.

Food for thought.

-j


On Fri, May 8, 2020 at 10:17 AM Jacob Barrett  wrote:

> As a general rule default implementations on an interface should only used
> when absolutely necessary because all the implementations are out of your
> control. For example, the collection interfaces in the JDK all gained new
> APIs but Java doesn’t implement every instance of them so a default is
> necessary for forward progress. However, if you own all instances you
> should not need to use default. So in this particular PR the use of default
> in the InternalCache in my opinion is wrong. We should control all internal
> interfaces and therefor can update them all with the correct
> implementation.
>
> -Jake
>
> > On May 8, 2020, at 9:49 AM, Kirk Lund  wrote:
> >
> > I believe some of the Geode community has already decided that we
> shouldn't
> > overuse default methods in interfaces. Dan and others were the ones who
> > decided this and thus I can't really explain to folks in PRs why it's bad
> > to overuse default methods. Could some of the folks with strong
> > understanding of why we should avoid making every method default empty
> > please speak up here and/or in https://github.com/apache/geode/pull/5014
> ?
> >
> > My understanding is that default implementations should only be provided
> in
> > interfaces when it's important to do so for facilitating some sort of
> > deprecation and replacing a deprecated method.
> >
> > Thanks,
> > Kirk
>
>

-- 
-John
Spring Data Team

Re: Over usage of @SuppressWarnings

[John Blum]

Another tip (for IJ IDEA users, probably same for Eclipse and other IDEs):

You can disable an inspection wher

On Fri, May 8, 2020 at 11:52 AM Michael Oleske  wrote:

> For context, here is an example of PR that added warnings as error
> https://github.com/apache/geode/pull/4816.  Here is the JIRA
> https://issues.apache.org/jira/projects/GEODE/issues/GEODE-7869
>
> -michael
>
> On Fri, May 8, 2020 at 11:45 AM Kirk Lund  wrote:
>
> > I'm reviewing lots of PRs which are
> > adding @SuppressWarnings("deprecation"), etc. I think this is a bad
> trend.
> > We should not be suppressing warnings in our code. That's hiding a
> problem
> > that we'll need to or want to deal with in the future. Also, if you add
> > several of these suppress annotations into a class or a method or a test,
> > it really diminishes the readability. It adds noise and suppresses valid
> > warnings.
> >
> > On one of Jinmei's PRs, she responded saying she has to add these to her
> > code because of some change that Jake made to the build. Can we make it
> so
> > we don't have to add these suppressions?
> >
> > Thanks,
> > Kirk
> >
>


-- 
-John
Spring Data Team

Re: Over usage of @SuppressWarnings

[John Blum]

Let's try this again :P.

+1 to Kirk's comments.  Plus...

Another tip (for IJ IDEA users, probably same for Eclipse and other IDEs):

You can disable inspection for a warning that is otherwise benign (or not
correct) *rather than* unnecessarily annotating the code with
@SuppressWarnings.

However, disable inspections judiciously.  Warnings in code are telling you
something that needs to be paid attention to and disabling the warning with
(@SuppressWarnings) or disabling the inspection makes it easy to lose sight
that the warning is there when the code is revisited.

-j


On Fri, May 8, 2020 at 11:55 AM Jacob Barrett  wrote:

> I submitted and PR a while ago that started making warnings errors on
> certain modules. Through lazy consensus it was approved and merged. I would
> love to apply it to more. To set a baseline, I tried to fix most of the
> deprecated and other warnings as possible in the effected code. Many were
> so bad off that to just keep from getting worse I marked some suppressions.
> I tried to isolate to single statements, often by extracting the offending
> line out into its own method and annotating it.
>
> Prior to this almost ever bit of free space in the warning/error gutter in
> IntelliJ was take up by these warnings. The hope was by making them errors,
> fixing most and suppressing where necessary that it wouldn’t get any worse.
> It was hoped it would be signal to the next person in there deprecating
> something, using generics, or whatever, to do it right and clean up the
> effected code too. Just suppressing errors because you want to get it done
> is not a good practice. Effort should be taken and only as a last resort
> should something be suppressed That suppression should be limited to the
> smallest possible set of statements, which may mean extracting a bit fo
> code into a method.
>
> We most definitely should make it so we don’t add anymore suppressions but
> absolutely not at the expense of allowing warnings. The code should be
> fixed or refactored to remove the suppression.
>
> -Jake
>
>
> > On May 8, 2020, at 11:45 AM, Kirk Lund  wrote:
> >
> > I'm reviewing lots of PRs which are
> > adding @SuppressWarnings("deprecation"), etc. I think this is a bad
> trend.
> > We should not be suppressing warnings in our code. That's hiding a
> problem
> > that we'll need to or want to deal with in the future. Also, if you add
> > several of these suppress annotations into a class or a method or a test,
> > it really diminishes the readability. It adds noise and suppresses valid
> > warnings.
> >
> > On one of Jinmei's PRs, she responded saying she has to add these to her
> > code because of some change that Jake made to the build. Can we make it
> so
> > we don't have to add these suppressions?
> >
> > Thanks,
> > Kirk
>
>

-- 
-John
Spring Data Team

Re: Over usage of @SuppressWarnings

[John Blum]

@Donal -

Well, if you have code like...

public void someMethod(@Nullable Object value) {

Assert.notNull(value, "...");

value.invokeSomeMethod();

...
}

The compiler will often *warn* you that value might be null without a
proper null check.  That is, not all IDEs recognize "valid" null checks,
particular if they are using some API/framework like AssertJ, perhaps.  For
example:

assertThat(value).isNotNull();

NOTE: *AssertJ* use is valid and common outside of just tests!

Usually the compiler only recognizes the assert keyword, i.e. ...

assert value != null : "...";

But the problem with Java assertions is you need to explicitly enable them,
therefore most users use lib or framework/API (e.g. like *AssertJ*).

I think other valid uses of the @SuppressWarnings annotation includes.

*"rawtypes"*
*"unchecked"* // particular around casting when the compiler is not smart
enough to figure it out though you know it is safe; usually an instanceof
check avoids these...
*"unused"* // arguable, though

Of course, use all of these judiciously and only when absolutely necessary
or certain.

I don't think it is OK to suppress deprecations (among other warnings)
since those should be addressed!

-j


On Fri, May 8, 2020 at 12:44 PM Jacob Barrett  wrote:

>
>
> > On May 8, 2020, at 12:41 PM, Donal Evans  wrote:
> >
> > Is there a consensus on what constitutes a benign warning? I think the
> only
> > times I use @SuppressWarnings is in parameterized tests to suppress the
> > unused method warning for the parameters method, or for unchecked casts,
> as
> > below:
> >
> > PartitionedRegion detailRegion1 = mock(PartitionedRegion.class);
> > when(cache.getRegion(regionPath1)).thenReturn(detailRegion1);
> >
> > where the thenReturn() would complain, since it's expecting to return a
> > Region.
> >
> > Would these be considered things that could safely just be ignored (and
> so
> > for which I can turn off inspection), or is the use of @SuppressWarnings
> > here warranted?
>
> This is a legitimate suppression. There is no other way to correct the
> dysfunctional nature of Java Generics than to @SuppressWarnings. In this
> case though only that statement should be suppressed.
>
> -Jake
>
>

-- 
-John
Spring Data Team

Re: Over usage of @SuppressWarnings

[John Blum]

I should clarify...

The use of ["rawtypes", "unchecked"] are quite common in test code and
"unused" is common in API/Framework (production) code

While *tests* make more liberal use of these checks  ("unused" is
questionable (!), though), I think all of these checks should be used
judiciously in production code.

-j


On Fri, May 8, 2020 at 12:50 PM John Blum  wrote:

> @Donal -
>
> Well, if you have code like...
>
> public void someMethod(@Nullable Object value) {
>
> Assert.notNull(value, "...");
>
> value.invokeSomeMethod();
>
> ...
> }
>
> The compiler will often *warn* you that value might be null without a
> proper null check.  That is, not all IDEs recognize "valid" null checks,
> particular if they are using some API/framework like AssertJ, perhaps.  For
> example:
>
> assertThat(value).isNotNull();
>
> NOTE: *AssertJ* use is valid and common outside of just tests!
>
> Usually the compiler only recognizes the assert keyword, i.e. ...
>
> assert value != null : "...";
>
> But the problem with Java assertions is you need to explicitly enable
> them, therefore most users use lib or framework/API (e.g. like *AssertJ*).
>
> I think other valid uses of the @SuppressWarnings annotation includes.
>
> *"rawtypes"*
> *"unchecked"* // particular around casting when the compiler is not smart
> enough to figure it out though you know it is safe; usually an instanceof
> check avoids these...
> *"unused"* // arguable, though
>
> Of course, use all of these judiciously and only when absolutely necessary
> or certain.
>
> I don't think it is OK to suppress deprecations (among other warnings)
> since those should be addressed!
>
> -j
>
>
> On Fri, May 8, 2020 at 12:44 PM Jacob Barrett  wrote:
>
>>
>>
>> > On May 8, 2020, at 12:41 PM, Donal Evans  wrote:
>> >
>> > Is there a consensus on what constitutes a benign warning? I think the
>> only
>> > times I use @SuppressWarnings is in parameterized tests to suppress the
>> > unused method warning for the parameters method, or for unchecked
>> casts, as
>> > below:
>> >
>> > PartitionedRegion detailRegion1 = mock(PartitionedRegion.class);
>> > when(cache.getRegion(regionPath1)).thenReturn(detailRegion1);
>> >
>> > where the thenReturn() would complain, since it's expecting to return a
>> > Region.
>> >
>> > Would these be considered things that could safely just be ignored (and
>> so
>> > for which I can turn off inspection), or is the use of @SuppressWarnings
>> > here warranted?
>>
>> This is a legitimate suppression. There is no other way to correct the
>> dysfunctional nature of Java Generics than to @SuppressWarnings. In this
>> case though only that statement should be suppressed.
>>
>> -Jake
>>
>>
>
> --
> -John
> Spring Data Team
>


-- 
-John
Spring Data Team

Re: Use of default methods in interfaces

[John Blum]

> *appropriate when the new method can be defined in terms of other
existing methods in the interface*

This is what it means when a method employs the "template" design pattern.

Correction to my (earlier) example:

@FunctionalInterace
interface Sorter {

default  Object[] sort(Object... array) {
return *sort*(Arrays.asList(array)).toArray();
}

> T *sort*(T collection);

}

-j

On Fri, May 8, 2020 at 1:03 PM Owen Nichols  wrote:

> Default interface methods are especially appropriate when the new method
> can be defined in terms of other existing methods in the interface.  For
> examples, when Collections added isEmpty(), it is basically just a
> shorthand for length()==0 [but certain subclasses might still be able to
> provide a more efficient implementation, for example a linked list might
> require traversing the entire list to get the length, while isEmpty could
> simply check the head].
>
> For public APIs, adding a new default interface method is safe (will not
> break source or binary compatibility), but for internal APIs, we don’t
> promise backward compatibility anyway.
>
> The pattern of adding a new default interface method with an empty
> implementation does concern me.  Perhaps a new interface that extends the
> original would be a more compile-time-verifiable way to express that new
> optional methods have been added that only some but not all implementations
> might implement?
>
>
> > On May 8, 2020, at 11:31 AM, John Blum  wrote:
> >
> > Another way to think about this is:
> >
> > 1. First, default methods are not inherently bad. They are useful in many
> > situations and can be "overridden" on implementing classes, if necessary.
> > 2. A default method should be provided when the operation is not strictly
> > required or if the implementation (procedure/algorithm) is rather simple
> > (e.g. following the template pattern), for example...
> >
> > @FunctionalInterace {
> > interface Sorter {
> >
> >default  Object[] sort(Object... array) {
> >return convert(Arrays.asList(array)).toArray();
> >}
> >
> >> T convert(T collection);
> >
> > }
> >
> > 3. If the interface footprint is small (as it should be) then it is
> > possible to use in *Lambda* expressions (and *Method References*), as
> > proper @FunctionalInterface as shown above, which is very useful when
> > composing *Streams*, etc.
> >
> > Food for thought.
> >
> > -j
> >
> >
> > On Fri, May 8, 2020 at 10:17 AM Jacob Barrett 
> wrote:
> >
> >> As a general rule default implementations on an interface should only
> used
> >> when absolutely necessary because all the implementations are out of
> your
> >> control. For example, the collection interfaces in the JDK all gained
> new
> >> APIs but Java doesn’t implement every instance of them so a default is
> >> necessary for forward progress. However, if you own all instances you
> >> should not need to use default. So in this particular PR the use of
> default
> >> in the InternalCache in my opinion is wrong. We should control all
> internal
> >> interfaces and therefor can update them all with the correct
> >> implementation.
> >>
> >> -Jake
> >>
> >>> On May 8, 2020, at 9:49 AM, Kirk Lund  wrote:
> >>>
> >>> I believe some of the Geode community has already decided that we
> >> shouldn't
> >>> overuse default methods in interfaces. Dan and others were the ones who
> >>> decided this and thus I can't really explain to folks in PRs why it's
> bad
> >>> to overuse default methods. Could some of the folks with strong
> >>> understanding of why we should avoid making every method default empty
> >>> please speak up here and/or in
> https://github.com/apache/geode/pull/5014
> >> ?
> >>>
> >>> My understanding is that default implementations should only be
> provided
> >> in
> >>> interfaces when it's important to do so for facilitating some sort of
> >>> deprecation and replacing a deprecated method.
> >>>
> >>> Thanks,
> >>> Kirk
> >>
> >>
> >
> > --
> > -John
> > Spring Data Team
>
>

-- 
-John
Spring Data Team

Re: Over usage of @SuppressWarnings

[John Blum]

Agreed, but the following (inside tests) does not work in all cases, i.e.

Region region...

Particularly if "region" is passed to a method with a different type
signature.

I am trying to find/think of the situation I encounter from time to time,
even when I use the *wildcard* signature (i.e. Region), but cannot
currently find it (*#ugh*).

Anyway, the point is, if the test is really not concerned with the type of
values (*keys*, *values*) being stored in the mock *Region* then rawtypes (or
sometimes Region) are useful in some cases since the point of the
test is not about the data but perhaps about *Region* configuration in
general, so adding types detracts (adds undue noise) to the code under test
(IMO).

It depends and is subjective.

I agree, though, in general, @SuppressWarnings should be kept to a minimum
and used only when necessary.

-j

On Fri, May 8, 2020 at 1:09 PM Kirk Lund  wrote:

> Actually there is an alternative to using @SuppressWarnings for Mockito
> mocks:
>
> Region region = cast(mock(Region.class));
>
> private static  T cast(Object object) {
>   return (T) object;
> }
>
> Personally, I'd prefer to see warnings or workarounds like above than see
> lots of @SuppressWarnings littered throughout our code base. I think it's a
> smell of bad code.
>
> On Fri, May 8, 2020 at 12:44 PM Jacob Barrett  wrote:
>
> >
> >
> > > On May 8, 2020, at 12:41 PM, Donal Evans  wrote:
> > >
> > > Is there a consensus on what constitutes a benign warning? I think the
> > only
> > > times I use @SuppressWarnings is in parameterized tests to suppress the
> > > unused method warning for the parameters method, or for unchecked
> casts,
> > as
> > > below:
> > >
> > > PartitionedRegion detailRegion1 = mock(PartitionedRegion.class);
> > > when(cache.getRegion(regionPath1)).thenReturn(detailRegion1);
> > >
> > > where the thenReturn() would complain, since it's expecting to return a
> > > Region.
> > >
> > > Would these be considered things that could safely just be ignored (and
> > so
> > > for which I can turn off inspection), or is the use of
> @SuppressWarnings
> > > here warranted?
> >
> > This is a legitimate suppression. There is no other way to correct the
> > dysfunctional nature of Java Generics than to @SuppressWarnings. In this
> > case though only that statement should be suppressed.
> >
> > -Jake
> >
> >
>


-- 
-John
Spring Data Team