Geode unit tests completed in 'develop/IntegrationTest' with non-zero exit code

[apachegeodeci]

Pipeline results can be found at:

Concourse: 
https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/IntegrationTest/builds/282

Geode unit tests completed in 'develop/DistributedTest' with non-zero exit code

[apachegeodeci]

Pipeline results can be found at:

Concourse: 
https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/200

Geode unit tests completed in 'develop/FlakyTest' with non-zero exit code

[apachegeodeci]

Pipeline results can be found at:

Concourse: 
https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/FlakyTest/builds/316

Broken: jinmeiliao/geode#272 (listJndi - 547280e)

[Travis CI]

Build Update for jinmeiliao/geode
-

Build: #272
Status: Broken

Duration: 17 minutes and 28 seconds
Commit: 547280e (listJndi)
Author: Jinmei Liao
Message: GEODE-4830: use CacheConfig to access the jndi list in 
ListJNDIBindingCommand

* updated the CacheConfig to hold only one JNDIBindingsType instead of a list
* exclude xerces library in modules projects to avoid pulling in an older 
version of xerces library
* make sure xml created by those POJOs can be used to start a server

View the changeset: 
https://github.com/jinmeiliao/geode/compare/cf32cc8ff878...547280e1a20c

View the full build log and details: 
https://travis-ci.org/jinmeiliao/geode/builds/353603909?utm_source=email_medium=notification

--

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







