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

[Jacob Barrett]

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, 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 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 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 pointers of pointers for maintaining collections. There
>> is
>>> a strange cross relationship between components in the stats classes
>> which
>>> create unique pointer ownership questions. Rather than solving those now
>>> and further dragging out the modernization of the C++ API we would drop
>> it
>>> and evaluated adding it back in a modern way in the future. Though I
>>> suspect adding it back in the future will never happen for the reasons
>>> below.
>>> 
>>> 2) The storage format for our stats in proprietary to Geode and lacks
>> wide
>>> market adoption.
>>> 
>>> 3) There are no modern tools for analyzing the statistics generated.
>> Geode
>>> lacks a tool for viewing or analyzing the statistics. Unless work is
>>> prioritized on completing the jVSD application then users are forced to
>>> write custom applications to extract the contents of the stats files.
>>> 
>>> I support the removal from the Java public API for reasons 2 and 3.
>> Unless
>>> we put a full effort into creating the ecosystem around the stats format
>> to
>>> make it usable we should remove it from the public API. I strongly
>>> encourage that we remove it internally too but that is for another
>>> discussion.
>>> 
>>> -Jake
>>> 
>>> 
 On Mon, Nov 20, 2017 at 9:43 AM Michael Stolz  wrote:
 
 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 <(631)%20835-4771> <(631)%20835-4771>
 
 On Mon, Nov 20, 2017 at 11:42 AM, Bruce Schuchardt <
>>> bschucha...@pivotal.io
> 
 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 appropriate to me.
>> 
>> Thanks,
>> David
>> 
>> On Fri, Nov 17, 2017 at 11:29 AM, Ernest Burghardt
>>  wrote:
>> 
>>> +1 for removal
>>> 
>>> On Thu, Nov 16, 2017 at 1:46 PM, Jacob Barrett <
>> jbarr...@pivotal.io>
>>> 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 plenty of other first class players in this space. If this
>>> isn't a
 feature of the client then I suggest it be moved internally. It’s
 highly
 unlikely it’s being used but in the case that it is we can
>> consider
 moving
 it back after some serious refactoring as it relies on an over
 abundance of
 raw pointers. Rather than spend time refactoring it now let’s just
 hide
 it
 away.
 
 -Jake
 
 
 
 
 
> 
 
>>> 
>> 

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

[Swapnil Bawaskar]

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 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 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 pointers of pointers for maintaining collections. There
> is
> > a strange cross relationship between components in the stats classes
> which
> > create unique pointer ownership questions. Rather than solving those now
> > and further dragging out the modernization of the C++ API we would drop
> it
> > and evaluated adding it back in a modern way in the future. Though I
> > suspect adding it back in the future will never happen for the reasons
> > below.
> >
> > 2) The storage format for our stats in proprietary to Geode and lacks
> wide
> > market adoption.
> >
> > 3) There are no modern tools for analyzing the statistics generated.
> Geode
> > lacks a tool for viewing or analyzing the statistics. Unless work is
> > prioritized on completing the jVSD application then users are forced to
> > write custom applications to extract the contents of the stats files.
> >
> > I support the removal from the Java public API for reasons 2 and 3.
> Unless
> > we put a full effort into creating the ecosystem around the stats format
> to
> > make it usable we should remove it from the public API. I strongly
> > encourage that we remove it internally too but that is for another
> > discussion.
> >
> > -Jake
> >
> >
> > On Mon, Nov 20, 2017 at 9:43 AM Michael Stolz  wrote:
> >
> > > 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 <(631)%20835-4771> <(631)%20835-4771>
> > >
> > > On Mon, Nov 20, 2017 at 11:42 AM, Bruce Schuchardt <
> > bschucha...@pivotal.io
> > > >
> > > 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 appropriate to me.
> > > >>
> > > >> Thanks,
> > > >> David
> > > >>
> > > >> On Fri, Nov 17, 2017 at 11:29 AM, Ernest Burghardt
> > > >>  wrote:
> > > >>
> > > >>> +1 for removal
> > > >>>
> > > >>> On Thu, Nov 16, 2017 at 1:46 PM, Jacob Barrett <
> jbarr...@pivotal.io>
> > > >>> 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 plenty of other first class players in this space. If this
> > isn't a
> > >  feature of the client then I suggest it be moved internally. It’s
> > > highly
> > >  unlikely it’s being used but in the case that it is we can
> consider
> > >  moving
> > >  it back after some serious refactoring as it relies on an over
> > >  abundance of
> > >  raw pointers. Rather than spend time refactoring it now let’s just
> > > hide
> > >  it
> > >  away.
> > > 
> > >  -Jake
> > > 
> > > 
> > > 
> > > 
> > > 
> > > >
> > >
> >
>

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

