Re: Visualize Geode Metrics/Stats with Grafana Dashboards

2017-01-16 Thread Christian Tzolov
Here is the JIRA ticket: https://issues.apache.org/jira/browse/GEODE-2299

My proposal is to start with something close to what we have prototyped so
far: Geode JMX/Statistics -> InfluxDB Time-Series DB -> Grafana with some
pre-defined dashboards
Next we can enhance it with:
1. Geode Grafana datasource implementation (this would benefit from a Geode
Time-Series model. But a lack of the later wouldn't be a blocker)
2. Geode to Ambari Metric Collector System loader

IMO both enhancements should live as separate JIRA tickets. E.g. GEODE-2299
shouldn't depend on them.

@Roman, @Michael: if we are positioning Geode as IoT tool and considering
that any IoT sensor is a time-series data sources, it is important to
provide some time-series support for Geode. I've done some digging on
subject and would be very interested to see Michael's proposal. Is there a
related JIRA ticket?

Regarding Grafana such time-series support will benefit the performance.
But even without it we can implement Geode/Grafana plugin right on top of
OQL. Will not be the most performant solution but imo would help for many
use cases.

@William the Geode Ambari plugin (use the geode branch [1]) needs little
adjustment to update it to Geode 1.0.0 and latest Ambar service. Will try
resolve this in the coming days. This work has been hanging for while and
maybe it is time to make it either Ambari common services [3] or part of
the Geode's tools umbrella [2].  Current approach relies on Geode tar.gz
distribution but in the future a proper Bigtop/Geode binary releases would
definitely provide a better deployment alternative for the Ambari service.

[2] https://issues.apache.org/jira/browse/GEODE-131
[3] https://issues.apache.org/jira/browse/AMBARI-12558

Cheers,
Christian



On 14 January 2017 at 05:03, William Markito Oliveira <
william.mark...@gmail.com> wrote:

> A bit late but indeed pretty awesome stuff! Congrats Christian!
>
> +1 for integrating Geode as datasource to Graphana and providing a visual
> tools for stats.
> +1 for the integration with Ambari. I believe the Geode community could
> leverage the Ambari services capability [1] and have a way to manage and
> install a cluster on multiple machines but very few people here know about
> it I guess...  Maybe you could also rename it from GemFire to Geode ? Does
> it work after package rename.
>
>
> [1] https://github.com/tzolov/ambari-gemfire
>
> On Fri, Jan 13, 2017 at 12:18 PM, Roman Shaposhnik 
> wrote:
>
> > On Fri, Jan 13, 2017 at 10:10 AM, Michael Stolz 
> wrote:
> > > Geode doesn't have a time-series capability yet, but I have a proposal
> > that
> > > I'm planning to submit to add it.
> >
> > Looking forward to it!
> >
> > Thanks,
> > Roman.
> >
>
>
>
> --
> ~/William
>



-- 
Christian Tzolov  | Solution Architect,
EMEA Practice Team | Pivotal 
ctzo...@pivotal.io|+31610285517


Native Client Directory Structure

2017-01-16 Thread Jacob Barrett
One of the first things necessary to get NC merged into the the develop
branch is understanding where it will go under the current geode project
structure.

The quick and obvious solution is adding a 'geode-nativeclient` subproject
and relocating all the NC sources into that directory.

Given that NC consists of two semi-distinct clients, C++ and .NET, it may
also make sense to organize more of a hierarchy. Consider:
geode-client/
geode++
geode.net
(or some other more creative names)
Keep in mind that today the .NET client is very tightly coupled with the
C++ client, so you can't build .NET without first building C++.

My suggestion would be to do the quick and easy now and as we continue to
refine and refactor and hopefully write the .NET in pure CLI we make that
move them. Perhaps by that time there will be a pure Java client to include
in that structure.

Thoughts?


-Jake


Re: Native Client Directory Structure

2017-01-16 Thread Michael Stolz
+1 Makes sense to me

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

On Mon, Jan 16, 2017 at 11:26 AM, Jacob Barrett  wrote:

> One of the first things necessary to get NC merged into the the develop
> branch is understanding where it will go under the current geode project
> structure.
>
> The quick and obvious solution is adding a 'geode-nativeclient` subproject
> and relocating all the NC sources into that directory.
>
> Given that NC consists of two semi-distinct clients, C++ and .NET, it may
> also make sense to organize more of a hierarchy. Consider:
> geode-client/
> geode++
> geode.net
> (or some other more creative names)
> Keep in mind that today the .NET client is very tightly coupled with the
> C++ client, so you can't build .NET without first building C++.
>
> My suggestion would be to do the quick and easy now and as we continue to
> refine and refactor and hopefully write the .NET in pure CLI we make that
> move them. Perhaps by that time there will be a pure Java client to include
> in that structure.
>
> Thoughts?
>
>
> -Jake
>


messages repeating when using CQ Query mechanism

2017-01-16 Thread Avital Amity
Hi,

When using CQQuery mechanism, when moving from GEMFIRE to GEODE we see 
differences in server log files including many of the following messages:

[info ...] Entry expiry tasks disabled because the queue became primary. Old 
messageTimeToLive was: 180
[fine ...] Started closing CQ CqName: ...  SendRequestToServer: false

These messages appear only once when working with Gemfire Server and many (too 
many) times when working with GEODE server
Any idea what could cause that? In the GEODE client there is only once the 
CLOSE_CQ trigger

Thanks
Avital

This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,
you may review at http://www.amdocs.com/email_disclaimer.asp
This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,

you may review at http://www.amdocs.com/email_disclaimer.asp


Build failed in Jenkins: Geode-nightly #718

2017-01-16 Thread Apache Jenkins Server
See 

--
[...truncated 552 lines...]
:geode-json:compileTestJava UP-TO-DATE
:geode-json:processTestResources UP-TO-DATE
:geode-json:testClasses UP-TO-DATE
:geode-json:checkMissedTests UP-TO-DATE
:geode-json:spotlessJavaCheck
:geode-json:spotlessCheck
:geode-json:test UP-TO-DATE
:geode-json:check
:geode-json:build
:geode-json:distributedTest UP-TO-DATE
:geode-json:flakyTest UP-TO-DATE
:geode-json:integrationTest UP-TO-DATE
:geode-junit:javadoc
:geode-junit:javadocJar
:geode-junit:sourcesJar
:geode-junit:signArchives SKIPPED
:geode-junit:assemble
:geode-junit:compileTestJava
:geode-junit:processTestResources UP-TO-DATE
:geode-junit:testClasses
:geode-junit:checkMissedTests
:geode-junit:spotlessJavaCheck
:geode-junit:spotlessCheck
:geode-junit:test
:geode-junit:check
:geode-junit:build
:geode-junit:distributedTest
:geode-junit:flakyTest
:geode-junit:integrationTest
:geode-lucene:assemble
:geode-lucene:compileTestJavaNote: Some input files use or override a 
deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

:geode-lucene:processTestResources
:geode-lucene:testClasses
:geode-lucene:checkMissedTests
:geode-lucene:spotlessJavaCheck
:geode-lucene:spotlessCheck
:geode-lucene:test
:geode-lucene:check
:geode-lucene:build
:geode-lucene:distributedTest
:geode-lucene:flakyTest
:geode-lucene:integrationTest
:geode-old-client-support:assemble
:geode-old-client-support:compileTestJava
:geode-old-client-support:processTestResources UP-TO-DATE
:geode-old-client-support:testClasses
:geode-old-client-support:checkMissedTests
:geode-old-client-support:spotlessJavaCheck
:geode-old-client-support:spotlessCheck
:geode-old-client-support:test
:geode-old-client-support:check
:geode-old-client-support:build
:geode-old-client-support:distributedTest
:geode-old-client-support:flakyTest
:geode-old-client-support:integrationTest
:geode-pulse:assemble
:geode-pulse:compileTestJavaNote: 

 uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: 

 uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

:geode-pulse:processTestResources
:geode-pulse:testClasses
:geode-pulse:checkMissedTests
:geode-pulse:spotlessJavaCheck
:geode-pulse:spotlessCheck
:geode-pulse:test
:geode-pulse:check
:geode-pulse:build
:geode-pulse:distributedTest
:geode-pulse:flakyTest
:geode-pulse:integrationTest
:geode-rebalancer:assemble
:geode-rebalancer:compileTestJava
:geode-rebalancer:processTestResources UP-TO-DATE
:geode-rebalancer:testClasses
:geode-rebalancer:checkMissedTests
:geode-rebalancer:spotlessJavaCheck
:geode-rebalancer:spotlessCheck
:geode-rebalancer:test
:geode-rebalancer:check
:geode-rebalancer:build
:geode-rebalancer:distributedTest
:geode-rebalancer:flakyTest
:geode-rebalancer:integrationTest
:geode-wan:assemble
:geode-wan:compileTestJavaNote: Some input files use or override a deprecated 
API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

:geode-wan:processTestResources
:geode-wan:testClasses
:geode-wan:checkMissedTests
:geode-wan:spotlessJavaCheck
:geode-wan:spotlessCheck
:geode-wan:test
:geode-wan:check
:geode-wan:build
:geode-wan:distributedTest

org.apache.geode.management.internal.configuration.WanDUnitTest > 
testConfigurePDX FAILED
org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at 
org.apache.geode.management.internal.configuration.WanDUnitTest.before(WanDUnitTest.java:55)

org.apache.geode.management.internal.configuration.WanDUnitTest > 
testCreateGatewaySenderReceiver FAILED
org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at 
org.apache.geode.management.internal.configuration.WanDUnitTest.before(WanDUnitTest.java:55)

572 tests completed, 2 failed, 59 skipped
:geode-wan:distributedTest FAILED
:geode-wan:flakyTest

[jira] [Updated] (GEODE-2299) Integrate Geode with Grafana for historical and real-time metrics analysis

2017-01-16 Thread Karen Smoler Miller (JIRA)

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

Karen Smoler Miller updated GEODE-2299:
---
Component/s: docs

> Integrate Geode with Grafana for historical and real-time metrics analysis
> --
>
> Key: GEODE-2299
> URL: https://issues.apache.org/jira/browse/GEODE-2299
> Project: Geode
>  Issue Type: Improvement
>  Components: docs, jmx, management, pulse, statistics
>Reporter: Christian Tzolov
>
> Use Grafana dashboards for querying, visualizing and analysing Apache Geode 
> statistics archives and JMX real-time metrics.
> Solution should provide unified technical stack for visualizing and analysing 
> both real-time (e.g JMX metrics) and historical (archive files) cluster 
> statistics.
> Initial work: https://github.com/tzolov/geode-dashboard



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


[jira] [Created] (GEODE-2303) Review openssl linking

2017-01-16 Thread Anthony Baker (JIRA)
Anthony Baker created GEODE-2303:


 Summary: Review openssl linking
 Key: GEODE-2303
 URL: https://issues.apache.org/jira/browse/GEODE-2303
 Project: Geode
  Issue Type: Sub-task
Reporter: Anthony Baker


Since we link to the openssl library, we should assess whether an ECCN is 
required.

https://www.apache.org/licenses/exports/




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


[jira] [Resolved] (GEODE-2194) Initial, post-login Pulse page is /pulse/pulse/pulseVersion

2017-01-16 Thread Jared Stewart (JIRA)

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

Jared Stewart resolved GEODE-2194.
--
Resolution: Fixed

> Initial, post-login Pulse page is /pulse/pulse/pulseVersion
> ---
>
> Key: GEODE-2194
> URL: https://issues.apache.org/jira/browse/GEODE-2194
> Project: Geode
>  Issue Type: Bug
>  Components: pulse
>Reporter: Jens Deppe
>Assignee: Jared Stewart
> Fix For: 1.1.0
>
>
> When I login to pulse (regular security) the page I end up on is 
> {{/pulse/pulse/pulseVersion}}. However the login is successful because if I 
> just switch the URL to {{/pulse}} I end up at {{/pulse/clusterDetail.html}}



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


[jira] [Commented] (GEODE-1733) Lucene indexes stats are zeroed after recovering from indexes from disk

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

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

ASF subversion and git services commented on GEODE-1733:


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

GEODE-1733: Lucene stats are displayed correctly.

* Lucene stats are displayed correctly when rebalancing occurs or a 
server is reinstantiated
* Listener added which creates the LuceneIndexRepository when a bucket 
becomes primary.
* LuceneIndexRepository no longer being created lazily.


> Lucene indexes stats are zeroed after recovering from indexes from disk
> ---
>
> Key: GEODE-1733
> URL: https://issues.apache.org/jira/browse/GEODE-1733
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: William Markito Oliveira
>Assignee: nabarun
>
> When recovering from disk the indexes stats are zeroed until a query is 
> executed. 
> {code}
> 
> gfsh>list lucene indexes --with-stats
>Index Name | Region Path |  Indexed Fields  | Field 
> Analyzer |   Status| Query Executions | Updates | Commits | Documents
> - | --- |  | 
> -- | --- |  | --- | --- | 
> -
> customerRegionAll | /customer   | [lastUpdateDateTime, displayNa.. | {}   
>   | Initialized | 0| 0   | 0   | 0
> customerRegionAll | /customer   | [lastUpdateDateTime, displayNa.. | {}   
>   | Initialized | 0| 0   | 0   | 0
> customerRegionAll | /customer   | [lastUpdateDateTime, displayNa.. | {}   
>   | Initialized | 0| 0   | 0   | 0
> customerRegionID  | /customer   | [id] | {}   
>   | Initialized | 0| 0   | 0   | 0
> customerRegionID  | /customer   | [id] | {}   
>   | Initialized | 0| 0   | 0   | 0
> customerRegionID  | /customer   | [id] | {}   
>   | Initialized | 0| 0   | 0   | 0
> 
> After query: 
> gfsh>list lucene indexes --with-stats
>Index Name | Region Path |  Indexed Fields  | Field 
> Analyzer |   Status| Query Executions | Updates | Commits | Documents
> - | --- |  | 
> -- | --- |  | --- | --- | 
> -
> customerRegionAll | /customer   | [lastUpdateDateTime, displayNa.. | {}   
>   | Initialized | 0| 0   | 0   | 0
> customerRegionAll | /customer   | [lastUpdateDateTime, displayNa.. | {}   
>   | Initialized | 0| 0   | 0   | 0
> customerRegionAll | /customer   | [lastUpdateDateTime, displayNa.. | {}   
>   | Initialized | 0| 0   | 0   | 0
> customerRegionID  | /customer   | [id] | {}   
>   | Initialized | 114  | 0   | 0   | 20644274
> customerRegionID  | /customer   | [id] | {}   
>   | Initialized | 111  | 0   | 0   | 20103890
> customerRegionID  | /customer   | [id] | {}   
>   | Initialized | 114  | 0   | 0   | 20637846
> {code}



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


Re: messages repeating when using CQ Query mechanism

2017-01-16 Thread Michael Stolz
And what versions of Geode and GemFire and C++ client are you trying?

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

On Mon, Jan 16, 2017 at 1:30 PM, Avital Amity 
wrote:

> Thanks Jason for your comments
>
> Just to emphasize I'm running the exact same flow once with GEODE and once
> with GF, and tried it on several environments and go consistent results. I
> assume it can eliminate network issues
> These repeating messages are only when using the C++ client (no problem
> with using the java client with GEODE)
> There is only 1 client in this test
>
> Also please see inline
>
> -Original Message-
> From: Jason Huynh [mailto:jhu...@pivotal.io]
> Sent: Monday, January 16, 2017 7:47 PM
> To: dev@geode.apache.org
> Subject: Re: messages repeating when using CQ Query mechanism
>
> Hello,
>
> I am not sure what would cause that to happen.  Just some questions and
> ideas, it looks like the first log about disabling expiry is logged when we
> create the ha region queue, become a primary queue or start/restop (and
> only if the old time to live is > 0.  After being the log, it should be set
> to 0, not sure why it keeps getting set back).
> [Avital Amity] I see this message usually prior to the expiry message:
> (again only in GEODE)
> invoking listeners: [org.apache.geode.internal.cache.ha.HARegionQueue$1@
> 63668e3a]
>
> The second message is logged obviously when the cq is closed.  If the
> client is only doing it one time, I am not sure why you would see so many.
> Is it possible that there are many clients or some sort of loop?  Is it
> closing the cq for the same cq name and is it on the same server? [Avital
> Amity] the name is the same for all closure messages, there are 2 servers
> with the exact same messages (and same name)
> Is it possible that there is some network issue that is causing the client
> to have to reconnect/re-establish a primary queue?  Is the region getting
> destroyed?
>
>
> -Jason
>
>
> On Mon, Jan 16, 2017 at 8:31 AM Avital Amity 
> wrote:
>
> > Hi,
> >
> > When using CQQuery mechanism, when moving from GEMFIRE to GEODE we see
> > differences in server log files including many of the following messages:
> >
> > [info ...] Entry expiry tasks disabled because the queue became primary.
> > Old messageTimeToLive was: 180
> > [fine ...] Started closing CQ CqName: ...  SendRequestToServer: false
> >
> > These messages appear only once when working with Gemfire Server and
> > many (too many) times when working with GEODE server Any idea what
> > could cause that? In the GEODE client there is only once the CLOSE_CQ
> > trigger
> >
> > Thanks
> > Avital
> >
> > This message and the information contained herein is proprietary and
> > confidential and subject to the Amdocs policy statement, you may
> > review at http://www.amdocs.com/email_disclaimer.asp
> > This message and the information contained herein is proprietary and
> > confidential and subject to the Amdocs policy statement,
> >
> > you may review at http://www.amdocs.com/email_disclaimer.asp
> >
> This message and the information contained herein is proprietary and
> confidential and subject to the Amdocs policy statement,
>
> you may review at http://www.amdocs.com/email_disclaimer.asp
>


[jira] [Created] (GEODE-2300) Document default names for start locator/server

2017-01-16 Thread Joey McAllister (JIRA)
Joey McAllister created GEODE-2300:
--

 Summary: Document default names for start locator/server
 Key: GEODE-2300
 URL: https://issues.apache.org/jira/browse/GEODE-2300
 Project: Geode
  Issue Type: Task
  Components: docs
Reporter: Joey McAllister


Documentation for GEODE-182



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


[jira] [Updated] (GEODE-2300) Document default names for start locator/server

2017-01-16 Thread Joey McAllister (JIRA)

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

Joey McAllister updated GEODE-2300:
---
Issue Type: Sub-task  (was: Task)
Parent: GEODE-182

> Document default names for start locator/server
> ---
>
> Key: GEODE-2300
> URL: https://issues.apache.org/jira/browse/GEODE-2300
> Project: Geode
>  Issue Type: Sub-task
>  Components: docs
>Reporter: Joey McAllister
>
> Documentation for GEODE-182



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


[GitHub] geode pull request #338: GEODE-2272: Fix Pulse data browser export

2017-01-16 Thread jaredjstewart
GitHub user jaredjstewart opened a pull request:

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

GEODE-2272: Fix Pulse data browser export

* Pulse no longer loads all results into the browser before generating a 
results file for download.

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

$ git pull https://github.com/jaredjstewart/geode GEODE-2272

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

https://github.com/apache/geode/pull/338.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 #338


commit 09e765ee07885f720852b351548915abcfd051f3
Author: Jared Stewart 
Date:   2017-01-16T17:33:42Z

GEODE-2272: Fix Pulse data browser export

* Pulse no longer loads all results into the browser before generating a 
results file for download.




---
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-2272) Pulse Data Browser export hangs

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

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

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

GitHub user jaredjstewart opened a pull request:

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

GEODE-2272: Fix Pulse data browser export

* Pulse no longer loads all results into the browser before generating a 
results file for download.

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

$ git pull https://github.com/jaredjstewart/geode GEODE-2272

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

https://github.com/apache/geode/pull/338.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 #338


commit 09e765ee07885f720852b351548915abcfd051f3
Author: Jared Stewart 
Date:   2017-01-16T17:33:42Z

GEODE-2272: Fix Pulse data browser export

* Pulse no longer loads all results into the browser before generating a 
results file for download.




> Pulse Data Browser export hangs
> ---
>
> Key: GEODE-2272
> URL: https://issues.apache.org/jira/browse/GEODE-2272
> Project: Geode
>  Issue Type: Bug
>  Components: pulse
>Affects Versions: 1.0.0-incubating
>Reporter: Jared Stewart
>Assignee: Jared Stewart
>
> The Export feature of Pulse Data Browser is prone to hang with large amounts 
> of data as it requires loading all the query results into the browser before 
> they can be exported.  Instead, we should allow a user to Export query 
> results directly to a file without first loading the results into their 
> browser.



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


Re: Review Request 55532: GEODE-2198: close and re-create the cache on a server when importing new cluster configuration

2017-01-16 Thread Jared Stewart


> On Jan. 16, 2017, 6:32 p.m., Jared Stewart wrote:
> > Ship It!

+1 after Kevin's comment is addressed


- Jared


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


On Jan. 14, 2017, 3:52 a.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/55532/
> ---
> 
> (Updated Jan. 14, 2017, 3:52 a.m.)
> 
> 
> Review request for geode, Jared Stewart, Kevin Duling, and Kirk Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> * When importing cluster config first check if there is any non-empty region
> * close and re-create cache if no data exists when importing new cluster 
> configuration
> * put the acquire/release lock inside the ClusterConfigurationService instead 
> of command execution strategy.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/ClusterConfigurationService.java
>  1d4030a8dedd017a0ab096925055f375bb5d3ef0 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java
>  795164d7a86f87afb60e800885fb5fb2c540451b 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/xmlcache/CacheCreation.java
>  1c3c93314841f5623c0e6387500af88f106328d9 
>   geode-core/src/main/java/org/apache/geode/management/cli/CliMetaData.java 
> 2e272fc083514456f0ef89d4b9824126e86828fa 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/CreateAlterDestroyRegionCommands.java
>  7df4112950cefcc1ae18bdd88cb752cdec5b7de1 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DeployCommands.java
>  f076cec670a4c787fbe4002edfdacde4b025d1bf 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DiskStoreCommands.java
>  14114cff2febf0e1ba7ae67427549ad4fd19ed85 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportImportSharedConfigurationCommands.java
>  914576b2b24eec670c06510aa5b056c0acd808fc 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/IndexCommands.java
>  bc436ba40e107b931e8d0d10082e26cf068dd56b 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/PDXCommands.java
>  72d5c0fc65090880b95f37868e72ef9dcba6c55f 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/QueueCommands.java
>  095bd68f54d0f06d9f9439fcaffbca72e49083fc 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/WanCommands.java
>  cbf589185e94345be6fd64ebd630f76e84cc2a09 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/remote/RemoteExecutionStrategy.java
>  1e4870f9b48e5cc5e4c7ded2af907f4e63aa2977 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/configuration/functions/RecreateCacheFunction.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/configuration/functions/RegionsWithDataOnServerFunction.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/extension/mock/MockExtensionCommands.java
>  1bd4478538f0e0c9413e95a01e835fa6af3a24ea 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ClusterConfigurationServiceCommandsDUnitTest.java
>  87cac55bc672ed380d3abb8ab69c9499f931e4b3 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfig.java
>  c2d511d1c4d34aea434751c2bb5b7e9b924482ad 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigBaseTest.java
>  506428a48c27435a3c89f97bc4d296853fe99415 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigImportDUnitTest.java
>  b301b80a1268c8ad0954e9abe86711cdfe5ac066 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigStartMemberDUnitTest.java
>  7dd0da67bdb38f027f717bfc96adc5f5ffc0af37 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/rules/ServerStarterRule.java
>  c94185a3b7f8e82cdab620b79c3cb836d0a7e530 
>   
> geode-core/src/test/resources/org/apache/geode/codeAnalysis/sanctionedSerializables.txt
>  9626be76c35194e07df10d3ad650cb3d2df4d73a 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/cli/LuceneIndexCommands.java
>  6a5a1e09c03b9a5362e44fd6fe55a6e6181ea17c 
>   
> geode-web/src/test/java/org/apache/geode/management/internal/cli/commands/CommandOverHttpDUnitTest.java
>  a1810b6eaa7d940ad359d64faab98c7d113165f0 
> 
> Diff: https://reviews.apache.org/r/55532/diff/
> 
> 
> Testing
> ---
> 
> precheckin successful
> 
> 
> Thanks,
> 
> Jinmei Liao
> 
>



Re: Review Request 55532: GEODE-2198: close and re-create the cache on a server when importing new cluster configuration

2017-01-16 Thread Jared Stewart

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


Ship it!




Ship It!

- Jared Stewart


On Jan. 14, 2017, 3:52 a.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/55532/
> ---
> 
> (Updated Jan. 14, 2017, 3:52 a.m.)
> 
> 
> Review request for geode, Jared Stewart, Kevin Duling, and Kirk Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> * When importing cluster config first check if there is any non-empty region
> * close and re-create cache if no data exists when importing new cluster 
> configuration
> * put the acquire/release lock inside the ClusterConfigurationService instead 
> of command execution strategy.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/ClusterConfigurationService.java
>  1d4030a8dedd017a0ab096925055f375bb5d3ef0 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java
>  795164d7a86f87afb60e800885fb5fb2c540451b 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/xmlcache/CacheCreation.java
>  1c3c93314841f5623c0e6387500af88f106328d9 
>   geode-core/src/main/java/org/apache/geode/management/cli/CliMetaData.java 
> 2e272fc083514456f0ef89d4b9824126e86828fa 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/CreateAlterDestroyRegionCommands.java
>  7df4112950cefcc1ae18bdd88cb752cdec5b7de1 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DeployCommands.java
>  f076cec670a4c787fbe4002edfdacde4b025d1bf 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DiskStoreCommands.java
>  14114cff2febf0e1ba7ae67427549ad4fd19ed85 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportImportSharedConfigurationCommands.java
>  914576b2b24eec670c06510aa5b056c0acd808fc 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/IndexCommands.java
>  bc436ba40e107b931e8d0d10082e26cf068dd56b 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/PDXCommands.java
>  72d5c0fc65090880b95f37868e72ef9dcba6c55f 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/QueueCommands.java
>  095bd68f54d0f06d9f9439fcaffbca72e49083fc 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/WanCommands.java
>  cbf589185e94345be6fd64ebd630f76e84cc2a09 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/remote/RemoteExecutionStrategy.java
>  1e4870f9b48e5cc5e4c7ded2af907f4e63aa2977 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/configuration/functions/RecreateCacheFunction.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/configuration/functions/RegionsWithDataOnServerFunction.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/extension/mock/MockExtensionCommands.java
>  1bd4478538f0e0c9413e95a01e835fa6af3a24ea 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ClusterConfigurationServiceCommandsDUnitTest.java
>  87cac55bc672ed380d3abb8ab69c9499f931e4b3 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfig.java
>  c2d511d1c4d34aea434751c2bb5b7e9b924482ad 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigBaseTest.java
>  506428a48c27435a3c89f97bc4d296853fe99415 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigImportDUnitTest.java
>  b301b80a1268c8ad0954e9abe86711cdfe5ac066 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigStartMemberDUnitTest.java
>  7dd0da67bdb38f027f717bfc96adc5f5ffc0af37 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/rules/ServerStarterRule.java
>  c94185a3b7f8e82cdab620b79c3cb836d0a7e530 
>   
> geode-core/src/test/resources/org/apache/geode/codeAnalysis/sanctionedSerializables.txt
>  9626be76c35194e07df10d3ad650cb3d2df4d73a 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/cli/LuceneIndexCommands.java
>  6a5a1e09c03b9a5362e44fd6fe55a6e6181ea17c 
>   
> geode-web/src/test/java/org/apache/geode/management/internal/cli/commands/CommandOverHttpDUnitTest.java
>  a1810b6eaa7d940ad359d64faab98c7d113165f0 
> 
> Diff: https://reviews.apache.org/r/55532/diff/
> 
> 
> Testing
> ---
> 
> precheckin successful
> 
> 
> Thanks,
> 
> Jinmei Liao
> 
>



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

2017-01-16 Thread Jared Stewart (JIRA)

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

Jared Stewart updated GEODE-1114:
-
Fix Version/s: 1.1.0

> 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
> Fix For: 1.1.0
>
>
> No need to drag around this old code



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


[jira] [Created] (GEODE-2301) Deprecate JTA transaction manager from Geode

2017-01-16 Thread Swapnil Bawaskar (JIRA)
Swapnil Bawaskar created GEODE-2301:
---

 Summary: Deprecate JTA transaction manager from Geode
 Key: GEODE-2301
 URL: https://issues.apache.org/jira/browse/GEODE-2301
 Project: Geode
  Issue Type: Bug
  Components: transactions
Reporter: Swapnil Bawaskar


We should deprecate the JTA transaction manager that ships with Geode on the 
following grounds:
>From 
>[documentation|http://geode.apache.org/docs/guide/developing/transactions/JTA_transactions.html#concept_8567sdkbigige]:
{noformat}
Geode ships with its own implementation of a JTA transaction manager.
However, note that this implementation is not XA-compliant;
therefore, it does not persist any state, which could lead to an inconsistent
state after recovering a crashed member.
{noformat}



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


[jira] [Updated] (GEODE-2194) Initial, post-login Pulse page is /pulse/pulse/pulseVersion

2017-01-16 Thread Jared Stewart (JIRA)

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

Jared Stewart updated GEODE-2194:
-
Fix Version/s: 1.1.0

> Initial, post-login Pulse page is /pulse/pulse/pulseVersion
> ---
>
> Key: GEODE-2194
> URL: https://issues.apache.org/jira/browse/GEODE-2194
> Project: Geode
>  Issue Type: Bug
>  Components: pulse
>Reporter: Jens Deppe
>Assignee: Jared Stewart
> Fix For: 1.1.0
>
>
> When I login to pulse (regular security) the page I end up on is 
> {{/pulse/pulse/pulseVersion}}. However the login is successful because if I 
> just switch the URL to {{/pulse}} I end up at {{/pulse/clusterDetail.html}}



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


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

2017-01-16 Thread Jared Stewart (JIRA)

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

Jared Stewart resolved GEODE-1114.
--
Resolution: Fixed

> 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
> Fix For: 1.1.0
>
>
> No need to drag around this old code



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


RE: messages repeating when using CQ Query mechanism

2017-01-16 Thread Avital Amity
Thanks Jason for your comments

Just to emphasize I'm running the exact same flow once with GEODE and once with 
GF, and tried it on several environments and go consistent results. I assume it 
can eliminate network issues
These repeating messages are only when using the C++ client (no problem with 
using the java client with GEODE)
There is only 1 client in this test

Also please see inline

-Original Message-
From: Jason Huynh [mailto:jhu...@pivotal.io] 
Sent: Monday, January 16, 2017 7:47 PM
To: dev@geode.apache.org
Subject: Re: messages repeating when using CQ Query mechanism

Hello,

I am not sure what would cause that to happen.  Just some questions and ideas, 
it looks like the first log about disabling expiry is logged when we create the 
ha region queue, become a primary queue or start/restop (and only if the old 
time to live is > 0.  After being the log, it should be set to 0, not sure why 
it keeps getting set back).
[Avital Amity] I see this message usually prior to the expiry message: (again 
only in GEODE)
invoking listeners: 
[org.apache.geode.internal.cache.ha.HARegionQueue$1@63668e3a]

The second message is logged obviously when the cq is closed.  If the client is 
only doing it one time, I am not sure why you would see so many.
Is it possible that there are many clients or some sort of loop?  Is it closing 
the cq for the same cq name and is it on the same server? [Avital Amity] the 
name is the same for all closure messages, there are 2 servers with the exact 
same messages (and same name)
Is it possible that there is some network issue that is causing the client to 
have to reconnect/re-establish a primary queue?  Is the region getting 
destroyed?


-Jason


On Mon, Jan 16, 2017 at 8:31 AM Avital Amity 
wrote:

> Hi,
>
> When using CQQuery mechanism, when moving from GEMFIRE to GEODE we see 
> differences in server log files including many of the following messages:
>
> [info ...] Entry expiry tasks disabled because the queue became primary.
> Old messageTimeToLive was: 180
> [fine ...] Started closing CQ CqName: ...  SendRequestToServer: false
>
> These messages appear only once when working with Gemfire Server and 
> many (too many) times when working with GEODE server Any idea what 
> could cause that? In the GEODE client there is only once the CLOSE_CQ 
> trigger
>
> Thanks
> Avital
>
> This message and the information contained herein is proprietary and 
> confidential and subject to the Amdocs policy statement, you may 
> review at http://www.amdocs.com/email_disclaimer.asp
> This message and the information contained herein is proprietary and 
> confidential and subject to the Amdocs policy statement,
>
> you may review at http://www.amdocs.com/email_disclaimer.asp
>
This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,

you may review at http://www.amdocs.com/email_disclaimer.asp


Review Request 55603: GEODE-2261: fix the dunit test in nightly build

2017-01-16 Thread Jinmei Liao

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

Review request for geode, Jared Stewart, Kevin Duling, and Kirk Lund.


Repository: geode


Description
---

* separte the failing tests. Put WAN test into WAN's test and another into 
core's test


Diffs
-

  
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigDistributionDUnitTest.java
 d72e38633dae1b68136c6bc99bb2620f401ee41a 
  
geode-core/src/test/java/org/apache/geode/test/dunit/rules/GfshShellConnectionRule.java
 718c816fc6d4d35cae0e286078638a5dfdc494ed 
  
geode-wan/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigurationExtensionsDUnitTest.java
 f9786c7f85eedd3eb1a358aae8f3a8fbcb9a61f4 
  
geode-wan/src/test/java/org/apache/geode/management/internal/configuration/WanDUnitTest.java
 c1aeae639b961f7e653d3c7e8c9ed153effeba36 

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


Testing
---

precheckin running


Thanks,

Jinmei Liao



Re: Review Request 55603: GEODE-2261: fix the dunit test in nightly build

2017-01-16 Thread Kirk Lund

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


Ship it!





geode-wan/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigurationExtensionsDUnitTest.java
 (line 142)


The value of NAME should be a String.


- Kirk Lund


On Jan. 17, 2017, 5:03 a.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/55603/
> ---
> 
> (Updated Jan. 17, 2017, 5:03 a.m.)
> 
> 
> Review request for geode, Jared Stewart, Kevin Duling, and Kirk Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> * separte the failing tests. Put WAN test into WAN's test and another into 
> core's test
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigDistributionDUnitTest.java
>  d72e38633dae1b68136c6bc99bb2620f401ee41a 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/rules/GfshShellConnectionRule.java
>  718c816fc6d4d35cae0e286078638a5dfdc494ed 
>   
> geode-wan/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigurationExtensionsDUnitTest.java
>  f9786c7f85eedd3eb1a358aae8f3a8fbcb9a61f4 
>   
> geode-wan/src/test/java/org/apache/geode/management/internal/configuration/WanDUnitTest.java
>  c1aeae639b961f7e653d3c7e8c9ed153effeba36 
> 
> Diff: https://reviews.apache.org/r/55603/diff/
> 
> 
> Testing
> ---
> 
> precheckin running
> 
> 
> Thanks,
> 
> Jinmei Liao
> 
>



[jira] [Commented] (GEODE-1733) Lucene indexes stats are zeroed after recovering from indexes from disk

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

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

ASF subversion and git services commented on GEODE-1733:


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

Revert "GEODE-1733: Lucene stats are displayed correctly."

This reverts commit f1cebc2f085807d48adf58d7ad0fbebced49e043.


> Lucene indexes stats are zeroed after recovering from indexes from disk
> ---
>
> Key: GEODE-1733
> URL: https://issues.apache.org/jira/browse/GEODE-1733
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: William Markito Oliveira
>Assignee: nabarun
> Fix For: 1.1.0
>
>
> When recovering from disk the indexes stats are zeroed until a query is 
> executed. 
> {code}
> 
> gfsh>list lucene indexes --with-stats
>Index Name | Region Path |  Indexed Fields  | Field 
> Analyzer |   Status| Query Executions | Updates | Commits | Documents
> - | --- |  | 
> -- | --- |  | --- | --- | 
> -
> customerRegionAll | /customer   | [lastUpdateDateTime, displayNa.. | {}   
>   | Initialized | 0| 0   | 0   | 0
> customerRegionAll | /customer   | [lastUpdateDateTime, displayNa.. | {}   
>   | Initialized | 0| 0   | 0   | 0
> customerRegionAll | /customer   | [lastUpdateDateTime, displayNa.. | {}   
>   | Initialized | 0| 0   | 0   | 0
> customerRegionID  | /customer   | [id] | {}   
>   | Initialized | 0| 0   | 0   | 0
> customerRegionID  | /customer   | [id] | {}   
>   | Initialized | 0| 0   | 0   | 0
> customerRegionID  | /customer   | [id] | {}   
>   | Initialized | 0| 0   | 0   | 0
> 
> After query: 
> gfsh>list lucene indexes --with-stats
>Index Name | Region Path |  Indexed Fields  | Field 
> Analyzer |   Status| Query Executions | Updates | Commits | Documents
> - | --- |  | 
> -- | --- |  | --- | --- | 
> -
> customerRegionAll | /customer   | [lastUpdateDateTime, displayNa.. | {}   
>   | Initialized | 0| 0   | 0   | 0
> customerRegionAll | /customer   | [lastUpdateDateTime, displayNa.. | {}   
>   | Initialized | 0| 0   | 0   | 0
> customerRegionAll | /customer   | [lastUpdateDateTime, displayNa.. | {}   
>   | Initialized | 0| 0   | 0   | 0
> customerRegionID  | /customer   | [id] | {}   
>   | Initialized | 114  | 0   | 0   | 20644274
> customerRegionID  | /customer   | [id] | {}   
>   | Initialized | 111  | 0   | 0   | 20103890
> customerRegionID  | /customer   | [id] | {}   
>   | Initialized | 114  | 0   | 0   | 20637846
> {code}



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


Re: Review Request 55603: GEODE-2261: fix the dunit test in nightly build

2017-01-16 Thread Jinmei Liao

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

(Updated Jan. 17, 2017, 5:03 a.m.)


Review request for geode, Jared Stewart, Kevin Duling, and Kirk Lund.


Repository: geode


Description
---

* separte the failing tests. Put WAN test into WAN's test and another into 
core's test


Diffs (updated)
-

  
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigDistributionDUnitTest.java
 d72e38633dae1b68136c6bc99bb2620f401ee41a 
  
geode-core/src/test/java/org/apache/geode/test/dunit/rules/GfshShellConnectionRule.java
 718c816fc6d4d35cae0e286078638a5dfdc494ed 
  
geode-wan/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigurationExtensionsDUnitTest.java
 f9786c7f85eedd3eb1a358aae8f3a8fbcb9a61f4 
  
geode-wan/src/test/java/org/apache/geode/management/internal/configuration/WanDUnitTest.java
 c1aeae639b961f7e653d3c7e8c9ed153effeba36 

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


Testing
---

precheckin running


Thanks,

Jinmei Liao



Re: New Repo for Native Client

2017-01-16 Thread Jacob Barrett
Roman,

I understand what you are saying. I think that since the build process
between the Java Geode bits and the Native Geode bits will completely
different it might help to have the separate. Until someone comes up with a
good cross platform and cross language build tool that is commonly used in
the development environments for each language these builds will remain
different. Gradle sucks for building C++ and .NET sources and CMake sucks
for building Java sources. Gradle is not popular in the native project
world nor is CMake popular in the Java world. So making one build system to
cover them all would just hurt everyone. Since the experience will be
unique for each I feel that it justifies a separate repo but I can totally
see the other side of just keeping it all together.

I too am worried about being isolated but I think as long as it is just the
repo we should be fine.

Thanks,
jake


On Mon, Jan 16, 2017 at 4:14 PM Roman Shaposhnik 
wrote:

> Here's my own, personal minority report: I think that a separate repo
> will complicate your build and release process and will fracture your
> nascent community. That said...
>
> On Mon, Jan 16, 2017 at 3:58 PM, Jacob Barrett 
> wrote:
> > Mark,
> >
> > Looks like we have lots of votes for your separate repo idea. What do we
> > need to do to get that going?
>
> This is a self-managing thing. Here's the tool:
> https://reporeq.apache.org/
>
> > On that note too, do you know who we need to ping to get a build going?
>
> Did I mention complications to build and release process? ;-)
>
> At any rate -- there's nobody to ping -- it'll be you Jacob (or whoever
> else is signing up to hack on the Native client). Mark can give you
> Jenkins karma tho:
> https://wiki.apache.org/general/Jenkins#How_do_I_get_an_account
>
> > I would suggest we target Linux first since it is the easiest. The tools
> > necessary can be found in the src/BUILDING.md file.
>
> That's very much up to whoever is doing the actual work, but it sounds
> reasonable.
>
> Thanks,
> Roman.
>


Re: New Repo for Native Client

2017-01-16 Thread Jacob Barrett
Roman or Mark,

Reading the list of build tools on the Jenkins slaves it sounds like these
boxes are geared solely towards Java compilation. Is there a build system
or slave for building native bits?

We will need GCC 4.9 or newer (C++11), CMake, Doxygen, and a few other
tools.

Thanks,
Jake


On Mon, Jan 16, 2017 at 8:47 PM Jacob Barrett  wrote:

> Roman,
>
> I understand what you are saying. I think that since the build process
> between the Java Geode bits and the Native Geode bits will completely
> different it might help to have the separate. Until someone comes up with a
> good cross platform and cross language build tool that is commonly used in
> the development environments for each language these builds will remain
> different. Gradle sucks for building C++ and .NET sources and CMake sucks
> for building Java sources. Gradle is not popular in the native project
> world nor is CMake popular in the Java world. So making one build system to
> cover them all would just hurt everyone. Since the experience will be
> unique for each I feel that it justifies a separate repo but I can totally
> see the other side of just keeping it all together.
>
> I too am worried about being isolated but I think as long as it is just
> the repo we should be fine.
>
> Thanks,
> jake
>
>
> On Mon, Jan 16, 2017 at 4:14 PM Roman Shaposhnik 
> wrote:
>
> Here's my own, personal minority report: I think that a separate repo
> will complicate your build and release process and will fracture your
> nascent community. That said...
>
> On Mon, Jan 16, 2017 at 3:58 PM, Jacob Barrett 
> wrote:
> > Mark,
> >
> > Looks like we have lots of votes for your separate repo idea. What do we
> > need to do to get that going?
>
> This is a self-managing thing. Here's the tool:
> https://reporeq.apache.org/
>
> > On that note too, do you know who we need to ping to get a build going?
>
> Did I mention complications to build and release process? ;-)
>
> At any rate -- there's nobody to ping -- it'll be you Jacob (or whoever
> else is signing up to hack on the Native client). Mark can give you
> Jenkins karma tho:
> https://wiki.apache.org/general/Jenkins#How_do_I_get_an_account
>
> > I would suggest we target Linux first since it is the easiest. The tools
> > necessary can be found in the src/BUILDING.md file.
>
> That's very much up to whoever is doing the actual work, but it sounds
> reasonable.
>
> Thanks,
> Roman.
>
>


Re: Review Request 55532: GEODE-2198: close and re-create the cache on a server when importing new cluster configuration

2017-01-16 Thread Jinmei Liao

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

(Updated Jan. 17, 2017, 5:07 a.m.)


Review request for geode, Jared Stewart, Kevin Duling, and Kirk Lund.


Repository: geode


Description
---

* When importing cluster config first check if there is any non-empty region
* close and re-create cache if no data exists when importing new cluster 
configuration
* put the acquire/release lock inside the ClusterConfigurationService instead 
of command execution strategy.


Diffs (updated)
-

  
geode-core/src/main/java/org/apache/geode/distributed/internal/ClusterConfigurationService.java
 1d4030a8dedd017a0ab096925055f375bb5d3ef0 
  
geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java 
795164d7a86f87afb60e800885fb5fb2c540451b 
  geode-core/src/main/java/org/apache/geode/management/cli/CliMetaData.java 
2e272fc083514456f0ef89d4b9824126e86828fa 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/CreateAlterDestroyRegionCommands.java
 7df4112950cefcc1ae18bdd88cb752cdec5b7de1 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DeployCommands.java
 f076cec670a4c787fbe4002edfdacde4b025d1bf 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DiskStoreCommands.java
 14114cff2febf0e1ba7ae67427549ad4fd19ed85 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportImportSharedConfigurationCommands.java
 914576b2b24eec670c06510aa5b056c0acd808fc 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/IndexCommands.java
 bc436ba40e107b931e8d0d10082e26cf068dd56b 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/PDXCommands.java
 72d5c0fc65090880b95f37868e72ef9dcba6c55f 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/QueueCommands.java
 095bd68f54d0f06d9f9439fcaffbca72e49083fc 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/WanCommands.java
 cbf589185e94345be6fd64ebd630f76e84cc2a09 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/remote/RemoteExecutionStrategy.java
 1e4870f9b48e5cc5e4c7ded2af907f4e63aa2977 
  
geode-core/src/main/java/org/apache/geode/management/internal/configuration/functions/RecreateCacheFunction.java
 PRE-CREATION 
  
geode-core/src/main/java/org/apache/geode/management/internal/configuration/functions/RegionsWithDataOnServerFunction.java
 PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/internal/cache/extension/mock/MockExtensionCommands.java
 1bd4478538f0e0c9413e95a01e835fa6af3a24ea 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ClusterConfigurationServiceCommandsDUnitTest.java
 87cac55bc672ed380d3abb8ab69c9499f931e4b3 
  
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfig.java
 c2d511d1c4d34aea434751c2bb5b7e9b924482ad 
  
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigBaseTest.java
 506428a48c27435a3c89f97bc4d296853fe99415 
  
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigImportDUnitTest.java
 b301b80a1268c8ad0954e9abe86711cdfe5ac066 
  
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigStartMemberDUnitTest.java
 7dd0da67bdb38f027f717bfc96adc5f5ffc0af37 
  
geode-core/src/test/java/org/apache/geode/test/dunit/rules/ServerStarterRule.java
 c94185a3b7f8e82cdab620b79c3cb836d0a7e530 
  
geode-core/src/test/resources/org/apache/geode/codeAnalysis/sanctionedSerializables.txt
 9626be76c35194e07df10d3ad650cb3d2df4d73a 
  
geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/cli/LuceneIndexCommands.java
 6a5a1e09c03b9a5362e44fd6fe55a6e6181ea17c 
  
geode-web/src/test/java/org/apache/geode/management/internal/cli/commands/CommandOverHttpDUnitTest.java
 a1810b6eaa7d940ad359d64faab98c7d113165f0 

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


Testing
---

precheckin successful


Thanks,

Jinmei Liao



[jira] [Commented] (GEODE-697) A client thread timing out an operation and performing further operations can result in cache inconsistency

2017-01-16 Thread Udo Kohlmeyer (JIRA)

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

Udo Kohlmeyer commented on GEODE-697:
-

I agree with [~hitesh.khamesra] that the most important piece is to keep the 
cache in a consistent state.

[~bschuchardt] I think that [~hitesh.khamesra] has a point in that we should 
accept any event from the primary bucket. In a partitioned region all CUD 
operations are handled through the primary, which means that if multiple 
clients where to make changes to the same key, they will be ordered (and 
blocked) by the primary node. This functionality should be checked with 
replicate regions and how they would be affected by them.

I agree with [~bschuchardt] in relation to the "clients should not timeout". I 
believe that the timeout should be honored by the server. This way if an 
operation has not been completed within a timeout period, then the server can, 
if possible, cancel the action/operation and return to the client with an 
"OperationTimeoutException". I've created GEODE-2304 to track this.



> A client thread timing out an operation and performing further operations can 
> result in cache inconsistency
> ---
>
> Key: GEODE-697
> URL: https://issues.apache.org/jira/browse/GEODE-697
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Dan Smith
>Assignee: Bruce Schuchardt
>
> There is a case where the primary and secondary buckets of a partitioned 
> region can become out of sync if a client times out while waiting for a slow 
> operation to finish. Here's the scenario:
> 1. A operation is started by the client and gets stuck on the server, for 
> example by a slow cache writer. That operation is assigned an EventID  with a 
> sequence number of 1.
> 2. The client times out.
> 3. The client performs a second operation. That operation gets assigned an 
> EventID with a sequence number of 2.
> 4. The second operation is applied on all members. The EventTracker records 
> the sequence number 2.
> 5. The original operation continues. It is applied to the primary (because it 
> has passed the EventTracker test).
> 6. The original operation is rejected by the EventTracker on the secondary. 
> The two copies of the bucket are now inconsistent.
> One possible fix is to change the thread id of the thread on the client when 
> the client operation times out. That would ensure that the EventTracker will 
> not reject the original operation when it finally goes through, because it 
> has a different thread id.
> If an operation is delayed on the server, for example by a very slow cache 
> writer, the operation can time out on the client.
> The client can then go on and perform a second operation.
> The problem is that each operation is assigned an event id which is a 
> combination of the clients thread id and a sequence number. That second 
> operation has a higher sequence number.
> Once the second operation is applied to a region on a given member, the event 
> is stored in the EventTracker and that member will reject any lower sequence 
> numbers



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


[jira] [Updated] (GEODE-697) A client thread timing out an operation and performing further operations can result in cache inconsistency

2017-01-16 Thread Udo Kohlmeyer (JIRA)

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

Udo Kohlmeyer updated GEODE-697:

Component/s: (was: client/server)
 regions

> A client thread timing out an operation and performing further operations can 
> result in cache inconsistency
> ---
>
> Key: GEODE-697
> URL: https://issues.apache.org/jira/browse/GEODE-697
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Dan Smith
>Assignee: Bruce Schuchardt
>
> There is a case where the primary and secondary buckets of a partitioned 
> region can become out of sync if a client times out while waiting for a slow 
> operation to finish. Here's the scenario:
> 1. A operation is started by the client and gets stuck on the server, for 
> example by a slow cache writer. That operation is assigned an EventID  with a 
> sequence number of 1.
> 2. The client times out.
> 3. The client performs a second operation. That operation gets assigned an 
> EventID with a sequence number of 2.
> 4. The second operation is applied on all members. The EventTracker records 
> the sequence number 2.
> 5. The original operation continues. It is applied to the primary (because it 
> has passed the EventTracker test).
> 6. The original operation is rejected by the EventTracker on the secondary. 
> The two copies of the bucket are now inconsistent.
> One possible fix is to change the thread id of the thread on the client when 
> the client operation times out. That would ensure that the EventTracker will 
> not reject the original operation when it finally goes through, because it 
> has a different thread id.
> If an operation is delayed on the server, for example by a very slow cache 
> writer, the operation can time out on the client.
> The client can then go on and perform a second operation.
> The problem is that each operation is assigned an event id which is a 
> combination of the clients thread id and a sequence number. That second 
> operation has a higher sequence number.
> Once the second operation is applied to a region on a given member, the event 
> is stored in the EventTracker and that member will reject any lower sequence 
> numbers



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


[jira] [Commented] (GEODE-2264) Update Geode Javadocs (no longer "incubating")

2017-01-16 Thread Anthony Baker (JIRA)

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

Anthony Baker commented on GEODE-2264:
--

Based on the discussion from dev@geode this is not an issue.  See this thread:

http://mail-archives.apache.org/mod_mbox/geode-dev/201701.mbox/%3cCADYVi7QsCVr6APHuJ-ZaA2z6+BonKYBnNxms=px+yx1spkz...@mail.gmail.com%3e


> Update Geode Javadocs (no longer "incubating")
> --
>
> Key: GEODE-2264
> URL: https://issues.apache.org/jira/browse/GEODE-2264
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Dave Barnes
> Fix For: 1.1.0
>
>
> The Geode Javadocs 
> (http://geode.apache.org/releases/latest/javadoc/index.html) title line still 
> says "Apache Geode (incubating) 1.0.0-incubating", even thought the project 
> has graduated from the incubator.



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


[jira] [Resolved] (GEODE-2264) Update Geode Javadocs (no longer "incubating")

2017-01-16 Thread Anthony Baker (JIRA)

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

Anthony Baker resolved GEODE-2264.
--
Resolution: Not A Problem

> Update Geode Javadocs (no longer "incubating")
> --
>
> Key: GEODE-2264
> URL: https://issues.apache.org/jira/browse/GEODE-2264
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Dave Barnes
> Fix For: 1.1.0
>
>
> The Geode Javadocs 
> (http://geode.apache.org/releases/latest/javadoc/index.html) title line still 
> says "Apache Geode (incubating) 1.0.0-incubating", even thought the project 
> has graduated from the incubator.



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


Re: Native Client Directory Structure

2017-01-16 Thread Jacob Barrett
+1 for separate repo for sub-projects that would or could likely release
independently of the core project. I see this applying to most clients,
.net, c++, python, etc. It also cleanly separates out the build process
which is quite different between these projects. The native clients in
particular are dependent a on bunch of toolchains that aren't part of the
standard core developer's toolbox. Even if released together under the
umbrella of the Geode product it may still make sense to let them evolve
independently in their own repos to isolate the concerns between the
sources.



On Mon, Jan 16, 2017 at 11:52 AM Anthony Baker  wrote:

> I’m cautiously in favor of this idea.  Allowing independent parts (geode,
> geode-examples, geode-native) to progress and release at their own pace
> seems like a good thing.
>
> From a release perspective, I think each repo would have separate vote
> threads and a section on our release page:
> http://geode.apache.org/releases/
>
> Anthony
>
> > On Jan 16, 2017, at 11:24 AM, Jacob Barrett  wrote:
> >
> > I would love a separate repo. Someone told me that wasn't an option. If
> > it's an option the let's make it so.
> >
> > On Mon, Jan 16, 2017 at 11:20 AM Mark Bretl  wrote:
> >
> >> Jake,
> >>
> >> Having all the clients in the repository is nice, however, has there
> been
> >> thought to have them in their own repository? Now that we are a TLP, we
> do
> >> have that capability, as seen with the 'geode-examples' repository.
> >>
> >> --Mark
> >>
> >> On Mon, Jan 16, 2017 at 10:38 AM, Udo Kohlmeyer 
> >> wrote:
>
>


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

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

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

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

Github user galen-pivotal commented on the issue:

https://github.com/apache/geode/pull/337
  
Moving to review board.


> 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
>Assignee: Galen O'Sullivan
>Priority: Minor
>
> 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: The next release (v1.1.0)

2017-01-16 Thread Hitesh Khamesra
Update: We are waiting on following tickets for first release candidate.

1.  GEODE-2296 GetFunctionAttribute command is throwing an Anonymouse User 
Exception
2.  GEODE-2277 client cache fails to deserialize a PdxInstance due to 
InternalGemFireError
3.  GEODE-2031 Host documentation for releases 
4.  GEODE-1965 Create backward-compatibility unit test framework 

Thanks.HItesh

  From: Anthony Baker 
 To: dev@geode.apache.org 
 Sent: Monday, January 9, 2017 9:49 AM
 Subject: Re: The next release (v1.1.0)
   
Updates:

1) I did a first round of changes on GEODE-2142, should be enough for v1.1.0.
2) Any volunteers to look at GEODE-2031 or GEODE-1965?
3) Are there other open issues that should be included in the release?
4) Last call for a release manager…  :-)

Thanks,
Anthony


> On Jan 6, 2017, at 10:13 AM, Anthony Baker  wrote:
> 
> Our last release was on October 25.  I think we’re past due for another one!  
> We’ve had lots of great contributions since 1.0.0-incubating and now that 
> we’re are a top-level project we can drop the “-incubating” qualifier.
> 
> I reviewed our open JIRA issues and would like to include the following in 
> the release:
> 
> GEODE-2142 - JSON license incompatibility
>     We can update the NOTICE files and leave the JSON dependency alone (as 
> long as we do another release before April 30).
> 
> GEODE-1965 - backwards compatibility tests
>     I’d like to make sure we haven’t broken anything since our last release.
> 
> GEODE-2031 - versioned documentation
>     Seems relatively straightforward?
> 
> The remaining issues that are tagged with v1.1.0 [1] could be pushed to a 
> following release IMO.  Thoughts?
> 
> Regarding the release manager, I can do the dirty work if no one else wants 
> to volunteer :-)
> 
> Anthony
> 
> [1] 
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20GEODE%20AND%20fixVersion%20%3D%201.1.0%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
> 
>> On Nov 21, 2016, at 9:26 AM, Anthony Baker  wrote:
>> 
>> Now that graduation is done (!!), we need to organize our next release.  I 
>> propose we focus on completing the transition to TLP and cleaning up 
>> “incubating" references.  The sequence would look something like this:
>> 
>> 1) Transition the git repo, mailing lists, etc.
>> 2) Update incubating references in source, docs, website, wiki, …
>> 3) Do a release.
>> 
>> Thoughts?
>> 
>> We need a release manager.  Any volunteers?
>> 
>> Also, we need to rename the JIRA version from 1.1.0-incubating to 1.1.0.  
>> Can someone with JIRA karma help?
>> 
>> Anthony
>> 
> 


   

[jira] [Created] (GEODE-2309) Replace or add ASF copyright statements in source.

2017-01-16 Thread Jacob S. Barrett (JIRA)
Jacob S. Barrett created GEODE-2309:
---

 Summary: Replace or add ASF copyright statements in source.
 Key: GEODE-2309
 URL: https://issues.apache.org/jira/browse/GEODE-2309
 Project: Geode
  Issue Type: Task
  Components: native client
Reporter: Jacob S. Barrett
 Fix For: 1.1.0






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


[jira] [Created] (GEODE-2308) Replace GemFire branding with Geode branding.

2017-01-16 Thread Jacob S. Barrett (JIRA)
Jacob S. Barrett created GEODE-2308:
---

 Summary: Replace GemFire branding with Geode branding.
 Key: GEODE-2308
 URL: https://issues.apache.org/jira/browse/GEODE-2308
 Project: Geode
  Issue Type: Task
  Components: native client
Reporter: Jacob S. Barrett
 Fix For: 1.1.0






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


[jira] [Updated] (GEODE-1733) Lucene indexes stats are zeroed after recovering from indexes from disk

2017-01-16 Thread nabarun (JIRA)

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

nabarun updated GEODE-1733:
---
Fix Version/s: 1.1.0

> Lucene indexes stats are zeroed after recovering from indexes from disk
> ---
>
> Key: GEODE-1733
> URL: https://issues.apache.org/jira/browse/GEODE-1733
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: William Markito Oliveira
>Assignee: nabarun
> Fix For: 1.1.0
>
>
> When recovering from disk the indexes stats are zeroed until a query is 
> executed. 
> {code}
> 
> gfsh>list lucene indexes --with-stats
>Index Name | Region Path |  Indexed Fields  | Field 
> Analyzer |   Status| Query Executions | Updates | Commits | Documents
> - | --- |  | 
> -- | --- |  | --- | --- | 
> -
> customerRegionAll | /customer   | [lastUpdateDateTime, displayNa.. | {}   
>   | Initialized | 0| 0   | 0   | 0
> customerRegionAll | /customer   | [lastUpdateDateTime, displayNa.. | {}   
>   | Initialized | 0| 0   | 0   | 0
> customerRegionAll | /customer   | [lastUpdateDateTime, displayNa.. | {}   
>   | Initialized | 0| 0   | 0   | 0
> customerRegionID  | /customer   | [id] | {}   
>   | Initialized | 0| 0   | 0   | 0
> customerRegionID  | /customer   | [id] | {}   
>   | Initialized | 0| 0   | 0   | 0
> customerRegionID  | /customer   | [id] | {}   
>   | Initialized | 0| 0   | 0   | 0
> 
> After query: 
> gfsh>list lucene indexes --with-stats
>Index Name | Region Path |  Indexed Fields  | Field 
> Analyzer |   Status| Query Executions | Updates | Commits | Documents
> - | --- |  | 
> -- | --- |  | --- | --- | 
> -
> customerRegionAll | /customer   | [lastUpdateDateTime, displayNa.. | {}   
>   | Initialized | 0| 0   | 0   | 0
> customerRegionAll | /customer   | [lastUpdateDateTime, displayNa.. | {}   
>   | Initialized | 0| 0   | 0   | 0
> customerRegionAll | /customer   | [lastUpdateDateTime, displayNa.. | {}   
>   | Initialized | 0| 0   | 0   | 0
> customerRegionID  | /customer   | [id] | {}   
>   | Initialized | 114  | 0   | 0   | 20644274
> customerRegionID  | /customer   | [id] | {}   
>   | Initialized | 111  | 0   | 0   | 20103890
> customerRegionID  | /customer   | [id] | {}   
>   | Initialized | 114  | 0   | 0   | 20637846
> {code}



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


[GitHub] geode pull request #337: [GEODE-2295] Add constructors for LocatorCancelExce...

2017-01-16 Thread galen-pivotal
Github user galen-pivotal closed the pull request at:

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


---
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-2295) LocatorCancelException ignores string passed in constructor

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

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

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

Github user galen-pivotal closed the pull request at:

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


> 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
>Assignee: Galen O'Sullivan
>Priority: Minor
>
> 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: [ANNOUNCE] Donation of improved GemFire native client

2017-01-16 Thread Anthony Baker

> On Jan 16, 2017, at 11:49 AM, Jacob Barrett  wrote:
> 
> So you envision a world where someone who doesn't care about native clients
> must build the native clients as part of the root gradle build and a person
> not interested in building the Java bits must you gradle to build the
> native clients?
> 
> Both those scenarios don't sound great to me. As a developer only
> interested in one of the component of project I really don't want to have
> to build them all to get one. I would actually use that to echo Mark's
> suggestion of a separate repo. Especially as a native developer I would not
> want to have all the dependencies of server project in my environment just
> to build native bits. Even worse would be requiring someone only interested
> in the Java bits to meet all the dependencies of the native build.
> 
> Am I misunderstanding what you are suggesting?
> 
> On Mon, Jan 16, 2017 at 11:04 AM Anthony Baker  wrote:

The reason why I want a single integrated build is to make it super simple for 
*anyone* to build the project.  This is also useful for doing releases.  I 
think that your suggestions about working patterns make sense and could be 
worked this approach.  Of course, if we split this source into its own repo 
this discussion is moot.

Anthony



Re: Native Client Directory Structure

2017-01-16 Thread Anilkumar Gingade
+1 Separate repo for clients...Jake has valid point...

-Anil.


On Mon, Jan 16, 2017 at 12:07 PM, Michael William Dodge 
wrote:

> +1 for at least a separate repo for the clients. Jake makes a good point
> about dependencies on different toolchains. I'm not sure whether that would
> merit have a separate repo for each platform's client, e.g., a repo for the
> Java client, a repo for the C# client, etc. My instinct is to divide the
> software along lines that matches how people who want to develop against
> the client APIs think of things. For example, Netty is for Java, dotNetty
> is for C#, and nettyplusplus is for C++. Would the developers of Geode
> clients think more in terms of a client API implemented for different
> platforms or different platforms that have a client API?
>
> Sarge
>
> > On 16 Jan, 2017, at 11:56, Jacob Barrett  wrote:
> >
> > +1 for separate repo for sub-projects that would or could likely release
> > independently of the core project. I see this applying to most clients,
> > .net, c++, python, etc. It also cleanly separates out the build process
> > which is quite different between these projects. The native clients in
> > particular are dependent a on bunch of toolchains that aren't part of the
> > standard core developer's toolbox. Even if released together under the
> > umbrella of the Geode product it may still make sense to let them evolve
> > independently in their own repos to isolate the concerns between the
> > sources.
> >
> >
> >
> > On Mon, Jan 16, 2017 at 11:52 AM Anthony Baker 
> wrote:
> >
> >> I’m cautiously in favor of this idea.  Allowing independent parts
> (geode,
> >> geode-examples, geode-native) to progress and release at their own pace
> >> seems like a good thing.
> >>
> >> From a release perspective, I think each repo would have separate vote
> >> threads and a section on our release page:
> >> http://geode.apache.org/releases/
> >>
> >> Anthony
> >>
> >>> On Jan 16, 2017, at 11:24 AM, Jacob Barrett 
> wrote:
> >>>
> >>> I would love a separate repo. Someone told me that wasn't an option. If
> >>> it's an option the let's make it so.
> >>>
> >>> On Mon, Jan 16, 2017 at 11:20 AM Mark Bretl  wrote:
> >>>
>  Jake,
> 
>  Having all the clients in the repository is nice, however, has there
> >> been
>  thought to have them in their own repository? Now that we are a TLP,
> we
> >> do
>  have that capability, as seen with the 'geode-examples' repository.
> 
>  --Mark
> 
>  On Mon, Jan 16, 2017 at 10:38 AM, Udo Kohlmeyer <
> ukohlme...@pivotal.io>
>  wrote:
> >>
> >>
>
>


[jira] [Created] (GEODE-2307) Add FindGeode CMake module to native client build for finding Geode installation

2017-01-16 Thread Jacob S. Barrett (JIRA)
Jacob S. Barrett created GEODE-2307:
---

 Summary: Add FindGeode CMake module to native client build for 
finding Geode installation
 Key: GEODE-2307
 URL: https://issues.apache.org/jira/browse/GEODE-2307
 Project: Geode
  Issue Type: Task
  Components: native client
Reporter: Jacob S. Barrett
 Fix For: 1.1.0


Native client build has dependencies on the Geode product installation. 
FindGeode would locate the product in know locations or take hint in the form 
of `-DGEODE_ROOT` argument to `cmake`.



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


GEODE-2260: reviews still needed. . .

2017-01-16 Thread Karen Miller
It's been a full week, but I haven't gotten any reviews on GEODE-2260, to
remove the geode-examples module from the geode repository.  I'm not
a build/gradle expert, and this commit changes the build, so it really needs
some reviews.

The review request is https://reviews.apache.org/r/55393/

Thanks.  Karen


Re: Review Request 55393: GEODE-2260 Remove geode-examples from geode repo and geode build

2017-01-16 Thread Mark Bretl

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


Ship it!




Ship It!

- Mark Bretl


On Jan. 10, 2017, 2:39 p.m., Karen Miller wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/55393/
> ---
> 
> (Updated Jan. 10, 2017, 2:39 p.m.)
> 
> 
> Review request for geode, Anthony Baker, William Markito, Mark Bretl, and Dan 
> Smith.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2260 Remove geode-examples from geode repo and geode build
> 
> 
> Diffs
> -
> 
>   build.gradle c9915358bd7b7071ddae9f8c058b2388db5a415b 
>   geode-assembly/build.gradle dba5dc768a0b4829aff17c4143e8da3b87106319 
>   geode-examples/.gitignore b1001a6575698224615e5d4b6ff804e9c4506d0a 
>   geode-examples/README.md 62666035ab1bde5f9d5548e887e0133f006c2ef9 
>   geode-examples/build.gradle 1e638bc2f18f5aed2ba007e60e7b8e48711383b9 
>   geode-examples/gradle.properties c1739aff2825d87e10717f877cc4a12f4101c6c1 
>   geode-examples/gradle/wrapper/gradle-wrapper.jar 
> 2c6137b87896c8f70315ae454e00a969ef5f6019 
>   geode-examples/gradle/wrapper/gradle-wrapper.properties 
> 6132c99fbc50c6921e25432874c31a55382ef8fc 
>   geode-examples/gradlew 9d82f78915133e1c35a6ea51252590fb38efac2f 
>   geode-examples/gradlew.bat 5f192121eb4f5b109f22fa96a6246eb39e749ed6 
>   geode-examples/replicated/.gitignore 
> b858ea877b065d2420484a484d649f98054c9cc0 
>   geode-examples/replicated/README.md 
> ea923ddc76b3143bc288daf615e2c6a02e84447d 
>   geode-examples/replicated/build.gradle 
> 52283ecef776b3f6a484bdc6e7cc3cdc5b1ffe29 
>   geode-examples/replicated/scripts/.gitignore 
> 32f8870d0e0514786c159a18c9bcc6b62ac48956 
>   geode-examples/replicated/scripts/pidkiller.sh 
> ecf8f2d6911121f12df29d69dbbde7c0a67b5ced 
>   geode-examples/replicated/scripts/setEnv.sh 
> e9e860e271f523d4818f13b73de5df64897c19ed 
>   geode-examples/replicated/scripts/startAll.sh 
> 2b08f197191ced868481462752b91cbe7d6e45b6 
>   geode-examples/replicated/scripts/stopAll.sh 
> a6364a861395e8e2077ff63f27946eee616e0b6b 
>   
> geode-examples/replicated/src/main/java/org/apache/geode/examples/replicated/BaseClient.java
>  3e656f6a5b86b226db3611559eae13f92bf76b38 
>   
> geode-examples/replicated/src/main/java/org/apache/geode/examples/replicated/Consumer.java
>  7954bb57b7a86bfe4baf8ba3b9798d713f71830e 
>   
> geode-examples/replicated/src/main/java/org/apache/geode/examples/replicated/Producer.java
>  79d5dfecb2c21a09a9f926d505d466490e18c0b6 
>   
> geode-examples/replicated/src/test/java/org/apache/geode/examples/replicated/ConsumerTest.java
>  2fab5087c0ce41dfeb57d2c97113165051d84096 
>   
> geode-examples/replicated/src/test/java/org/apache/geode/examples/replicated/ProducerTest.java
>  9b4a2511bf27b83dbcd5552a5ed46ac2d85c1163 
>   
> geode-examples/replicated/src/test/java/org/apache/geode/examples/replicated/ReplicatedTest.java
>  ab84485f8cd26a7da246fb59dc7856c79d1bcca2 
>   geode-examples/settings.gradle 432a8ebc38f85e7e3e6c8b7d71328b90bc1356e4 
>   
> geode-examples/utils/src/main/java/org/apache/geode/example/utils/ShellUtil.java
>  c5290b826ab40df4474e714e2a4d298e9f10e7f5 
> 
> Diff: https://reviews.apache.org/r/55393/diff/
> 
> 
> Testing
> ---
> 
> Ran
> `./gradlew precheckin -xdistributedTest -xintegrationTest -xflakyTest`
> to verify that a geode-examples directory is not included in the source 
> distribution.
> 
> Ran
> `./gradlew build -Dskip.tests=true`
> to verify no errors in the build (without tests).
> 
> Ran
> `./gradlew tasks`
> to observe that there were no tasks involving Examples.
> 
> 
> Thanks,
> 
> Karen Miller
> 
>



JIRA components for native clients

2017-01-16 Thread Jacob Barrett
Would someone with some karma please add some components to the JIRA for
native client.

At a minimum "C++ client" and ".NET client" components would be helpful.

Thanks,
Jake


Re: Native Client Directory Structure

2017-01-16 Thread Joey McAllister
+1 to the separate repo.

I think it also makes sense—especially with independent release
schedules—to keep the client documentation source in the client repo and
build it as its own User Guide, which we can host in its own section on
geode.apache.org/docs/.

On Mon, Jan 16, 2017 at 12:14 PM Udo Kohlmeyer 
wrote:

+1 to separate client repos. Or at least some ability to independently
version client code for releases.

--Udo


On 1/16/17 11:56, Jacob Barrett wrote:
> +1 for separate repo for sub-projects that would or could likely release
> independently of the core project. I see this applying to most clients,
> .net, c++, python, etc. It also cleanly separates out the build process
> which is quite different between these projects. The native clients in
> particular are dependent a on bunch of toolchains that aren't part of the
> standard core developer's toolbox. Even if released together under the
> umbrella of the Geode product it may still make sense to let them evolve
> independently in their own repos to isolate the concerns between the
> sources.
>
>
>
> On Mon, Jan 16, 2017 at 11:52 AM Anthony Baker  wrote:
>
>> I’m cautiously in favor of this idea.  Allowing independent parts (geode,
>> geode-examples, geode-native) to progress and release at their own pace
>> seems like a good thing.
>>
>>  From a release perspective, I think each repo would have separate vote
>> threads and a section on our release page:
>> http://geode.apache.org/releases/
>>
>> Anthony
>>
>>> On Jan 16, 2017, at 11:24 AM, Jacob Barrett  wrote:
>>>
>>> I would love a separate repo. Someone told me that wasn't an option. If
>>> it's an option the let's make it so.
>>>
>>> On Mon, Jan 16, 2017 at 11:20 AM Mark Bretl  wrote:
>>>
 Jake,

 Having all the clients in the repository is nice, however, has there
>> been
 thought to have them in their own repository? Now that we are a TLP, we
>> do
 have that capability, as seen with the 'geode-examples' repository.

 --Mark

 On Mon, Jan 16, 2017 at 10:38 AM, Udo Kohlmeyer 
 wrote:
>>


[jira] [Resolved] (GEODE-1733) Lucene indexes stats are zeroed after recovering from indexes from disk

2017-01-16 Thread nabarun (JIRA)

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

nabarun resolved GEODE-1733.

Resolution: Fixed

> Lucene indexes stats are zeroed after recovering from indexes from disk
> ---
>
> Key: GEODE-1733
> URL: https://issues.apache.org/jira/browse/GEODE-1733
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: William Markito Oliveira
>Assignee: nabarun
> Fix For: 1.1.0
>
>
> When recovering from disk the indexes stats are zeroed until a query is 
> executed. 
> {code}
> 
> gfsh>list lucene indexes --with-stats
>Index Name | Region Path |  Indexed Fields  | Field 
> Analyzer |   Status| Query Executions | Updates | Commits | Documents
> - | --- |  | 
> -- | --- |  | --- | --- | 
> -
> customerRegionAll | /customer   | [lastUpdateDateTime, displayNa.. | {}   
>   | Initialized | 0| 0   | 0   | 0
> customerRegionAll | /customer   | [lastUpdateDateTime, displayNa.. | {}   
>   | Initialized | 0| 0   | 0   | 0
> customerRegionAll | /customer   | [lastUpdateDateTime, displayNa.. | {}   
>   | Initialized | 0| 0   | 0   | 0
> customerRegionID  | /customer   | [id] | {}   
>   | Initialized | 0| 0   | 0   | 0
> customerRegionID  | /customer   | [id] | {}   
>   | Initialized | 0| 0   | 0   | 0
> customerRegionID  | /customer   | [id] | {}   
>   | Initialized | 0| 0   | 0   | 0
> 
> After query: 
> gfsh>list lucene indexes --with-stats
>Index Name | Region Path |  Indexed Fields  | Field 
> Analyzer |   Status| Query Executions | Updates | Commits | Documents
> - | --- |  | 
> -- | --- |  | --- | --- | 
> -
> customerRegionAll | /customer   | [lastUpdateDateTime, displayNa.. | {}   
>   | Initialized | 0| 0   | 0   | 0
> customerRegionAll | /customer   | [lastUpdateDateTime, displayNa.. | {}   
>   | Initialized | 0| 0   | 0   | 0
> customerRegionAll | /customer   | [lastUpdateDateTime, displayNa.. | {}   
>   | Initialized | 0| 0   | 0   | 0
> customerRegionID  | /customer   | [id] | {}   
>   | Initialized | 114  | 0   | 0   | 20644274
> customerRegionID  | /customer   | [id] | {}   
>   | Initialized | 111  | 0   | 0   | 20103890
> customerRegionID  | /customer   | [id] | {}   
>   | Initialized | 114  | 0   | 0   | 20637846
> {code}



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


[jira] [Updated] (GEODE-2273) Display the server name while listing the Lucene index stats

2017-01-16 Thread nabarun (JIRA)

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

nabarun updated GEODE-2273:
---
Component/s: lucene

> Display the server name while listing the Lucene index stats
> 
>
> Key: GEODE-2273
> URL: https://issues.apache.org/jira/browse/GEODE-2273
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: nabarun
>
> Display the server's name hosting the Lucene indexes while listing the Lucene 
> index stats in gfsh.
> Currently we can't distinguish between the listed pairs.
> {noformat}
> 
> gfsh>list lucene indexes --with-stats
>Index Name | Region Path |  Indexed Fields  | Field 
> Analyzer |   Status| Query Executions | Updates | Commits | Documents
> - | --- |  | 
> -- | --- |  | --- | --- | 
> -
> customerRegionAll | /customer   | [lastUpdateDateTime, displayNa.. | {}   
>   | Initialized | 0| 0   | 0   | 0
> customerRegionAll | /customer   | [lastUpdateDateTime, displayNa.. | {}   
>   | Initialized | 0| 0   | 0   | 0
> {noformat}



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


Re: Native Client Directory Structure

2017-01-16 Thread Mark Bretl
Jake,

Having all the clients in the repository is nice, however, has there been
thought to have them in their own repository? Now that we are a TLP, we do
have that capability, as seen with the 'geode-examples' repository.

--Mark

On Mon, Jan 16, 2017 at 10:38 AM, Udo Kohlmeyer 
wrote:

> -1 "geode-native" directory name
>
> +1 "geode-client" directory name
>
> Maybe the directories for the different clients are by language, so we
> omit the "geode" prefix i.e
>
> geode-client/
>c++,
>net
>java
>python
>
>
> If clients are in their own project, then the clients can be independently
> versioned of the server code. imo, there should be no need for them to be
> in lock-stead with the server code.
>
> --Udo
>
>
>
> On 1/16/17 08:52, Jacob Barrett wrote:
>
>> Let's try this again. Using the +1 mechanism for a multipart email is
>> tough
>> so please include a comment on which part you are +1ing.
>>
>> Also, I want to revise my suggestion to just call the directory
>> 'geode-native' rather than 'geode-nativeclient'. Simply because I am lazy
>> and don't want to type the extra 6 letters all the time.
>>
>> -Jake
>>
>> On Mon, Jan 16, 2017 at 8:26 AM Jacob Barrett 
>> wrote:
>>
>> One of the first things necessary to get NC merged into the the develop
>>> branch is understanding where it will go under the current geode project
>>> structure.
>>>
>>> The quick and obvious solution is adding a 'geode-nativeclient`
>>> subproject
>>> and relocating all the NC sources into that directory.
>>>
>>> Given that NC consists of two semi-distinct clients, C++ and .NET, it may
>>> also make sense to organize more of a hierarchy. Consider:
>>> geode-client/
>>>  geode++
>>>  geode.net
>>> (or some other more creative names)
>>> Keep in mind that today the .NET client is very tightly coupled with the
>>> C++ client, so you can't build .NET without first building C++.
>>>
>>> My suggestion would be to do the quick and easy now and as we continue to
>>> refine and refactor and hopefully write the .NET in pure CLI we make that
>>> move them. Perhaps by that time there will be a pure Java client to
>>> include
>>> in that structure.
>>>
>>> Thoughts?
>>>
>>>
>>> -Jake
>>>
>>>
>>>
>


[jira] [Updated] (GEODE-697) A client thread timing out an operation and performing further operations can result in cache inconsistency

2017-01-16 Thread Udo Kohlmeyer (JIRA)

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

Udo Kohlmeyer updated GEODE-697:

Assignee: Darrel Schneider  (was: Bruce Schuchardt)

> A client thread timing out an operation and performing further operations can 
> result in cache inconsistency
> ---
>
> Key: GEODE-697
> URL: https://issues.apache.org/jira/browse/GEODE-697
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Dan Smith
>Assignee: Darrel Schneider
>
> There is a case where the primary and secondary buckets of a partitioned 
> region can become out of sync if a client times out while waiting for a slow 
> operation to finish. Here's the scenario:
> 1. A operation is started by the client and gets stuck on the server, for 
> example by a slow cache writer. That operation is assigned an EventID  with a 
> sequence number of 1.
> 2. The client times out.
> 3. The client performs a second operation. That operation gets assigned an 
> EventID with a sequence number of 2.
> 4. The second operation is applied on all members. The EventTracker records 
> the sequence number 2.
> 5. The original operation continues. It is applied to the primary (because it 
> has passed the EventTracker test).
> 6. The original operation is rejected by the EventTracker on the secondary. 
> The two copies of the bucket are now inconsistent.
> One possible fix is to change the thread id of the thread on the client when 
> the client operation times out. That would ensure that the EventTracker will 
> not reject the original operation when it finally goes through, because it 
> has a different thread id.
> If an operation is delayed on the server, for example by a very slow cache 
> writer, the operation can time out on the client.
> The client can then go on and perform a second operation.
> The problem is that each operation is assigned an event id which is a 
> combination of the clients thread id and a sequence number. That second 
> operation has a higher sequence number.
> Once the second operation is applied to a region on a given member, the event 
> is stored in the EventTracker and that member will reject any lower sequence 
> numbers



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


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

2017-01-16 Thread Joey McAllister
Thanks, Karen. Let me know if you have any questions.

On Mon, Jan 16, 2017 at 11:56 AM Karen Miller  wrote:

> I'm going to pull this in and then update Geode web page.
>
>
> On Wed, Jan 11, 2017 at 4:50 PM, joeymcallister 
> wrote:
>
> > 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 <
> http://localhost:9292
> > >.
> >
> > -## 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.
> > ---
> >
>


Re: JIRA components for native clients

2017-01-16 Thread Roman Shaposhnik
We do have an existing "native client" component. What should we do with that?

Thanks,
Roman.

On Mon, Jan 16, 2017 at 12:00 PM, Jacob Barrett  wrote:
> Would someone with some karma please add some components to the JIRA for
> native client.
>
> At a minimum "C++ client" and ".NET client" components would be helpful.
>
> Thanks,
> Jake


Re: JIRA components for native clients

2017-01-16 Thread Jacob Barrett
I suppose that one is sufficient to cover both but it would be nice to
narrow down on specific clients.

It is coming from it's own JIRA where we had components for:
C++ library
.NET library
test (for test framework issues)
install (for installer issues)
docs
build

Would be nice to be able to cover all those individually here too but we
realize we are sharing JIRA with the main project. Maybe:
native/C++ library
native/.NET library
native/test
native/... (you get the point)

Thoughts?


On Mon, Jan 16, 2017 at 12:29 PM Roman Shaposhnik 
wrote:

> We do have an existing "native client" component. What should we do with
> that?
>
> Thanks,
> Roman.
>
> On Mon, Jan 16, 2017 at 12:00 PM, Jacob Barrett 
> wrote:
> > Would someone with some karma please add some components to the JIRA for
> > native client.
> >
> > At a minimum "C++ client" and ".NET client" components would be helpful.
> >
> > Thanks,
> > Jake
>


[jira] [Updated] (GEODE-2308) Replace GemFire branding with Geode branding.

2017-01-16 Thread Anthony Baker (JIRA)

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

Anthony Baker updated GEODE-2308:
-
Fix Version/s: (was: 1.1.0)

> Replace GemFire branding with Geode branding.
> -
>
> Key: GEODE-2308
> URL: https://issues.apache.org/jira/browse/GEODE-2308
> Project: Geode
>  Issue Type: Task
>  Components: native client
>Reporter: Jacob S. Barrett
>




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


[jira] [Commented] (GEODE-2272) Pulse Data Browser export hangs

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

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

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

GitHub user jaredjstewart opened a pull request:

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

GEODE-2272: Fix Pulse data browser export

* Pulse no longer loads all results into the browser before generating a 
results file for download.

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

$ git pull https://github.com/jaredjstewart/geode GEODE-2272

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

https://github.com/apache/geode/pull/339.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 #339


commit f6767f0e93d3a49cd4a8322fb93d07b49e0f5d65
Author: Jared Stewart 
Date:   2017-01-16T21:58:28Z

GEODE-2272: Fix Pulse data browser export

* Pulse no longer loads all results into the browser before generating a 
results file for download.




> Pulse Data Browser export hangs
> ---
>
> Key: GEODE-2272
> URL: https://issues.apache.org/jira/browse/GEODE-2272
> Project: Geode
>  Issue Type: Bug
>  Components: pulse
>Affects Versions: 1.0.0-incubating
>Reporter: Jared Stewart
>Assignee: Jared Stewart
>
> The Export feature of Pulse Data Browser is prone to hang with large amounts 
> of data as it requires loading all the query results into the browser before 
> they can be exported.  Instead, we should allow a user to Export query 
> results directly to a file without first loading the results into their 
> browser.



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


[Spring CI] Spring Data GemFire > Nightly-ApacheGeode > #440 was SUCCESSFUL

2017-01-16 Thread Spring CI

---
Spring Data GemFire > Nightly-ApacheGeode > #440 was successful.
---
Scheduled

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





--
This message is automatically generated by Atlassian Bamboo

[jira] [Commented] (GEODE-2272) Pulse Data Browser export hangs

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

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

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

Github user asfgit closed the pull request at:

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


> Pulse Data Browser export hangs
> ---
>
> Key: GEODE-2272
> URL: https://issues.apache.org/jira/browse/GEODE-2272
> Project: Geode
>  Issue Type: Bug
>  Components: pulse
>Affects Versions: 1.0.0-incubating
>Reporter: Jared Stewart
>Assignee: Jared Stewart
>
> The Export feature of Pulse Data Browser is prone to hang with large amounts 
> of data as it requires loading all the query results into the browser before 
> they can be exported.  Instead, we should allow a user to Export query 
> results directly to a file without first loading the results into their 
> browser.



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


[jira] [Created] (GEODE-2311) Add CSharp Project for securityImpl for Building Native Client .NET Security Quickstarts

2017-01-16 Thread Michael Martell (JIRA)
Michael Martell created GEODE-2311:
--

 Summary: Add CSharp Project for securityImpl for Building Native 
Client .NET Security Quickstarts
 Key: GEODE-2311
 URL: https://issues.apache.org/jira/browse/GEODE-2311
 Project: Geode
  Issue Type: Task
  Components: native client
Reporter: Michael Martell


Native client build has dependencies on the Geode product installation. 
FindGeode would locate the product in know locations or take hint in the form 
of {{-DGEODE_ROOT}} argument to {{cmake}}.



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


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

2017-01-16 Thread xiaojian zhou

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


Ship it!




Ship It!

- xiaojian zhou


On Jan. 16, 2017, 7:37 p.m., nabarun nag wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/55442/
> ---
> 
> (Updated Jan. 16, 2017, 7:37 p.m.)
> 
> 
> 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
> ```
> 
> 
> After Dan's review.
> 
> ```
> Index Name | Region Path | Server Name | Indexed Fields | Field 
> Analyzer |   Status| Query Executions | Updates | Commits | Documents
> -- | --- | --- | -- | 
> -- | --- |  | --- | --- | 
> -
> testIndex  | /testRegion | server1 | [__REGION_VALUE_FIELD] | {}  
>| Initialized | 0| 3   | 3   | 2
> testIndex  | /testRegion | server2 | [__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 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/cli/functions/LuceneDescribeIndexFunction.java
>  0ec5b4d 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/cli/functions/LuceneListIndexFunction.java
>  8732bba 
>   
> geode-lucene/src/test/java/org/apache/geode/cache/lucene/internal/cli/LuceneIndexCommandsJUnitTest.java
>  dbb80dc 
>   
> geode-lucene/src/test/java/org/apache/geode/cache/lucene/internal/cli/functions/LuceneDescribeIndexFunctionJUnitTest.java
>  7330e2c 
>   
> geode-lucene/src/test/java/org/apache/geode/cache/lucene/internal/cli/functions/LuceneListIndexFunctionJUnitTest.java
>  3adc030 
> 
> Diff: https://reviews.apache.org/r/55442/diff/
> 
> 
> Testing
> ---
> 
> 1. Precheck
> 2. Running it on gfsh terminal
> 
> 
> Thanks,
> 
> nabarun nag
> 
>



[jira] [Updated] (GEODE-2309) Replace or add ASF copyright statements in source.

2017-01-16 Thread Anthony Baker (JIRA)

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

Anthony Baker updated GEODE-2309:
-
Fix Version/s: (was: 1.1.0)

> Replace or add ASF copyright statements in source.
> --
>
> Key: GEODE-2309
> URL: https://issues.apache.org/jira/browse/GEODE-2309
> Project: Geode
>  Issue Type: Task
>  Components: native client
>Reporter: Jacob S. Barrett
>




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


[jira] [Updated] (GEODE-2307) Add FindGeode CMake module to native client build for finding Geode installation

2017-01-16 Thread Anthony Baker (JIRA)

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

Anthony Baker updated GEODE-2307:
-
Fix Version/s: (was: 1.1.0)

> Add FindGeode CMake module to native client build for finding Geode 
> installation
> 
>
> Key: GEODE-2307
> URL: https://issues.apache.org/jira/browse/GEODE-2307
> Project: Geode
>  Issue Type: Task
>  Components: native client
>Reporter: Jacob S. Barrett
>
> Native client build has dependencies on the Geode product installation. 
> FindGeode would locate the product in know locations or take hint in the form 
> of {{-DGEODE_ROOT}} argument to {{cmake}}.



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


Re: Review Request 55591: GEODE-2297: passively discover DistributedSystem instance in AlertAppender

2017-01-16 Thread Jared Stewart

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


Ship it!




Ship It!

- Jared Stewart


On Jan. 16, 2017, 10 p.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/55591/
> ---
> 
> (Updated Jan. 16, 2017, 10 p.m.)
> 
> 
> Review request for geode, Bruce Schuchardt, Darrel Schneider, Jinmei Liao, 
> Jared Stewart, and Kevin Duling.
> 
> 
> Bugs: GEODE-2297
> https://issues.apache.org/jira/browse/GEODE-2297
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2297: passively discover DistributedSystem instance in AlertAppender to 
> use in append
> 
> AlertAppender was actively hitting a synchronization and fetching 
> InternalDistributedSystem singleton in every append(!) call. This can produce 
> a deadlock if an alert is generated during startup. 
> 
> This change removes the active fetch from the append code path and uses 
> InternalDistributedSystem.ConnectListener and 
> InternalDistributedSystem.DisconnectListener to receive notifications of 
> connect and disconnect. These notifications set an AtomicReference that is 
> now checked within append. (Registering a ConnectListener is static and 
> remains registered for the life of the JVM. For every onConnect, the 
> AlertAppender registers a non-static DisconnectListener for each 
> InternalDistributedSystem instance.)
> 
> I also fixed some minor IDE warnings, changed a logger statement from info to 
> debug and added a TODO to the class' logger instance. I want to follow up 
> later to *probably* change from using Logger to StatusLogger. Note: we run 
> with StatusLogger level of FATAL by default. Appender impl's really should 
> use StatusLogger instead of Logger (to avoid risk of infinite looping). As 
> it's currently written (with Logger), you'd have to set the AlertLevel to 
> DEBUG to hit this problem. I believe someone would only do this by error or 
> for experimentation.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/internal/logging/log4j/AlertAppender.java
>  a6c54aba352ba4dd3ece94c94f770292db6e9284 
> 
> Diff: https://reviews.apache.org/r/55591/diff/
> 
> 
> Testing
> ---
> 
> precheckin in progress
> 
> 
> Thanks,
> 
> Kirk Lund
> 
>



[jira] [Created] (GEODE-2310) Native client is looking for specific version of Geode jar.

2017-01-16 Thread Jacob S. Barrett (JIRA)
Jacob S. Barrett created GEODE-2310:
---

 Summary: Native client is looking for specific version of Geode 
jar.
 Key: GEODE-2310
 URL: https://issues.apache.org/jira/browse/GEODE-2310
 Project: Geode
  Issue Type: Bug
  Components: native client
Reporter: Jacob S. Barrett


Native client build is looking for specific version of Geode.jar rather than 
just geode-dependencies.jar.



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


[GitHub] geode issue #339: GEODE-2272: Fix Pulse data browser export

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

https://github.com/apache/geode/pull/339
  
Precheckin started


---
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-2272) Pulse Data Browser export hangs

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

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

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

Github user jaredjstewart commented on the issue:

https://github.com/apache/geode/pull/339
  
Precheckin started


> Pulse Data Browser export hangs
> ---
>
> Key: GEODE-2272
> URL: https://issues.apache.org/jira/browse/GEODE-2272
> Project: Geode
>  Issue Type: Bug
>  Components: pulse
>Affects Versions: 1.0.0-incubating
>Reporter: Jared Stewart
>Assignee: Jared Stewart
>
> The Export feature of Pulse Data Browser is prone to hang with large amounts 
> of data as it requires loading all the query results into the browser before 
> they can be exported.  Instead, we should allow a user to Export query 
> results directly to a file without first loading the results into their 
> browser.



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


[GitHub] geode pull request #339: GEODE-2272: Fix Pulse data browser export

2017-01-16 Thread jaredjstewart
GitHub user jaredjstewart opened a pull request:

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

GEODE-2272: Fix Pulse data browser export

* Pulse no longer loads all results into the browser before generating a 
results file for download.

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

$ git pull https://github.com/jaredjstewart/geode GEODE-2272

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

https://github.com/apache/geode/pull/339.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 #339


commit f6767f0e93d3a49cd4a8322fb93d07b49e0f5d65
Author: Jared Stewart 
Date:   2017-01-16T21:58:28Z

GEODE-2272: Fix Pulse data browser export

* Pulse no longer loads all results into the browser before generating a 
results file for download.




---
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 #339: GEODE-2272: Fix Pulse data browser export

2017-01-16 Thread asfgit
Github user asfgit closed the pull request at:

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


---
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-2272) Pulse Data Browser export hangs

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

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

ASF subversion and git services commented on GEODE-2272:


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

GEODE-2272: Fix Pulse data browser export

* Pulse no longer loads all results into the browser before generating a 
results file for download.

This closes #339


> Pulse Data Browser export hangs
> ---
>
> Key: GEODE-2272
> URL: https://issues.apache.org/jira/browse/GEODE-2272
> Project: Geode
>  Issue Type: Bug
>  Components: pulse
>Affects Versions: 1.0.0-incubating
>Reporter: Jared Stewart
>Assignee: Jared Stewart
>
> The Export feature of Pulse Data Browser is prone to hang with large amounts 
> of data as it requires loading all the query results into the browser before 
> they can be exported.  Instead, we should allow a user to Export query 
> results directly to a file without first loading the results into their 
> browser.



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


[jira] [Commented] (GEODE-2310) Native client is looking for specific version of Geode jar.

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

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

ASF subversion and git services commented on GEODE-2310:


Commit efd752ea3c8b5f83b2a624beecfb98301edd1d8b in geode's branch 
refs/heads/next-gen-native-client-software-grant from Jacob Barrett
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=efd752e ]

GEODE-2310: Fixed path to Geode jar.


> Native client is looking for specific version of Geode jar.
> ---
>
> Key: GEODE-2310
> URL: https://issues.apache.org/jira/browse/GEODE-2310
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Jacob S. Barrett
>
> Native client build is looking for specific version of Geode.jar rather than 
> just geode-dependencies.jar.



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


[jira] [Updated] (GEODE-2311) Add CSharp Project for securityImpl for Building Native Client .NET Security Quickstarts

2017-01-16 Thread Michael Martell (JIRA)

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

Michael Martell updated GEODE-2311:
---
Description: Since cmake doesn't yet support C#, we should provide a CSharp 
project (.csproj file) for easily building the securityImpl dll, which is 
needed by the native client C# security quickstarts.  (was: Native client build 
has dependencies on the Geode product installation. FindGeode would locate the 
product in know locations or take hint in the form of {{-DGEODE_ROOT}} argument 
to {{cmake}}.)

> Add CSharp Project for securityImpl for Building Native Client .NET Security 
> Quickstarts
> 
>
> Key: GEODE-2311
> URL: https://issues.apache.org/jira/browse/GEODE-2311
> Project: Geode
>  Issue Type: Task
>  Components: native client
>Reporter: Michael Martell
>
> Since cmake doesn't yet support C#, we should provide a CSharp project 
> (.csproj file) for easily building the securityImpl dll, which is needed by 
> the native client C# security quickstarts.



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


[jira] [Updated] (GEODE-2311) Add CSharp Project for securityImpl for Building Native Client .NET Security Quickstarts

2017-01-16 Thread Michael Martell (JIRA)

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

Michael Martell updated GEODE-2311:
---
Priority: Minor  (was: Major)

> Add CSharp Project for securityImpl for Building Native Client .NET Security 
> Quickstarts
> 
>
> Key: GEODE-2311
> URL: https://issues.apache.org/jira/browse/GEODE-2311
> Project: Geode
>  Issue Type: Task
>  Components: native client
>Reporter: Michael Martell
>Priority: Minor
>
> Since cmake doesn't yet support C#, we should provide a CSharp project 
> (.csproj file) for easily building the securityImpl dll, which is needed by 
> the native client C# security quickstarts.



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


[jira] [Commented] (GEODE-2296) GetFunctionAttribute command is throwing an Anonymouse User Exception

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

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

ASF subversion and git services commented on GEODE-2296:


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

GEODE-2296: remove security check in GetFunctionAttribute command


> GetFunctionAttribute command is throwing an Anonymouse User Exception
> -
>
> Key: GEODE-2296
> URL: https://issues.apache.org/jira/browse/GEODE-2296
> Project: Geode
>  Issue Type: Bug
>  Components: docs, management, security
>Reporter: Jinmei Liao
> Fix For: 1.1.0
>
>
> When trying to execute a function from a client, we sometimes would get this 
> exception. This is because GetFunctionAttribute is regarded as an internal 
> message, so it's not getting the subject bound to the executing thread, but 
> the cmdExecute method of this command is checking for authorization. Need to 
> remove that check and update the docs to not include this client command.
> [error 2017/01/12 15:25:20.968567 Pacific Standard Time mmartell-Win10:3084 
> 7460] Region::GET_FUNCTION_ATTRIBUTES: An exception 
> (org.apache.geode.security.GemFireSecurityException: Error: Anonymous User
>at 
> org.apache.geode.internal.security.IntegratedSecurityService.getSubject(IntegratedSecurityService.java:114)
>at 
> org.apache.geode.internal.security.IntegratedSecurityService.authorize(IntegratedSecurityService.java:273)
>at 
> org.apache.geode.internal.security.IntegratedSecurityService.authorize(IntegratedSecurityService.java:269)
>at 
> org.apache.geode.internal.security.IntegratedSecurityService.authorize(IntegratedSecurityService.java:264)
>at 
> org.apache.geode.internal.security.IntegratedSecurityService.authorize(IntegratedSecurityService.java:260)
>at 
> org.apache.geode.internal.security.IntegratedSecurityService.authorizeClusterRead(IntegratedSecurityService.java:220)
>at 
> org.apache.geode.internal.cache.tier.sockets.command.GetFunctionAttribute.cmdExecute(GetFunctionAttribute.java:60)
>at 
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:141)
>at 
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMsg(ServerConnection.java:776)
>at 
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doOneMessage(ServerConnection.java:904)
>at 
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1160)
>at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>at 
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl$1$1.run(AcceptorImpl.java:519)
>at java.lang.Thread.run(Thread.java:745)



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


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

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

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

ASF subversion and git services commented on GEODE-2031:


Commit ec31a26b0a4418e3397b7d75ccab43a80a7637d7 in geode's branch 
refs/heads/develop from [~jmcallis...@pivotal.io]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=ec31a26 ]

GEODE-2031 Add docs archive


> 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: [ANNOUNCE] Donation of improved GemFire native client

2017-01-16 Thread Jacob Barrett
Avinash,

We just added some changes to the Geode dependency. You should be able to
set cmake -DGEODE_ROOT=/path/to/apache-geode. Without that flag set it will
look for Geode in:

  /geode/bin
  /apache-geode/bin
  /usr/geode/bin
  /usr/apache-geode/bin
  /usr/local/geode/bin
  /usr/local/apache-geode/bin
  /opt/geode/bin
  /opt/apache-geode/bin
  /opt/local/geode/bin
  /opt/local/apache-geode/bin


-Jake


On Sun, Jan 15, 2017 at 2:24 AM Avinash Dongre  wrote:

> This is great.
>
> Need to make following change to PASS the build.
>
>
> diff --git a/src/tests/javaobject/CMakeLists.txt
> b/src/tests/javaobject/CMakeLists.txt
> index 4924e5c..7f85878 100644
> --- a/src/tests/javaobject/CMakeLists.txt
> +++ b/src/tests/javaobject/CMakeLists.txt
> @@ -9,8 +9,8 @@ get_filename_component(JAVA_HOME ${JAVA_BIN} DIRECTORY)
>
>  # Update the class path.
>  set(CMAKE_JAVA_INCLUDE_PATH ${JAVA_HOME}/lib/tools.jar)
> -if (GEMFIRE_HOME)
> -LIST(APPEND CMAKE_JAVA_INCLUDE_PATH
> ${GEMFIRE_HOME}/lib/geode-core-9.0.0.jar)
> +if (DEFINED ENV{GEMFIRE_HOME})
> +LIST(APPEND CMAKE_JAVA_INCLUDE_PATH
> $ENV{GEMFIRE_HOME}/lib/geode-core-1.0.0-incubating.jar)
>  else()
>  LIST(APPEND CMAKE_JAVA_INCLUDE_PATH
> "/gemfire/lib/geode-core-9.0.0.jar")
>  endif()
>
>
> Also need to update the src/BUILDING.md for instruction to download geode
> build from [1] and set GEMFIRE_HOME ( which I think should be changed to
> GEODE_HOME )
>
>


[jira] [Commented] (GEODE-2305) Remove native client packaging dependency on Pivotal EULA

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

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

ASF subversion and git services commented on GEODE-2305:


Commit 7a1b9d3b874e3b8240e40406766de452f20a189e in geode's branch 
refs/heads/next-gen-native-client-software-grant from Jacob Barrett
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=7a1b9d3 ]

GEODE-2305: Removed Pivotal_EULA.txt from the packaging.


> Remove native client packaging dependency on Pivotal EULA
> -
>
> Key: GEODE-2305
> URL: https://issues.apache.org/jira/browse/GEODE-2305
> Project: Geode
>  Issue Type: Task
>  Components: native client
>Reporter: Jacob S. Barrett
> Fix For: 1.1.0
>
>




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


Re: Native Client Directory Structure

2017-01-16 Thread Swapnil Bawaskar
+1 for a separate repo for each client.

On Mon, Jan 16, 2017 at 12:25 PM, Joey McAllister 
wrote:

> +1 to the separate repo.
>
> I think it also makes sense—especially with independent release
> schedules—to keep the client documentation source in the client repo and
> build it as its own User Guide, which we can host in its own section on
> geode.apache.org/docs/.
>
> On Mon, Jan 16, 2017 at 12:14 PM Udo Kohlmeyer 
> wrote:
>
> +1 to separate client repos. Or at least some ability to independently
> version client code for releases.
>
> --Udo
>
>
> On 1/16/17 11:56, Jacob Barrett wrote:
> > +1 for separate repo for sub-projects that would or could likely release
> > independently of the core project. I see this applying to most clients,
> > .net, c++, python, etc. It also cleanly separates out the build process
> > which is quite different between these projects. The native clients in
> > particular are dependent a on bunch of toolchains that aren't part of the
> > standard core developer's toolbox. Even if released together under the
> > umbrella of the Geode product it may still make sense to let them evolve
> > independently in their own repos to isolate the concerns between the
> > sources.
> >
> >
> >
> > On Mon, Jan 16, 2017 at 11:52 AM Anthony Baker 
> wrote:
> >
> >> I’m cautiously in favor of this idea.  Allowing independent parts
> (geode,
> >> geode-examples, geode-native) to progress and release at their own pace
> >> seems like a good thing.
> >>
> >>  From a release perspective, I think each repo would have separate vote
> >> threads and a section on our release page:
> >> http://geode.apache.org/releases/
> >>
> >> Anthony
> >>
> >>> On Jan 16, 2017, at 11:24 AM, Jacob Barrett 
> wrote:
> >>>
> >>> I would love a separate repo. Someone told me that wasn't an option. If
> >>> it's an option the let's make it so.
> >>>
> >>> On Mon, Jan 16, 2017 at 11:20 AM Mark Bretl  wrote:
> >>>
>  Jake,
> 
>  Having all the clients in the repository is nice, however, has there
> >> been
>  thought to have them in their own repository? Now that we are a TLP,
> we
> >> do
>  have that capability, as seen with the 'geode-examples' repository.
> 
>  --Mark
> 
>  On Mon, Jan 16, 2017 at 10:38 AM, Udo Kohlmeyer <
> ukohlme...@pivotal.io>
>  wrote:
> >>
>


[jira] [Resolved] (GEODE-2305) Remove native client packaging dependency on Pivotal EULA

2017-01-16 Thread Jacob S. Barrett (JIRA)

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

Jacob S. Barrett resolved GEODE-2305.
-
   Resolution: Fixed
 Assignee: Jacob S. Barrett
Fix Version/s: (was: 1.1.0)

> Remove native client packaging dependency on Pivotal EULA
> -
>
> Key: GEODE-2305
> URL: https://issues.apache.org/jira/browse/GEODE-2305
> Project: Geode
>  Issue Type: Task
>  Components: native client
>Reporter: Jacob S. Barrett
>Assignee: Jacob S. Barrett
>




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


Re: Native Client Directory Structure

2017-01-16 Thread Michael Stolz
+1 for a separate repo per client.

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

On Mon, Jan 16, 2017 at 4:02 PM, Swapnil Bawaskar 
wrote:

> +1 for a separate repo for each client.
>
> On Mon, Jan 16, 2017 at 12:25 PM, Joey McAllister 
> wrote:
>
> > +1 to the separate repo.
> >
> > I think it also makes sense—especially with independent release
> > schedules—to keep the client documentation source in the client repo and
> > build it as its own User Guide, which we can host in its own section on
> > geode.apache.org/docs/.
> >
> > On Mon, Jan 16, 2017 at 12:14 PM Udo Kohlmeyer 
> > wrote:
> >
> > +1 to separate client repos. Or at least some ability to independently
> > version client code for releases.
> >
> > --Udo
> >
> >
> > On 1/16/17 11:56, Jacob Barrett wrote:
> > > +1 for separate repo for sub-projects that would or could likely
> release
> > > independently of the core project. I see this applying to most clients,
> > > .net, c++, python, etc. It also cleanly separates out the build process
> > > which is quite different between these projects. The native clients in
> > > particular are dependent a on bunch of toolchains that aren't part of
> the
> > > standard core developer's toolbox. Even if released together under the
> > > umbrella of the Geode product it may still make sense to let them
> evolve
> > > independently in their own repos to isolate the concerns between the
> > > sources.
> > >
> > >
> > >
> > > On Mon, Jan 16, 2017 at 11:52 AM Anthony Baker 
> > wrote:
> > >
> > >> I’m cautiously in favor of this idea.  Allowing independent parts
> > (geode,
> > >> geode-examples, geode-native) to progress and release at their own
> pace
> > >> seems like a good thing.
> > >>
> > >>  From a release perspective, I think each repo would have separate
> vote
> > >> threads and a section on our release page:
> > >> http://geode.apache.org/releases/
> > >>
> > >> Anthony
> > >>
> > >>> On Jan 16, 2017, at 11:24 AM, Jacob Barrett 
> > wrote:
> > >>>
> > >>> I would love a separate repo. Someone told me that wasn't an option.
> If
> > >>> it's an option the let's make it so.
> > >>>
> > >>> On Mon, Jan 16, 2017 at 11:20 AM Mark Bretl 
> wrote:
> > >>>
> >  Jake,
> > 
> >  Having all the clients in the repository is nice, however, has there
> > >> been
> >  thought to have them in their own repository? Now that we are a TLP,
> > we
> > >> do
> >  have that capability, as seen with the 'geode-examples' repository.
> > 
> >  --Mark
> > 
> >  On Mon, Jan 16, 2017 at 10:38 AM, Udo Kohlmeyer <
> > ukohlme...@pivotal.io>
> >  wrote:
> > >>
> >
>


[jira] [Assigned] (GEODE-2306) Update native client BUILDING.md to reflect changes for Geode

2017-01-16 Thread Michael Dodge (JIRA)

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

Michael Dodge reassigned GEODE-2306:


Assignee: Michael Dodge

> Update native client BUILDING.md to reflect changes for Geode
> -
>
> Key: GEODE-2306
> URL: https://issues.apache.org/jira/browse/GEODE-2306
> Project: Geode
>  Issue Type: Task
>  Components: native client
>Reporter: Jacob S. Barrett
>Assignee: Michael Dodge
> Fix For: 1.1.0
>
>




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


[GitHub] geode pull request #338: GEODE-2272: Fix Pulse data browser export

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

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


---
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 #338: GEODE-2272: Fix Pulse data browser export

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

https://github.com/apache/geode/pull/338
  
Closing for now due precheckin failures


---
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-2297) AlertAppender.append should avoid synchronizing on InternalDistributedSystem

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

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

ASF subversion and git services commented on GEODE-2297:


Commit deb52c06bf7cb00617301859ce9f0b8f1e44573d in geode's branch 
refs/heads/feature/GEODE-2297 from [~apa...@the9muses.net]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=deb52c0 ]

GEODE-2297: passively discover DistributedSystem instance


> AlertAppender.append should avoid synchronizing on InternalDistributedSystem
> 
>
> Key: GEODE-2297
> URL: https://issues.apache.org/jira/browse/GEODE-2297
> Project: Geode
>  Issue Type: Bug
>  Components: management
>Reporter: Kirk Lund
>
> AlertAppender.append should avoid synchronizing on InternalDistributedSystem 
> for two reasons:
> 1) risks deadlock
> 2) impacts performance
> {noformat}
> "Pooled High Priority Message Processor 3" daemon prio=10 
> tid=0x7f1cd4009000 nid=0x1e31 waiting for monitor entry 
> [0x7f1d5d965000]
>java.lang.Thread.State: BLOCKED (on object monitor)
> at 
> com.gemstone.gemfire.distributed.internal.InternalDistributedSystem.getConnectedInstance(InternalDistributedSystem.java:316)
> - waiting to lock <0x0005cf476e10> (a java.lang.Object)
> at 
> com.gemstone.gemfire.internal.logging.log4j.AlertAppender.append(AlertAppender.java:101)
> at 
> org.apache.logging.log4j.core.config.AppenderControl.callAppender(AppenderControl.java:99)
> at 
> org.apache.logging.log4j.core.config.LoggerConfig.callAppenders(LoggerConfig.java:430)
> at 
> org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:409)
> at 
> org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:412)
> at 
> org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:412)
> at 
> org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:367)
> at org.apache.logging.log4j.core.Logger.logMessage(Logger.java:112)
> at 
> org.apache.logging.log4j.spi.ExtendedLoggerWrapper.logMessage(ExtendedLoggerWrapper.java:127)
> at 
> org.apache.logging.log4j.spi.AbstractLogger.logIfEnabled(AbstractLogger.java:685)
> at 
> org.apache.logging.log4j.spi.AbstractLogger.warn(AbstractLogger.java:899)
> at 
> com.gemstone.gemfire.internal.tcp.Connection.createSender(Connection.java:1078)
> at 
> com.gemstone.gemfire.internal.tcp.ConnectionTable.handleNewPendingConnection(ConnectionTable.java:358)
> at 
> com.gemstone.gemfire.internal.tcp.ConnectionTable.getUnorderedOrConserveSockets(ConnectionTable.java:474)
> at 
> com.gemstone.gemfire.internal.tcp.ConnectionTable.get(ConnectionTable.java:664)
> at 
> com.gemstone.gemfire.internal.tcp.TCPConduit.getConnection(TCPConduit.java:977)
> at 
> com.gemstone.gemfire.distributed.internal.direct.DirectChannel.getConnections(DirectChannel.java:638)
> at 
> com.gemstone.gemfire.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:396)
> at 
> com.gemstone.gemfire.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:310)
> at 
> com.gemstone.gemfire.distributed.internal.direct.DirectChannel.send(DirectChannel.java:696)
> at 
> com.gemstone.gemfire.distributed.internal.membership.jgroup.JGroupMembershipManager.directChannelSend(JGroupMembershipManager.java:2930)
> at 
> com.gemstone.gemfire.distributed.internal.membership.jgroup.JGroupMembershipManager.send(JGroupMembershipManager.java:3164)
> at 
> com.gemstone.gemfire.distributed.internal.DistributionChannel.send(DistributionChannel.java:79)
> at 
> com.gemstone.gemfire.distributed.internal.DistributionManager.sendOutgoing(DistributionManager.java:3913)
> at 
> com.gemstone.gemfire.distributed.internal.DistributionManager.sendMessage(DistributionManager.java:3954)
> at 
> com.gemstone.gemfire.distributed.internal.DistributionManager.putOutgoing(DistributionManager.java:1957)
> at 
> com.gemstone.gemfire.distributed.internal.StartupMessage.process(StartupMessage.java:321)
> at 
> com.gemstone.gemfire.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:386)
> at 
> com.gemstone.gemfire.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:457)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> {noformat}



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