This email was sent to dev@geode.apache.org (mailto:dev@geode.apache.org)
unsubscribe from this list 
(http://clicks.travis-ci.com/track/unsub.php?u=14313403=0d821432d726455b9b49f3009730df21.J7HZbFy6S8dTlH7tD%2B7uJ8FM8HM%3D=https%3A%2F%2Fmandrillapp.com%2Funsub%3Fmd_email%3Ddev%2540geode.apache.org)

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

[Spring CI]

---
Spring Data GemFire > Nightly-ApacheGeode > #856 was successful.
---
Scheduled
2381 tests in total.

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





--
This message is automatically generated by Atlassian Bamboo

Geode unit tests completed in 'develop/FlakyTest' with non-zero exit code

[apachegeodeci]

Pipeline results can be found at:

Concourse: 
https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/FlakyTest/builds/315

Geode unit tests completed in 'release-1.5.0/FlakyTest' with non-zero exit code

[apachegeodeci]

Pipeline results can be found at:

Concourse: 
https://concourse.apachegeode-ci.info/teams/main/pipelines/release-1.5.0/jobs/FlakyTest/builds/6

Re: Please remember to search JIRA

[Anthony Baker]

Thanks for finding that Kirk!  I marked it as a duplicate of GEODE-4622.

Anthony


> On Mar 14, 2018, at 12:38 PM, Kirk Lund  wrote:
> 
> When you work on something, please remember to search JIRA to see if
> someone else already filed a JIRA ticket for the work. I'm not sure how
> many open "old" tickets that we have like this, but here's one example:
> 
> GEODE-2557: Upgrade jna dependency
> 
> https://issues.apache.org/jira/browse/GEODE-2557
> 
> Thanks,
> Kirk

Geode unit tests completed in 'develop/IntegrationTest' with non-zero exit code

[apachegeodeci]

Pipeline results can be found at:

Concourse: 
https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/IntegrationTest/builds/279

Please remember to search JIRA

[Kirk Lund]

When you work on something, please remember to search JIRA to see if
someone else already filed a JIRA ticket for the work. I'm not sure how
many open "old" tickets that we have like this, but here's one example:

GEODE-2557: Upgrade jna dependency

https://issues.apache.org/jira/browse/GEODE-2557

Thanks,
Kirk

Re: [PROPOSAL] Public API for Cluster Configuration

[John Blum]

*> @Jake, I vaguely remember that we had once spoken about the concept of
nouns and verbs for commands. Maybe this could be a start, understanding
what the nouns are and then understand the verbs that should go with them.
That might actually start flushing out the configuration services. i.e
noun: region verb: create, update, destroy, clear*

This was exactly the intent behind the Management REST-like API when it was
designed, i.e. proper resource abstractions such as *Regions*, *Indexes*,
*DiskStores*, etc along with actions on the resources (with REST over HTTP,
the verbs being: POST, GET, PUT/PATCH, DELETE) and eventually hypermedia
controls to allow for a discoverable API (by tooling, for instance).
However, on the *Richardson's Maturity Model*, it never quite reached full
maturity since the initial intent was to just provide an HTTP tunnel between
 *Gfsh* and the Apache Geode *Manager*.  However, it would not have been so
much work to continue down that path if the Management REST API had not
changed as it has now.  It was also language neutral.

I do have more thoughts on our (ab)use/notion of "internal" API(s), but I
will save it for another thread/time as it does not directly relate to this
topic.  In a nutshell, it is concerned with putting interfaces and classes
in "internal" packages and claiming they are for internal use only, when
occasionally, there is no public API to accomplish the task at hand.  Also,
you don't need something heavy like OSGi, or even Java 9 modules, to
properly enforce truly internal APIs either.  Finally, I would argue that
most things (if not all) should just be in the public API, i.e. with proper
interfaces (APIs and/or SPIs) no one should really have to worry about
accessing "implementation" classes.

Regards,
John



On Wed, Mar 14, 2018 at 11:40 AM, Dan Smith  wrote:

> If I understand it correctly, the intended users of this public API are
> people writing extensions to geode that need to save their own
> configuration elements, is that correct? It might be good to spell out in a
> little more detail how that will work. Does CacheConfig have methods that
> let you add extension elements?
>
> The section on concurrency seems a bit hand-wavy. What specifically is the
> API guaranteeing? That the cluster configuration will be consistent on all
> locators and it will be the result of the last write? When do I need to use
> a distributed lock?
>
> -Dan
>
>
>
> On Wed, Mar 14, 2018 at 9:17 AM, Jacob Barrett 
> wrote:
>
> > I echo everything John Said.
> >
> > I also want to throw out that we have a “public api” for config in sorts
> > through gfsh. I am by no means suggesting users programmatically invoke
> > command lines to gfsh but what if we could leverage gfsh as a console
> > terminal app, a Java API, or REST daemon? A common interface/command set
> to
> > rule them all. It is not fun as a plug-in developer to have to implement
> > multiple interfaces for multiple configuration systems.
> >
> > The other thing I’ll toss out is rather than rework what we have how
> about
> > replacing it all with something already mature. There are many other open
> > source projects that have solved the configuration problem. Let’s not
> > reinvent the wheel here.
> >
> > -Jake
> >
> >
> >
> > > On Mar 13, 2018, at 1:59 PM, John Blum  wrote:
> > >
> > > Some initial thoughts after looking over the spec...
> > >
> > >
> > > 1. As a developer (application, API/framework, tool or even a module
> > > developer), I really don't care nor should I care what Apache Geode is
> > > storing the configuration as under-the-hood.
> > >
> > > It could be XML, JSON, YAML, a database or even some configuration
> > server.
> > > It is an implementation detail and I simply don't care; i.e. nothing in
> > the
> > > interface or types should suggest otherwise.  I am not saying this is
> the
> > > case now, just to be mindful of this when refining this API.
> > >
> > > Things like...
> > >
> > > 1.1. "... *as well as injection of elements into the cache and region
> > > levels of the cluster configuration.*"
> > > 1.2. "*Define a no-op interfaces CacheElement and RegionElement to
> > identify
> > > classes that may be saved to the cache and region XML entities*"
> > > 1.3. "*Leverage JAXB to generate an initial set of configuration
> > objects.*"
> > >
> > > .. are dangerously suspicious.
> > >
> > >
> > > 2. "*Expose ClusterConfigurationService via the cache, provided a
> locator
> > > is managing that cache.*"
> > >
> > > I agree with everything but the Locator bit, which brings me back to
> > > something I mentioned/suggested during the inception.  The Management
> > > capabilities/functionality should also be a "Service", which is
> > > invokable/runnable from any node (not just Locators).  It is not
> > uncommon,
> > > and I would even argue, it (is/ought to be) recommended that clusters
> > > consist of dedicated, standalone Managers.  If 

Re: Geode JIRA permissions

[Dan Smith]

Ok, you should have access now.

-Dan

On Wed, Mar 14, 2018 at 11:30 AM, Ryan McMahon  wrote:

> Hi Dan,
>
> My username is rmcmahon according to my profile.  Not sure how the second
> username got associated with my email address.
>
> Thanks,
> Ryan
>
> On Wed, Mar 14, 2018 at 11:24 AM, Dan Smith  wrote:
>
>> Hi Ryan,
>>
>> What's your JIRA username? I see two usernames linked to this email
>> address mcmellawatt and rmcmahon.
>>
>> -Dan
>>
>> On Wed, Mar 14, 2018 at 11:09 AM, Ryan McMahon 
>> wrote:
>>
>>> Hello,
>>>
>>> I need permissions to update tickets in Geode JIRA.  If someone can grant
>>> me those permissions it would be appreciated.
>>>
>>> Thanks,
>>> Ryan
>>>
>>
>>
>

Re: [PROPOSAL] Public API for Cluster Configuration

[Dan Smith]

If I understand it correctly, the intended users of this public API are
people writing extensions to geode that need to save their own
configuration elements, is that correct? It might be good to spell out in a
little more detail how that will work. Does CacheConfig have methods that
let you add extension elements?

The section on concurrency seems a bit hand-wavy. What specifically is the
API guaranteeing? That the cluster configuration will be consistent on all
locators and it will be the result of the last write? When do I need to use
a distributed lock?

-Dan



On Wed, Mar 14, 2018 at 9:17 AM, Jacob Barrett  wrote:

> I echo everything John Said.
>
> I also want to throw out that we have a “public api” for config in sorts
> through gfsh. I am by no means suggesting users programmatically invoke
> command lines to gfsh but what if we could leverage gfsh as a console
> terminal app, a Java API, or REST daemon? A common interface/command set to
> rule them all. It is not fun as a plug-in developer to have to implement
> multiple interfaces for multiple configuration systems.
>
> The other thing I’ll toss out is rather than rework what we have how about
> replacing it all with something already mature. There are many other open
> source projects that have solved the configuration problem. Let’s not
> reinvent the wheel here.
>
> -Jake
>
>
>
> > On Mar 13, 2018, at 1:59 PM, John Blum  wrote:
> >
> > Some initial thoughts after looking over the spec...
> >
> >
> > 1. As a developer (application, API/framework, tool or even a module
> > developer), I really don't care nor should I care what Apache Geode is
> > storing the configuration as under-the-hood.
> >
> > It could be XML, JSON, YAML, a database or even some configuration
> server.
> > It is an implementation detail and I simply don't care; i.e. nothing in
> the
> > interface or types should suggest otherwise.  I am not saying this is the
> > case now, just to be mindful of this when refining this API.
> >
> > Things like...
> >
> > 1.1. "... *as well as injection of elements into the cache and region
> > levels of the cluster configuration.*"
> > 1.2. "*Define a no-op interfaces CacheElement and RegionElement to
> identify
> > classes that may be saved to the cache and region XML entities*"
> > 1.3. "*Leverage JAXB to generate an initial set of configuration
> objects.*"
> >
> > .. are dangerously suspicious.
> >
> >
> > 2. "*Expose ClusterConfigurationService via the cache, provided a locator
> > is managing that cache.*"
> >
> > I agree with everything but the Locator bit, which brings me back to
> > something I mentioned/suggested during the inception.  The Management
> > capabilities/functionality should also be a "Service", which is
> > invokable/runnable from any node (not just Locators).  It is not
> uncommon,
> > and I would even argue, it (is/ought to be) recommended that clusters
> > consist of dedicated, standalone Managers.  If Locators are overloaded
> and
> > go down, then clients would not be able to discover servers, peers
> wouldn't
> > be able to be added in a (automated/managed) scale-up environment like
> PCF
> > on AWS/GCP/Azure, etc.
> >
> > As such, the ManagementService is somewhat of a dependency for the
> > ClusterConfigurationService.  Perhaps that is not conducive to the
> > implementation today given the amount of coupling/dependencies on the
> > *Locator*, but it is far more logical.
> >
> > I see the ClusterConfigurationService as an extension of the Management
> > capabilities.
> >
> > I would also assume this ClusterConfigurationService is accessible from a
> > o.a.g.cache.client.ClientCache application?
> >
> >
> > 3. It would be nice to provide overloaded variants of getCacheConfig(..)
> > and updateCacheConfig(..) that do not require "Group" if it defaults to "
> > *cluster*" anyway.
> >
> > It is a simple matter to provide a default method in the interface of the
> > nature, for example...
> >
> >  public static final String DEFAULT_GROUP = "cluster";
> >
> >  default CacheConfig getCacheConfig(Class... additionalBindClass) {
> >return getCacheConfig(DEFAULT_GROUP, additionalBindClass);
> >  }
> >
> >  CacheConfig getCacheConfig(String group, Class... additionalBindClass);
> >
> >
> > I would also spell out getCacheConfig(..) as getCacheConfiguration(..)
> and
> > similarly for update.
> >
> >
> > 4. "The ClusterConfigurationService will be made available from the
> Cache,
> > provided the Cache is managed by a Locator.  The service is unavailable
> for
> > other members."
> >
> > See above.  Again, 1 of the intents for this API is to be accessible to
> > application, framework and tool developers, not just module developers.
> > Having 1 API is better than multiple.  Less is more.
> >
> >
> > 5.  I like the API usage overall, but this is broken (you have the making
> > of a NPE) ...
> >
> > RegionConfig regionConfig =
> >  cc.getRegion().stream().filter(x ->
> > 

Re: Geode JIRA permissions

[Ryan McMahon]

Hi Dan,

My username is rmcmahon according to my profile.  Not sure how the second
username got associated with my email address.

Thanks,
Ryan

On Wed, Mar 14, 2018 at 11:24 AM, Dan Smith  wrote:

> Hi Ryan,
>
> What's your JIRA username? I see two usernames linked to this email
> address mcmellawatt and rmcmahon.
>
> -Dan
>
> On Wed, Mar 14, 2018 at 11:09 AM, Ryan McMahon 
> wrote:
>
>> Hello,
>>
>> I need permissions to update tickets in Geode JIRA.  If someone can grant
>> me those permissions it would be appreciated.
>>
>> Thanks,
>> Ryan
>>
>
>

Re: Geode JIRA permissions

[Dan Smith]

Hi Ryan,

What's your JIRA username? I see two usernames linked to this email address
mcmellawatt and rmcmahon.

-Dan

On Wed, Mar 14, 2018 at 11:09 AM, Ryan McMahon  wrote:

> Hello,
>
> I need permissions to update tickets in Geode JIRA.  If someone can grant
> me those permissions it would be appreciated.
>
> Thanks,
> Ryan
>

Geode JIRA permissions

[Ryan McMahon]

Hello,

I need permissions to update tickets in Geode JIRA.  If someone can grant
me those permissions it would be appreciated.

Thanks,
Ryan

Re: [PROPOSAL] Public API for Cluster Configuration

[Udo Kohlmeyer]

+1 to what John said and many are thinking.

@Jake, I vaguely remember that we had once spoken about the concept of 
nouns and verbs for commands. Maybe this could be a start, understanding 
what the nouns are and then understand the verbs that should go with 
them. That might actually start flushing out the configuration services. 
i.e noun: region verb: create, update, destroy, clear


From a users perspective, I don't care if the configuration is 
clustered, replicated, centralized or stored on sticky-notes on 
someone's screen. This detail could be implemented using an SPI. The 
point for the API  should be that it is clear, easy to use and simple to 
extend. (I'm thinking that with modularity, each module can expose its 
API to configured itself)


I would like to suggest that we treat GFSH as "just another 
text-completing" shell. I think we should focus on making a 
configuration service that is easy to use and clearly defined. The HOW 
we expose this API with tools like XML, YML, REST, JAVA API, GFSH, *your 
tooling of choice* should be a secondary thought.


In addition to this, I think we should shy away from the notion of 
internal and public configuration API's. All API's should be seen as 
public and the ability to execute should be restricted by authorization.


On 3/14/18 09:17, Jacob Barrett wrote:

I echo everything John Said.

I also want to throw out that we have a “public api” for config in sorts 
through gfsh. I am by no means suggesting users programmatically invoke command 
lines to gfsh but what if we could leverage gfsh as a console terminal app, a 
Java API, or REST daemon? A common interface/command set to rule them all. It 
is not fun as a plug-in developer to have to implement multiple interfaces for 
multiple configuration systems.

The other thing I’ll toss out is rather than rework what we have how about 
replacing it all with something already mature. There are many other open 
source projects that have solved the configuration problem. Let’s not reinvent 
the wheel here.

-Jake




On Mar 13, 2018, at 1:59 PM, John Blum  wrote:

Some initial thoughts after looking over the spec...


1. As a developer (application, API/framework, tool or even a module
developer), I really don't care nor should I care what Apache Geode is
storing the configuration as under-the-hood.

It could be XML, JSON, YAML, a database or even some configuration server.
It is an implementation detail and I simply don't care; i.e. nothing in the
interface or types should suggest otherwise.  I am not saying this is the
case now, just to be mindful of this when refining this API.

Things like...

1.1. "... *as well as injection of elements into the cache and region
levels of the cluster configuration.*"
1.2. "*Define a no-op interfaces CacheElement and RegionElement to identify
classes that may be saved to the cache and region XML entities*"
1.3. "*Leverage JAXB to generate an initial set of configuration objects.*"

.. are dangerously suspicious.


2. "*Expose ClusterConfigurationService via the cache, provided a locator
is managing that cache.*"

I agree with everything but the Locator bit, which brings me back to
something I mentioned/suggested during the inception.  The Management
capabilities/functionality should also be a "Service", which is
invokable/runnable from any node (not just Locators).  It is not uncommon,
and I would even argue, it (is/ought to be) recommended that clusters
consist of dedicated, standalone Managers.  If Locators are overloaded and
go down, then clients would not be able to discover servers, peers wouldn't
be able to be added in a (automated/managed) scale-up environment like PCF
on AWS/GCP/Azure, etc.

As such, the ManagementService is somewhat of a dependency for the
ClusterConfigurationService.  Perhaps that is not conducive to the
implementation today given the amount of coupling/dependencies on the
*Locator*, but it is far more logical.

I see the ClusterConfigurationService as an extension of the Management
capabilities.

I would also assume this ClusterConfigurationService is accessible from a
o.a.g.cache.client.ClientCache application?


3. It would be nice to provide overloaded variants of getCacheConfig(..)
and updateCacheConfig(..) that do not require "Group" if it defaults to "
*cluster*" anyway.

It is a simple matter to provide a default method in the interface of the
nature, for example...

  public static final String DEFAULT_GROUP = "cluster";

  default CacheConfig getCacheConfig(Class... additionalBindClass) {
return getCacheConfig(DEFAULT_GROUP, additionalBindClass);
  }

  CacheConfig getCacheConfig(String group, Class... additionalBindClass);


I would also spell out getCacheConfig(..) as getCacheConfiguration(..) and
similarly for update.


4. "The ClusterConfigurationService will be made available from the Cache,
provided the Cache is managed by a Locator.  The service is unavailable for
other members."

See above.  Again, 1 of 

Re: [PROPOSAL] Public API for Cluster Configuration

[Jacob Barrett]

I echo everything John Said.

I also want to throw out that we have a “public api” for config in sorts 
through gfsh. I am by no means suggesting users programmatically invoke command 
lines to gfsh but what if we could leverage gfsh as a console terminal app, a 
Java API, or REST daemon? A common interface/command set to rule them all. It 
is not fun as a plug-in developer to have to implement multiple interfaces for 
multiple configuration systems.

The other thing I’ll toss out is rather than rework what we have how about 
replacing it all with something already mature. There are many other open 
source projects that have solved the configuration problem. Let’s not reinvent 
the wheel here.

-Jake



> On Mar 13, 2018, at 1:59 PM, John Blum  wrote:
> 
> Some initial thoughts after looking over the spec...
> 
> 
> 1. As a developer (application, API/framework, tool or even a module
> developer), I really don't care nor should I care what Apache Geode is
> storing the configuration as under-the-hood.
> 
> It could be XML, JSON, YAML, a database or even some configuration server.
> It is an implementation detail and I simply don't care; i.e. nothing in the
> interface or types should suggest otherwise.  I am not saying this is the
> case now, just to be mindful of this when refining this API.
> 
> Things like...
> 
> 1.1. "... *as well as injection of elements into the cache and region
> levels of the cluster configuration.*"
> 1.2. "*Define a no-op interfaces CacheElement and RegionElement to identify
> classes that may be saved to the cache and region XML entities*"
> 1.3. "*Leverage JAXB to generate an initial set of configuration objects.*"
> 
> .. are dangerously suspicious.
> 
> 
> 2. "*Expose ClusterConfigurationService via the cache, provided a locator
> is managing that cache.*"
> 
> I agree with everything but the Locator bit, which brings me back to
> something I mentioned/suggested during the inception.  The Management
> capabilities/functionality should also be a "Service", which is
> invokable/runnable from any node (not just Locators).  It is not uncommon,
> and I would even argue, it (is/ought to be) recommended that clusters
> consist of dedicated, standalone Managers.  If Locators are overloaded and
> go down, then clients would not be able to discover servers, peers wouldn't
> be able to be added in a (automated/managed) scale-up environment like PCF
> on AWS/GCP/Azure, etc.
> 
> As such, the ManagementService is somewhat of a dependency for the
> ClusterConfigurationService.  Perhaps that is not conducive to the
> implementation today given the amount of coupling/dependencies on the
> *Locator*, but it is far more logical.
> 
> I see the ClusterConfigurationService as an extension of the Management
> capabilities.
> 
> I would also assume this ClusterConfigurationService is accessible from a
> o.a.g.cache.client.ClientCache application?
> 
> 
> 3. It would be nice to provide overloaded variants of getCacheConfig(..)
> and updateCacheConfig(..) that do not require "Group" if it defaults to "
> *cluster*" anyway.
> 
> It is a simple matter to provide a default method in the interface of the
> nature, for example...
> 
>  public static final String DEFAULT_GROUP = "cluster";
> 
>  default CacheConfig getCacheConfig(Class... additionalBindClass) {
>return getCacheConfig(DEFAULT_GROUP, additionalBindClass);
>  }
> 
>  CacheConfig getCacheConfig(String group, Class... additionalBindClass);
> 
> 
> I would also spell out getCacheConfig(..) as getCacheConfiguration(..) and
> similarly for update.
> 
> 
> 4. "The ClusterConfigurationService will be made available from the Cache,
> provided the Cache is managed by a Locator.  The service is unavailable for
> other members."
> 
> See above.  Again, 1 of the intents for this API is to be accessible to
> application, framework and tool developers, not just module developers.
> Having 1 API is better than multiple.  Less is more.
> 
> 
> 5.  I like the API usage overall, but this is broken (you have the making
> of a NPE) ...
> 
> RegionConfig regionConfig =
>  cc.getRegion().stream().filter(x ->
> x.getName().equals(regionPath)).findFirst()
>  .orElse(null);
>  regionConfig.getIndex().add(index);
> 
>  return cc;
> 
> 
> And should read...
> 
>  cc.getRegion().stream().filter(x ->
> x.getName().equals(regionPath)).findFirst()
>  *.ifPresent(regionConfig.getIndex()::add);*
> 
>  return cc;
> 
> 
> 
> 6. Regarding...
> 
> *> "Common operations, such as the above "find region config", could also
> be considered for initial inclusion to the public API."*
> 
> Yes, I think these operations should be included.
> 
> In fact the whole ClusterConfigurationService should perhaps be, or better
> yet, return an object that functions more like a *Repository* (aka DAO) to
> operate on the "cluster configuration".
> 
> For instance, how do I "remove" part of the cluster configuration?  

Reverted PutIfAbsent

[Galen O'Sullivan]

Hopefully this will fix the pipeline failures. Sorry for the inconvenience.

Best,
Galen

Geode unit tests completed in 'develop/IntegrationTest' with non-zero exit code

[apachegeodeci]

Pipeline results can be found at:

Concourse: 
https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/IntegrationTest/builds/278