Re: [DISCUSS] Java 11 jobs in the pipeline

2018-10-11 Thread Owen Nichols 
I’ve created PR 2598  to hide 
non-gating jobs from default pipeline view, if someone feels strongly enough to 
merge this.

> On Oct 11, 2018, at 3:31 PM, Alexander Murmann  wrote:
> 
>> 
>> If you don’t want to look at the OpenJDK11 jobs, simply click on the
>> OpenJDK8 <
>> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop?groups=OpenJDK8>
>> tab.
>> 
> I'd follow the rule of thumb that the default should be what we want people
> to look at. We don't want people to get desensitized that red CI => "This
> is bad, I must jump into action". So I'd argue that the OpenJDK11 jobs
> should not be in the default view until they are reliably green and at that
> point also should block the pipeline.
> 
> On Thu, Oct 11, 2018 at 2:02 PM Owen Nichols  wrote:
> 
>> If you don’t want to look at the OpenJDK11 jobs, simply click on the
>> OpenJDK8 <
>> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop?groups=OpenJDK8>
>> tab.
>> 
>> For this week, the jobs we are not yet expecting to be green have been
>> paused blue until related PRs are approved.  For example, UnitTestOpenJDK11
>> and WindowsUnitTestOpenJDK11 will turn green as soon as PR 2591 <
>> https://github.com/apache/geode/pull/2591> is merged.
>> 
>> Looking ahead to next week, if we need to hide all OpenJDK11 jobs, then do
>> we unhide each one as it gets fixed?  Or wait for 100% green and then
>> unhide them all at once?  Either way that’s a lot of PRs just for hiding
>> and un-hiding.
>> 
>> Even better, feel free to help get to green by picking up a subtask of
>> GEODE-3 .
>> 
>> -Owen
>> 
>>> On Oct 10, 2018, at 2:16 PM, Alexander Murmann 
>> wrote:
>>> 
>>> +1 to keeping them off the main tab.
>>> 
>>> Having red jobs that aren't actionable will train us to ignore red jobs.
>>> 
>>> On Wed, Oct 10, 2018 at 2:13 PM Dan Smith  wrote:
>>> 
 I feel like it would be better to keep the Java 11 jobs off of the main
>> tab
 in the pipeline until they are actually working. In the spirit of
>> keeping
 develop releasable, we should keep the main pipeline clean and only
>> include
 what is releasable today in the pipeline.
 
 Thoughts?
 -Dan
 
>> 
>>

Re: [DISCUSS] Java 11 jobs in the pipeline

2018-10-11 Thread Dan Smith 
On Thu, Oct 11, 2018 at 3:36 PM Owen Nichols  wrote:

> Does same go for Windows jobs?  They seem to be reliably green at this
> point, yet are not gating.  Should they be hidden by default as well for
> consistency?
>

Seems reasonable. I don't know if that means we should hide the windows
jobs or make them gating at this point - maybe the folks working on Windows
have an opinion on where those are at. But I think we should only have jobs
that are gating a release on the main tab.

-Dan

[Spring CI] Spring Data GemFire > Nightly-ApacheGeode > #1067 was SUCCESSFUL (with 2456 tests)

2018-10-11 Thread Spring CI 

---
Spring Data GemFire > Nightly-ApacheGeode > #1067 was successful.
---
Scheduled
2458 tests in total.

https://build.spring.io/browse/SGF-NAG-1067/





--
This message is automatically generated by Atlassian Bamboo

Re: [DISCUSS] Java 11 jobs in the pipeline

2018-10-11 Thread Owen Nichols 
Does same go for Windows jobs?  They seem to be reliably green at this point, 
yet are not gating.  Should they be hidden by default as well for consistency?

> On Oct 11, 2018, at 3:31 PM, Alexander Murmann  wrote:
> 
>> 
>> If you don’t want to look at the OpenJDK11 jobs, simply click on the
>> OpenJDK8 <
>> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop?groups=OpenJDK8>
>> tab.
>> 
> I'd follow the rule of thumb that the default should be what we want people
> to look at. We don't want people to get desensitized that red CI => "This
> is bad, I must jump into action". So I'd argue that the OpenJDK11 jobs
> should not be in the default view until they are reliably green and at that
> point also should block the pipeline.
> 
> On Thu, Oct 11, 2018 at 2:02 PM Owen Nichols  wrote:
> 
>> If you don’t want to look at the OpenJDK11 jobs, simply click on the
>> OpenJDK8 <
>> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop?groups=OpenJDK8>
>> tab.
>> 
>> For this week, the jobs we are not yet expecting to be green have been
>> paused blue until related PRs are approved.  For example, UnitTestOpenJDK11
>> and WindowsUnitTestOpenJDK11 will turn green as soon as PR 2591 <
>> https://github.com/apache/geode/pull/2591> is merged.
>> 
>> Looking ahead to next week, if we need to hide all OpenJDK11 jobs, then do
>> we unhide each one as it gets fixed?  Or wait for 100% green and then
>> unhide them all at once?  Either way that’s a lot of PRs just for hiding
>> and un-hiding.
>> 
>> Even better, feel free to help get to green by picking up a subtask of
>> GEODE-3 .
>> 
>> -Owen
>> 
>>> On Oct 10, 2018, at 2:16 PM, Alexander Murmann 
>> wrote:
>>> 
>>> +1 to keeping them off the main tab.
>>> 
>>> Having red jobs that aren't actionable will train us to ignore red jobs.
>>> 
>>> On Wed, Oct 10, 2018 at 2:13 PM Dan Smith  wrote:
>>> 
 I feel like it would be better to keep the Java 11 jobs off of the main
>> tab
 in the pipeline until they are actually working. In the spirit of
>> keeping
 develop releasable, we should keep the main pipeline clean and only
>> include
 what is releasable today in the pipeline.
 
 Thoughts?
 -Dan
 
>> 
>>

Re: [DISCUSS] Java 11 jobs in the pipeline

2018-10-11 Thread Alexander Murmann 
>
> If you don’t want to look at the OpenJDK11 jobs, simply click on the
> OpenJDK8 <
> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop?groups=OpenJDK8>
> tab.
>
I'd follow the rule of thumb that the default should be what we want people
to look at. We don't want people to get desensitized that red CI => "This
is bad, I must jump into action". So I'd argue that the OpenJDK11 jobs
should not be in the default view until they are reliably green and at that
point also should block the pipeline.

On Thu, Oct 11, 2018 at 2:02 PM Owen Nichols  wrote:

> If you don’t want to look at the OpenJDK11 jobs, simply click on the
> OpenJDK8 <
> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop?groups=OpenJDK8>
> tab.
>
> For this week, the jobs we are not yet expecting to be green have been
> paused blue until related PRs are approved.  For example, UnitTestOpenJDK11
> and WindowsUnitTestOpenJDK11 will turn green as soon as PR 2591 <
> https://github.com/apache/geode/pull/2591> is merged.
>
> Looking ahead to next week, if we need to hide all OpenJDK11 jobs, then do
> we unhide each one as it gets fixed?  Or wait for 100% green and then
> unhide them all at once?  Either way that’s a lot of PRs just for hiding
> and un-hiding.
>
> Even better, feel free to help get to green by picking up a subtask of
> GEODE-3 .
>
> -Owen
>
> > On Oct 10, 2018, at 2:16 PM, Alexander Murmann 
> wrote:
> >
> > +1 to keeping them off the main tab.
> >
> > Having red jobs that aren't actionable will train us to ignore red jobs.
> >
> > On Wed, Oct 10, 2018 at 2:13 PM Dan Smith  wrote:
> >
> >> I feel like it would be better to keep the Java 11 jobs off of the main
> tab
> >> in the pipeline until they are actually working. In the spirit of
> keeping
> >> develop releasable, we should keep the main pipeline clean and only
> include
> >> what is releasable today in the pipeline.
> >>
> >> Thoughts?
> >> -Dan
> >>
>
>

Re: Geode Native & Apache Geode 1.8 Release

2018-10-11 Thread Dan Smith 
+1 for a source release. Awesome!

-Dan

On Thu, Oct 11, 2018 at 2:32 PM Michael Oleske  wrote:

> Plus 1 for source release. Exciting times we live in!
>
> For verifying, plus one to a pipeline that's not just travis. Though
> they're instructions in the repo about how to run tests to get that
> baseline confidence.
>
> -michael
>
> On Wednesday, October 10, 2018, Anilkumar Gingade 
> wrote:
>
> > Good work team.
> > +1 to get this as part of Geode 1.8 release.
> > It will be good to see community taking advantage of this. And building
> new
> > native client apps.
> > I assume it will have all the docs about client-server compatibility
> > version info. And framework for backward compatibility testing with new
> > geode releases.
> >
> > -Anil.
> >
> >
> >
> > On Wed, Oct 10, 2018 at 12:02 PM Ernest Burghardt  >
> > wrote:
> >
> > > +1 for a source release
> > >
> > >
> > > On Wed, Oct 10, 2018 at 12:59 PM Anthony Baker 
> > wrote:
> > >
> > > > I think starting with a source-only release of the native client is a
> > > good
> > > > first step.  That lets us focus on verifying that all the tasks
> > outlined
> > > in
> > > > [1] are complete and correct.
> > > >
> > > > Anthony
> > > >
> > > > [1] https://issues.apache.org/jira/browse/GEODE-1416
> > > >
> > > >
> > > > > On Oct 10, 2018, at 11:52 AM, Dan Smith  wrote:
> > > > >
> > > > > That is awesome! Let's get it in!
> > > > >
> > > > > I think there are some details to work out:
> > > > > - Do we need to build any automation for creating the native source
> > > > > release (similar to ./gradlew srcDist on the java side)?
> > > > > - Will we release binaries? Which platforms and how to does the
> > release
> > > > > manager build them?
> > > > > - How do we verify the NC code - can we create a public pipeline?
> > > > >
> > > > > Shipping these native APIs will be a great improvement!
> > > > >
> > > > > -Dan
> > > > >
> > > > > On Wed, Oct 10, 2018 at 8:41 AM Addison Huddy 
> > > wrote:
> > > > >
> > > > >> Hi,
> > > > >>
> > > > >> The Geode Native components (
> https://github.com/apache/geode-native
> > )
> > > > have
> > > > >> made tremendous progress since its original donation to Apache.
> The
> > > > >> project is nearing a release candidate and I propose that the
> *first
> > > > >> official release of Geode Native be included in Apache Geode 1.8.*
> > > > >>
> > > > >> Since donation, the project has
> > > > >>
> > > > >>   - modernized its C++ API based on C++ 11 standards
> > > > >>   - refactored away the cache singleton to allow for more flexible
> > > > >>   architectures and client-side data modeling
> > > > >>   - refactored the serializable interfaces (DataSerializable,
> > > > >>   PdxSerializable, DataSerializableFixedId) to make object
> > > serialization
> > > > >>   more straight-forward
> > > > >>   - created several examples on how to use the client (
> > > > >>   https://github.com/apache/geode-native/tree/develop/examples)
> > > > >>
> > > > >> In all, the project has closed 285 JIRA tickets since donation.
> > > > >>
> > > > >> If you want to learn more about the Geode Native, check out these
> > two
> > > > >> Apache Geode By Example videos.
> > > > >>
> > > > >> .NET: https://www.youtube.com/watch?v=-LQYNJNQ7B4&t=3s
> > > > >>
> > > > >> C++: https://www.youtube.com/watch?v=KJciEcFRdtY&t=1s
> > > > >>
> > > > >> Looking forward to hearing your input on including the first cut
> of
> > > > Geode
> > > > >> Native in Apache Geode 1.8.
> > > > >>
> > > > >>
> > > > >> Best,
> > > > >> Addison
> > > > >>
> > > >
> > > >
> > >
> >
>

Re: Running compatibility and upgrade tests using jdk9+

2018-10-11 Thread Patrick Rhomberg 
> If we throw away support for rolling JDK versions (which we’ve always
supported)

Looking at the documentation and our history of testing, I thought we've
only supported Java8, since Geode 1.0.  At Geode 1.5, the required JDK
became Java 1.8.121, but this is significantly different than rolling a
patch version.  I can't find anywhere that suggests "we've always supported
rolling JDK versions" is anything more than vacuously true.  Which isn't to
say we shouldn't -- I'm mostly just trying to be a voice of caution here.

@Dan, Owen, thank you for the correction.  My mistake.

On Thu, Oct 11, 2018 at 1:39 PM, Owen Nichols  wrote:

> Here’s the potential test matrix:
>
> Geode 1.7 on Java 8  <—>  Geode 1.7 on Java 8: already extensively tested
> Geode 1.8 on Java 8  <—>  Geode 1.7 on Java 8: already in
> backward-compatibility test plan
> Geode 1.7 on Java 11  <—>  Geode 1.7 on Java 8: UNSUPPORTED1
> Geode 1.8 on Java 11  <—>  Geode 1.7 on Java 8: UNSUPPORTED2
> Geode 1.8 on Java 8  <—>  Geode 1.8 on Java 8: already extensively tested
> Geode 1.7 on Java 11  <—>  Geode 1.8 on Java 8: UNSUPPORTED1
> Geode 1.8 on Java 11  <—>  Geode 1.8 on Java 8: need to add additional
> tests for this
> Geode 1.7 on Java 11  <—>  Geode 1.7 on Java 11: UNSUPPORTED1
> Geode 1.8 on Java 11  <—>  Geode 1.7 on Java 11: UNSUPPORTED1
> Geode 1.8 on Java 11  <—>  Geode 1.8 on Java 11: already extensively tested
>
> 1=Versions of Geode prior to 1.8 can’t run on Java 11.
> 2=ALL members of existing geode clusters MUST be rolled to Geode 1.8
> before ANY members are rolled to Java 11.
>
> We will need to do whatever it takes to make Geode 1.8 able to talk to
> other Geode 1.8 members even when one is running Java 8 and one is running
> Java 11.  If we are unable to achieve that, then we cannot bring Java 11
> support until Geode 2.0.
>
> -Owen
>
> > On Oct 11, 2018, at 10:26 AM, Galen O'Sullivan 
> wrote:
> >
> > I think we should run some sort of backwards-compatibility tests between
> > Java 8 and Java 9/11+. We need testing of Geode (both old and current
> > versions) on older JVMs talking to Geode on newer JVMs. (for example,
> what
> > if Java built-in serialization changes in a way that breaks our code
> > somehow?)
> >
> > On Mon, Oct 8, 2018 at 2:50 PM Jinmei Liao  wrote:
> >
> >> On Mon, Oct 8, 2018 at 2:45 PM Udo Kohlmeyer  wrote:
> >>
> >>> Should this not rather be a statement of.. "Running on JDK 11+" and not
> >>> 9+? Given that 9 + 10 are not in support anymore.
> >>> Also, when this is released, we will running on 11 rather than 9, or
> >>> what is the thought (end goal) with this effort?
> >>>
> >> Yes, let's for the sake of discussion, assuming jdk9+ here means jdk11+.
> >>
> >>
> >>>
> >>> Also does this effort cover some of the main additions to the JDK since
> >>> 9, which is the whole modularity theme?
> >>>
> >> Not yet. We are just trying to get a green pipeline to start with.
> >>
> >>
> >>>
> >>> --Udo
> >>>
> >>> On 10/8/18 14:11, Jinmei Liao wrote:
>  In the effort of making GEODE java 9+ compatible, we already
> determined
>  that older released versions of GEODE can NOT be run using jdk9+. With
> >>> this
>  in mind, should we still run those compatibility/upgrade DUnit tests
> in
>  java9+ pipeline? The current state of things are:
> 
>  1) A subset of compatibility/upgrade DUnit tests are successful in
> >> java9+
>  are passing because the dunit test environment happen to have the
> >> missing
>  jars in the classpath.  With the exclusion of Geode 1.4 in those test,
> >> we
>  can make all of them pass. (Just FYI, only Geode1.4 is failing in
> jdk9+
> >>> is
>  because we introduced SerializationFilter in 1.4, but the support for
> >> in
>  jdk9 was added only in 1.5).
>  2. We will have parallel pipelines testing with both jdk8 and jdk9+.
> So
>  even if we don't run these tests in jdk9+ pipeline, we are still
> >> running
>  them in jdk8.
> 
>  The question to ask is: does running compatibility/upgrade tests in
> >> jdk9
> >>> in
>  addition to jdk8 offer additional value?
> 
> >>>
> >>>
> >>
> >> --
> >> Cheers
> >>
> >> Jinmei
> >>
>
>

Re: Running compatibility and upgrade tests using jdk9+

2018-10-11 Thread Owen Nichols 
Serialization between two JVMs running different versions of Java is definitely 
possible.  Serialization sends field values, not any bytecode.

GEODE-5850 seems to be a different issue (attempting to use Java11-compiled 
bytecode in Java8, which will not work for reasons that have nothing to do with 
serialization). 

> On Oct 11, 2018, at 12:49 PM, Patrick Rhomberg  wrote:
> 
>> We need testing of Geode (both old and current versions) on older JVMs
> talking to Geode on newer JVMs.
> 
> It would be nice to support this, but I'm not sure we should.  We support
> rolling upgrades between versions of Geode, but I'm not convinced we should
> support JDK mismatch within a live cluster.
> 
>> what if Java built-in serialization changes in a way that breaks our code
> somehow?
> 
> I just submitted a PR addressing the fact that this definitely happens.
> `java.io.Serialization` will just flat-out refuse to deserialize a class
> when running in Version X if it was compiled in Version >X.
> 
> See GEODE-5850 / "exception java.lang.UnsupportedClassVersionError:
>  has been compiled by a more recent version of the Java Runtime
> (class file version 55.0), this version of the Java Runtime only recognizes
> class file versions up to 52.0."
> 
> On Thu, Oct 11, 2018 at 10:26 AM, Galen O'Sullivan 
> wrote:
> 
>> I think we should run some sort of backwards-compatibility tests between
>> Java 8 and Java 9/11+. We need testing of Geode (both old and current
>> versions) on older JVMs talking to Geode on newer JVMs. (for example, what
>> if Java built-in serialization changes in a way that breaks our code
>> somehow?)
>> 
>> On Mon, Oct 8, 2018 at 2:50 PM Jinmei Liao  wrote:
>> 
>>> On Mon, Oct 8, 2018 at 2:45 PM Udo Kohlmeyer  wrote:
>>> 
 Should this not rather be a statement of.. "Running on JDK 11+" and not
 9+? Given that 9 + 10 are not in support anymore.
 Also, when this is released, we will running on 11 rather than 9, or
 what is the thought (end goal) with this effort?
 
>>> Yes, let's for the sake of discussion, assuming jdk9+ here means jdk11+.
>>> 
>>> 
 
 Also does this effort cover some of the main additions to the JDK since
 9, which is the whole modularity theme?
 
>>> Not yet. We are just trying to get a green pipeline to start with.
>>> 
>>> 
 
 --Udo
 
 On 10/8/18 14:11, Jinmei Liao wrote:
> In the effort of making GEODE java 9+ compatible, we already
>> determined
> that older released versions of GEODE can NOT be run using jdk9+.
>> With
 this
> in mind, should we still run those compatibility/upgrade DUnit tests
>> in
> java9+ pipeline? The current state of things are:
> 
> 1) A subset of compatibility/upgrade DUnit tests are successful in
>>> java9+
> are passing because the dunit test environment happen to have the
>>> missing
> jars in the classpath.  With the exclusion of Geode 1.4 in those
>> test,
>>> we
> can make all of them pass. (Just FYI, only Geode1.4 is failing in
>> jdk9+
 is
> because we introduced SerializationFilter in 1.4, but the support for
>>> in
> jdk9 was added only in 1.5).
> 2. We will have parallel pipelines testing with both jdk8 and jdk9+.
>> So
> even if we don't run these tests in jdk9+ pipeline, we are still
>>> running
> them in jdk8.
> 
> The question to ask is: does running compatibility/upgrade tests in
>>> jdk9
 in