[Akihiro Kitada]

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 result, some existing SQLFire/GemFire XD users could be
interested in it.

Because of EOSL of SQLFire/GemFire XD products, current their one of
migration paths is SnappyData (like GemFire XD + Apache Spark and etc...)
but it's too much for non-Spark users (I.e., users only needing SQL
capability for OLTP empowered by in-memory data grid).

It seems that Apache Calcite is a simple and handy solution for such users.

In terms of SQL capability of SQLFire/GemFire XD products, they are based
on Apache Derby. I hope Apache Calcite (based on the modern implementation)
is faster than Apache Derby, in terms of query speed.

Thanks, regards.



-- 
Akihiro Kitada  |  Staff Customer Engineer |  +81 80 3716 3736
Support.Pivotal.io   |  Mon-Fri  9:00am to
5:30pm JST  |  1-877-477-2269
[image: support]  [image: twitter]
 [image: linkedin]
 [image: facebook]
 [image: google plus]
 [image: youtube]



2017-11-21 5:56 GMT+09:00 Swapnil Bawaskar :

> 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, original developer of Calcite and a current PMC member.
> >
> > I'd love to see Calcite-Geode integration and so I'm delighted with
> > the work Christian has been doing. Whenever someone builds an adapter
> > for a particular data store X, the question comes up whether it should
> > live in X or become an adapter in Calcite. Generally I prefer the
> > former. I think Geode would benefit by having a built-in SQL interface
> > and ODBC/JDBC server, and Calcite embeds quite easily to make that
> > happen. (You just need a couple of jars from maven, and implement some
> > SPIs to provide metadata; no extra data on disk.)
> >
> > If you don't want that, I think our community would be happy to accept
> > Christian's code as a Geode adapter in Calcite. Geode would be able to
> > include that adapter later, albeit with a small added complication of
> > version differences.
> >
> > But if there are particular concerns, or reasons why you do not want
> > SQL support in Geode, now would be a good time to discuss.
> >
> > Julian
> >
> >
> > On Thu, Nov 16, 2017 at 12:22 PM, Christian Tzolov 
> > wrote:
> > > Hi Jason
> > > ,
> > >
> > > Thanks for the comments!
> > >
> > > Regarding the talk, i'm not completely sure but i believe that as a
> part
> > of
> > > the S1P conference the sessions will be recorded.
> > >
> > >>>
> > > Also for question 1. Would you be interested to have the adapter as
> part
> > of
> > >
> > > Geode's code ecosystem?
> > >>
> > > Do you mean to create a module in Geode for this adapter?  Would it
> make
> > >
> > > sense to add a Geode module to Calcite?  Were you wanting a tighter
> > >
> > > integration (beyond an adapter) with Calcite within
> > >
> > > Geode?
> > >
> > > Currently the adapter is implemented as a pure Geode client using only
> > the
> > > public Geode API/OQL. There are no dependencies from Geode to the
> > adapter!
> > >
> > > 1. If the adapter became one of Calcite project adapter (
> > > https://calcite.apache.org/docs/adapter.html) it will benefit from
> being
> > > up to date with latest Calcite developments. But IMO this might not the
> > > most important driving force for evolving the adapter.
> > > 2. If it became an "extension" project/module under Geode's project
> > > umbrella it will stay closer to it potential users and will evolve with
> > > their needs. Hopefully it may attract more contributors if found
> useful.
> > >
> > > Personally I would be interested to explore further the approach and
> > figure
> > > out what are its strengths and weaknesses.
> > >
> > > - Cheers,
> > > Christian
> > >
> > >
> > > On 13 November 2017 at 19:46, Jason Huynh  wrote:
> > >
> > >> Hi Christian,
> > >>
> > >> I don't know much about Calcite and haven't had a chance to try out
> your
> > >> adapter yet but it sounds like a neat idea.  Will your talk be
> recorded
> > and
> > >> available after the Summit?
> > >>
> > >> Also for question 1. Would you be interested to have the adapter as
> > part of
> > >> Geode's code ecosystem?
> > >> Do you mean to create a module in Geode for this adapter?  Would it
> make
> > >> sense to add a Geode module to Calcite?  Were you want

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

[Jinmei Liao]

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


-- 
Cheers

Jinmei

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

[Bruce Schuchardt]

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.

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

[Jagdish Mirani]

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 *discount code (**S1P200_JMirani), *which will take $200 off the
price of registration.

We're *starting on Monday, Dec 4th, a day earlier than the other tracks and
sessions. *Starting early allows us to bring the Geode community together
at a time when there are no other competing sessions from other topics.

The Monday, Dec 4th, Geode segment will start with check-in at *1PM, at
Moscone Center West*. You will not need to check-in again on the following
day, when the main conference starts.

Please keep in mind that the Monday, Dec 4th segment is an early start, but
it not the only day on which Geode sessions will be offered. *A full
listing of the Geode sessions at the conference can be found here*
. You can also check out a blog post
that briefly introduces each session
,
with links to the full abstracts.

We're looking forward to bringing you together with your peer experts, core
committers, and leading production users of Geode. With the Geode coverage
at the conference, we can all walk away a lot more informed and inspired to
reap additional benefits from this technology.

See you there!

Jag

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

[Spring CI]

---
Spring Data GemFire > Nightly-ApacheGeode > #742 was successful.
---
Scheduled
2189 tests in total.

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





--
This message is automatically generated by Atlassian Bamboo

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

[Addison Huddy]

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 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 pointers of pointers for maintaining collections. There is
> a strange cross relationship between components in the stats classes which
> create unique pointer ownership questions. Rather than solving those now
> and further dragging out the modernization of the C++ API we would drop it
> and evaluated adding it back in a modern way in the future. Though I
> suspect adding it back in the future will never happen for the reasons
> below.
>
> 2) The storage format for our stats in proprietary to Geode and lacks wide
> market adoption.
>
> 3) There are no modern tools for analyzing the statistics generated. Geode
> lacks a tool for viewing or analyzing the statistics. Unless work is
> prioritized on completing the jVSD application then users are forced to
> write custom applications to extract the contents of the stats files.
>
> I support the removal from the Java public API for reasons 2 and 3. Unless
> we put a full effort into creating the ecosystem around the stats format to
> make it usable we should remove it from the public API. I strongly
> encourage that we remove it internally too but that is for another
> discussion.
>
> -Jake
>
>
> On Mon, Nov 20, 2017 at 9:43 AM Michael Stolz  wrote:
>
> > 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 <(631)%20835-4771>
> >
> > On Mon, Nov 20, 2017 at 11:42 AM, Bruce Schuchardt <
> bschucha...@pivotal.io
> > >
> > 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 appropriate to me.
> > >>
> > >> Thanks,
> > >> David
> > >>
> > >> On Fri, Nov 17, 2017 at 11:29 AM, Ernest Burghardt
> > >>  wrote:
> > >>
> > >>> +1 for removal
> > >>>
> > >>> On Thu, Nov 16, 2017 at 1: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 plenty of other first class players in this space. If this
> isn't a
> >  feature of the client then I suggest it be moved internally. It’s
> > highly
> >  unlikely it’s being used but in the case that it is we can consider
> >  moving
> >  it back after some serious refactoring as it relies on an over
> >  abundance of
> >  raw pointers. Rather than spend time refactoring it now let’s just
> > hide
> >  it
> >  away.
> > 
> >  -Jake
> > 
> > 
> > 
> > 
> > 
> > >
> >
>

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

