Build failed in Jenkins: Geode-release #89

See -- [...truncated 1.25 MB...] :geode-junit:assemble :geode-junit:compileTestJavaNote:

Re: [DISCUSS] geode-native c++ exceptions

Let me see if I can considerate the consensus here: As reasonably possible throw library specific exceptions from all public methods. As reasonably possible those exceptions should extend C++11 standard library exceptions. All exceptions should extend less specific but logically relevant base ex

Re: [DISCUSS] geode-native c++ exceptions

I think that it would be best to abide by using the std::exception as the base. I think it brings with it all the language support and flexibility. There are a few penalties obviously to using std::exception as a base, but I think they are sufficiently offset by using a standard. As far as the n

Re: [Discuss] Investigation of C++ object return types

Hi All, I favor the “pointer" approach that is identified in the code sample. There is greater clarity and less bytes seemingly created and written. We do sacrifice the potential ease of using an object, but in all, I think the way our code is structured. It is not conducive to do a value appro

[Spring CI] Spring Data GemFire > Nightly-ApacheGeode > #677 was SUCCESSFUL (with 2042 tests). Change made by John Blum.

--- Spring Data GemFire > Nightly-ApacheGeode > #677 was successful. --- Scheduled with changes by John Blum. 2044 tests in total. https://build.spring.io/browse

[DISCUSS] Change signature of Serializable::fromData on Geode-Native

I would like to propose a change: Serializable* Serializable::formData(DataInput& in) to void Serializable::formData(DataInput& in) The current signature allows the object being deserialized to return an object other than itself. The use of this trick is only done internally for a few internal sys

Re: [VOTE] Apache Geode release - v1.2.1 RC3

Thanks for finding this Dan! Anthony > On Sep 13, 2017, at 1:02 PM, Dan Smith wrote: > > I also found a few artifacts the source distribution that I don't think > should be there. Looks like maybe you missed doing a git clean before > creating the source dist? > > apache-geode-src-1.2.1/ext

Re: [VOTE] Apache Geode release - v1.2.1 RC3

I also found a few artifacts the source distribution that I don't think should be there. Looks like maybe you missed doing a git clean before creating the source dist? apache-geode-src-1.2.1/extensions: session-testing-war apache-geode-src-1.2.1/geode-core/src/main/java/org/apache/geode/internal/c

Re: [VOTE] Apache Geode release - v1.2.1 RC3

I’ve started another geode-release build but my confidence in jenkins test results is pretty low. The last successful nightly build was almost 6 weeks ago. Anthony > On Sep 13, 2017, at 10:22 AM, Dan Smith wrote: > > The jenkins build had failures for this revision. They look like they might

Re: Review Request 62248: GEODE-3539: Add test for missing coverage of status locator command

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/62248/#review185325 --- Ship it! Ship It! - Jared Stewart On Sept. 12, 2017, 3:20 p.

Re: [DISCUSS] authorizing function execution

After some more investigation into the implementation details, here is our updated proposal to add to the Function interface: default Collection getRequiredPermissions(Optional onRegion) { return Collections.singletonList(ResourcePermissions.DATA_WRITE); } This method can be overridden by Fun

Re: [VOTE] Apache Geode release - v1.2.1 RC3

+1 for always only shipping from a green CI On Wed, Sep 13, 2017 at 11:22 AM, Dan Smith wrote: > The jenkins build had failures for this revision. They look like they might > be environmental issues but I don't think we should actually ship this > unless we have a green build. Can someone kick t

Re: Flaky failures in Geode Nightly Build

Please don't mark Jetty9CachingClientServerTest as flaky. We need to look into why it failed and fix it. There are a bunch of other tests that are using the same framework, so marking this one test as flaky isn't going to help. -Dan On Wed, Sep 13, 2017 at 10:07 AM, Jared Stewart wrote: > I wou

Re: [VOTE] Apache Geode release - v1.2.1 RC3

The jenkins build had failures for this revision. They look like they might be environmental issues but I don't think we should actually ship this unless we have a green build. Can someone kick the pipeline to restart the build? https://builds.apache.org/blue/organizations/jenkins/Geode-release/de

Re: Flaky failures in Geode Nightly Build

I would prefer not to mark ExportLogsStatsOverHttpDUnitTest as flaky. This is the first time we’ve seen it fail, and it looks like it failed due to insufficient cleanup from a previous test. We’re working on finding the culprit test and adding the missing cleanup. (Or you can mark it flaky

Flaky failures in Geode Nightly Build

We need to get more serious about getting the Geode Nightly Build back to consistent GREEN. I want to mark these flickering tests as FlakyTest. Please let me know if you have a problem with me doing so: 1) Jetty9CachingClientServerTest 2) ExportLogsStatsOverHttpDUnitTest If you do have a problem

Jenkins build is back to normal : Geode-nightly-flaky #122

See

Build failed in Jenkins: Geode-nightly #953

See Changes: [abaker] GEODE-3587 Fix the source distribution basename -- [...truncated 130.35 KB...] :geode-old-client-support:checkMissedTests :geode-old-client-support:spotl