> addition to jdk8 offer additional value?
> 
 
 
>>> 
>>> --
>>> Cheers
>>> 
>>> Jinmei
>>> 
>>

Re: Geode Native & Apache Geode 1.8 Release

2018-10-11 Thread Michael Oleske 
Plus 1 for source release. Exciting times we live in!

For verifying, plus one to a pipeline that's not just travis. Though
they're instructions in the repo about how to run tests to get that
baseline confidence.

-michael

On Wednesday, October 10, 2018, Anilkumar Gingade 
wrote:

> Good work team.
> +1 to get this as part of Geode 1.8 release.
> It will be good to see community taking advantage of this. And building new
> native client apps.
> I assume it will have all the docs about client-server compatibility
> version info. And framework for backward compatibility testing with new
> geode releases.
>
> -Anil.
>
>
>
> On Wed, Oct 10, 2018 at 12:02 PM Ernest Burghardt 
> wrote:
>
> > +1 for a source release
> >
> >
> > On Wed, Oct 10, 2018 at 12:59 PM Anthony Baker 
> wrote:
> >
> > > I think starting with a source-only release of the native client is a
> > good
> > > first step.  That lets us focus on verifying that all the tasks
> outlined
> > in
> > > [1] are complete and correct.
> > >
> > > Anthony
> > >
> > > [1] https://issues.apache.org/jira/browse/GEODE-1416
> > >
> > >
> > > > On Oct 10, 2018, at 11:52 AM, Dan Smith  wrote:
> > > >
> > > > That is awesome! Let's get it in!
> > > >
> > > > I think there are some details to work out:
> > > > - Do we need to build any automation for creating the native source
> > > > release (similar to ./gradlew srcDist on the java side)?
> > > > - Will we release binaries? Which platforms and how to does the
> release
> > > > manager build them?
> > > > - How do we verify the NC code - can we create a public pipeline?
> > > >
> > > > Shipping these native APIs will be a great improvement!
> > > >
> > > > -Dan
> > > >
> > > > On Wed, Oct 10, 2018 at 8:41 AM Addison Huddy 
> > wrote:
> > > >
> > > >> Hi,
> > > >>
> > > >> The Geode Native components (https://github.com/apache/geode-native
> )
> > > have
> > > >> made tremendous progress since its original donation to Apache.  The
> > > >> project is nearing a release candidate and I propose that the *first
> > > >> official release of Geode Native be included in Apache Geode 1.8.*
> > > >>
> > > >> Since donation, the project has
> > > >>
> > > >>   - modernized its C++ API based on C++ 11 standards
> > > >>   - refactored away the cache singleton to allow for more flexible
> > > >>   architectures and client-side data modeling
> > > >>   - refactored the serializable interfaces (DataSerializable,
> > > >>   PdxSerializable, DataSerializableFixedId) to make object
> > serialization
> > > >>   more straight-forward
> > > >>   - created several examples on how to use the client (
> > > >>   https://github.com/apache/geode-native/tree/develop/examples)
> > > >>
> > > >> In all, the project has closed 285 JIRA tickets since donation.
> > > >>
> > > >> If you want to learn more about the Geode Native, check out these
> two
> > > >> Apache Geode By Example videos.
> > > >>
> > > >> .NET: https://www.youtube.com/watch?v=-LQYNJNQ7B4&t=3s
> > > >>
> > > >> C++: https://www.youtube.com/watch?v=KJciEcFRdtY&t=1s
> > > >>
> > > >> Looking forward to hearing your input on including the first cut of
> > > Geode
> > > >> Native in Apache Geode 1.8.
> > > >>
> > > >>
> > > >> Best,
> > > >> Addison
> > > >>
> > >
> > >
> >
>

Re: [DISCUSS] Java 11 jobs in the pipeline

2018-10-11 Thread Owen Nichols 
If you don’t want to look at the OpenJDK11 jobs, simply click on the OpenJDK8 

 tab.

For this week, the jobs we are not yet expecting to be green have been paused 
blue until related PRs are approved.  For example, UnitTestOpenJDK11 and 
WindowsUnitTestOpenJDK11 will turn green as soon as PR 2591 
 is merged.

Looking ahead to next week, if we need to hide all OpenJDK11 jobs, then do we 
unhide each one as it gets fixed?  Or wait for 100% green and then unhide them 
all at once?  Either way that’s a lot of PRs just for hiding and un-hiding. 

Even better, feel free to help get to green by picking up a subtask of GEODE-3 
. 

-Owen

> On Oct 10, 2018, at 2:16 PM, Alexander Murmann  wrote:
> 
> +1 to keeping them off the main tab.
> 
> Having red jobs that aren't actionable will train us to ignore red jobs.
> 
> On Wed, Oct 10, 2018 at 2:13 PM Dan Smith  wrote:
> 
>> I feel like it would be better to keep the Java 11 jobs off of the main tab
>> in the pipeline until they are actually working. In the spirit of keeping
>> develop releasable, we should keep the main pipeline clean and only include
>> what is releasable today in the pipeline.
>> 
>> Thoughts?
>> -Dan
>>

Re: Running compatibility and upgrade tests using jdk9+

2018-10-11 Thread Owen Nichols 
Here’s the potential test matrix:

Geode 1.7 on Java 8  <—>  Geode 1.7 on Java 8: already extensively tested
Geode 1.8 on Java 8  <—>  Geode 1.7 on Java 8: already in 
backward-compatibility test plan
Geode 1.7 on Java 11  <—>  Geode 1.7 on Java 8: UNSUPPORTED1
Geode 1.8 on Java 11  <—>  Geode 1.7 on Java 8: UNSUPPORTED2
Geode 1.8 on Java 8  <—>  Geode 1.8 on Java 8: already extensively tested
Geode 1.7 on Java 11  <—>  Geode 1.8 on Java 8: UNSUPPORTED1
Geode 1.8 on Java 11  <—>  Geode 1.8 on Java 8: need to add additional tests 
for this
Geode 1.7 on Java 11  <—>  Geode 1.7 on Java 11: UNSUPPORTED1
Geode 1.8 on Java 11  <—>  Geode 1.7 on Java 11: UNSUPPORTED1
Geode 1.8 on Java 11  <—>  Geode 1.8 on Java 11: already extensively tested

1=Versions of Geode prior to 1.8 can’t run on Java 11.
2=ALL members of existing geode clusters MUST be rolled to Geode 1.8 before ANY 
members are rolled to Java 11.

We will need to do whatever it takes to make Geode 1.8 able to talk to other 
Geode 1.8 members even when one is running Java 8 and one is running Java 11.  
If we are unable to achieve that, then we cannot bring Java 11 support until 
Geode 2.0.

-Owen
 
> On Oct 11, 2018, at 10:26 AM, Galen O'Sullivan  wrote:
> 
> I think we should run some sort of backwards-compatibility tests between
> Java 8 and Java 9/11+. We need testing of Geode (both old and current
> versions) on older JVMs talking to Geode on newer JVMs. (for example, what
> if Java built-in serialization changes in a way that breaks our code
> somehow?)
> 
> On Mon, Oct 8, 2018 at 2:50 PM Jinmei Liao  wrote:
> 
>> On Mon, Oct 8, 2018 at 2:45 PM Udo Kohlmeyer  wrote:
>> 
>>> Should this not rather be a statement of.. "Running on JDK 11+" and not
>>> 9+? Given that 9 + 10 are not in support anymore.
>>> Also, when this is released, we will running on 11 rather than 9, or
>>> what is the thought (end goal) with this effort?
>>> 
>> Yes, let's for the sake of discussion, assuming jdk9+ here means jdk11+.
>> 
>> 
>>> 
>>> Also does this effort cover some of the main additions to the JDK since
>>> 9, which is the whole modularity theme?
>>> 
>> Not yet. We are just trying to get a green pipeline to start with.
>> 
>> 
>>> 
>>> --Udo
>>> 
>>> On 10/8/18 14:11, Jinmei Liao wrote:
 In the effort of making GEODE java 9+ compatible, we already determined
 that older released versions of GEODE can NOT be run using jdk9+. With
>>> this
 in mind, should we still run those compatibility/upgrade DUnit tests in
 java9+ pipeline? The current state of things are:
 
 1) A subset of compatibility/upgrade DUnit tests are successful in
>> java9+
 are passing because the dunit test environment happen to have the
>> missing
 jars in the classpath.  With the exclusion of Geode 1.4 in those test,
>> we
 can make all of them pass. (Just FYI, only Geode1.4 is failing in jdk9+
>>> is
 because we introduced SerializationFilter in 1.4, but the support for
>> in
 jdk9 was added only in 1.5).
 2. We will have parallel pipelines testing with both jdk8 and jdk9+. So
 even if we don't run these tests in jdk9+ pipeline, we are still
>> running
 them in jdk8.
 
 The question to ask is: does running compatibility/upgrade tests in
>> jdk9
>>> in
 addition to jdk8 offer additional value?
 
>>> 
>>> 
>> 
>> --
>> Cheers
>> 
>> Jinmei
>>

Re: Running compatibility and upgrade tests using jdk9+

2018-10-11 Thread Dan Smith 
At the current moment I don't think it makes sense to run old versions with
anything but JDK 8, since they didn't support JDK 9+ or anything like that.

Going forward though it seems like we should start running the backwards
compatibility tests between versions that do support JDK 9+, once we have
more than one of those. Could we just skip testing versions *less* than
whenever we start supporting JDK 9+? For the first release, that would mean
no compatibility testing but after that we would start doing it.

The test suite Galen is talking about seems nice, although I'm not sure if
we need to be testing the JDK's serialization guarantees. Changing the JDK
should not break compatibility of Java serialization.

Patrick - the case you mentioned is not serialization. That's an
incompatibility in compiled code, not in serialized data.

-Dan
On Thu, Oct 11, 2018 at 12:49 PM Patrick Rhomberg 
wrote:

> > We need testing of Geode (both old and current versions) on older JVMs
> talking to Geode on newer JVMs.
>
> It would be nice to support this, but I'm not sure we should.  We support
> rolling upgrades between versions of Geode, but I'm not convinced we should
> support JDK mismatch within a live cluster.
>
> > what if Java built-in serialization changes in a way that breaks our code
> somehow?
>
> I just submitted a PR addressing the fact that this definitely happens.
> `java.io.Serialization` will just flat-out refuse to deserialize a class
> when running in Version X if it was compiled in Version >X.
>
> See GEODE-5850 / "exception java.lang.UnsupportedClassVersionError:
>  has been compiled by a more recent version of the Java Runtime
> (class file version 55.0), this version of the Java Runtime only recognizes
> class file versions up to 52.0."
>
> On Thu, Oct 11, 2018 at 10:26 AM, Galen O'Sullivan 
> wrote:
>
> > I think we should run some sort of backwards-compatibility tests between
> > Java 8 and Java 9/11+. We need testing of Geode (both old and current
> > versions) on older JVMs talking to Geode on newer JVMs. (for example,
> what
> > if Java built-in serialization changes in a way that breaks our code
> > somehow?)
> >
> > On Mon, Oct 8, 2018 at 2:50 PM Jinmei Liao  wrote:
> >
> > > On Mon, Oct 8, 2018 at 2:45 PM Udo Kohlmeyer  wrote:
> > >
> > > > Should this not rather be a statement of.. "Running on JDK 11+" and
> not
> > > > 9+? Given that 9 + 10 are not in support anymore.
> > > > Also, when this is released, we will running on 11 rather than 9, or
> > > > what is the thought (end goal) with this effort?
> > > >
> > > Yes, let's for the sake of discussion, assuming jdk9+ here means
> jdk11+.
> > >
> > >
> > > >
> > > > Also does this effort cover some of the main additions to the JDK
> since
> > > > 9, which is the whole modularity theme?
> > > >
> > > Not yet. We are just trying to get a green pipeline to start with.
> > >
> > >
> > > >
> > > > --Udo
> > > >
> > > > On 10/8/18 14:11, Jinmei Liao wrote:
> > > > > In the effort of making GEODE java 9+ compatible, we already
> > determined
> > > > > that older released versions of GEODE can NOT be run using jdk9+.
> > With
> > > > this
> > > > > in mind, should we still run those compatibility/upgrade DUnit
> tests
> > in
> > > > > java9+ pipeline? The current state of things are:
> > > > >
> > > > > 1) A subset of compatibility/upgrade DUnit tests are successful in
> > > java9+
> > > > > are passing because the dunit test environment happen to have the
> > > missing
> > > > > jars in the classpath.  With the exclusion of Geode 1.4 in those
> > test,
> > > we
> > > > > can make all of them pass. (Just FYI, only Geode1.4 is failing in
> > jdk9+
> > > > is
> > > > > because we introduced SerializationFilter in 1.4, but the support
> for
> > > in
> > > > > jdk9 was added only in 1.5).
> > > > > 2. We will have parallel pipelines testing with both jdk8 and
> jdk9+.
> > So
> > > > > even if we don't run these tests in jdk9+ pipeline, we are still
> > > running
> > > > > them in jdk8.
> > > > >
> > > > > The question to ask is: does running compatibility/upgrade tests in
> > > jdk9
> > > > in
> > > > > addition to jdk8 offer additional value?
> > > > >
> > > >
> > > >
> > >
> > > --
> > > Cheers
> > >
> > > Jinmei
> > >
> >
>

Re: Running compatibility and upgrade tests using jdk9+

2018-10-11 Thread Anthony Baker 



> On Oct 11, 2018, at 12:49 PM, Patrick Rhomberg  wrote:
> 
>> We need testing of Geode (both old and current versions) on older JVMs
> talking to Geode on newer JVMs.
> 
> It would be nice to support this, but I'm not sure we should.  We support
> rolling upgrades between versions of Geode, but I'm not convinced we should
> support JDK mismatch within a live cluster.

There is a long list of capabilities built into Geode that work together to 
provide 24x7x365 operation with zero downtime *ever*.  This is why we carefully 
test backwards compatibility across various dimensions and ensure that users 
can do rolling upgrades from version to version.

If we throw away support for rolling JDK versions (which we’ve always 
supported) then we leave our users with a difficult decision:  schedule an 
outage, fail-over to a secondary cluster, or stay on jdk 8 forever.

Is there a technical reason preventing us from supporting rolling JDK upgrades? 
 If so, can we find a way to work around this?


Anthony

Re: Running compatibility and upgrade tests using jdk9+

2018-10-11 Thread Patrick Rhomberg 
> We need testing of Geode (both old and current versions) on older JVMs
talking to Geode on newer JVMs.

It would be nice to support this, but I'm not sure we should.  We support
rolling upgrades between versions of Geode, but I'm not convinced we should
support JDK mismatch within a live cluster.

> what if Java built-in serialization changes in a way that breaks our code
somehow?

I just submitted a PR addressing the fact that this definitely happens.
`java.io.Serialization` will just flat-out refuse to deserialize a class
when running in Version X if it was compiled in Version >X.

See GEODE-5850 / "exception java.lang.UnsupportedClassVersionError:
 has been compiled by a more recent version of the Java Runtime
(class file version 55.0), this version of the Java Runtime only recognizes
class file versions up to 52.0."

On Thu, Oct 11, 2018 at 10:26 AM, Galen O'Sullivan 
wrote:

> I think we should run some sort of backwards-compatibility tests between
> Java 8 and Java 9/11+. We need testing of Geode (both old and current
> versions) on older JVMs talking to Geode on newer JVMs. (for example, what
> if Java built-in serialization changes in a way that breaks our code
> somehow?)
>
> On Mon, Oct 8, 2018 at 2:50 PM Jinmei Liao  wrote:
>
> > On Mon, Oct 8, 2018 at 2:45 PM Udo Kohlmeyer  wrote:
> >
> > > Should this not rather be a statement of.. "Running on JDK 11+" and not
> > > 9+? Given that 9 + 10 are not in support anymore.
> > > Also, when this is released, we will running on 11 rather than 9, or
> > > what is the thought (end goal) with this effort?
> > >
> > Yes, let's for the sake of discussion, assuming jdk9+ here means jdk11+.
> >
> >
> > >
> > > Also does this effort cover some of the main additions to the JDK since
> > > 9, which is the whole modularity theme?
> > >
> > Not yet. We are just trying to get a green pipeline to start with.
> >
> >
> > >
> > > --Udo
> > >
> > > On 10/8/18 14:11, Jinmei Liao wrote:
> > > > In the effort of making GEODE java 9+ compatible, we already
> determined
> > > > that older released versions of GEODE can NOT be run using jdk9+.
> With
> > > this
> > > > in mind, should we still run those compatibility/upgrade DUnit tests
> in
> > > > java9+ pipeline? The current state of things are:
> > > >
> > > > 1) A subset of compatibility/upgrade DUnit tests are successful in
> > java9+
> > > > are passing because the dunit test environment happen to have the
> > missing
> > > > jars in the classpath.  With the exclusion of Geode 1.4 in those
> test,
> > we
> > > > can make all of them pass. (Just FYI, only Geode1.4 is failing in
> jdk9+
> > > is
> > > > because we introduced SerializationFilter in 1.4, but the support for
> > in
> > > > jdk9 was added only in 1.5).
> > > > 2. We will have parallel pipelines testing with both jdk8 and jdk9+.
> So
> > > > even if we don't run these tests in jdk9+ pipeline, we are still
> > running
> > > > them in jdk8.
> > > >
> > > > The question to ask is: does running compatibility/upgrade tests in
> > jdk9
> > > in
> > > > addition to jdk8 offer additional value?
> > > >
> > >
> > >
> >
> > --
> > Cheers
> >
> > Jinmei
> >
>

Re: [Discuss] showcasing community work

2018-10-11 Thread John Blum 
This is a very nice idea Sai.

Perhaps a page with a table containing...

* Project Name
* Project Description (Summary)
* Project License
* Project URL (to GitHub page, Website, etc, where users can find out more
information)

Food for thought.


On Thu, Oct 11, 2018 at 12:04 PM, Sai Boorlagadda  wrote:

> I would like to discuss what's best to capture all the community work in
> one place. There are some good plugins/extensions that are built by the
> community which does not necessarily be merged into the mainstream but
> would be a great value for others in the community. Capturing all these at
> one place would a great help for someone looking for a solution.
>
> Also, I would like to capture (if any) requirements (Eg: licenses etc) that
> these developers need to adhere to showcase their work. Are there any
> Apache guidelines for such work?
>
> There are many ways to do this. if everyone agrees about the idea of
> capturing all at one place then I propose we add a page/section capturing
> both the requirements and a table of references URLs to those open-source
> work. That way it easy for someone to update the page and create a PR for
> the website.
>
> Sai
>



-- 
-John
john.blum10101 (skype)

[Discuss] showcasing community work

2018-10-11 Thread Sai Boorlagadda 
I would like to discuss what's best to capture all the community work in
one place. There are some good plugins/extensions that are built by the
community which does not necessarily be merged into the mainstream but
would be a great value for others in the community. Capturing all these at
one place would a great help for someone looking for a solution.

Also, I would like to capture (if any) requirements (Eg: licenses etc) that
these developers need to adhere to showcase their work. Are there any
Apache guidelines for such work?

There are many ways to do this. if everyone agrees about the idea of
capturing all at one place then I propose we add a page/section capturing
both the requirements and a table of references URLs to those open-source
work. That way it easy for someone to update the page and create a PR for
the website.

Sai

Re: proposing reduced default for "membership-port-range"

2018-10-11 Thread Brian Rowe 
It should be, but I don't believe it can be.  Some of the places that we
pass the membership range to are third party.

On Thu, Oct 11, 2018 at 11:54 AM, Helena Bales  wrote:

> Could and should the port selecting logic be pulled out into one common
> implementation used throughout the code base? It seems like having a common
> implementation of this would make it a lot easier to solve this type of
> problem in the future.
>
> On Thu, Oct 11, 2018 at 11:27 AM Brian Rowe  wrote:
>
> > Galen, this was actually my first instinct.  Unfortunately this range is
> > passed into numerous places such as JGroups and BeanUtils, all of which
> > implement their own port selecting logic.
> >
> > On Thu, Oct 11, 2018 at 10:35 AM, Galen O'Sullivan <
> gosulli...@pivotal.io>
> > wrote:
> >
> > > Would it be feasible to reserve chosen ports before selecting ephemeral
> > > ports? I think this would resolve the collision issue described above.
> > >
> > > On Thu, Oct 11, 2018 at 9:58 AM Brian Rowe  wrote:
> > >
> > > > I agree that we should have defaulted everything to using ephemeral
> > ports
> > > > and forced clients to explicitly assign ports and membership ranges
> if
> > > > needed (any of the reasons Anthony mentioned above).  However, I
> don't
> > > > think we can change the default assigned ports at this point, unless
> we
> > > > want to try to go through the effort of verifying that no customers
> are
> > > > relying on the default assignments (is that even something we can do
> > with
> > > > any confidence?).  The membership port range default, however, is
> > > something
> > > > we should be able to change, so long as we restrict it to a proper
> > subset
> > > > of the current default.  I think the best we can do right now is just
> > to
> > > > make it so the default membership port range doesn't conflict with
> the
> > > > default assigned ports.
> > > >
> > > > On Fri, Oct 5, 2018 at 3:42 PM, Jacob Barrett 
> > > wrote:
> > > >
> > > > > So in the Dockerfile you explicitly set the server to start on port
> > > > 40404,
> > > > > problem solved. In whatever environment where you need it on a
> > specific
> > > > > port you then assign that port. But for all the other cases where
> we
> > > > don’t
> > > > > need to know it, like most of the time, it should just pick
> something
> > > > > ephemeral and work.
> > > > >
> > > > >
> > > > > > On Oct 5, 2018, at 1:57 PM, Anthony Baker 
> > wrote:
> > > > > >
> > > > > > I think there are a lot of dependencies when deploying geode that
> > > rely
> > > > > on well-known ports and port ranges (e.g. exporting ports from a
> > > > container,
> > > > > firewall rules, etc).  Changing the default server port from 40404
> to
> > > ??
> > > > > would break stuff.
> > > > > >
> > > > > > Here’s the rule from our own Dockerfile:
> > > > > >
> > > > > > # Default ports:
> > > > > > # RMI/JMX 1099
> > > > > > # REST 8080
> > > > > > # PULE 7070
> > > > > > # LOCATOR 10334
> > > > > > # CACHESERVER 40404
> > > > > > EXPOSE  8080 10334 40404 1099 7070
> > > > > >
> > > > > > Anthony
> > > > > >
> > > > > >
> > > > > >> On Oct 5, 2018, at 1:45 PM, Jacob Barrett 
> > > > wrote:
> > > > > >>
> > > > > >> But if all ports where ephemeral by default then no collisions
> > > right?
> > > > > Why have any port have a default to a single fixed value or
> > overlapping
> > > > > range of values. Since our opinionated use case is for clients to
> > > connect
> > > > > via locators then a known server port isn’t important.
> > > > > >>
> > > > > >>> On Oct 5, 2018, at 10:55 AM, Dan Smith 
> > wrote:
> > > > > >>>
> > > > > >>> The problem is that the membership port is picked *first*. So
> it
> > > may
> > > > > pick
> > > > > >>> 40404. Then, when the cache server tries to use port 40404, it
> > > gets a
> > > > > >>> collision.
> > > > > >>>
> > > > > >>> -Dan
> > > > > >>>
> > > > >  On Fri, Oct 5, 2018 at 10:52 AM Jacob Barrett <
> > > jbarr...@pivotal.io>
> > > > > wrote:
> > > > > 
> > > > >  If we just default to 0 then the OS will pick is a port in
> > > whatever
> > > > > range
> > > > >  is ephemeral and free. We don’t have to do any work. No need
> to
> > > > > define a
> > > > >  range and seek an open port.
> > > > > 
> > > > > >> On Oct 5, 2018, at 10:40 AM, Dan Smith 
> > > wrote:
> > > > > >>
> > > > > >> On Fri, Oct 5, 2018 at 10:31 AM Jacob Barrett <
> > > > jbarr...@pivotal.io>
> > > > >  wrote:
> > > > > >>
> > > > > >> Why not change the default behavior to that of port 0,
> letting
> > > the
> > > > > OS
> > > > > >> select an open ephemeral port if the user doesn’t specify a
> > > > specific
> > > > >  port?
> > > > > >>
> > > > > >
> > > > > > I think what we'd really like to do is change the cache
> server
> > > port
> > > > > to
> > > > > > something other than 40404. Maybe 0 (pick a port), or maybe
> > > > something
> > > > >  less
> > > > > > than 32K.
> > > > > >
> > > > >

Re: proposing reduced default for "membership-port-range"

2018-10-11 Thread Helena Bales 
Could and should the port selecting logic be pulled out into one common
implementation used throughout the code base? It seems like having a common
implementation of this would make it a lot easier to solve this type of
problem in the future.

On Thu, Oct 11, 2018 at 11:27 AM Brian Rowe  wrote:

> Galen, this was actually my first instinct.  Unfortunately this range is
> passed into numerous places such as JGroups and BeanUtils, all of which
> implement their own port selecting logic.
>
> On Thu, Oct 11, 2018 at 10:35 AM, Galen O'Sullivan 
> wrote:
>
> > Would it be feasible to reserve chosen ports before selecting ephemeral
> > ports? I think this would resolve the collision issue described above.
> >
> > On Thu, Oct 11, 2018 at 9:58 AM Brian Rowe  wrote:
> >
> > > I agree that we should have defaulted everything to using ephemeral
> ports
> > > and forced clients to explicitly assign ports and membership ranges if
> > > needed (any of the reasons Anthony mentioned above).  However, I don't
> > > think we can change the default assigned ports at this point, unless we
> > > want to try to go through the effort of verifying that no customers are
> > > relying on the default assignments (is that even something we can do
> with
> > > any confidence?).  The membership port range default, however, is
> > something
> > > we should be able to change, so long as we restrict it to a proper
> subset
> > > of the current default.  I think the best we can do right now is just
> to
> > > make it so the default membership port range doesn't conflict with the
> > > default assigned ports.
> > >
> > > On Fri, Oct 5, 2018 at 3:42 PM, Jacob Barrett 
> > wrote:
> > >
> > > > So in the Dockerfile you explicitly set the server to start on port
> > > 40404,
> > > > problem solved. In whatever environment where you need it on a
> specific
> > > > port you then assign that port. But for all the other cases where we
> > > don’t
> > > > need to know it, like most of the time, it should just pick something
> > > > ephemeral and work.
> > > >
> > > >
> > > > > On Oct 5, 2018, at 1:57 PM, Anthony Baker 
> wrote:
> > > > >
> > > > > I think there are a lot of dependencies when deploying geode that
> > rely
> > > > on well-known ports and port ranges (e.g. exporting ports from a
> > > container,
> > > > firewall rules, etc).  Changing the default server port from 40404 to
> > ??
> > > > would break stuff.
> > > > >
> > > > > Here’s the rule from our own Dockerfile:
> > > > >
> > > > > # Default ports:
> > > > > # RMI/JMX 1099
> > > > > # REST 8080
> > > > > # PULE 7070
> > > > > # LOCATOR 10334
> > > > > # CACHESERVER 40404
> > > > > EXPOSE  8080 10334 40404 1099 7070
> > > > >
> > > > > Anthony
> > > > >
> > > > >
> > > > >> On Oct 5, 2018, at 1:45 PM, Jacob Barrett 
> > > wrote:
> > > > >>
> > > > >> But if all ports where ephemeral by default then no collisions
> > right?
> > > > Why have any port have a default to a single fixed value or
> overlapping
> > > > range of values. Since our opinionated use case is for clients to
> > connect
> > > > via locators then a known server port isn’t important.
> > > > >>
> > > > >>> On Oct 5, 2018, at 10:55 AM, Dan Smith 
> wrote:
> > > > >>>
> > > > >>> The problem is that the membership port is picked *first*. So it
> > may
> > > > pick
> > > > >>> 40404. Then, when the cache server tries to use port 40404, it
> > gets a
> > > > >>> collision.
> > > > >>>
> > > > >>> -Dan
> > > > >>>
> > > >  On Fri, Oct 5, 2018 at 10:52 AM Jacob Barrett <
> > jbarr...@pivotal.io>
> > > > wrote:
> > > > 
> > > >  If we just default to 0 then the OS will pick is a port in
> > whatever
> > > > range
> > > >  is ephemeral and free. We don’t have to do any work. No need to
> > > > define a
> > > >  range and seek an open port.
> > > > 
> > > > >> On Oct 5, 2018, at 10:40 AM, Dan Smith 
> > wrote:
> > > > >>
> > > > >> On Fri, Oct 5, 2018 at 10:31 AM Jacob Barrett <
> > > jbarr...@pivotal.io>
> > > >  wrote:
> > > > >>
> > > > >> Why not change the default behavior to that of port 0, letting
> > the
> > > > OS
> > > > >> select an open ephemeral port if the user doesn’t specify a
> > > specific
> > > >  port?
> > > > >>
> > > > >
> > > > > I think what we'd really like to do is change the cache server
> > port
> > > > to
> > > > > something other than 40404. Maybe 0 (pick a port), or maybe
> > > something
> > > >  less
> > > > > than 32K.
> > > > >
> > > > > Unfortunately, on most linux distributions the ephemeral port
> > range
> > > > is
> > > >  32K
> > > > > -> 61K, which includes 40404, which I think is why Brian is
> > > > proposing a
> > > > > subset of that range.
> > > > >
> > > > > -Dan
> > > > 
> > > > >
> > > >
> > >
> >
>

Re: Release process for Apache Geode wiki

2018-10-11 Thread Anthony Baker 
I like it!  There’s some overlap with the prior ‘Release Steps’ page, which was 
getting a bit unwieldy anyway.  Perhaps we can review and consolidate/split up 
sections later.

Anthony