[Swapnil Bawaskar]

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, original developer of Calcite and a current PMC member.
>
> I'd love to see Calcite-Geode integration and so I'm delighted with
> the work Christian has been doing. Whenever someone builds an adapter
> for a particular data store X, the question comes up whether it should
> live in X or become an adapter in Calcite. Generally I prefer the
> former. I think Geode would benefit by having a built-in SQL interface
> and ODBC/JDBC server, and Calcite embeds quite easily to make that
> happen. (You just need a couple of jars from maven, and implement some
> SPIs to provide metadata; no extra data on disk.)
>
> If you don't want that, I think our community would be happy to accept
> Christian's code as a Geode adapter in Calcite. Geode would be able to
> include that adapter later, albeit with a small added complication of
> version differences.
>
> But if there are particular concerns, or reasons why you do not want
> SQL support in Geode, now would be a good time to discuss.
>
> Julian
>
>
> On Thu, Nov 16, 2017 at 12:22 PM, Christian Tzolov 
> wrote:
> > Hi Jason
> > ,
> >
> > Thanks for the comments!
> >
> > Regarding the talk, i'm not completely sure but i believe that as a part
> of
> > the S1P conference the sessions will be recorded.
> >
> >>>
> > Also for question 1. Would you be interested to have the adapter as part
> of
> >
> > Geode's code ecosystem?
> >>
> > Do you mean to create a module in Geode for this adapter?  Would it make
> >
> > sense to add a Geode module to Calcite?  Were you wanting a tighter
> >
> > integration (beyond an adapter) with Calcite within
> >
> > Geode?
> >
> > Currently the adapter is implemented as a pure Geode client using only
> the
> > public Geode API/OQL. There are no dependencies from Geode to the
> adapter!
> >
> > 1. If the adapter became one of Calcite project adapter (
> > https://calcite.apache.org/docs/adapter.html) it will benefit from being
> > up to date with latest Calcite developments. But IMO this might not the
> > most important driving force for evolving the adapter.
> > 2. If it became an "extension" project/module under Geode's project
> > umbrella it will stay closer to it potential users and will evolve with
> > their needs. Hopefully it may attract more contributors if found useful.
> >
> > Personally I would be interested to explore further the approach and
> figure
> > out what are its strengths and weaknesses.
> >
> > - Cheers,
> > Christian
> >
> >
> > On 13 November 2017 at 19:46, Jason Huynh  wrote:
> >
> >> Hi Christian,
> >>
> >> I don't know much about Calcite and haven't had a chance to try out your
> >> adapter yet but it sounds like a neat idea.  Will your talk be recorded
> and
> >> available after the Summit?
> >>
> >> Also for question 1. Would you be interested to have the adapter as
> part of
> >> Geode's code ecosystem?
> >> Do you mean to create a module in Geode for this adapter?  Would it make
> >> sense to add a Geode module to Calcite?  Were you wanting a tighter
> >> integration (beyond an adapter) with Calcite within Geode?
> >>
> >> -Jason
> >>
> >> On Fri, Nov 10, 2017 at 3:49 AM Christian Tzolov 
> >> wrote:
> >>
> >> > Hi,
> >> >
> >> > I've been working lately on Apache Calcite SQL/JDBC adapter for Apache
> >> > Geode [1].
> >> >
> >> > Adapter's current implementation act as a plain Geode client (using
> the
> >> > public API/OQL interfaces) trying to push down to Geode OQL as many
> >> > relational expressions as it can. Relational expressions not
> supported by
> >> > OQL are executed by the adapter itself.
> >> >
> >> > While this approach has its advantages and disadvantages, which I will
> >> try
> >> > to address at my Geode Summit talk [2] I would like to ask two
> question:
> >> >
> >> > 1. Would you be interested to have the adapter as part of Geode's code
> >> > ecosystem?
> >> >
> >> > 2. I am aware (an experienced it myself) the SQLFire story. But given
> >> that
> >> > OQL features are expanding (aggregations are are already supported)
> and
> >> > that tools like Calcite offer proper logical/physical (cost based)
> planer
> >> > and SQL extensions such as SQL streaming, would it be useful to
> discuss
> >> > what novel approaches for using SQL/JDBC with Geode are possible?
> >> >
> >> > (Julian Hyde - founder of Calcite - is in cc)
> >> >
> >> > Cheers,
> >> > Christian
> >> >
> >> > [1] https://github.com/tzolov/calcite/tree/geode-1.3
> >> > [2]
> >> >
> >> > https://springoneplatform.io/sessions/enable-sql-jdbc-
> >> access-to-apache-geode-gemfire-using-apache-calcite
> >> >
> >> >
> >> > --
> >> > Christian Tzolov  | Principle
> >> Software
> >> > Engineer | Pivotal 

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

