Visualize Geode Metrics/Stats with Grafana Dashboards

2017-01-11 Thread Christian Tzolov
I've been experimenting with Geode-to-Grafana integration options. The
geode-dashboard (https://github.com/tzolov/geode-dashboard) project uses
Grafana dashboards for querying, visualizing and analysing Apache Geode
(GemFire) historical and real-time metrics and statistics.

An important goal was to provides an unified stack that can analyze BOTH
the real-time (JMX metrics) and the historical (archive files) Geode
distributed-system statistics.

The github documentation and the blogs below should explain the approach:
https://www.linkedin.com/pulse/visualize-analyse-apache-geode-gemfire-real-time-metrics-tzolov
http://blog.tzolov.net/2017/01/visualize-and-analyse-apache-geode.html?view=sidebar

At the moment the tool uses InfluxDB as a time-series DB.But i've been
considering adding support for Ambari Metrics Collector System as an
alternative time-series DB. Later is supported by Grafana (
https://grafana.net/plugins/praj-ams-datasource) and Ambari in-turn
integrates with Grafana (http://bit.ly/2j34aIX). So if we add to the mix
the Geode Ambari service (http://bit.ly/2jd0MbS) It will make a decent
Hadoop friendly stack for Geode/Gemfire.

Another even more interesting angle is to make Geode itself a Grafana
compliant datasource (http://docs.grafana.org/plugins/datasources,
https://grafana.net/plugins). So

Do you think it would be worth bringing part of this work under Geode
project umbrella?

Cheers,
Christian

P.S. Note that this project focus on Geode metrics only but similar
approach can be used to explore business time-series.


Jenkins build is back to normal : Geode-nightly #713

2017-01-11 Thread Apache Jenkins Server
See 



Re: Visualize Geode Metrics/Stats with Grafana Dashboards

2017-01-11 Thread Jens Deppe
This is fantastic work! I did something with the same components for a
hackday last year and it looked very promising - it's great to see it fully
realized here. Although it's not difficult pulling the components together,
it would be awesome to provide a turnkey (ala docker) solution that Just
Works.

Even better is that you've included a statistics-to-grafana bridge.

--Jens

On Wed, Jan 11, 2017 at 3:42 AM, Christian Tzolov 
wrote:

> I've been experimenting with Geode-to-Grafana integration options. The
> geode-dashboard (https://github.com/tzolov/geode-dashboard) project uses
> Grafana dashboards for querying, visualizing and analysing Apache Geode
> (GemFire) historical and real-time metrics and statistics.
>
> An important goal was to provides an unified stack that can analyze BOTH
> the real-time (JMX metrics) and the historical (archive files) Geode
> distributed-system statistics.
>
> The github documentation and the blogs below should explain the approach:
> https://www.linkedin.com/pulse/visualize-analyse-
> apache-geode-gemfire-real-time-metrics-tzolov
> http://blog.tzolov.net/2017/01/visualize-and-analyse-
> apache-geode.html?view=sidebar
>
> At the moment the tool uses InfluxDB as a time-series DB.But i've been
> considering adding support for Ambari Metrics Collector System as an
> alternative time-series DB. Later is supported by Grafana (
> https://grafana.net/plugins/praj-ams-datasource) and Ambari in-turn
> integrates with Grafana (http://bit.ly/2j34aIX). So if we add to the mix
> the Geode Ambari service (http://bit.ly/2jd0MbS) It will make a decent
> Hadoop friendly stack for Geode/Gemfire.
>
> Another even more interesting angle is to make Geode itself a Grafana
> compliant datasource (http://docs.grafana.org/plugins/datasources,
> https://grafana.net/plugins). So
>
> Do you think it would be worth bringing part of this work under Geode
> project umbrella?
>
> Cheers,
> Christian
>
> P.S. Note that this project focus on Geode metrics only but similar
> approach can be used to explore business time-series.
>
>


[GitHub] geode issue #333: Various pulse fixes

2017-01-11 Thread jaredjstewart
Github user jaredjstewart commented on the issue:

https://github.com/apache/geode/pull/333
  
The pulse dataExportTest failed in precheckin.  Closing this PR until I've 
made the test more resilient.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[GitHub] geode pull request #333: Various pulse fixes

2017-01-11 Thread jaredjstewart
Github user jaredjstewart closed the pull request at:

https://github.com/apache/geode/pull/333


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[jira] [Commented] (GEODE-1114) Remove sqlfire/GemFireXD references from Pulse

2017-01-11 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/GEODE-1114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15818805#comment-15818805
 ] 

ASF GitHub Bot commented on GEODE-1114:
---

Github user jaredjstewart closed the pull request at:

https://github.com/apache/geode/pull/333


> Remove sqlfire/GemFireXD references from Pulse
> --
>
> Key: GEODE-1114
> URL: https://issues.apache.org/jira/browse/GEODE-1114
> Project: Geode
>  Issue Type: Task
>  Components: pulse
>Reporter: Jens Deppe
>Assignee: Jared Stewart
>
> No need to drag around this old code



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Resolved] (GEODE-2279) Events may linger in HARegionQueue

2017-01-11 Thread Jason Huynh (JIRA)

 [ 
https://issues.apache.org/jira/browse/GEODE-2279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jason Huynh resolved GEODE-2279.

   Resolution: Fixed
Fix Version/s: 1.1.0

> Events may linger in HARegionQueue
> --
>
> Key: GEODE-2279
> URL: https://issues.apache.org/jira/browse/GEODE-2279
> Project: Geode
>  Issue Type: Bug
>  Components: client queues
>Reporter: Jason Huynh
>Assignee: Jason Huynh
> Fix For: 1.1.0
>
>
> In HARegionQueue, removal of ack'd events is only done after dispatching a 
> message.  If there are no more events to dispatch to a client, any ack'd 
> messages that were received by the server, after the last dispatch, will 
> linger in the queue.  This can lead to confusion with stats.
> The secondaries themselves would be cleaned up by the QRM thread and does not 
> have this issue.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Resolved] (GEODE-2287) Possible NPE in HARegionQueue during gii with conflation

2017-01-11 Thread Jason Huynh (JIRA)

 [ 
https://issues.apache.org/jira/browse/GEODE-2287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jason Huynh resolved GEODE-2287.

   Resolution: Fixed
Fix Version/s: 1.1.0

> Possible NPE in HARegionQueue during gii with conflation
> 
>
> Key: GEODE-2287
> URL: https://issues.apache.org/jira/browse/GEODE-2287
> Project: Geode
>  Issue Type: Bug
>  Components: client queues
>Reporter: Jason Huynh
>Assignee: Jason Huynh
> Fix For: 1.1.0
>
>
> There is a chance that a conflated value causes in NPE during gii for ha 
> region queue.
> The following line should probably have a check to make sure val is not null.
> if (val.getEventId() != null) { // bug #44959 null event ID caused NPE



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


Re: Visualize Geode Metrics/Stats with Grafana Dashboards

2017-01-11 Thread Michael Stolz
This is exciting!
I'd love to see this effort proceed.
Maybe we should start a discussion of exactly what stats should be pulled
in for monitoring a production grade system?

--
Mike Stolz
Principal Engineer, GemFire Product Manager
Mobile: 631-835-4771

On Wed, Jan 11, 2017 at 11:05 AM, Jens Deppe  wrote:

> This is fantastic work! I did something with the same components for a
> hackday last year and it looked very promising - it's great to see it fully
> realized here. Although it's not difficult pulling the components together,
> it would be awesome to provide a turnkey (ala docker) solution that Just
> Works.
>
> Even better is that you've included a statistics-to-grafana bridge.
>
> --Jens
>
> On Wed, Jan 11, 2017 at 3:42 AM, Christian Tzolov 
> wrote:
>
> > I've been experimenting with Geode-to-Grafana integration options. The
> > geode-dashboard (https://github.com/tzolov/geode-dashboard) project uses
> > Grafana dashboards for querying, visualizing and analysing Apache Geode
> > (GemFire) historical and real-time metrics and statistics.
> >
> > An important goal was to provides an unified stack that can analyze BOTH
> > the real-time (JMX metrics) and the historical (archive files) Geode
> > distributed-system statistics.
> >
> > The github documentation and the blogs below should explain the approach:
> > https://www.linkedin.com/pulse/visualize-analyse-
> > apache-geode-gemfire-real-time-metrics-tzolov
> > http://blog.tzolov.net/2017/01/visualize-and-analyse-
> > apache-geode.html?view=sidebar
> >
> > At the moment the tool uses InfluxDB as a time-series DB.But i've been
> > considering adding support for Ambari Metrics Collector System as an
> > alternative time-series DB. Later is supported by Grafana (
> > https://grafana.net/plugins/praj-ams-datasource) and Ambari in-turn
> > integrates with Grafana (http://bit.ly/2j34aIX). So if we add to the mix
> > the Geode Ambari service (http://bit.ly/2jd0MbS) It will make a decent
> > Hadoop friendly stack for Geode/Gemfire.
> >
> > Another even more interesting angle is to make Geode itself a Grafana
> > compliant datasource (http://docs.grafana.org/plugins/datasources,
> > https://grafana.net/plugins). So
> >
> > Do you think it would be worth bringing part of this work under Geode
> > project umbrella?
> >
> > Cheers,
> > Christian
> >
> > P.S. Note that this project focus on Geode metrics only but similar
> > approach can be used to explore business time-series.
> >
> >
>


[jira] [Commented] (GEODE-2143) JSON deserialization fails if a String contains an apostrophe

2017-01-11 Thread Hitesh Khamesra (JIRA)

[ 
https://issues.apache.org/jira/browse/GEODE-2143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15818863#comment-15818863
 ] 

Hitesh Khamesra commented on GEODE-2143:


[~kduling] It seems we can re-implement GfJSONObject using Jackson. We use 
jackson in geode for JSONFormattor. I find this link very useful to start with 
http://proliferay.com/create-json-by-jackson-api/.

> JSON deserialization fails if a String contains an apostrophe
> -
>
> Key: GEODE-2143
> URL: https://issues.apache.org/jira/browse/GEODE-2143
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: Jared Stewart
>Assignee: Kevin Duling
>
> Testing revealed this causes an issue when a String value contains a single 
> apostrophe in it.  For example: {{Customer customer = new Customer(1L, 
> "Galen", "O'Sullivan", "555-11-");}}
> If you create a region and put in a value which is an instance of 
> org.apache.geode.rest.internal.web.controllers.Customer, then gfsh blows up 
> when attempting to display the value:
> {code}
> gfsh>query --query="select * from /customers"
> Result : true
> startCount : 0
> endCount   : 20
> Rows   : 1
> Value
> ---
> Error getting bean properties Expected a ',' or '}' at 86 [character 87 line 
> 1]
> {code}
> It would be good to determine why this occurs to prevent the same error from 
> arising with user-provided classes.
> The error occurs in the GfJsonObject, which will be replaced in an upcoming 
> release.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


Re: Visualize Geode Metrics/Stats with Grafana Dashboards

2017-01-11 Thread Udo Kohlmeyer
turnkey sounds good... but with a set of scripts, config files and steps 
to get to final result, docker would just be an option.


--Udo


On 1/11/17 08:05, Jens Deppe wrote:

This is fantastic work! I did something with the same components for a
hackday last year and it looked very promising - it's great to see it fully
realized here. Although it's not difficult pulling the components together,
it would be awesome to provide a turnkey (ala docker) solution that Just
Works.

Even better is that you've included a statistics-to-grafana bridge.

--Jens

On Wed, Jan 11, 2017 at 3:42 AM, Christian Tzolov 
wrote:


I've been experimenting with Geode-to-Grafana integration options. The
geode-dashboard (https://github.com/tzolov/geode-dashboard) project uses
Grafana dashboards for querying, visualizing and analysing Apache Geode
(GemFire) historical and real-time metrics and statistics.

An important goal was to provides an unified stack that can analyze BOTH
the real-time (JMX metrics) and the historical (archive files) Geode
distributed-system statistics.

The github documentation and the blogs below should explain the approach:
https://www.linkedin.com/pulse/visualize-analyse-
apache-geode-gemfire-real-time-metrics-tzolov
http://blog.tzolov.net/2017/01/visualize-and-analyse-
apache-geode.html?view=sidebar

At the moment the tool uses InfluxDB as a time-series DB.But i've been
considering adding support for Ambari Metrics Collector System as an
alternative time-series DB. Later is supported by Grafana (
https://grafana.net/plugins/praj-ams-datasource) and Ambari in-turn
integrates with Grafana (http://bit.ly/2j34aIX). So if we add to the mix
the Geode Ambari service (http://bit.ly/2jd0MbS) It will make a decent
Hadoop friendly stack for Geode/Gemfire.

Another even more interesting angle is to make Geode itself a Grafana
compliant datasource (http://docs.grafana.org/plugins/datasources,
https://grafana.net/plugins). So

Do you think it would be worth bringing part of this work under Geode
project umbrella?

Cheers,
Christian

P.S. Note that this project focus on Geode metrics only but similar
approach can be used to explore business time-series.






Re: Visualize Geode Metrics/Stats with Grafana Dashboards

2017-01-11 Thread Gregory Chase
This is awesome work Christian.

Agreed turnkey for sure.

Just thinking forward - once everyone starts loving this tool, they'll want
to start asking for event triggers and automation based on statistics as
well.

Maybe Geode becomes a self-administering distributed system soon :)

-Greg

On Wed, Jan 11, 2017 at 9:12 AM, Udo Kohlmeyer 
wrote:

> turnkey sounds good... but with a set of scripts, config files and steps
> to get to final result, docker would just be an option.
>
> --Udo
>
>
>
> On 1/11/17 08:05, Jens Deppe wrote:
>
>> This is fantastic work! I did something with the same components for a
>> hackday last year and it looked very promising - it's great to see it
>> fully
>> realized here. Although it's not difficult pulling the components
>> together,
>> it would be awesome to provide a turnkey (ala docker) solution that Just
>> Works.
>>
>> Even better is that you've included a statistics-to-grafana bridge.
>>
>> --Jens
>>
>> On Wed, Jan 11, 2017 at 3:42 AM, Christian Tzolov 
>> wrote:
>>
>> I've been experimenting with Geode-to-Grafana integration options. The
>>> geode-dashboard (https://github.com/tzolov/geode-dashboard) project uses
>>> Grafana dashboards for querying, visualizing and analysing Apache Geode
>>> (GemFire) historical and real-time metrics and statistics.
>>>
>>> An important goal was to provides an unified stack that can analyze BOTH
>>> the real-time (JMX metrics) and the historical (archive files) Geode
>>> distributed-system statistics.
>>>
>>> The github documentation and the blogs below should explain the approach:
>>> https://www.linkedin.com/pulse/visualize-analyse-
>>> apache-geode-gemfire-real-time-metrics-tzolov
>>> http://blog.tzolov.net/2017/01/visualize-and-analyse-
>>> apache-geode.html?view=sidebar
>>>
>>> At the moment the tool uses InfluxDB as a time-series DB.But i've been
>>> considering adding support for Ambari Metrics Collector System as an
>>> alternative time-series DB. Later is supported by Grafana (
>>> https://grafana.net/plugins/praj-ams-datasource) and Ambari in-turn
>>> integrates with Grafana (http://bit.ly/2j34aIX). So if we add to the mix
>>> the Geode Ambari service (http://bit.ly/2jd0MbS) It will make a decent
>>> Hadoop friendly stack for Geode/Gemfire.
>>>
>>> Another even more interesting angle is to make Geode itself a Grafana
>>> compliant datasource (http://docs.grafana.org/plugins/datasources,
>>> https://grafana.net/plugins). So
>>>
>>> Do you think it would be worth bringing part of this work under Geode
>>> project umbrella?
>>>
>>> Cheers,
>>> Christian
>>>
>>> P.S. Note that this project focus on Geode metrics only but similar
>>> approach can be used to explore business time-series.
>>>
>>>
>>>
>


-- 
Greg Chase

Product team
http://www.pivotal.io/big-data

Pivotal Software
http://www.pivotal.io/

650-215-0477
@GregChase
Blog: http://geekmarketing.biz/


Re: Visualize Geode Metrics/Stats with Grafana Dashboards

2017-01-11 Thread John Blum
Nice work Christian!  This is pretty wicked.

On Wed, Jan 11, 2017 at 9:23 AM, Gregory Chase  wrote:

> This is awesome work Christian.
>
> Agreed turnkey for sure.
>
> Just thinking forward - once everyone starts loving this tool, they'll want
> to start asking for event triggers and automation based on statistics as
> well.
>
> Maybe Geode becomes a self-administering distributed system soon :)
>
> -Greg
>
> On Wed, Jan 11, 2017 at 9:12 AM, Udo Kohlmeyer 
> wrote:
>
> > turnkey sounds good... but with a set of scripts, config files and steps
> > to get to final result, docker would just be an option.
> >
> > --Udo
> >
> >
> >
> > On 1/11/17 08:05, Jens Deppe wrote:
> >
> >> This is fantastic work! I did something with the same components for a
> >> hackday last year and it looked very promising - it's great to see it
> >> fully
> >> realized here. Although it's not difficult pulling the components
> >> together,
> >> it would be awesome to provide a turnkey (ala docker) solution that Just
> >> Works.
> >>
> >> Even better is that you've included a statistics-to-grafana bridge.
> >>
> >> --Jens
> >>
> >> On Wed, Jan 11, 2017 at 3:42 AM, Christian Tzolov 
> >> wrote:
> >>
> >> I've been experimenting with Geode-to-Grafana integration options. The
> >>> geode-dashboard (https://github.com/tzolov/geode-dashboard) project
> uses
> >>> Grafana dashboards for querying, visualizing and analysing Apache Geode
> >>> (GemFire) historical and real-time metrics and statistics.
> >>>
> >>> An important goal was to provides an unified stack that can analyze
> BOTH
> >>> the real-time (JMX metrics) and the historical (archive files) Geode
> >>> distributed-system statistics.
> >>>
> >>> The github documentation and the blogs below should explain the
> approach:
> >>> https://www.linkedin.com/pulse/visualize-analyse-
> >>> apache-geode-gemfire-real-time-metrics-tzolov
> >>> http://blog.tzolov.net/2017/01/visualize-and-analyse-
> >>> apache-geode.html?view=sidebar
> >>>
> >>> At the moment the tool uses InfluxDB as a time-series DB.But i've been
> >>> considering adding support for Ambari Metrics Collector System as an
> >>> alternative time-series DB. Later is supported by Grafana (
> >>> https://grafana.net/plugins/praj-ams-datasource) and Ambari in-turn
> >>> integrates with Grafana (http://bit.ly/2j34aIX). So if we add to the
> mix
> >>> the Geode Ambari service (http://bit.ly/2jd0MbS) It will make a decent
> >>> Hadoop friendly stack for Geode/Gemfire.
> >>>
> >>> Another even more interesting angle is to make Geode itself a Grafana
> >>> compliant datasource (http://docs.grafana.org/plugins/datasources,
> >>> https://grafana.net/plugins). So
> >>>
> >>> Do you think it would be worth bringing part of this work under Geode
> >>> project umbrella?
> >>>
> >>> Cheers,
> >>> Christian
> >>>
> >>> P.S. Note that this project focus on Geode metrics only but similar
> >>> approach can be used to explore business time-series.
> >>>
> >>>
> >>>
> >
>
>
> --
> Greg Chase
>
> Product team
> http://www.pivotal.io/big-data
>
> Pivotal Software
> http://www.pivotal.io/
>
> 650-215-0477
> @GregChase
> Blog: http://geekmarketing.biz/
>



-- 
-John
john.blum10101 (skype)


Re: Visualize Geode Metrics/Stats with Grafana Dashboards

2017-01-11 Thread Diane Rose Hardman
Very cool! Thanks for sharing.

Diane Hardman
GemFire PM

On Wed, Jan 11, 2017 at 10:21 AM, John Blum  wrote:

> Nice work Christian!  This is pretty wicked.
>
> On Wed, Jan 11, 2017 at 9:23 AM, Gregory Chase  wrote:
>
> > This is awesome work Christian.
> >
> > Agreed turnkey for sure.
> >
> > Just thinking forward - once everyone starts loving this tool, they'll
> want
> > to start asking for event triggers and automation based on statistics as
> > well.
> >
> > Maybe Geode becomes a self-administering distributed system soon :)
> >
> > -Greg
> >
> > On Wed, Jan 11, 2017 at 9:12 AM, Udo Kohlmeyer 
> > wrote:
> >
> > > turnkey sounds good... but with a set of scripts, config files and
> steps
> > > to get to final result, docker would just be an option.
> > >
> > > --Udo
> > >
> > >
> > >
> > > On 1/11/17 08:05, Jens Deppe wrote:
> > >
> > >> This is fantastic work! I did something with the same components for a
> > >> hackday last year and it looked very promising - it's great to see it
> > >> fully
> > >> realized here. Although it's not difficult pulling the components
> > >> together,
> > >> it would be awesome to provide a turnkey (ala docker) solution that
> Just
> > >> Works.
> > >>
> > >> Even better is that you've included a statistics-to-grafana bridge.
> > >>
> > >> --Jens
> > >>
> > >> On Wed, Jan 11, 2017 at 3:42 AM, Christian Tzolov  >
> > >> wrote:
> > >>
> > >> I've been experimenting with Geode-to-Grafana integration options. The
> > >>> geode-dashboard (https://github.com/tzolov/geode-dashboard) project
> > uses
> > >>> Grafana dashboards for querying, visualizing and analysing Apache
> Geode
> > >>> (GemFire) historical and real-time metrics and statistics.
> > >>>
> > >>> An important goal was to provides an unified stack that can analyze
> > BOTH
> > >>> the real-time (JMX metrics) and the historical (archive files) Geode
> > >>> distributed-system statistics.
> > >>>
> > >>> The github documentation and the blogs below should explain the
> > approach:
> > >>> https://www.linkedin.com/pulse/visualize-analyse-
> > >>> apache-geode-gemfire-real-time-metrics-tzolov
> > >>> http://blog.tzolov.net/2017/01/visualize-and-analyse-
> > >>> apache-geode.html?view=sidebar
> > >>>
> > >>> At the moment the tool uses InfluxDB as a time-series DB.But i've
> been
> > >>> considering adding support for Ambari Metrics Collector System as an
> > >>> alternative time-series DB. Later is supported by Grafana (
> > >>> https://grafana.net/plugins/praj-ams-datasource) and Ambari in-turn
> > >>> integrates with Grafana (http://bit.ly/2j34aIX). So if we add to the
> > mix
> > >>> the Geode Ambari service (http://bit.ly/2jd0MbS) It will make a
> decent
> > >>> Hadoop friendly stack for Geode/Gemfire.
> > >>>
> > >>> Another even more interesting angle is to make Geode itself a Grafana
> > >>> compliant datasource (http://docs.grafana.org/plugins/datasources,
> > >>> https://grafana.net/plugins). So
> > >>>
> > >>> Do you think it would be worth bringing part of this work under Geode
> > >>> project umbrella?
> > >>>
> > >>> Cheers,
> > >>> Christian
> > >>>
> > >>> P.S. Note that this project focus on Geode metrics only but similar
> > >>> approach can be used to explore business time-series.
> > >>>
> > >>>
> > >>>
> > >
> >
> >
> > --
> > Greg Chase
> >
> > Product team
> > http://www.pivotal.io/big-data
> >
> > Pivotal Software
> > http://www.pivotal.io/
> >
> > 650-215-0477
> > @GregChase
> > Blog: http://geekmarketing.biz/
> >
>
>
>
> --
> -John
> john.blum10101 (skype)
>


[jira] [Created] (GEODE-2294) When executing a function, error messages are being lost

2017-01-11 Thread Kevin Duling (JIRA)
Kevin Duling created GEODE-2294:
---

 Summary: When executing a function, error messages are being lost
 Key: GEODE-2294
 URL: https://issues.apache.org/jira/browse/GEODE-2294
 Project: Geode
  Issue Type: Bug
  Components: rest (dev)
Reporter: Kevin Duling


In FunctionAccessController:

While debugging the execution of a function via the REST API, a null-pointer 
exception was thrown and should have returned the error:
{{Specified key is null and this region does not permit null keys!}}

instead, an error code of 0 is returned with the message:
{code}
{
  "error": "no response from server"
}
{code}





--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (GEODE-2294) When executing a function, error messages are being lost

2017-01-11 Thread Kirk Lund (JIRA)

[ 
https://issues.apache.org/jira/browse/GEODE-2294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15819018#comment-15819018
 ] 

Kirk Lund commented on GEODE-2294:
--

Need to capture some more info for this bug. How are you executing the 
Function? By default, most people will assume that you have a Java Client 
connected to a Server and using the Client API to execute the Function.

Also, a test case that reproduces the bug is highly recommended.


> When executing a function, error messages are being lost
> 
>
> Key: GEODE-2294
> URL: https://issues.apache.org/jira/browse/GEODE-2294
> Project: Geode
>  Issue Type: Bug
>  Components: rest (dev)
>Reporter: Kevin Duling
>
> In FunctionAccessController:
> While debugging the execution of a function via the REST API, a null-pointer 
> exception was thrown and should have returned the error:
> {{Specified key is null and this region does not permit null keys!}}
> instead, an error code of 0 is returned with the message:
> {code}
> {
>   "error": "no response from server"
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (GEODE-2294) When executing a function, error messages are being lost

2017-01-11 Thread Kirk Lund (JIRA)

[ 
https://issues.apache.org/jira/browse/GEODE-2294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15819023#comment-15819023
 ] 

Kirk Lund commented on GEODE-2294:
--

It would also be good to try executing the Function in multiple ways (from a 
Client, from a peer application, from GFSH) and compare the error handling of 
those different approaches.


> When executing a function, error messages are being lost
> 
>
> Key: GEODE-2294
> URL: https://issues.apache.org/jira/browse/GEODE-2294
> Project: Geode
>  Issue Type: Bug
>  Components: rest (dev)
>Reporter: Kevin Duling
>
> In FunctionAccessController:
> While debugging the execution of a function via the REST API, a null-pointer 
> exception was thrown and should have returned the error:
> {{Specified key is null and this region does not permit null keys!}}
> instead, an error code of 0 is returned with the message:
> {code}
> {
>   "error": "no response from server"
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[GitHub] geode pull request #334: Feature/geode 2031

2017-01-11 Thread joeymcallister
GitHub user joeymcallister opened a pull request:

https://github.com/apache/geode/pull/334

Feature/geode 2031

This PR accomplishes a few things:
1. As outlined in the GEODE-2031 ticket, I've adjusted the flow so we can 
now publish older versions of the docs in addition to the latest version. To do 
this, you build the User Guide, add it to a version-specific directory in 
`geode-site/website/content/docs/guide/NN` (where `NN` is the product version 
number—e.g., Apache Geode 1.0 is `../docs/guide/10`), and point to them from 
the Docs page on the website.
2. In order to do item 1, I fixed/simplified the complicated way we were 
previously publishing the documents by building the GEODE website and then 
shoehorning the docs HTML in at the end. Now, a built User Guide has a 
permanent home with the other website source pages.
3. I edited some docs/website READMEs to account for the changes in items 1 
and 2.
4. I made some minor website edits for clarity.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/joeymcallister/geode feature/GEODE-2031

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/geode/pull/334.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #334


commit fc1396f55bda21419a390c4ee4292b1ae30aaf7e
Author: joeymcallister 
Date:   2017-01-10T18:36:30Z

GEODE-2031 Add docs archive

commit 0a9e79ac5dffc9b35ad697607310d47e00f90582
Author: joeymcallister 
Date:   2017-01-10T20:32:40Z

GEODE-2031 Edit Nanoc config/rules to use extensions

commit 46f4d27921c2f9281656ee7fbfa4a46d2ce0589e
Author: joeymcallister 
Date:   2017-01-11T00:44:12Z

GEODE-2031 Edit nanoc for file extensions

commit a4af953a4e97997771714c16f6f98756fb1fe436
Author: joeymcallister 
Date:   2017-01-11T00:46:19Z

GEODE-2031 Add Geode 1.0 docs to geode-site

commit 719da4b26bf72bea8986b5126283e27369667585
Author: joeymcallister 
Date:   2017-01-11T01:22:00Z

GEODE-2031 More docs-related site changes

commit fdf86b6d508508341c4263be2a58d94ce6a8311f
Author: joeymcallister 
Date:   2017-01-11T01:27:06Z

GEODE-2031 Add titles to index pages

commit 171af8126e87e0508cb6d241d80002d2c4e153e5
Author: joeymcallister 
Date:   2017-01-11T20:08:50Z

GEODE-2031 Update README instructions for docs, website




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[jira] [Commented] (GEODE-2031) Host documentation for releases

2017-01-11 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/GEODE-2031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15819068#comment-15819068
 ] 

ASF GitHub Bot commented on GEODE-2031:
---

GitHub user joeymcallister opened a pull request:

https://github.com/apache/geode/pull/334

Feature/geode 2031

This PR accomplishes a few things:
1. As outlined in the GEODE-2031 ticket, I've adjusted the flow so we can 
now publish older versions of the docs in addition to the latest version. To do 
this, you build the User Guide, add it to a version-specific directory in 
`geode-site/website/content/docs/guide/NN` (where `NN` is the product version 
number—e.g., Apache Geode 1.0 is `../docs/guide/10`), and point to them from 
the Docs page on the website.
2. In order to do item 1, I fixed/simplified the complicated way we were 
previously publishing the documents by building the GEODE website and then 
shoehorning the docs HTML in at the end. Now, a built User Guide has a 
permanent home with the other website source pages.
3. I edited some docs/website READMEs to account for the changes in items 1 
and 2.
4. I made some minor website edits for clarity.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/joeymcallister/geode feature/GEODE-2031

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/geode/pull/334.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #334


commit fc1396f55bda21419a390c4ee4292b1ae30aaf7e
Author: joeymcallister 
Date:   2017-01-10T18:36:30Z

GEODE-2031 Add docs archive

commit 0a9e79ac5dffc9b35ad697607310d47e00f90582
Author: joeymcallister 
Date:   2017-01-10T20:32:40Z

GEODE-2031 Edit Nanoc config/rules to use extensions

commit 46f4d27921c2f9281656ee7fbfa4a46d2ce0589e
Author: joeymcallister 
Date:   2017-01-11T00:44:12Z

GEODE-2031 Edit nanoc for file extensions

commit a4af953a4e97997771714c16f6f98756fb1fe436
Author: joeymcallister 
Date:   2017-01-11T00:46:19Z

GEODE-2031 Add Geode 1.0 docs to geode-site

commit 719da4b26bf72bea8986b5126283e27369667585
Author: joeymcallister 
Date:   2017-01-11T01:22:00Z

GEODE-2031 More docs-related site changes

commit fdf86b6d508508341c4263be2a58d94ce6a8311f
Author: joeymcallister 
Date:   2017-01-11T01:27:06Z

GEODE-2031 Add titles to index pages

commit 171af8126e87e0508cb6d241d80002d2c4e153e5
Author: joeymcallister 
Date:   2017-01-11T20:08:50Z

GEODE-2031 Update README instructions for docs, website




> Host documentation for releases
> ---
>
> Key: GEODE-2031
> URL: https://issues.apache.org/jira/browse/GEODE-2031
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Anthony Baker
>Assignee: Joey McAllister
> Fix For: 1.1.0
>
>
> Currently we overwrite documentation hosted on geode.apache.org with every 
> release.  We should allow a user to browse the documentation (user guide + 
> javadocs) for past releases, not just the most recent release.
> Improvement:
> 1) The documentation page always points to the docs for the latest release.
> 2) There is a documentation link associated with each release just like we do 
> release links for source and binary artifacts.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[GitHub] geode pull request #334: Feature/geode 2031

2017-01-11 Thread davebarnes97
Github user davebarnes97 commented on a diff in the pull request:

https://github.com/apache/geode/pull/334#discussion_r95665599
  
--- Diff: geode-book/README.md ---
@@ -63,30 +63,19 @@ For Geode, a preconfigured **book** is provided in the 
directory `{geode-project
 
You can now view the local documentation at . 
 
-## Embedding the User Guide in the Geode Website
+## Publishing the User Guide to the Geode Website
 
-Once you have reviewed your local build of the User Guide, you can embed 
it in the Apache Geode website by doing the following:
+Once you have reviewed your local build of the User Guide, you can move it 
in the Apache Geode website by doing the following:
--- End diff --

..you can move it **_to_** the Apache Geode website..


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[jira] [Commented] (GEODE-2294) When executing a function, error messages are being lost

2017-01-11 Thread Kevin Duling (JIRA)

[ 
https://issues.apache.org/jira/browse/GEODE-2294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15819105#comment-15819105
 ] 

Kevin Duling commented on GEODE-2294:
-

This problem is not related to the function itself or gfsh.  It's with the REST 
controller, which is why the component is marked as {{rest (dev)}}.  It is in 
the execute() method in 
org.apache.geode.rest.internal.web.controllers.FunctionAccessController.  The 
only way to reproduce this is via a REST client, be it Swagger, Postman, curl 
or whatever.

When an exception is thrown, it is caught and wrapped in to a 
GemfireRestException, assigned a text error, and rethrown.

What should be happening is that the exception should be captured by 
BaseControllerAdvice and properly wrapped in to a well-formed JSON response.

The specific error doesn't matter, it's the fact that GemFireRestExeption isn't 
being handled properly by the REST framework to return a well-formed error code 
and message.

> When executing a function, error messages are being lost
> 
>
> Key: GEODE-2294
> URL: https://issues.apache.org/jira/browse/GEODE-2294
> Project: Geode
>  Issue Type: Bug
>  Components: rest (dev)
>Reporter: Kevin Duling
>
> In FunctionAccessController:
> While debugging the execution of a function via the REST API, a null-pointer 
> exception was thrown and should have returned the error:
> {{Specified key is null and this region does not permit null keys!}}
> instead, an error code of 0 is returned with the message:
> {code}
> {
>   "error": "no response from server"
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Comment Edited] (GEODE-2294) When executing a function, error messages are being lost

2017-01-11 Thread Kevin Duling (JIRA)

[ 
https://issues.apache.org/jira/browse/GEODE-2294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15819105#comment-15819105
 ] 

Kevin Duling edited comment on GEODE-2294 at 1/11/17 8:41 PM:
--

This problem is not related to the function itself or gfsh.  It's with the REST 
controller, which is why the component is marked as {{rest (dev)}}.  It is in 
the execute() method in 
{{org.apache.geode.rest.internal.web.controllers.FunctionAccessController}}.  
The only way to reproduce this is via a REST client, be it Swagger, Postman, 
curl or whatever.

When an exception is thrown, it is caught and wrapped in to a 
GemfireRestException, assigned a text error, and rethrown.

What should be happening is that the exception should be captured by 
BaseControllerAdvice and properly wrapped in to a well-formed JSON response.

The specific error doesn't matter, it's the fact that GemFireRestExeption isn't 
being handled properly by the REST framework to return a well-formed error code 
and message.


was (Author: kduling):
This problem is not related to the function itself or gfsh.  It's with the REST 
controller, which is why the component is marked as {{rest (dev)}}.  It is in 
the execute() method in 
org.apache.geode.rest.internal.web.controllers.FunctionAccessController.  The 
only way to reproduce this is via a REST client, be it Swagger, Postman, curl 
or whatever.

When an exception is thrown, it is caught and wrapped in to a 
GemfireRestException, assigned a text error, and rethrown.

What should be happening is that the exception should be captured by 
BaseControllerAdvice and properly wrapped in to a well-formed JSON response.

The specific error doesn't matter, it's the fact that GemFireRestExeption isn't 
being handled properly by the REST framework to return a well-formed error code 
and message.

> When executing a function, error messages are being lost
> 
>
> Key: GEODE-2294
> URL: https://issues.apache.org/jira/browse/GEODE-2294
> Project: Geode
>  Issue Type: Bug
>  Components: rest (dev)
>Reporter: Kevin Duling
>
> In FunctionAccessController:
> While debugging the execution of a function via the REST API, a null-pointer 
> exception was thrown and should have returned the error:
> {{Specified key is null and this region does not permit null keys!}}
> instead, an error code of 0 is returned with the message:
> {code}
> {
>   "error": "no response from server"
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (GEODE-2294) When attempting to execute a function via Dev Rest API, error messages are being lost

2017-01-11 Thread Kevin Duling (JIRA)

 [ 
https://issues.apache.org/jira/browse/GEODE-2294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kevin Duling updated GEODE-2294:

Summary: When attempting to execute a function via Dev Rest API, error 
messages are being lost  (was: When executing a function, error messages are 
being lost)

> When attempting to execute a function via Dev Rest API, error messages are 
> being lost
> -
>
> Key: GEODE-2294
> URL: https://issues.apache.org/jira/browse/GEODE-2294
> Project: Geode
>  Issue Type: Bug
>  Components: rest (dev)
>Reporter: Kevin Duling
>
> In FunctionAccessController:
> While debugging the execution of a function via the REST API, a null-pointer 
> exception was thrown and should have returned the error:
> {{Specified key is null and this region does not permit null keys!}}
> instead, an error code of 0 is returned with the message:
> {code}
> {
>   "error": "no response from server"
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Comment Edited] (GEODE-2294) When attempting to execute a function via Dev Rest API, error messages are being lost

2017-01-11 Thread Kevin Duling (JIRA)

[ 
https://issues.apache.org/jira/browse/GEODE-2294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15819105#comment-15819105
 ] 

Kevin Duling edited comment on GEODE-2294 at 1/11/17 8:51 PM:
--

This problem is not related to the function itself or gfsh.  It's with the REST 
controller, which is why the component is marked as {{rest (dev)}}.  It is in 
the execute() method in 
{{org.apache.geode.rest.internal.web.controllers.FunctionAccessController}}.  
The only way to reproduce this is via a REST client, be it Swagger, Postman, 
curl or whatever.

The controller attempts to validate all of the parameters prior to actually 
executing the function.  If an exception is thrown at this stage, it is caught 
and wrapped in to a GemfireRestException, assigned a text error, and rethrown 
so that the comm framework will return an error to the requesting client.

What should be happening is that the exception should be captured by 
BaseControllerAdvice and properly wrapped in to a well-formed JSON response.

The specific error doesn't matter, it's the fact that GemFireRestExeption isn't 
being handled properly by the REST framework to return a well-formed error code 
and message.


was (Author: kduling):
This problem is not related to the function itself or gfsh.  It's with the REST 
controller, which is why the component is marked as {{rest (dev)}}.  It is in 
the execute() method in 
{{org.apache.geode.rest.internal.web.controllers.FunctionAccessController}}.  
The only way to reproduce this is via a REST client, be it Swagger, Postman, 
curl or whatever.

When an exception is thrown, it is caught and wrapped in to a 
GemfireRestException, assigned a text error, and rethrown.

What should be happening is that the exception should be captured by 
BaseControllerAdvice and properly wrapped in to a well-formed JSON response.

The specific error doesn't matter, it's the fact that GemFireRestExeption isn't 
being handled properly by the REST framework to return a well-formed error code 
and message.

> When attempting to execute a function via Dev Rest API, error messages are 
> being lost
> -
>
> Key: GEODE-2294
> URL: https://issues.apache.org/jira/browse/GEODE-2294
> Project: Geode
>  Issue Type: Bug
>  Components: rest (dev)
>Reporter: Kevin Duling
>
> In FunctionAccessController:
> While debugging the execution of a function via the REST API, a null-pointer 
> exception was thrown and should have returned the error:
> {{Specified key is null and this region does not permit null keys!}}
> instead, an error code of 0 is returned with the message:
> {code}
> {
>   "error": "no response from server"
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (GEODE-182) Generate "random" member names if no name is provided

2017-01-11 Thread Anthony Baker (JIRA)

 [ 
https://issues.apache.org/jira/browse/GEODE-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Anthony Baker updated GEODE-182:

Fix Version/s: 1.1.0

> Generate "random" member names if no name is provided
> -
>
> Key: GEODE-182
> URL: https://issues.apache.org/jira/browse/GEODE-182
> Project: Geode
>  Issue Type: New Feature
>  Components: configuration
>Reporter: William Markito Oliveira
>Assignee: Kirk Lund
>Priority: Minor
> Fix For: 1.1.0
>
>
> In current cloud and container deployments it's very common to allow the 
> infrastructure to just re-execute the same command in order to provision a 
> new node for a system.
> Since Geode require unique member names on a system I'm proposing to create 
> something similar to what Docker and other projects does and generate 
> "random" names on when none are provided.
> Following the Docker implementation, I'd suggest something like:
> * List of adjectives
> * List of gems 
> and a combination using _ for example:
> {code}
> clever_alexandrite
> sharp_emerald
> tender_sapphire
> {code}
> Those would be server names when *-name* param is not specified OR if a 
> *property file* doesn't have a name as well. 
> From the initial list I'm thinking the model would have:
> * Adjectives = 56
> * Names = 70
> * Total names possible = 3920
> Other benefits I can see for non-cloud deployments as well is for example 
> setting member ports to 0 and by providing no name, it's also easier to 
> create multiple geode nodes on the same physical host without specifying 
> names.
> This wouldn't change current naming features and capabilities.  I'm not 
> planning to implement the feature for locators initially.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (GEODE-182) Generate "random" member names if no name is provided

2017-01-11 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/GEODE-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15819389#comment-15819389
 ] 

ASF subversion and git services commented on GEODE-182:
---

Commit feb2a0fcbff995e71c293ac2726f78081d366599 in geode's branch 
refs/heads/develop from [~amb]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=feb2a0f ]

GEODE-182: Auto-generate member names if needed

When a user runs `start server` or `start locator` from gfsh
without specifying the member name, gfsh will automatically pick
a random member name. This is useful for automation.


> Generate "random" member names if no name is provided
> -
>
> Key: GEODE-182
> URL: https://issues.apache.org/jira/browse/GEODE-182
> Project: Geode
>  Issue Type: New Feature
>  Components: configuration
>Reporter: William Markito Oliveira
>Assignee: Kirk Lund
>Priority: Minor
> Fix For: 1.1.0
>
>
> In current cloud and container deployments it's very common to allow the 
> infrastructure to just re-execute the same command in order to provision a 
> new node for a system.
> Since Geode require unique member names on a system I'm proposing to create 
> something similar to what Docker and other projects does and generate 
> "random" names on when none are provided.
> Following the Docker implementation, I'd suggest something like:
> * List of adjectives
> * List of gems 
> and a combination using _ for example:
> {code}
> clever_alexandrite
> sharp_emerald
> tender_sapphire
> {code}
> Those would be server names when *-name* param is not specified OR if a 
> *property file* doesn't have a name as well. 
> From the initial list I'm thinking the model would have:
> * Adjectives = 56
> * Names = 70
> * Total names possible = 3920
> Other benefits I can see for non-cloud deployments as well is for example 
> setting member ports to 0 and by providing no name, it's also easier to 
> create multiple geode nodes on the same physical host without specifying 
> names.
> This wouldn't change current naming features and capabilities.  I'm not 
> planning to implement the feature for locators initially.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Resolved] (GEODE-182) Generate "random" member names if no name is provided

2017-01-11 Thread Anthony Baker (JIRA)

 [ 
https://issues.apache.org/jira/browse/GEODE-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Anthony Baker resolved GEODE-182.
-
Resolution: Fixed

> Generate "random" member names if no name is provided
> -
>
> Key: GEODE-182
> URL: https://issues.apache.org/jira/browse/GEODE-182
> Project: Geode
>  Issue Type: New Feature
>  Components: configuration
>Reporter: William Markito Oliveira
>Assignee: Kirk Lund
>Priority: Minor
> Fix For: 1.1.0
>
>
> In current cloud and container deployments it's very common to allow the 
> infrastructure to just re-execute the same command in order to provision a 
> new node for a system.
> Since Geode require unique member names on a system I'm proposing to create 
> something similar to what Docker and other projects does and generate 
> "random" names on when none are provided.
> Following the Docker implementation, I'd suggest something like:
> * List of adjectives
> * List of gems 
> and a combination using _ for example:
> {code}
> clever_alexandrite
> sharp_emerald
> tender_sapphire
> {code}
> Those would be server names when *-name* param is not specified OR if a 
> *property file* doesn't have a name as well. 
> From the initial list I'm thinking the model would have:
> * Adjectives = 56
> * Names = 70
> * Total names possible = 3920
> Other benefits I can see for non-cloud deployments as well is for example 
> setting member ports to 0 and by providing no name, it's also easier to 
> create multiple geode nodes on the same physical host without specifying 
> names.
> This wouldn't change current naming features and capabilities.  I'm not 
> planning to implement the feature for locators initially.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Resolved] (GEODE-2166) testStartTwoLocatorsOneWithSSLAndTheOtherNonSSL FAILED with suspect string

2017-01-11 Thread Hitesh Khamesra (JIRA)

 [ 
https://issues.apache.org/jira/browse/GEODE-2166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hitesh Khamesra resolved GEODE-2166.

Resolution: Duplicate

GEODE-1793

> testStartTwoLocatorsOneWithSSLAndTheOtherNonSSL FAILED with suspect string
> --
>
> Key: GEODE-2166
> URL: https://issues.apache.org/jira/browse/GEODE-2166
> Project: Geode
>  Issue Type: Bug
>  Components: membership
>Reporter: Hitesh Khamesra
>
> org.apache.geode.distributed.LocatorUDPSecurityDUnitTest > 
> testStartTwoLocatorsOneWithSSLAndTheOtherNonSSL FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.test.dunit.NamedRunnable.run in VM 2 running on Host 
> 037366ebf0ff with 4 VMs
> Caused by:
> org.apache.geode.SystemConnectException: Problem starting up 
> membership services
> Caused by:
> 
> org.apache.geode.distributed.internal.tcpserver.LocatorCancelException
> java.lang.AssertionError: Suspicious strings were written to the log 
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 934
> [error 2016/11/15 21:05:50.448 UTC  
> tid=0x1e] Unexpected problem starting up membership services
> org.apache.geode.distributed.internal.tcpserver.LocatorCancelException
>   at 
> org.apache.geode.distributed.internal.tcpserver.TcpClient.getServerVersion(TcpClient.java:285)
>   at 
> org.apache.geode.distributed.internal.tcpserver.TcpClient.requestToServer(TcpClient.java:165)
>   at 
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave$TcpClientWrapper.sendCoordinatorFindRequest(GMSJoinLeave.java:1153)
>   at 
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.findCoordinator(GMSJoinLeave.java:1066)
>   at 
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.join(GMSJoinLeave.java:306)
>   at 
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.join(GMSMembershipManager.java:656)
>   at 
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.joinDistributedSystem(GMSMembershipManager.java:745)
>   at 
> org.apache.geode.distributed.internal.membership.gms.Services.start(Services.java:181)
>   at 
> org.apache.geode.distributed.internal.membership.gms.GMSMemberFactory.newMembershipManager(GMSMemberFactory.java:102)
>   at 
> org.apache.geode.distributed.internal.membership.MemberFactory.newMembershipManager(MemberFactory.java:89)
>   at 
> org.apache.geode.distributed.internal.DistributionManager.(DistributionManager.java:1112)
>   at 
> org.apache.geode.distributed.internal.DistributionManager.(DistributionManager.java:1160)
>   at 
> org.apache.geode.distributed.internal.DistributionManager.create(DistributionManager.java:531)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:683)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:297)
>   at 
> org.apache.geode.distributed.DistributedSystem.connect(DistributedSystem.java:202)
>   at 
> org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:751)
>   at 
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:380)
>   at 
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:322)
>   at org.apache.geode.distributed.Locator.startLocator(Locator.java:255)
>   at 
> org.apache.geode.distributed.Locator.startLocatorAndDS(Locator.java:142)
>   at 
> org.apache.geode.distributed.LocatorDUnitTest.startLocator(LocatorDUnitTest.java:645)
>   at 
> org.apache.geode.distributed.LocatorDUnitTest.lambda$testStartTwoLocatorsOneWithSSLAndTheOtherNonSSL$1965b9f9$1(LocatorDUnitTest.java:493)
>   at org.apache.geode.test.dunit.NamedRunnable.run(NamedRunnable.java:31)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at hydra.MethExecutor.executeObject(MethExecutor.java:245)
>   at 
> org.apache.geode.test.dunit.standalone.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:73)
>   at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImp

Re: Visualize Geode Metrics/Stats with Grafana Dashboards

2017-01-11 Thread Kirk Lund
+1 I'm definitely interested in bringing part or all of this into Apache
Geode! Great work. This is a huge improvement over Pulse.


On Wed, Jan 11, 2017 at 3:42 AM, Christian Tzolov 
wrote:

> I've been experimenting with Geode-to-Grafana integration options. The
> geode-dashboard (https://github.com/tzolov/geode-dashboard) project uses
> Grafana dashboards for querying, visualizing and analysing Apache Geode
> (GemFire) historical and real-time metrics and statistics.
>
> An important goal was to provides an unified stack that can analyze BOTH
> the real-time (JMX metrics) and the historical (archive files) Geode
> distributed-system statistics.
>
> The github documentation and the blogs below should explain the approach:
> https://www.linkedin.com/pulse/visualize-analyse-
> apache-geode-gemfire-real-time-metrics-tzolov
> http://blog.tzolov.net/2017/01/visualize-and-analyse-
> apache-geode.html?view=sidebar
>
> At the moment the tool uses InfluxDB as a time-series DB.But i've been
> considering adding support for Ambari Metrics Collector System as an
> alternative time-series DB. Later is supported by Grafana (
> https://grafana.net/plugins/praj-ams-datasource) and Ambari in-turn
> integrates with Grafana (http://bit.ly/2j34aIX). So if we add to the mix
> the Geode Ambari service (http://bit.ly/2jd0MbS) It will make a decent
> Hadoop friendly stack for Geode/Gemfire.
>
> Another even more interesting angle is to make Geode itself a Grafana
> compliant datasource (http://docs.grafana.org/plugins/datasources,
> https://grafana.net/plugins). So
>
> Do you think it would be worth bringing part of this work under Geode
> project umbrella?
>
> Cheers,
> Christian
>
> P.S. Note that this project focus on Geode metrics only but similar
> approach can be used to explore business time-series.
>
>


Re: Visualize Geode Metrics/Stats with Grafana Dashboards

2017-01-11 Thread Dan Smith
+1 This looks awesome! Looks like grafana is apache licensed, so that
shouldn't be a problem with integrating this.

-Dan

On Wed, Jan 11, 2017 at 3:42 AM, Christian Tzolov  wrote:
> I've been experimenting with Geode-to-Grafana integration options. The
> geode-dashboard (https://github.com/tzolov/geode-dashboard) project uses
> Grafana dashboards for querying, visualizing and analysing Apache Geode
> (GemFire) historical and real-time metrics and statistics.
>
> An important goal was to provides an unified stack that can analyze BOTH the
> real-time (JMX metrics) and the historical (archive files) Geode
> distributed-system statistics.
>
> The github documentation and the blogs below should explain the approach:
> https://www.linkedin.com/pulse/visualize-analyse-apache-geode-gemfire-real-time-metrics-tzolov
> http://blog.tzolov.net/2017/01/visualize-and-analyse-apache-geode.html?view=sidebar
>
> At the moment the tool uses InfluxDB as a time-series DB.But i've been
> considering adding support for Ambari Metrics Collector System as an
> alternative time-series DB. Later is supported by Grafana
> (https://grafana.net/plugins/praj-ams-datasource) and Ambari in-turn
> integrates with Grafana (http://bit.ly/2j34aIX). So if we add to the mix the
> Geode Ambari service (http://bit.ly/2jd0MbS) It will make a decent Hadoop
> friendly stack for Geode/Gemfire.
>
> Another even more interesting angle is to make Geode itself a Grafana
> compliant datasource (http://docs.grafana.org/plugins/datasources,
> https://grafana.net/plugins). So
>
> Do you think it would be worth bringing part of this work under Geode
> project umbrella?
>
> Cheers,
> Christian
>
> P.S. Note that this project focus on Geode metrics only but similar approach
> can be used to explore business time-series.
>


Reviews for GEODE-1930

2017-01-11 Thread Kirk Lund
I need some reviews for GEODE-1930: https://issues.apache.org/
jira/browse/GEODE-1930

These changes involve the test tree. It's not complete but it's part of the
way towards overhauling the JMX tests. I need to get this merged in and
then continue one test or other change at a time. The problem is conflicts
from other commits, I already had to throw away my rewrite of one test.


Re: Reviews for GEODE-1930

2017-01-11 Thread Jared Stewart
I’ll take a look. 

-Jared
> On Jan 11, 2017, at 4:32 PM, Kirk Lund  wrote:
> 
> I need some reviews for GEODE-1930: https://issues.apache.org/
> jira/browse/GEODE-1930
> 
> These changes involve the test tree. It's not complete but it's part of the
> way towards overhauling the JMX tests. I need to get this merged in and
> then continue one test or other change at a time. The problem is conflicts
> from other commits, I already had to throw away my rewrite of one test.



[jira] [Updated] (GEODE-2031) Host documentation for releases

2017-01-11 Thread Joey McAllister (JIRA)

 [ 
https://issues.apache.org/jira/browse/GEODE-2031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joey McAllister updated GEODE-2031:
---
Priority: Minor  (was: Major)

> Host documentation for releases
> ---
>
> Key: GEODE-2031
> URL: https://issues.apache.org/jira/browse/GEODE-2031
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Anthony Baker
>Assignee: Joey McAllister
>Priority: Minor
> Fix For: 1.1.0
>
>
> Currently we overwrite documentation hosted on geode.apache.org with every 
> release.  We should allow a user to browse the documentation (user guide + 
> javadocs) for past releases, not just the most recent release.
> Improvement:
> 1) The documentation page always points to the docs for the latest release.
> 2) There is a documentation link associated with each release just like we do 
> release links for source and binary artifacts.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[GitHub] geode pull request #334: Feature/geode 2031

2017-01-11 Thread joeymcallister
Github user joeymcallister commented on a diff in the pull request:

https://github.com/apache/geode/pull/334#discussion_r95706396
  
--- Diff: geode-book/README.md ---
@@ -63,30 +63,19 @@ For Geode, a preconfigured **book** is provided in the 
directory `{geode-project
 
You can now view the local documentation at . 
 
-## Embedding the User Guide in the Geode Website
+## Publishing the User Guide to the Geode Website
 
-Once you have reviewed your local build of the User Guide, you can embed 
it in the Apache Geode website by doing the following:
+Once you have reviewed your local build of the User Guide, you can move it 
in the Apache Geode website by doing the following:
--- End diff --

Good catch. Thank you!


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[jira] [Created] (GEODE-2295) LocatorCancelException ignores string passed in constructor

2017-01-11 Thread Galen O'Sullivan (JIRA)
Galen O'Sullivan created GEODE-2295:
---

 Summary: LocatorCancelException ignores string passed in 
constructor
 Key: GEODE-2295
 URL: https://issues.apache.org/jira/browse/GEODE-2295
 Project: Geode
  Issue Type: Bug
Reporter: Galen O'Sullivan


The` LocatorCancelException` class has a constructor that takes a String and 
fails to call `super`. This should be fixed so that the exception produces a 
useful message.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


Re: Review Request 55398: GEODE-1930: change several Management dunit tests to use ManagementTestRule

2017-01-11 Thread Jared Stewart

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/55398/#review161338
---


Ship it!




+1 

I believe `DistributedRunRule` is unused, and `DistributedStatement` is only 
used inside of `DistributedRunRule`.  Do you plan to use them later?  

It looked to me like RemoteInvoker::invokeEverywhere used to invoke in locators 
but RemoteInvoker::invokeInEveryVMAndController no longer does invoke in 
locators.  Was this intentional?

- Jared Stewart


On Jan. 11, 2017, 12:07 a.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/55398/
> ---
> 
> (Updated Jan. 11, 2017, 12:07 a.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, and Kevin Duling.
> 
> 
> Bugs: GEODE-1930
> https://issues.apache.org/jira/browse/GEODE-1930
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> I was going to submit this after converting all of the Management dunit 
> tests, but I've already lost the changes I made to LocatorManagementDUnitTest 
> due to conflicts with another commit for GEODE-1893. I'd like to merge what I 
> have so far to develop and then we can cleanup the ManagementTestRule further 
> and convert the remaineder of Management dunit tests.
> 
> There are also a lot of tests using ManagementTestBase in unexpected ways. I 
> removed those.
> 
> 
> Diffs
> -
> 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/controllers/RestAPIsAndInterOpsDUnitTest.java
>  c90a7a4b6d5568e8d25d54f5191648c314a481ed 
>   geode-core/build.gradle 49dd84b387867e0189892ba096d35a2483c0ee37 
>   geode-core/src/main/java/org/apache/geode/management/JVMMetrics.java 
> 127592a5fc75032d430be171d275f6982fc49854 
>   geode-core/src/main/java/org/apache/geode/management/OSMetrics.java 
> d90c8be1268a5758742ad9e1fd188638de541c9e 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/SystemManagementService.java
>  cb755916d86af1d83f6f619fd77abc7147f5a56f 
>   
> geode-core/src/test/java/org/apache/geode/distributed/DistributedLockServiceDUnitTest.java
>  277c6046a36e32cc0fb53f6c8c53a02e10c826e1 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/ConnectDisconnectDUnitTest.java
>  de6343304cefa39ac353e8b692f1f10b03ce0de3 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/PartitionedRegionBucketCreationDistributionDUnitTest.java
>  ed23f2add324a5402405623972ce1160816371d7 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/locks/TXLockServiceDUnitTest.java
>  14267a4cc910aa37c5ab92eff53dee16d19c80eb 
>   
> geode-core/src/test/java/org/apache/geode/management/CacheManagementDUnitTest.java
>  680579d47070a593b00045eec75a5b6a7dd261fa 
>   
> geode-core/src/test/java/org/apache/geode/management/ClientHealthStatsDUnitTest.java
>  a3c8b27bb170ef07e24142da66b2d5ccb17cf959 
>   
> geode-core/src/test/java/org/apache/geode/management/CompositeTypeTestDUnitTest.java
>  9c33003639751420b505ce0234d64dfe6bd85ffd 
>   
> geode-core/src/test/java/org/apache/geode/management/DLockManagementDUnitTest.java
>  86501c31dbca3c06718472c902112cc62301c852 
>   
> geode-core/src/test/java/org/apache/geode/management/DiskManagementDUnitTest.java
>  bcfadde1035a4092d130e43cf617cd4da67345c0 
>   
> geode-core/src/test/java/org/apache/geode/management/DistributedSystemDUnitTest.java
>  4eaba67db0a9a8a811c511814cdb1236c7400f51 
>   geode-core/src/test/java/org/apache/geode/management/JMXMBeanDUnitTest.java 
> 0feb4c25a957eeeb29a34a90227b01257a92a600 
>   
> geode-core/src/test/java/org/apache/geode/management/LocatorManagementDUnitTest.java
>  205ada535dd0e38e008f0443b010877729936d16 
>   
> geode-core/src/test/java/org/apache/geode/management/ManagementTestBase.java 
> 85d42ee35402fb44282244c75d61caba70491b9e 
>   
> geode-core/src/test/java/org/apache/geode/management/ManagementTestRule.java 
> PRE-CREATION 
>   geode-core/src/test/java/org/apache/geode/management/Manager.java 
> PRE-CREATION 
>   geode-core/src/test/java/org/apache/geode/management/Member.java 
> PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/management/OffHeapManagementDUnitTest.java
>  289d6d73822fbfd4fcbfb2298f7c43afe6df40f9 
>   
> geode-core/src/test/java/org/apache/geode/management/QueryDataDUnitTest.java 
> 1773a27531331ea3d3169d73246ec0742457f9f1 
>   
> geode-core/src/test/java/org/apache/geode/management/RegionManagementDUnitTest.java
>  fcdc3a416ffc19044f9385d779b362e0b449f4f5 
>   
> geode-core/src/test/java/org/apache/geode/management/bean/stats/DistributedSystemStatsDUnitTest.java
>  d2e797ea7b6525a27ed45794c3f620cdc2552f37 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/beans/QueryDataFunctionApplyLimitClauseTest.java
> 

Review Request 55440: GEODE-1733: Index repository is now created when the chunk bucket becomes primary.

2017-01-11 Thread nabarun nag

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/55440/
---

Review request for geode, Barry Oglesby, Jason Huynh, Dan Smith, and xiaojian 
zhou.


Repository: geode


Description
---

Issue(Steps are using GFSH as mentioned in the ticket):
1. Indexes are created, and documents are inserted into a persistent region.
2. Server is restarted.
3. Immediately displaying the lucene index stats shows no documents are indexed
4. Run a lucene query, which gets executed successfully.
5. Now, displaying index stats with "list lucene index --with-stats" shows the 
actual number of documents indexed.


Reason:
Number of documents indexed is taken from the IndexWriter, which is created 
lazily when a lucene query is executed. Hence when a persistent server is 
restarted or a rebalance occurs we lose the stats for number of documents 
indexed until the IndexWriter is created when a lucene query is executed.

Solution:
We attached a listener to each chunk bucket so that when a bucket becomes 
primary, it initiates the process to create the IndexReposity for the bucket 
which creates the IndexWriter, thus we get stat for number of documents 
immediately after a rebalance or a restart occurs.
When a bucket becomes secondary, it removes its document count from the stats.


NOTE: IndexWriter can be created only when we have both chuck and file primary 
bucket present. There can be a possibility that chuck bucket became primary but 
the file bucket was still in the process of becoming primary hence the 
IndexRepository creation will result in BucketNotFoundException. If this 
happens we log a warning and defer the index repository to be created lazily 
during query excution. Rather than shutting the system down with an exception 
we give it second chance.


Diffs
-

  
geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/LuceneIndexForPartitionedRegion.java
 f8bbc41 
  
geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/LucenePrimaryBucketListener.java
 PRE-CREATION 
  
geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/repository/IndexRepositoryImpl.java
 572b5ea 
  
geode-lucene/src/test/java/org/apache/geode/cache/lucene/internal/LuceneIndexForPartitionedRegionTest.java
 cec3734 
  
geode-lucene/src/test/java/org/apache/geode/cache/lucene/internal/repository/IndexRepositoryImplJUnitTest.java
 dd52258 

Diff: https://reviews.apache.org/r/55440/diff/


Testing
---

1. Precheckin
2. Running gfsh commands to create a persistent server and restarting it and 
checking the stats are correct.
3. Running gfsh command to create two servers and shutting / restarting them 
alternatively and checking if the stats remain correct after the primary 
buckets are moved around.


Thanks,

nabarun nag



Review Request 55442: GEODE-2273: Adding a server column to the Lucene index stat

2017-01-11 Thread nabarun nag

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/55442/
---

Review request for geode, Barry Oglesby, Jason Huynh, Dan Smith, and xiaojian 
zhou.


Repository: geode


Description
---

Issue: 

Initially:
We could not link the index information to the server storing the index.

```
Index Name | Region Path | Indexed Fields | Field Analyzer |   Status   
 | Query Executions | Updates | Commits | Documents
-- | --- | -- | -- | 
--- |  | --- | --- | -
testIndex  | /testRegion | [__REGION_VALUE_FIELD] | {} | 
Initialized | 0| 3   | 3   | 2
testIndex  | /testRegion | [__REGION_VALUE_FIELD] | {} | 
Initialized | 0| 0   | 0   | 1
```


Solution: Added a server column.
```
Index Name | Region Path |Server Name | 
Indexed Fields | Field Analyzer |   Status| Query Executions | Updates 
| Commits | Documents
-- | --- | -- | 
-- | -- | --- |  | 
--- | --- | -
testIndex  | /testRegion | server2 -- 10.0.0.8(server2:2814):1026 | 
[__REGION_VALUE_FIELD] | {} | Initialized | 0| 0
   | 0   | 2
testIndex  | /testRegion | server1 -- 10.0.0.8(server1:3037):1025 | 
[__REGION_VALUE_FIELD] | {} | Initialized | 0| 0
   | 0   | 1
```


Diffs
-

  
geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/cli/LuceneIndexCommands.java
 6a5a1e0 
  
geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/cli/LuceneIndexDetails.java
 cc96df2 

Diff: https://reviews.apache.org/r/55442/diff/


Testing
---

1. Precheck
2. Running it on gfsh terminal


Thanks,

nabarun nag



[jira] [Resolved] (GEODE-2049) unit of measure wrong in DistributionStats tcpFinalCheck statitistics

2017-01-11 Thread Amey Barve (JIRA)

 [ 
https://issues.apache.org/jira/browse/GEODE-2049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amey Barve resolved GEODE-2049.
---
   Resolution: Fixed
Fix Version/s: 1.1.0

> unit of measure wrong in DistributionStats tcpFinalCheck statitistics
> -
>
> Key: GEODE-2049
> URL: https://issues.apache.org/jira/browse/GEODE-2049
> Project: Geode
>  Issue Type: Bug
>  Components: membership
>Reporter: Bruce Schuchardt
>Assignee: Amey Barve
>Priority: Minor
> Fix For: 1.1.0
>
>
> The unit of measure for all of the tcpfinalCheck statistics is currently 
> "nanoseconds" but should be "messages".



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (GEODE-523) PartitionListener requires tests and clean up

2017-01-11 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/GEODE-523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15820319#comment-15820319
 ] 

ASF subversion and git services commented on GEODE-523:
---

Commit a65466247497262cb633dc6b59eacf52b350edca in geode's branch 
refs/heads/develop from [~sboorlagadda]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=a654662 ]

GEODE-523: PartitionListener requires tests and clean up

  * Updated javadoc on the interface about usage
and removed gemstone contact.
  * Added tests for afterPrimary and afterRegionCreate


> PartitionListener requires tests and clean up
> -
>
> Key: GEODE-523
> URL: https://issues.apache.org/jira/browse/GEODE-523
> Project: Geode
>  Issue Type: Test
>  Components: regions
>Reporter: Kirk Lund
>Assignee: Sai Boorlagadda
>
> Many users are using PartitionListener. This API requires tests, proper 
> javadocs and general cleanup.
> See GEODE-390 and GEODE-72



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Resolved] (GEODE-523) PartitionListener requires tests and clean up

2017-01-11 Thread Sai Boorlagadda (JIRA)

 [ 
https://issues.apache.org/jira/browse/GEODE-523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sai Boorlagadda resolved GEODE-523.
---
Resolution: Fixed

> PartitionListener requires tests and clean up
> -
>
> Key: GEODE-523
> URL: https://issues.apache.org/jira/browse/GEODE-523
> Project: Geode
>  Issue Type: Test
>  Components: regions
>Reporter: Kirk Lund
>Assignee: Sai Boorlagadda
>
> Many users are using PartitionListener. This API requires tests, proper 
> javadocs and general cleanup.
> See GEODE-390 and GEODE-72



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)