> On Oct 11, 2018, at 10:31 AM, Nabarun Nag  wrote:
> 
> @Dave sure, any contribution to improving the article is highly appreciated.
> 
> @Sai  Thanks for your feedback, I have included the software dependencies
> as the first paragraph of the article.
> 
> Regards
> Nabarun
> 
> On Thu, Oct 11, 2018 at 10:21 AM Dave Barnes  wrote:
> 
>> Good work! I had no idea there was so much involved with regard to Apach
>> permissions and such.
>> I fixed a few typos / rewordings. Very minor.
>> There's one thing I wanted to ask you about: The sample paragraph under
>> release doc preparation is one long line. Would it be OK to reformat so it
>> wraps?
>> 
>> 
>> On Wed, Oct 10, 2018 at 7:01 PM Nabarun Nag  wrote:
>> 
>>> Hi,
>>> 
>>> I have created a new wiki page on how to release Apache Geode.
>>> Please do a review and let me know if there are any suggestions or
>>> modifications required.
>>> 
>>> https://cwiki.apache.org/confluence/display/GEODE/Releasing+Apache+Geode
>>> 
>>> Regard
>>> Nabarun Nag
>>> 
>>

Re: Concourse upgrade

2018-10-11 Thread Sean Goller 
This should be resolved at this point. If anyone sees any weirdness now,
please inform the list.

On Wed, Oct 10, 2018 at 1:03 PM Bruce Schuchardt 
wrote:

> Concourse runs have started to fail
>
> ERROR: JAVA_HOME is set to an invalid directory:
> /usr/lib/jvm/java--openjdk-amd64
> Please set the JAVA_HOME variable in your environment to match the
> location of your Java installation.
>
>
> On 10/10/18 11:03 AM, Sean Goller wrote:
> > We're going to be upgrading the concourse infrastructure to the latest
> > version today, since 1.7 has been released. Best case it will be fairly
> > seamless and everything will be unicorns and puppies and happiness. Worst
> > case it'll be messed up for a few days.
> >
> > -Sean.
> >
>
>

Re: proposing reduced default for "membership-port-range"

2018-10-11 Thread Brian Rowe 
Galen, this was actually my first instinct.  Unfortunately this range is
passed into numerous places such as JGroups and BeanUtils, all of which
implement their own port selecting logic.

On Thu, Oct 11, 2018 at 10:35 AM, Galen O'Sullivan 
wrote:

> Would it be feasible to reserve chosen ports before selecting ephemeral
> ports? I think this would resolve the collision issue described above.
>
> On Thu, Oct 11, 2018 at 9:58 AM Brian Rowe  wrote:
>
> > I agree that we should have defaulted everything to using ephemeral ports
> > and forced clients to explicitly assign ports and membership ranges if
> > needed (any of the reasons Anthony mentioned above).  However, I don't
> > think we can change the default assigned ports at this point, unless we
> > want to try to go through the effort of verifying that no customers are
> > relying on the default assignments (is that even something we can do with
> > any confidence?).  The membership port range default, however, is
> something
> > we should be able to change, so long as we restrict it to a proper subset
> > of the current default.  I think the best we can do right now is just to
> > make it so the default membership port range doesn't conflict with the
> > default assigned ports.
> >
> > On Fri, Oct 5, 2018 at 3:42 PM, Jacob Barrett 
> wrote:
> >
> > > So in the Dockerfile you explicitly set the server to start on port
> > 40404,
> > > problem solved. In whatever environment where you need it on a specific
> > > port you then assign that port. But for all the other cases where we
> > don’t
> > > need to know it, like most of the time, it should just pick something
> > > ephemeral and work.
> > >
> > >
> > > > On Oct 5, 2018, at 1:57 PM, Anthony Baker  wrote:
> > > >
> > > > I think there are a lot of dependencies when deploying geode that
> rely
> > > on well-known ports and port ranges (e.g. exporting ports from a
> > container,
> > > firewall rules, etc).  Changing the default server port from 40404 to
> ??
> > > would break stuff.
> > > >
> > > > Here’s the rule from our own Dockerfile:
> > > >
> > > > # Default ports:
> > > > # RMI/JMX 1099
> > > > # REST 8080
> > > > # PULE 7070
> > > > # LOCATOR 10334
> > > > # CACHESERVER 40404
> > > > EXPOSE  8080 10334 40404 1099 7070
> > > >
> > > > Anthony
> > > >
> > > >
> > > >> On Oct 5, 2018, at 1:45 PM, Jacob Barrett 
> > wrote:
> > > >>
> > > >> But if all ports where ephemeral by default then no collisions
> right?
> > > Why have any port have a default to a single fixed value or overlapping
> > > range of values. Since our opinionated use case is for clients to
> connect
> > > via locators then a known server port isn’t important.
> > > >>
> > > >>> On Oct 5, 2018, at 10:55 AM, Dan Smith  wrote:
> > > >>>
> > > >>> The problem is that the membership port is picked *first*. So it
> may
> > > pick
> > > >>> 40404. Then, when the cache server tries to use port 40404, it
> gets a
> > > >>> collision.
> > > >>>
> > > >>> -Dan
> > > >>>
> > >  On Fri, Oct 5, 2018 at 10:52 AM Jacob Barrett <
> jbarr...@pivotal.io>
> > > wrote:
> > > 
> > >  If we just default to 0 then the OS will pick is a port in
> whatever
> > > range
> > >  is ephemeral and free. We don’t have to do any work. No need to
> > > define a
> > >  range and seek an open port.
> > > 
> > > >> On Oct 5, 2018, at 10:40 AM, Dan Smith 
> wrote:
> > > >>
> > > >> On Fri, Oct 5, 2018 at 10:31 AM Jacob Barrett <
> > jbarr...@pivotal.io>
> > >  wrote:
> > > >>
> > > >> Why not change the default behavior to that of port 0, letting
> the
> > > OS
> > > >> select an open ephemeral port if the user doesn’t specify a
> > specific
> > >  port?
> > > >>
> > > >
> > > > I think what we'd really like to do is change the cache server
> port
> > > to
> > > > something other than 40404. Maybe 0 (pick a port), or maybe
> > something
> > >  less
> > > > than 32K.
> > > >
> > > > Unfortunately, on most linux distributions the ephemeral port
> range
> > > is
> > >  32K
> > > > -> 61K, which includes 40404, which I think is why Brian is
> > > proposing a
> > > > subset of that range.
> > > >
> > > > -Dan
> > > 
> > > >
> > >
> >
>

Re: proposing reduced default for "membership-port-range"

2018-10-11 Thread Galen O'Sullivan 
Would it be feasible to reserve chosen ports before selecting ephemeral
ports? I think this would resolve the collision issue described above.

On Thu, Oct 11, 2018 at 9:58 AM Brian Rowe  wrote:

> I agree that we should have defaulted everything to using ephemeral ports
> and forced clients to explicitly assign ports and membership ranges if
> needed (any of the reasons Anthony mentioned above).  However, I don't
> think we can change the default assigned ports at this point, unless we
> want to try to go through the effort of verifying that no customers are
> relying on the default assignments (is that even something we can do with
> any confidence?).  The membership port range default, however, is something
> we should be able to change, so long as we restrict it to a proper subset
> of the current default.  I think the best we can do right now is just to
> make it so the default membership port range doesn't conflict with the
> default assigned ports.
>
> On Fri, Oct 5, 2018 at 3:42 PM, Jacob Barrett  wrote:
>
> > So in the Dockerfile you explicitly set the server to start on port
> 40404,
> > problem solved. In whatever environment where you need it on a specific
> > port you then assign that port. But for all the other cases where we
> don’t
> > need to know it, like most of the time, it should just pick something
> > ephemeral and work.
> >
> >
> > > On Oct 5, 2018, at 1:57 PM, Anthony Baker  wrote:
> > >
> > > I think there are a lot of dependencies when deploying geode that rely
> > on well-known ports and port ranges (e.g. exporting ports from a
> container,
> > firewall rules, etc).  Changing the default server port from 40404 to ??
> > would break stuff.
> > >
> > > Here’s the rule from our own Dockerfile:
> > >
> > > # Default ports:
> > > # RMI/JMX 1099
> > > # REST 8080
> > > # PULE 7070
> > > # LOCATOR 10334
> > > # CACHESERVER 40404
> > > EXPOSE  8080 10334 40404 1099 7070
> > >
> > > Anthony
> > >
> > >
> > >> On Oct 5, 2018, at 1:45 PM, Jacob Barrett 
> wrote:
> > >>
> > >> But if all ports where ephemeral by default then no collisions right?
> > Why have any port have a default to a single fixed value or overlapping
> > range of values. Since our opinionated use case is for clients to connect
> > via locators then a known server port isn’t important.
> > >>
> > >>> On Oct 5, 2018, at 10:55 AM, Dan Smith  wrote:
> > >>>
> > >>> The problem is that the membership port is picked *first*. So it may
> > pick
> > >>> 40404. Then, when the cache server tries to use port 40404, it gets a
> > >>> collision.
> > >>>
> > >>> -Dan
> > >>>
> >  On Fri, Oct 5, 2018 at 10:52 AM Jacob Barrett 
> > wrote:
> > 
> >  If we just default to 0 then the OS will pick is a port in whatever
> > range
> >  is ephemeral and free. We don’t have to do any work. No need to
> > define a
> >  range and seek an open port.
> > 
> > >> On Oct 5, 2018, at 10:40 AM, Dan Smith  wrote:
> > >>
> > >> On Fri, Oct 5, 2018 at 10:31 AM Jacob Barrett <
> jbarr...@pivotal.io>
> >  wrote:
> > >>
> > >> Why not change the default behavior to that of port 0, letting the
> > OS
> > >> select an open ephemeral port if the user doesn’t specify a
> specific
> >  port?
> > >>
> > >
> > > I think what we'd really like to do is change the cache server port
> > to
> > > something other than 40404. Maybe 0 (pick a port), or maybe
> something
> >  less
> > > than 32K.
> > >
> > > Unfortunately, on most linux distributions the ephemeral port range
> > is
> >  32K
> > > -> 61K, which includes 40404, which I think is why Brian is
> > proposing a
> > > subset of that range.
> > >
> > > -Dan
> > 
> > >
> >
>