[Travis CI]

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://github.com/apache/geode/compare/0c6322214dd3...1b87b3ed61f8

View the full build log and details: 
https://travis-ci.org/apache/geode/builds/304845418?utm_source=email&utm_medium=notification

--

You can configure recipients for build notifications in your .travis.yml file. 
See https://docs.travis-ci.com/user/notifications

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

[Jacob Barrett]

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 pointers of pointers for maintaining collections. There is
a strange cross relationship between components in the stats classes which
create unique pointer ownership questions. Rather than solving those now
and further dragging out the modernization of the C++ API we would drop it
and evaluated adding it back in a modern way in the future. Though I
suspect adding it back in the future will never happen for the reasons
below.

2) The storage format for our stats in proprietary to Geode and lacks wide
market adoption.

3) There are no modern tools for analyzing the statistics generated. Geode
lacks a tool for viewing or analyzing the statistics. Unless work is
prioritized on completing the jVSD application then users are forced to
write custom applications to extract the contents of the stats files.

I support the removal from the Java public API for reasons 2 and 3. Unless
we put a full effort into creating the ecosystem around the stats format to
make it usable we should remove it from the public API. I strongly
encourage that we remove it internally too but that is for another
discussion.

-Jake


On Mon, Nov 20, 2017 at 9:43 AM Michael Stolz  wrote:

