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

See

Build failed in Jenkins: Geode-nightly #1030

See Changes: [github] GEODE-3539: enhance rule to start locator joining other locators (#1104) [metatype] GEODE-4023: Add precheckin tests to pipeline. [github] GEODE-1683: fix ClientAuthorizationDUnit test

Re: DISCUSS: Deprecating and replacing current serializable string encodings

On Fri, Dec 1, 2017 at 4:59 PM Dan Smith wrote: > I think I'm kinda with Mike on this one. The existing string format does > seem pretty gnarly. But the complexity of implementing and testing all of > the backwards compatibility transcoding that would be required in order to >

Re: DISCUSS: Deprecating and replacing current serializable string encodings

It could always WRITE UTF-16 strings, but it will still need to be able to read the others. -- Mike Stolz Principal Engineer, GemFire Product Lead Mobile: +1-631-835-4771 On Fri, Dec 1, 2017 at 7:58 PM, Dan Smith wrote: > I think I'm kinda with Mike on this one. The existing

Re: DISCUSS: Deprecating and replacing current serializable string encodings

I think I'm kinda with Mike on this one. The existing string format does seem pretty gnarly. But the complexity of implementing and testing all of the backwards compatibility transcoding that would be required in order to move to the new proposed format seems to be way more work with much more

Re: Concourse pipeline

Mail should be sent out only on failures, so I would hope they'd be less frequent than Travis. I think Travis also processes PRs which contributes to the noise. -S. On Fri, Dec 1, 2017 at 4:26 PM, Greg Chase wrote: > I wonder - do we want a separate email alias for these

Re: Concourse pipeline

I wonder - do we want a separate email alias for these messages if they are going to be even more frequent than Travis? On Fri, Dec 1, 2017 at 3:24 PM, Sean Goller wrote: > Hi everyone, > If you haven't already heard, we have a new concourse pipeline > infrastructure up

Re: DISCUSS: Deprecating and replacing current serializable string encodings

My opinion is that risk/reward on this on is not worth it -- Mike Stolz Principal Engineer - Gemfire Product Manager Mobile: 631-835-4771 On Dec 1, 2017 5:19 PM, "Jacob Barrett" wrote: > On Fri, Dec 1, 2017 at 1:48 PM Michael Stolz wrote: > > > There

Concourse pipeline

Hi everyone, If you haven't already heard, we have a new concourse pipeline infrastructure up and running at https://concourse.apachegeode-ci.info/ . When these jobs fail, email will be sent to the dev list, so be aware! :) -Sean.

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

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

Re: DISCUSS: Deprecating and replacing current serializable string encodings

On Fri, Dec 1, 2017 at 1:48 PM Michael Stolz wrote: > There also would likely be Disk Stores that would need to be converted. > That would be real ugly too. Disk store could transcode each entry on demand or all at once on first load. Not saying it will be easy but progress

Re: DISCUSS: Deprecating and replacing current serializable string encodings

On Fri, Dec 1, 2017 at 1:25 PM Bruce Schuchardt wrote: > I'm wondering how we would maintain backward compatibility with this > change? Geode accepts serialized data from a client and keeps it in > serialized form and might transmit this serialized data to an older >

Geode PR cleanup

Hey all, Could we do some github pull request housekeeping please? Specifically: - If you have an open PR that you know is not going to be merged, please close it. - If you have reviewed a PR and requested changes which have not been made, please bump the PR and see if the original

Re: DISCUSS: Deprecating and replacing current serializable string encodings

There also would likely be Disk Stores that would need to be converted. That would be real ugly too. -- Mike Stolz Principal Engineer - Gemfire Product Manager Mobile: 631-835-4771 On Dec 1, 2017 4:25 PM, "Bruce Schuchardt" wrote: > I'm wondering how we would maintain

Re: DISCUSS: Deprecating and replacing current serializable string encodings

I'm wondering how we would maintain backward compatibility with this change?  Geode accepts serialized data from a client and keeps it in serialized form and might transmit this serialized data to an older version peer or client.  An older peer or client wouldn't be able to handle a new string

DISCUSS: Deprecating and replacing current serializable string encodings

The current data serializer support 4 different encodings (in addition to the 3 or 4 other encodings I have found elsewhere in Geode). It supports encoding ASCII prefixed with an uint16 length (64K), ASCII prefixed with an uint32 length, Java Modified UTF-8 with unit16 length (64k) and finally

Re: Apache geode nightly failures

I just blacklisted H34 but some 12 days back the nightly ran fine on H34 after blacklisting H12 and H14 as not being reliable. Now H34 has become the same. This is the complete list of specific machines and the same probably happened when we added H2. &&!H2&&!H12&&!H14&&!H34 Smells like there

Apache geode nightly failures

Has anyone been getting emails for the nightly builds and failures (My last build email was 1027 and I think the latest is 1030)? It looks like the last few have been a mess with Out of Memory exceptions and I think they were all ran on H34. Should that machine be black listed? If so, would

Re: [DISCUSS] changes to registerInterest API

I think Dan’s suggestion clarifies the intent. Anthony > On Nov 30, 2017, at 3:54 PM, Dan Smith wrote: > > I think it should be registerInterestAll(Iterablekeys) to mirror > Collection.addAll. > > I could easily see a user creating their own Tuple class or using one that >