Re: Release process for Apache Geode wiki

2018-10-11 Thread Nabarun Nag 
@Dave sure, any contribution to improving the article is highly appreciated.

@Sai  Thanks for your feedback, I have included the software dependencies
as the first paragraph of the article.

Regards
Nabarun

On Thu, Oct 11, 2018 at 10:21 AM Dave Barnes  wrote:

> Good work! I had no idea there was so much involved with regard to Apach
> permissions and such.
> I fixed a few typos / rewordings. Very minor.
> There's one thing I wanted to ask you about: The sample paragraph under
> release doc preparation is one long line. Would it be OK to reformat so it
> wraps?
>
>
> On Wed, Oct 10, 2018 at 7:01 PM Nabarun Nag  wrote:
>
> > Hi,
> >
> > I have created a new wiki page on how to release Apache Geode.
> > Please do a review and let me know if there are any suggestions or
> > modifications required.
> >
> > https://cwiki.apache.org/confluence/display/GEODE/Releasing+Apache+Geode
> >
> > Regard
> > Nabarun Nag
> >
>

Re: Running compatibility and upgrade tests using jdk9+

2018-10-11 Thread Galen O'Sullivan 
I think we should run some sort of backwards-compatibility tests between
Java 8 and Java 9/11+. We need testing of Geode (both old and current
versions) on older JVMs talking to Geode on newer JVMs. (for example, what
if Java built-in serialization changes in a way that breaks our code
somehow?)

On Mon, Oct 8, 2018 at 2:50 PM Jinmei Liao  wrote:

> On Mon, Oct 8, 2018 at 2:45 PM Udo Kohlmeyer  wrote:
>
> > Should this not rather be a statement of.. "Running on JDK 11+" and not
> > 9+? Given that 9 + 10 are not in support anymore.
> > Also, when this is released, we will running on 11 rather than 9, or
> > what is the thought (end goal) with this effort?
> >
> Yes, let's for the sake of discussion, assuming jdk9+ here means jdk11+.
>
>
> >
> > Also does this effort cover some of the main additions to the JDK since
> > 9, which is the whole modularity theme?
> >
> Not yet. We are just trying to get a green pipeline to start with.
>
>
> >
> > --Udo
> >
> > On 10/8/18 14:11, Jinmei Liao wrote:
> > > In the effort of making GEODE java 9+ compatible, we already determined
> > > that older released versions of GEODE can NOT be run using jdk9+. With
> > this
> > > in mind, should we still run those compatibility/upgrade DUnit tests in
> > > java9+ pipeline? The current state of things are:
> > >
> > > 1) A subset of compatibility/upgrade DUnit tests are successful in
> java9+
> > > are passing because the dunit test environment happen to have the
> missing
> > > jars in the classpath.  With the exclusion of Geode 1.4 in those test,
> we
> > > can make all of them pass. (Just FYI, only Geode1.4 is failing in jdk9+
> > is
> > > because we introduced SerializationFilter in 1.4, but the support for
> in
> > > jdk9 was added only in 1.5).
> > > 2. We will have parallel pipelines testing with both jdk8 and jdk9+. So
> > > even if we don't run these tests in jdk9+ pipeline, we are still
> running
> > > them in jdk8.
> > >
> > > The question to ask is: does running compatibility/upgrade tests in
> jdk9
> > in
> > > addition to jdk8 offer additional value?
> > >
> >
> >
>
> --
> Cheers
>
> Jinmei
>

Re: Release process for Apache Geode wiki

2018-10-11 Thread Dave Barnes 
Good work! I had no idea there was so much involved with regard to Apach
permissions and such.
I fixed a few typos / rewordings. Very minor.
There's one thing I wanted to ask you about: The sample paragraph under
release doc preparation is one long line. Would it be OK to reformat so it
wraps?


On Wed, Oct 10, 2018 at 7:01 PM Nabarun Nag  wrote:

> Hi,
>
> I have created a new wiki page on how to release Apache Geode.
> Please do a review and let me know if there are any suggestions or
> modifications required.
>
> https://cwiki.apache.org/confluence/display/GEODE/Releasing+Apache+Geode
>
> Regard
> Nabarun Nag
>

Re: [DISCUSS] permit-reflect vs --add-opens for Java 11 support

2018-10-11 Thread Sai Boorlagadda 
>Do we know what third party libraries are using java internals that >we might
have problems with? #2 isn't going to work for those >libraries, unless
they also add a module-info.class. So maybe we >will need to do #3 for
third-party libraries?

Adding these third-party libs on module path[1] rather than class path
seems to address this issue.

[1] http://openjdk.java.net/projects/jigsaw/spec/sotms/#automatic-modules

Re: [DISCUSS] permit-reflect vs --add-opens for Java 11 support

2018-10-11 Thread Patrick Rhomberg 
I'm with Galen on this one.  As nice as it would be to be able to say "This
is what we'll do," I don't think any of these is going to be the proverbial
silver bullet.