> 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 <(631)%20835-4771>
>
> On Mon, Nov 20, 2017 at 11: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 appropriate to me.
> >>
> >> Thanks,
> >> David
> >>
> >> On Fri, Nov 17, 2017 at 11:29 AM, Ernest Burghardt
> >>  wrote:
> >>
> >>> +1 for removal
> >>>
> >>> On Thu, Nov 16, 2017 at 1: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 plenty of other first class players in this space. If this isn't a
>  feature of the client then I suggest it be moved internally. It’s
> highly
>  unlikely it’s being used but in the case that it is we can consider
>  moving
>  it back after some serious refactoring as it relies on an over
>  abundance of
>  raw pointers. Rather than spend time refactoring it now let’s just
> hide
>  it
>  away.
> 
>  -Jake
> 
> 
> 
> 
> 
> >
>

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

[Mark Hanson]

+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 plenty of other first class players in this space. If this isn't a
> feature of the client then I suggest it be moved internally. It’s highly
> unlikely it’s being used but in the case that it is we can consider moving
> it back after some serious refactoring as it relies on an over abundance of
> raw pointers. Rather than spend time refactoring it now let’s just hide it
> away.
>
> -Jake
>
>
>
>

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

[Michael Stolz]

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 
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 appropriate to me.
>>
>> Thanks,
>> David
>>
>> On Fri, Nov 17, 2017 at 11:29 AM, Ernest Burghardt
>>  wrote:
>>
>>> +1 for removal
>>>
>>> On Thu, Nov 16, 2017 at 1: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 plenty of other first class players in this space. If this isn't a
 feature of the client then I suggest it be moved internally. It’s highly
 unlikely it’s being used but in the case that it is we can consider
 moving
 it back after some serious refactoring as it relies on an over
 abundance of
 raw pointers. Rather than spend time refactoring it now let’s just hide
 it
 away.

 -Jake





>