Review Request 55591: GEODE-2297: passively discover DistributedSystem instance in AlertAppender

2017-01-16 Thread Kirk Lund

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

Review request for geode, Bruce Schuchardt, Darrel Schneider, Jinmei Liao, 
Jared Stewart, and Kevin Duling.


Bugs: GEODE-2297
https://issues.apache.org/jira/browse/GEODE-2297


Repository: geode


Description
---

GEODE-2297: passively discover DistributedSystem instance in AlertAppender to 
use in append

AlertAppender was actively hitting a synchronization and fetching 
InternalDistributedSystem singleton in every append(!) call. This can produce a 
deadlock if an alert is generated during startup. 

This change removes the active fetch from the append code path and uses 
InternalDistributedSystem.ConnectListener and 
InternalDistributedSystem.DisconnectListener to receive notifications of 
connect and disconnect. These notifications set an AtomicReference that is now 
checked within append. (Registering a ConnectListener is static and remains 
registered for the life of the JVM. For every onConnect, the AlertAppender 
registers a non-static DisconnectListener for each InternalDistributedSystem 
instance.)

I also fixed some minor IDE warnings, changed a logger statement from info to 
debug and added a TODO to the class' logger instance. I want to follow up later 
to *probably* change from using Logger to StatusLogger. Note: we run with 
StatusLogger level of FATAL by default. Appender impl's really should use 
StatusLogger instead of Logger (to avoid risk of infinite looping). As it's 
currently written (with Logger), you'd have to set the AlertLevel to DEBUG to 
hit this problem. I believe someone would only do this by error or for 
experimentation.