I think we should, in priority order, (#1) remove what restricted API calls
we can, (#2) adopt the module system and properly declare our dependencies
on APIs that we do need, and (#3) update our wrappers where me must,
perhaps in cases like Dan has noticed, where it's not even our own
consumption of an internal API that would be problematic.



On Thu, Oct 11, 2018 at 9:49 AM, Dan Smith  wrote:

> Do we know what third party libraries are using java internals that we
> might have problems with? #2 isn't going to work for those libraries,
> unless they also add a module-info.class. So maybe we will need to do #3
> for third-party libraries?
>
> For #2, maybe we don't have to go whole hog on adding module-info to all of
> our modules right away. We can identify and isolate our use of internal JDK
> classes to some small modules with few dependencies. For example, we could
> move our use of Unsafe to a geode-off-heap module and just add a
> module-info for that. We probably ought to have that code in a separate
> module anyway!
>
> -Dan
>
> On Wed, Oct 10, 2018 at 2:59 PM Jinmei Liao  wrote:
>
> > #3 first and then work towards #1, then #2.  We can document what
> > "--add-open" options needs to be added to start client if running with
> > jdk11+ in the meantime.
> >
> > I also have reservations about how #4 works. If it works, it is a good
> > alternation for #3.
> >
> > On Wed, Oct 10, 2018 at 2:23 PM Sai Boorlagadda <
> sai.boorlaga...@gmail.com
> > >
> > wrote:
> >
> > > +1 to Dan's idea if its possible.
> > >
> > > There is a maven plugin to invoke javac twice with respective java
> > targets.
> > >
> > >
> > https://maven.apache.org/plugins/maven-compiler-plugin/
> examples/module-info.html
> > >
> > >
> > > On Wed, Oct 10, 2018 at 1:52 PM Galen O'Sullivan <
> gosulli...@pivotal.io>
> > > wrote:
> > >
> > > > er, lost the end of that first sentence there. I think that reducing
> > > > dependencies on Unsafe &c is a good goal regardless.
> > > >
> > > > On Wed, Oct 10, 2018 at 1:51 PM Galen O'Sullivan <
> > gosulli...@pivotal.io>
> > > > wrote:
> > > >
> > > > > #1 sounds awesome but may be unrealistic given our advertised
> feature
> > > > set.
> > > > > I think that reducing dependencies on Unsafe &c
> > > > >
> > > > > If we can conditionally use Jigsaw modules for Java versions later
> > > than 8
> > > > > while maintaining Java 8 compatiblity, that seems like the best
> > > solution.
> > > > >
> > > > > +2 to Dan's idea if it allows this.
> > > > >
> > > > > On Wed, Oct 10, 2018 at 1:47 PM Jacob Barrett  >
> > > > wrote:
> > > > >
> > > > >> Here is a discussion from Google Guava project about compiling
> > > > >> module-info.java in Java 9+ and including it in a jar with classes
> > > > >> compiled
> > > > >> for Java 8.
> > > > >>
> > > > >> https://github.com/google/guava/issues/2970
> > > > >>
> > > > >>
> > > > >> On Wed, Oct 10, 2018 at 1:39 PM Jacob Barrett <
> jbarr...@pivotal.io>
> > > > >> wrote:
> > > > >>
> > > > >> > I like Dan’s idea! I would rather we work towards the correct
> > > > solution.
> > > > >> >
> > > > >> > > On Oct 10, 2018, at 1:22 PM, Dan Smith 
> > wrote:
> > > > >> > >
> > > > >> > > #2 seems like the least hacky way to continue using things
> like
> > > > >> > > sun.misc.Unsafe. Could we just compile a module-info.java with
> > > Java
> > > > 9
> > > > >> and
> > > > >> > > bundle it? This would also help consumers of geode that want
> to
> > > use
> > > > >> Java
> > > > >> > 9
> > > > >> > > modules.
> > > > >> > >
> > > > >> > > I'm a little bit sceptical of this permit-reflect libary,
> seeing
> > > as
> > > > >> it's
> > > > >> > > been around for about 1 month, has 0 tests in the source that
> I
> > > can
> > > > >> see,
> > > > >> > > and seems to be tripling down on relying on sun.misc.Unsafe to
> > do
> > > > >> stuff.
> > > > >> > > I'd be inclined to do #3 before this.
> > > > >> > >
> > > > >> > > -Dan
> > > > >> > >
> > > > >> > > On Wed, Oct 10, 2018 at 12:20 PM Owen Nichols <
> > > onich...@pivotal.io>
> > > > >> > wrote:
> > > > >> > >
> > > > >> > >> Goal:
> > > > >> > >>
> > > > >> > >> Run Geode on Java 11 (GEODE-3 <
> > > > >> > >> https://issues.apache.org/jira/browse/GEODE-3>).
> > > > >> > >>
> > > > >> > >>
> > > > >> > >> Problem:
> > > > >> > >>
> > > > >> > >> Java 8 allows Geode (and its 3rd party libraries) full access
> > to
> > > > all
> > > > >> > Java
> > > > >> > >> APIs, including internal APIs.  However, Java 11 restricts
> > access
> > > > to
> > > > >> > many
> > > > >> > >> of these APIs by default.
> > > > >> > >>
> > > > >> > >>
> > > > >> > >> Solution #1:
> > > > >> > >>
> > > > >> > >> Remove all usage of restricted APIs from all Geode code, and
> > find
> > > > >> > >> replacements for all 3rd party libraries that depend on
> > > restricted
> > > > >> APIs.

Re: proposing reduced default for "membership-port-range"

2018-10-11 Thread Brian Rowe 
I agree that we should have defaulted everything to using ephemeral ports
and forced clients to explicitly assign ports and membership ranges if
needed (any of the reasons Anthony mentioned above).  However, I don't
think we can change the default assigned ports at this point, unless we
want to try to go through the effort of verifying that no customers are
relying on the default assignments (is that even something we can do with
any confidence?).  The membership port range default, however, is something
we should be able to change, so long as we restrict it to a proper subset
of the current default.  I think the best we can do right now is just to
make it so the default membership port range doesn't conflict with the
default assigned ports.

On Fri, Oct 5, 2018 at 3:42 PM, Jacob Barrett  wrote:

> So in the Dockerfile you explicitly set the server to start on port 40404,
> problem solved. In whatever environment where you need it on a specific
> port you then assign that port. But for all the other cases where we don’t
> need to know it, like most of the time, it should just pick something
> ephemeral and work.
>
>
> > On Oct 5, 2018, at 1:57 PM, Anthony Baker  wrote:
> >
> > I think there are a lot of dependencies when deploying geode that rely
> on well-known ports and port ranges (e.g. exporting ports from a container,
> firewall rules, etc).  Changing the default server port from 40404 to ??
> would break stuff.
> >
> > Here’s the rule from our own Dockerfile:
> >
> > # Default ports:
> > # RMI/JMX 1099
> > # REST 8080
> > # PULE 7070
> > # LOCATOR 10334
> > # CACHESERVER 40404
> > EXPOSE  8080 10334 40404 1099 7070
> >
> > Anthony
> >
> >
> >> On Oct 5, 2018, at 1:45 PM, Jacob Barrett  wrote:
> >>
> >> But if all ports where ephemeral by default then no collisions right?
> Why have any port have a default to a single fixed value or overlapping
> range of values. Since our opinionated use case is for clients to connect
> via locators then a known server port isn’t important.
> >>
> >>> On Oct 5, 2018, at 10:55 AM, Dan Smith  wrote:
> >>>
> >>> The problem is that the membership port is picked *first*. So it may
> pick
> >>> 40404. Then, when the cache server tries to use port 40404, it gets a
> >>> collision.
> >>>
> >>> -Dan
> >>>
>  On Fri, Oct 5, 2018 at 10:52 AM Jacob Barrett 
> wrote:
> 
>  If we just default to 0 then the OS will pick is a port in whatever
> range
>  is ephemeral and free. We don’t have to do any work. No need to
> define a
>  range and seek an open port.
> 
> >> On Oct 5, 2018, at 10:40 AM, Dan Smith  wrote:
> >>
> >> On Fri, Oct 5, 2018 at 10:31 AM Jacob Barrett 
>  wrote:
> >>
> >> Why not change the default behavior to that of port 0, letting the
> OS
> >> select an open ephemeral port if the user doesn’t specify a specific
>  port?
> >>
> >
> > I think what we'd really like to do is change the cache server port
> to
> > something other than 40404. Maybe 0 (pick a port), or maybe something
>  less
> > than 32K.
> >
> > Unfortunately, on most linux distributions the ephemeral port range
> is
>  32K
> > -> 61K, which includes 40404, which I think is why Brian is
> proposing a
> > subset of that range.
> >
> > -Dan
> 
> >
>

Re: [DISCUSS] permit-reflect vs --add-opens for Java 11 support

2018-10-11 Thread Dan Smith 
Do we know what third party libraries are using java internals that we
might have problems with? #2 isn't going to work for those libraries,
unless they also add a module-info.class. So maybe we will need to do #3
for third-party libraries?

For #2, maybe we don't have to go whole hog on adding module-info to all of
our modules right away. We can identify and isolate our use of internal JDK
classes to some small modules with few dependencies. For example, we could
move our use of Unsafe to a geode-off-heap module and just add a
module-info for that. We probably ought to have that code in a separate
module anyway!

-Dan

On Wed, Oct 10, 2018 at 2:59 PM Jinmei Liao  wrote:

> #3 first and then work towards #1, then #2.  We can document what
> "--add-open" options needs to be added to start client if running with
> jdk11+ in the meantime.
>
> I also have reservations about how #4 works. If it works, it is a good
> alternation for #3.
>
> On Wed, Oct 10, 2018 at 2:23 PM Sai Boorlagadda  >
> wrote:
>
> > +1 to Dan's idea if its possible.
> >
> > There is a maven plugin to invoke javac twice with respective java
> targets.
> >
> >
> https://maven.apache.org/plugins/maven-compiler-plugin/examples/module-info.html
> >
> >
> > On Wed, Oct 10, 2018 at 1:52 PM Galen O'Sullivan 
> > wrote:
> >
> > > er, lost the end of that first sentence there. I think that reducing
> > > dependencies on Unsafe &c is a good goal regardless.
> > >
> > > On Wed, Oct 10, 2018 at 1:51 PM Galen O'Sullivan <
> gosulli...@pivotal.io>
> > > wrote:
> > >
> > > > #1 sounds awesome but may be unrealistic given our advertised feature
> > > set.
> > > > I think that reducing dependencies on Unsafe &c
> > > >
> > > > If we can conditionally use Jigsaw modules for Java versions later
> > than 8
> > > > while maintaining Java 8 compatiblity, that seems like the best
> > solution.
> > > >
> > > > +2 to Dan's idea if it allows this.
> > > >
> > > > On Wed, Oct 10, 2018 at 1:47 PM Jacob Barrett 
> > > wrote:
> > > >
> > > >> Here is a discussion from Google Guava project about compiling
> > > >> module-info.java in Java 9+ and including it in a jar with classes
> > > >> compiled
> > > >> for Java 8.
> > > >>
> > > >> https://github.com/google/guava/issues/2970
> > > >>
> > > >>
> > > >> On Wed, Oct 10, 2018 at 1:39 PM Jacob Barrett 
> > > >> wrote:
> > > >>
> > > >> > I like Dan’s idea! I would rather we work towards the correct
> > > solution.
> > > >> >
> > > >> > > On Oct 10, 2018, at 1:22 PM, Dan Smith 
> wrote:
> > > >> > >
> > > >> > > #2 seems like the least hacky way to continue using things like
> > > >> > > sun.misc.Unsafe. Could we just compile a module-info.java with
> > Java
> > > 9
> > > >> and
> > > >> > > bundle it? This would also help consumers of geode that want to
> > use
> > > >> Java
> > > >> > 9
> > > >> > > modules.
> > > >> > >
> > > >> > > I'm a little bit sceptical of this permit-reflect libary, seeing
> > as
> > > >> it's
> > > >> > > been around for about 1 month, has 0 tests in the source that I
> > can
> > > >> see,
> > > >> > > and seems to be tripling down on relying on sun.misc.Unsafe to
> do
> > > >> stuff.
> > > >> > > I'd be inclined to do #3 before this.
> > > >> > >
> > > >> > > -Dan
> > > >> > >
> > > >> > > On Wed, Oct 10, 2018 at 12:20 PM Owen Nichols <
> > onich...@pivotal.io>
> > > >> > wrote:
> > > >> > >
> > > >> > >> Goal:
> > > >> > >>
> > > >> > >> Run Geode on Java 11 (GEODE-3 <
> > > >> > >> https://issues.apache.org/jira/browse/GEODE-3>).
> > > >> > >>
> > > >> > >>
> > > >> > >> Problem:
> > > >> > >>
> > > >> > >> Java 8 allows Geode (and its 3rd party libraries) full access
> to
> > > all
> > > >> > Java
> > > >> > >> APIs, including internal APIs.  However, Java 11 restricts
> access
> > > to
> > > >> > many
> > > >> > >> of these APIs by default.
> > > >> > >>
> > > >> > >>
> > > >> > >> Solution #1:
> > > >> > >>
> > > >> > >> Remove all usage of restricted APIs from all Geode code, and
> find
> > > >> > >> replacements for all 3rd party libraries that depend on
> > restricted
> > > >> APIs.
> > > >> > >>
> > > >> > >> Solution #2:
> > > >> > >>
> > > >> > >> Adopt Java 11’s “Jigsaw" Module System and properly declare
> > > >> dependencies
> > > >> > >> on restricted APIs.
> > > >> > >>
> > > >> > >> Solution #3:
> > > >> > >>
> > > >> > >> Update all existing public and personal scripts, wrappers, IDE
> > > >> > >> configurations, test harnesses, and other java invocations to
> > add a
> > > >> > handful
> > > >> > >> of --add-opens flags to the java commandline to override the
> > > default
> > > >> > Java
> > > >> > >> 11 restrictions.
> > > >> > >>
> > > >> > >> Solution #4:
> > > >> > >>
> > > >> > >> Use the MIT-licensed permit-reflect <
> > > >> > >> https://github.com/nqzero/permit-reflect> library to
> > > >> programmatically
> > > >> > >> override Java 11’s API restrictions.
> > > >> > >>
> > > >> > >>
> > > >> > >> In terms of feasibility:
> > > >> > >> #1 would be extremely difficult

Re: Release process for Apache Geode wiki

2018-10-11 Thread Sai Boorlagadda 
Thanks Naba! it looks comprehensive. I have not done a release myself so
cannot ask more.

If it's possible would you be able to capture software dependencies that a
release manager have to install on his workstation. Following the steps I
see docker & svn is needed.

On Wed, Oct 10, 2018, 7:01 PM Nabarun Nag  wrote:

> Hi,
>
> I have created a new wiki page on how to release Apache Geode.
> Please do a review and let me know if there are any suggestions or
> modifications required.
>
> https://cwiki.apache.org/confluence/display/GEODE/Releasing+Apache+Geode
>
> Regard
> Nabarun Nag
>