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

[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)

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

[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

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

[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)

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

[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)

Re: Reviews for GEODE-1930

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

Re: Visualize Geode Metrics/Stats with Grafana Dashboards

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

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

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

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

[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] [Updated] (GEODE-182) Generate "random" member names if no name is provided

[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] [Comment Edited] (GEODE-2294) When attempting to execute a function via Dev Rest API, error messages are being lost

[Kevin Duling (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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-2294) When attempting to execute a function via Dev Rest API, error messages are being lost

[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 executing a function, error messages are being lost

[Kevin Duling (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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] [Commented] (GEODE-2294) When executing a function, error messages are being lost

[Kevin Duling (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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] [Commented] (GEODE-2031) Host documentation for releases

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[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-2294) When executing a function, error messages are being lost

[Kirk Lund (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)

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

[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)

Re: Visualize Geode Metrics/Stats with Grafana Dashboards

[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)
>

Re: Visualize Geode Metrics/Stats with Grafana Dashboards

[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/

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

[Hitesh Khamesra (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[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] [Resolved] (GEODE-2287) Possible NPE in HARegionQueue during gii with conflation

[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)

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

[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] [Commented] (GEODE-1114) Remove sqlfire/GemFireXD references from Pulse

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-1114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)

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

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

[GitHub] geode issue #333: Various pulse fixes

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

Re: Visualize Geode Metrics/Stats with Grafana Dashboards

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

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

[Apache Jenkins Server]

See