Diffs
-

  
geode-core/src/main/java/org/apache/geode/internal/logging/log4j/AlertAppender.java
 a6c54aba352ba4dd3ece94c94f770292db6e9284 

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


Testing
---

precheckin in progress


Thanks,

Kirk Lund



[jira] [Updated] (GEODE-2306) Update native client BUILDING.md to reflect changes for Geode

2017-01-16 Thread Anthony Baker (JIRA)

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

Anthony Baker updated GEODE-2306:
-
Fix Version/s: (was: 1.1.0)

> Update native client BUILDING.md to reflect changes for Geode
> -
>
> Key: GEODE-2306
> URL: https://issues.apache.org/jira/browse/GEODE-2306
> Project: Geode
>  Issue Type: Task
>  Components: native client
>Reporter: Jacob S. Barrett
>Assignee: Michael Dodge
>




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


[jira] [Assigned] (GEODE-2273) Display the server name while listing the Lucene index stats

2017-01-16 Thread nabarun (JIRA)

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

nabarun reassigned GEODE-2273:
--

Assignee: nabarun

> Display the server name while listing the Lucene index stats
> 
>
> Key: GEODE-2273
> URL: https://issues.apache.org/jira/browse/GEODE-2273
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: nabarun
>Assignee: nabarun
>
> Display the server's name hosting the Lucene indexes while listing the Lucene 
> index stats in gfsh.
> Currently we can't distinguish between the listed pairs.
> {noformat}
> 
> gfsh>list lucene indexes --with-stats
>Index Name | Region Path |  Indexed Fields  | Field 
> Analyzer |   Status| Query Executions | Updates | Commits | Documents
> - | --- |  | 
> -- | --- |  | --- | --- | 
> -
> customerRegionAll | /customer   | [lastUpdateDateTime, displayNa.. | {}   
>   | Initialized | 0| 0   | 0   | 0
> customerRegionAll | /customer   | [lastUpdateDateTime, displayNa.. | {}   
>   | Initialized | 0| 0   | 0   | 0
> {noformat}



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


[jira] [Commented] (GEODE-2272) Pulse Data Browser export hangs

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

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

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

Github user jaredjstewart commented on the issue:

https://github.com/apache/geode/pull/338
  
Closing for now due precheckin failures


> Pulse Data Browser export hangs
> ---
>
> Key: GEODE-2272
> URL: https://issues.apache.org/jira/browse/GEODE-2272
> Project: Geode
>  Issue Type: Bug
>  Components: pulse
>Affects Versions: 1.0.0-incubating
>Reporter: Jared Stewart
>Assignee: Jared Stewart
>
> The Export feature of Pulse Data Browser is prone to hang with large amounts 
> of data as it requires loading all the query results into the browser before 
> they can be exported.  Instead, we should allow a user to Export query 
> results directly to a file without first loading the results into their 
> browser.



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


Re: Review Request 55591: GEODE-2297: passively discover DistributedSystem instance in AlertAppender

2017-01-16 Thread Hitesh Khamesra

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




geode-core/src/main/java/org/apache/geode/internal/logging/log4j/AlertAppender.java
 (line 68)


addConnectListener also takes "existingSystemsLock", so this may run into 
same issue?


- Hitesh Khamesra


On Jan. 16, 2017, 10 p.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/55591/
> ---
> 
> (Updated Jan. 16, 2017, 10 p.m.)
> 
> 
> Review request for geode, Bruce Schuchardt, Darrel Schneider, Jinmei Liao, 
> Jared Stewart, and Kevin Duling.
> 
> 
> Bugs: GEODE-2297
> https://issues.apache.org/jira/browse/GEODE-2297
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2297: passively discover DistributedSystem instance in AlertAppender to 
> use in append
> 
> AlertAppender was actively hitting a synchronization and fetching 
> InternalDistributedSystem singleton in every append(!) call. This can produce 
> a deadlock if an alert is generated during startup. 
> 
> This change removes the active fetch from the append code path and uses 
> InternalDistributedSystem.ConnectListener and 
> InternalDistributedSystem.DisconnectListener to receive notifications of 
> connect and disconnect. These notifications set an AtomicReference that is 
> now checked within append. (Registering a ConnectListener is static and 
> remains registered for the life of the JVM. For every onConnect, the 
> AlertAppender registers a non-static DisconnectListener for each 
> InternalDistributedSystem instance.)
> 
> I also fixed some minor IDE warnings, changed a logger statement from info to 
> debug and added a TODO to the class' logger instance. I want to follow up 
> later to *probably* change from using Logger to StatusLogger. Note: we run 
> with StatusLogger level of FATAL by default. Appender impl's really should 
> use StatusLogger instead of Logger (to avoid risk of infinite looping). As 
> it's currently written (with Logger), you'd have to set the AlertLevel to 
> DEBUG to hit this problem. I believe someone would only do this by error or 
> for experimentation.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/internal/logging/log4j/AlertAppender.java
>  a6c54aba352ba4dd3ece94c94f770292db6e9284 
> 
> Diff: https://reviews.apache.org/r/55591/diff/
> 
> 
> Testing
> ---
> 
> precheckin in progress
> 
> 
> Thanks,
> 
> Kirk Lund
> 
>



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

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

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

ASF subversion and git services commented on GEODE-2031:


Commit 42130ad097f8a3758a428f153d3d49e80ab9156b in geode's branch 
refs/heads/develop from [~jmcallis...@pivotal.io]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=42130ad ]

GEODE-2031 Add titles to index pages


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


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

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

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

ASF subversion and git services commented on GEODE-2031:


Commit 50ea2e914c6e5ba8e52058c86e4736bc6b0807d7 in geode's branch 
refs/heads/develop from [~jmcallis...@pivotal.io]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=50ea2e9 ]