Re: [DISCUSS] changes to registerInterest API

[Kirk Lund]

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 1:12 PM John Blum  wrote:
>
> > This...
> >
> > > The Iterable version would handle any collection type by having the
> user
> > pass
> > in the iterator for the collection.
> >
> > Is not correct.
> >
> > The Collection interface itself "extends" the java.lang.Iterable
> > interface (see here...
> > https://docs.oracle.com/javase/8/docs/api/java/util/Collection.html
> under
> > "*All
> > Superinterfaces*").
> >
> > Therefore a user can simply to this...
> >
> > *List* keys = ...
> >
> > region.registerInterest(keys); *// calls the
> > Region.registerInterest(:Iterable) method.*
> >
> > Alternatively, this would also be allowed...
> >
> > *Set* keys = ...
> >
> > region.registerInterest(keys);
> >
> >
> > On Fri, Nov 17, 2017 at 11:44 AM, Jason Huynh  wrote:
> >
> > > Current idea is to:
> > > - deprecate current "ALL_KEYS" and List passing behavior in
> > > registerInterest()
> > > - add registerInterestAllKeys();
> > > - add registerInterest(T... keys) and registerInterest(Iterable
> keys)
> > > and
> > > not have one specifically for List or specific collections.
> > >
> > > The Iterable version would handle any collection type by having the
> user
> > > pass in the iterator for the collection.
> > >
> > > On Fri, Nov 17, 2017 at 11:32 AM Jacob Barrett 
> > > wrote:
> > >
> > > > I am failing to see where registerInterest(List keys) is an issue
> > for
> > > > the key type in the region. If our region is Region then I
> > would
> > > > expect registerInterest(List). If the keys are unknown or a
> mix
> > > > then you should have Region and thus
> > > registerInterest(List > > >
> > > > I echo John's statements on VarArgs and type erasure as well as his
> > > > argument for Iterable.
> > > >
> > > > Also, List does not restrict you from List indexes. The region
> would
> > > be
> > > > Region> with registerInterest>().
> > > >
> > > > -Jake
> > > >
> > > >
> > > > On Fri, Nov 17, 2017 at 10:04 AM John Blum  wrote:
> > > >
> > > > > Personally, I prefer the var args method (registerInterest(T...
> > keys))
> > > > > myself.  It is way more convenient if I only have a few keys when
> > > calling
> > > > > this method then to have to add the keys to a List, especially for
> > > > testing
> > > > > purposes.
> > > > >
> > > > > But, I typically like to pair that with a
> > registerInterest(Iterable
> > > > > keys) method
> > > > > as well.  By having a overloaded Iterable variant, then I can pass
> in
> > > any
> > > > > Collection type I want (which shouldn't be restricted to just
> List).
> > > It
> > > > > also is a simple matter to convert any *Collection* (i.e. *List*,
> > > *Set*,
> > > > > etc) to an array, which can be passed to the var args method.  By
> > using
> > > > > List,
> > > > > you are implying that "order matters" since a List is a order
> > > collection
> > > > of
> > > > > elements.
> > > > >
> > > > > This ("*It might even cause problems of pushing in **multiple
> > different
> > > > > types.*"), regarding var args, does not even make sense.
> Technically,
> > > > > List is no different.  Java's type erasure essentially equates
> var
> > > > args
> > > > > too "Object..." (or Object[]) and the List to List (or a List of
> > > > > Objects,
> > > > > essentially like if you just did this... List) So, while
> the
> > > > > compiler ensures compile-time type-safety of generics, there is no
> > > > generics
> > > > > type-safety guarantees at runtime.
> > > > >
> > > > >
> > > > >
> > > > > On Fri, Nov 17, 2017 at 9:22 AM, Jason Huynh 
> > > wrote:
> > > > >
> > > > > > Hi Mike,
> > > > > >
> > > > > > The current support for List leads to compilation issues if the
> > > region
> > > > is
> > > > > > type constrained.  However I think you are suggesting instead of
> a
> > > var
> > > > > args
> > > > > > method, instead provide a registerInterest(List keys) method?
> > > > > >
> > > > > > So far what I am hearing requested is:
> > > > > > deprecate current "ALL_KEYS" and List passing behavior
> > > > > > registerInterestAllKeys();
> > > > > > registerInterest(List keys) instead of a registerInterest(T...
> > > keys)
> > > > > >
> > > > > > Will anyone ever actually have a List as the key itself? The
> > current
> > > > and
> > > > > > suggested changes would not allow it registering for a specific
> > List
> > > > > > object.
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Thu, Nov 16, 2017 at 6:50 PM Jacob Barrett <
> jbarr...@pivotal.io
> > >
> > > > > wrote:
> > > > > >
> > > > > > > Geode Native C++ and .NET have:
> > > > > > >
> > > > > > >   virtual void registerKeys(const
> > > > > > > std::vector> & keys,
> > > > > > > bool isDurable = false,
> > > > > > >  

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

[Jacob Barrett]

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 appropriate to me.
>> 
>> Thanks,
>> David
>> 
>> On Fri, Nov 17, 2017 at 11:29 AM, Ernest Burghardt
>>  wrote:
>>> +1 for removal
>>> 
 On Thu, Nov 16, 2017 at 1: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 plenty of other first class players in this space. If this isn't a
 feature of the client then I suggest it be moved internally. It’s highly
 unlikely it’s being used but in the case that it is we can consider moving
 it back after some serious refactoring as it relies on an over abundance of
 raw pointers. Rather than spend time refactoring it now let’s just hide it
 away.
 
 -Jake
 
 
 
 
> 

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

[Bruce Schuchardt]

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

+1 for removal

On Thu, Nov 16, 2017 at 1: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 plenty of other first class players in this space. If this isn't a
feature of the client then I suggest it be moved internally. It’s highly
unlikely it’s being used but in the case that it is we can consider moving
it back after some serious refactoring as it relies on an over abundance of
raw pointers. Rather than spend time refactoring it now let’s just hide it
away.

-Jake

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

[Apache Jenkins Server]

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/springframework/plugin/spring-plugin-core/1.2.0.RELEASE/spring-plugin-core-1.2.0.RELEASE.pom
Download 
https://repo1.maven.org/maven2/org/springframework/plugin/spring-plugin/1.2.0.RELEASE/spring-plugin-1.2.0.RELEASE.pom
Download 
https://repo1.maven.org/maven2/org/springframework/plugin/spring-plugin-metadata/1.2.0.RELEASE/spring-plugin-metadata-1.2.0.RELEASE.pom
Download 
https://repo1.maven.org/maven2/org/mapstruct/mapstruct/1.0.0.Final/mapstruct-1.0.0.Final.pom
Download 
https://repo1.maven.org/maven2/org/mapstruct/mapstruct-parent/1.0.0.Final/mapstruct-parent-1.0.0.Final.pom
Download 
https://repo1.maven.org/maven2/org/springframework/spring-expression/4.3.5.RELEASE/spring-expression-4.3.5.RELEASE.pom
Download 
https://repo1.maven.org/maven2/io/springfox/springfox-core/2.6.1/springfox-core-2.6.1.pom
Download 
https://repo1.maven.org/maven2/com/fasterxml/jackson/module/jackson-module-scala_2.10/2.8.6/jackson-module-scala_2.10-2.8.6.jar
Download 
https://repo1.maven.org/maven2/io/springfox/springfox-swagger2/2.6.1/springfox-swagger2-2.6.1.jar
Download 
https://repo1.maven.org/maven2/io/springfox/springfox-swagger-ui/2.6.1/springfox-swagger-ui-2.6.1.jar
Download 
https://repo1.maven.org/maven2/org/springframework/hateoas/spring-hateoas/0.23.0.RELEASE/spring-hateoas-0.23.0.RELEASE.jar
Download 
https://repo1.maven.org/maven2/org/scala-lang/scala-reflect/2.10.6/scala-reflect-2.10.6.jar
Download 
https://repo1.maven.org/maven2/com/fasterxml/jackson/module/jackson-module-paranamer/2.8.6/jackson-module-paranamer-2.8.6.jar
Download 
https://repo1.maven.org/maven2/io/swagger/swagger-annotations/1.5.10/swagger-annotations-1.5.10.jar
Download 
https://repo1.maven.org/maven2/io/swagger/swagger-models/1.5.10/swagger-models-1.5.10.jar
Download 
https://repo1.maven.org/maven2/io/springfox/springfox-spi/2.6.1/springfox-spi-2.6.1.jar
Download 
https://repo1.maven.org/maven2/io/springfox/springfox-schema/2.6.1/springfox-schema-2.6.1.jar
Download 
https://repo1.maven.org/maven2/io/springfox/springfox-swagger-common/2.6.1/springfox-swagger-common-2.6.1.jar
Download 
https://repo1.maven.org/maven2/io/springfox/springfox-spring-web/2.6.1/springfox-spring-web-2.6.1.jar
Download 
https://repo1.maven.org/maven2/com/fasterxml/classmate/1.3.1/classmate-1.3.1.jar
Download 
https://repo1.maven.org/maven2/org/springframework/plugin/spring-plugin-core/1.2.0.RELEASE/spring-plugin-core-1.2.0.RELEASE.jar
Download 
https://repo1.maven.org/maven2/org/springframework/plugin/spring-plugin-metadata/1.2.0.RELEASE/spring-plugin-metadata-1.2.0.RELEASE.jar
Download 
https://repo1.maven.org/maven2/org/mapstruct/mapstruct/1.0.0.Final/mapstruct-1.0.0.Final.jar
Download 
https://repo1.maven.org/maven2/io/springfox/springfox-core/2.6.1/springfox-core-2.6.1.jar
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
:geode-web-api:processResources
:geode-web-api:classes
:geode-assembly:docs
:geode-assembly:gfshDepsJar
:geode-client-protocol:javadoc
:geode-client-protocol:javadocJar
:geode-client-protocol:sourcesJar
:geode-client-protocol:signArchives SKIPPED
:geode-common:javadocJar
:geode-common:sourcesJar
:geode-common:signArchives SKIPPED
:geode-core:javadocJar
:geode-core:raJar
:geode-core:jcaJar
:geode-core:sourcesJar
:geode-core:signArchives SKIPPED
:geode-core:webJar
:geode-cq:jar
:geode-cq:javadoc
:geode-cq:javadocJar
:geode-cq:sourcesJar
:geode-cq:signArchives SKIPPED
:geode-json:javadocJar
:geode-json:sourcesJar
:geode-json:signArchives SKIPPED
:geode-lucene:jar
:geode-lucene:javadoc
:geode-lucene:javadocJar
:geode-lucene:sourcesJar
:geode-lucene:signArchives SKIPPED
:geode-old-client-support:jar
:geode-old-client-support:javadoc
:geode-old-client-support:javadocJar
:geode-old-client-support:sourcesJar
:geode-old-client-support:signArchives SKIPPED
:geode-protobuf:jar
:geode-protobuf:javadoc
:geode-protobuf:javadocJar
:geode-protobuf:sourcesJar
:geode-protobuf:signArchives SKIPPED
:geode-protobuf:zip
:geode-pulse:javadoc
:geode-pulse:javadocJar
:geode-pulse:sourcesJar
:geode-pulse:war
:geode-pulse:signArchives SKIPPED
:geode-rebalancer:jar
:geode-rebalancer:javadoc
:geode-rebalancer:javadocJar
:geode-rebalancer:sourcesJar
:geode-rebalancer:signArchives SKIPPED
:geode-wan:jar
:geode-wan:javadoc
:geode-wan:javadocJar
:geode-wan:sourcesJar
:geode-wan:signArchives SKIPPED
:geode-web:javadoc NO-SOURCE
:geode-web:javadocJar
:geode-web:sourcesJar
:geode-web:war
:geode-web:signArchives SKIPPED
:geode-web-api:javadoc
:geode-web-api:javadocJar
:geode-web-api:sourcesJar
:geode-web-api:war
:geode-web-api:signArc