Re: [DISCUSS] Java 11 jobs in the pipeline

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

Re: [DISCUSS] Java 11 jobs in the pipeline

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

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

--- Spring Data GemFire > Nightly-ApacheGeode > #1067 was successful. --- Scheduled 2458 tests in total. https://build.spring.io/browse/SGF-NAG-1067/ --

Re: [DISCUSS] Java 11 jobs in the pipeline

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 >>

Re: [DISCUSS] Java 11 jobs in the pipeline

> > 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

Re: Geode Native & Apache Geode 1.8 Release

+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 >

Re: Running compatibility and upgrade tests using jdk9+

> 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

Re: Running compatibility and upgrade tests using jdk9+

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

Re: Geode Native & Apache Geode 1.8 Release

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

Re: [DISCUSS] Java 11 jobs in the pipeline

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

Re: Running compatibility and upgrade tests using jdk9+

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

Re: Running compatibility and upgrade tests using jdk9+

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

Re: Running compatibility and upgrade tests using jdk9+

> 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,

Re: Running compatibility and upgrade tests using jdk9+

> 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

Re: [Discuss] showcasing community work

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

[Discuss] showcasing community work

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

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

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?

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

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: >

Re: Release process for Apache Geode wiki

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

Re: Concourse upgrade

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 >

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

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

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

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

Re: Release process for Apache Geode wiki

@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

Re: Running compatibility and upgrade tests using jdk9+

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?)

Re: Release process for Apache Geode wiki

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?

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

>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]

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

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

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

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

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

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

Re: Release process for Apache Geode wiki

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