GEODE-2031 fix typo


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


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

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

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

ASF subversion and git services commented on GEODE-2031:


Commit 3b73fcb2240f021c11b0420e342f7b9fd2749bc9 in geode's branch 
refs/heads/develop from [~jmcallis...@pivotal.io]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=3b73fcb ]

GEODE-2031 More docs-related site changes


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


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

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

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

ASF subversion and git services commented on GEODE-2031:


Commit 3b3ea9cf765e4ae46646aad1a01c2cf856a2e5f8 in geode's branch 
refs/heads/develop from [~jmcallis...@pivotal.io]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=3b3ea9c ]

GEODE-2031 Add licenses for rat check


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


[jira] [Resolved] (GEODE-2307) Add FindGeode CMake module to native client build for finding Geode installation

2017-01-16 Thread Jacob S. Barrett (JIRA)

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

Jacob S. Barrett resolved GEODE-2307.
-
Resolution: Fixed

> Add FindGeode CMake module to native client build for finding Geode 
> installation
> 
>
> Key: GEODE-2307
> URL: https://issues.apache.org/jira/browse/GEODE-2307
> Project: Geode
>  Issue Type: Task
>  Components: native client
>Reporter: Jacob S. Barrett
>
> Native client build has dependencies on the Geode product installation. 
> FindGeode would locate the product in know locations or take hint in the form 
> of {{-DGEODE_ROOT}} argument to {{cmake}}.



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


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

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

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

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

