Build failed in Jenkins: Geode-nightly-flaky #177

See -- [...truncated 117.76 KB...] Download https://repo1.maven.org/maven2/com/fasterxml/classmate/1.3.1/classmate-1.3.1.pom Download https://repo1.maven.org/maven2/org/springframewor

Re: [Discussion] Geode-Native Removing Stats from Public API

Should this be done for the Java caches as well? On 11/17/17 11:48 AM, David Kimura wrote: I agree, a statistics interface seems beyond the scope of Geode Native client responsibility. Hiding or removing seems appropriate to me. Thanks, David On Fri, Nov 17, 2017 at 11:29 AM, Ernest Burghard

Re: [Discussion] Geode-Native Removing Stats from Public API

Great idea! > On Nov 20, 2017, at 8:42 AM, Bruce Schuchardt wrote: > > Should this be done for the Java caches as well? > > >> On 11/17/17 11:48 AM, David Kimura wrote: >> I agree, a statistics interface seems beyond the scope of Geode Native >> client responsibility. Hiding or removing seems

Re: [DISCUSS] changes to registerInterest API

John's approach looks best for when you need to specify keys. For ALL_KEYS, what about an API that doesn't require a token or all keys: public void registerInterestForAllKeys(); On Fri, Nov 17, 2017 at 1:24 PM, Jason Huynh wrote: > Thanks John for the clarification! > > On Fri, Nov 17, 2017 at

Re: [Discussion] Geode-Native Removing Stats from Public API

I'm not clear on why we are removing stats gathering capability. Do we know that customers aren't using this? Is it badly broken? What is actually driving this work? -- Mike Stolz Principal Engineer, GemFire Product Lead Mobile: +1-631-835-4771 On Mon, Nov 20, 2017 at 11:42 AM, Bruce Schuchardt

Re: [Discussion] Geode-Native Removing Stats from Public API

+1 On Thu, Nov 16, 2017 at 12:46 PM, Jacob Barrett wrote: > I want to open a discussion regarding the removal of StatisticsFactory and > related APIs from the public API. I can't see that we would want the Geode > Native client to be a first class statistics/metrics gathering API. There > are pl

Re: [Discussion] Geode-Native Removing Stats from Public API

To clarify, the goal here is to remove access from the public API to inject custom stats into our stats stream. We would still collect stats for the internals of the client. The rational is multifaceted: 1) The C++ API is would need a non-trivial amount of time to modernize. The current API uses

Broken: apache/geode#4911 (whitelist_wip - 1b87b3e)

Build Update for apache/geode - Build: #4911 Status: Broken Duration: 13 minutes and 15 seconds Commit: 1b87b3e (whitelist_wip) Author: Bruce Schuchardt Message: whitelist WIP adding serialization whitelists to FlakyTest tests View the changeset: https://git

Re: [Discussion] SQL+Streaming/JDBC as one of the unified interfaces

Hi Christian and Julian, This indeed sounds very promising. Looking at the formidable list of "Powered by Calcite " projects, I think we should explore embedding Calcite in Geode. On Thu, Nov 16, 2017 at 2:52 PM Julian Hyde wrote: > I'm Julian Hyde

Re: [Discussion] Geode-Native Removing Stats from Public API

Thanks for the clarification Jake. So yes, I'm in agreement that we should simplify the C++ API and remove the stats API from the C++ client. \ah On Mon, Nov 20, 2017 at 10:23 AM, Jacob Barrett wrote: > To clarify, the goal here is to remove access from the public API to inject > custom stats i

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

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

Geode Program @SpringOne Platform Starts on Mon, Dec 4th!

Hello Geode Community: We're almost there! The Geode program at the SpringOne Platform conference starts on *Monday, Dec 4th, 2017*. If you haven't registered for the conference, now is the time. You can *register here * - please use my *d

CommandOverHttpDUnitTest seems to be causing a bunch of tests to needlessly be run

This is a test-suite class that is causing 13 other test classes to be run a second time.  We should remove this class and create a gradle task to run the tests based on their category, like we do with client/server, membership and other categories.

Re: CommandOverHttpDUnitTest seems to be causing a bunch of tests to needlessly be run

We are trying to get rid of this suite, currently there are only 5 test classes included in that suite now. This suites runs those tests in a different connect type. But we are trying to refactor them all to not to use a suite. On Mon, Nov 20, 2017 at 3:19 PM, Bruce Schuchardt wrote: > This is a

Re: [Discussion] SQL+Streaming/JDBC as one of the unified interfaces

Hell folks, This is a very interesting discussion to provide additional migration options for users loving SQLFire/GemFire XD. >1. Would you be interested to have the adapter as part of Geode's code ecosystem? If such a adapter is embedded in GemFire (commercial version of Apache Geode) as a res

Re: [Discussion] Geode-Native Removing Stats from Public API

A lot of statistics we have are exposed over JMX. I think we should make an effort to expose all the stats over JMX, making them consumable with existing tooling rather than investing in jVSD. On Mon, Nov 20, 2017 at 2:32 PM Addison Huddy wrote: > Thanks for the clarification Jake. So yes, I'm i

Re: [Discussion] Geode-Native Removing Stats from Public API

Couldn’t agree more for the Java side of things. The first step is deprecating the API for adding custom stats. > On Nov 20, 2017, at 11:13 PM, Swapnil Bawaskar wrote: > > A lot of statistics we have are exposed over JMX. I think we should make an > effort to expose all the stats over JMX, maki