Github user joeymcallister closed the pull request at:

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


> 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-16 Thread joeymcallister
GitHub user joeymcallister reopened 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

commit e1cc02b9751728caf320d3ea4504ea271171d07e
Author: joeymcallister 
Date:   2017-01-11T20:39:25Z

GEODE-2031 fix typo

commit bd32282ef2d4045fbb1d2f3841de84bc259e8483
Author: joeymcallister 
Date:   2017-01-11T21:29:17Z

GEODE-2031 Add licenses for rat check

commit 606e2b45d41c4519a0f1bec5edbb8627e644ee48
Author: joeymcallister 
Date:   2017-01-12T00:27:42Z

GEODE-2031 (Re?)Add missing book infra to site; update rat




---
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-16 Thread ASF GitHub Bot (JIRA)

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

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

Github user joeymcallister closed the pull request at:

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


> 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-16 Thread joeymcallister
Github user joeymcallister closed the pull request at:

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


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


New Repo for Native Client

2017-01-16 Thread Jacob Barrett
Mark,

Looks like we have lots of votes for your separate repo idea. What do we
need to do to get that going?

On that note too, do you know who we need to ping to get a build going? I
would suggest we target Linux first since it is the easiest. The tools
necessary can be found in the src/BUILDING.md file.

Thanks,
Jake


[GitHub] geode pull request #340: Restore constructor used for Mocks

2017-01-16 Thread asfgit
Github user asfgit closed the pull request at:

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


---
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-16 Thread ASF GitHub Bot (JIRA)

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

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

GitHub user joeymcallister reopened 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

commit e1cc02b9751728caf320d3ea4504ea271171d07e
Author: joeymcallister 
Date:   2017-01-11T20:39:25Z

GEODE-2031 fix typo

commit bd32282ef2d4045fbb1d2f3841de84bc259e8483
Author: joeymcallister 
Date:   2017-01-11T21:29:17Z

GEODE-2031 Add licenses for rat check

commit 606e2b45d41c4519a0f1bec5edbb8627e644ee48
Author: joeymcallister 
Date:   2017-01-12T00:27:42Z

GEODE-2031 (Re?)Add missing book infra to site; update rat




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


  1   2   >