date:20170328

[jira] [Commented] (GEODE-2513) Geode Native docs: rebrand to match open-source software

2017-03-28 Thread ASF GitHub Bot (JIRA)


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

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

Github user karensmolermiller closed the pull request at:

https://github.com/apache/geode-native/pull/75


> Geode Native docs: rebrand to match open-source software
> 
>
> Key: GEODE-2513
> URL: https://issues.apache.org/jira/browse/GEODE-2513
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Dave Barnes
>
> The newly-contributed Geode Native doc sources contain some GemFire artifacts 
> that have been purged from the open-source code. Docs should be updated to 
> match. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2513) Geode Native docs: rebrand to match open-source software

2017-03-28 Thread ASF GitHub Bot (JIRA)


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

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

Github user karensmolermiller commented on the issue:

https://github.com/apache/geode-native/pull/75
  
Merged in to develop.


> Geode Native docs: rebrand to match open-source software
> 
>
> Key: GEODE-2513
> URL: https://issues.apache.org/jira/browse/GEODE-2513
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Dave Barnes
>
> The newly-contributed Geode Native doc sources contain some GemFire artifacts 
> that have been purged from the open-source code. Docs should be updated to 
> match. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode-native pull request #75: GEODE-2513 Unbrand .NET API docs section

2017-03-28 Thread karensmolermiller

Github user karensmolermiller closed the pull request at:

https://github.com/apache/geode-native/pull/75


---
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-native issue #75: GEODE-2513 Unbrand .NET API docs section

2017-03-28 Thread karensmolermiller

Github user karensmolermiller commented on the issue:

https://github.com/apache/geode-native/pull/75
  
Merged in to develop.


---
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-2513) Geode Native docs: rebrand to match open-source software

2017-03-28 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on GEODE-2513:


Commit 226662f075e7ca9a39354ce67eba42bcf0dc0dba in geode-native's branch 
refs/heads/develop from [~karensmolermiller]
[ https://git-wip-us.apache.org/repos/asf?p=geode-native.git;h=226662f ]

GEODE-2513 Unbrand .NET API docs section

- Remove references to GemFire
- Namespace updates
- Correct typos and capitalization
- Use .NET scoping operator (not C++)
- Avoid duplication in the manual of QuickStart code


> Geode Native docs: rebrand to match open-source software
> 
>
> Key: GEODE-2513
> URL: https://issues.apache.org/jira/browse/GEODE-2513
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Dave Barnes
>
> The newly-contributed Geode Native doc sources contain some GemFire artifacts 
> that have been purged from the open-source code. Docs should be updated to 
> match. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2513) Geode Native docs: rebrand to match open-source software

2017-03-28 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on GEODE-2513:


Commit 00682c3302d894dcd2dcb527014a5d86dbcd9c75 in geode-native's branch 
refs/heads/develop from [~karensmolermiller]
[ https://git-wip-us.apache.org/repos/asf?p=geode-native.git;h=00682c3 ]

GEODE-2513 Revise docs section on .NET API per reviews

- IGFSerializable becomes IGeodeSerializable
- Apache.Geode.Client.dll should be Apache.Geode.dll


> Geode Native docs: rebrand to match open-source software
> 
>
> Key: GEODE-2513
> URL: https://issues.apache.org/jira/browse/GEODE-2513
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Dave Barnes
>
> The newly-contributed Geode Native doc sources contain some GemFire artifacts 
> that have been purged from the open-source code. Docs should be updated to 
> match. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2727) optimize new 1.8 ConcurrentMap default methods on Region

2017-03-28 Thread Darrel Schneider (JIRA)

Darrel Schneider created GEODE-2727:
---

 Summary: optimize new 1.8 ConcurrentMap default methods on Region
 Key: GEODE-2727
 URL: https://issues.apache.org/jira/browse/GEODE-2727
 Project: Geode
  Issue Type: Improvement
  Components: regions
Reporter: Darrel Schneider


In JDK 1.8 ConcurrentMap added the following default methods to the interface:
  getOrDefault
  computeIfAbsent
  computeIfPresent
  compute
  merge
  foreach
  replaceAll

All of the default implementations of these methods have issues with get 
returning null when the key actually exists. So they do not support invalid 
region entries.
The other problem with all of them (except getOrDefault) is that they will make 
multiple round trips when done from a proxy. In a distributed environment we 
should implement these to send the lambda to the primary so that the entire 
operation can be done with one message and while the RegionEntry is locked.
This would require that the lambda parameter by serializable which would be 
consistent with what we do for other parameters to Region methods (for example 
"put").
>From a performance point of view "foreach" and "replaceAll" are the worst 
>since they bring back to whoever is executing the method all the keys and 
>values from the entire cluster.
It is also worth considering how the operations behave in a geode transaction.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: [VOTE] Apache Geode release - v1.1.1 RC2

2017-03-28 Thread Kirk Lund

-1

We still have failing tests in Geode-release #50 (this is the most recent
CI for Geode-release). I assume "Geode-release #50" is testing v1.1.1 RC2.

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.ClusterConfigImportDUnitTest.before(ClusterConfigImportDUnitTest.java:63)

org.apache.geode.management.internal.configuration.ClusterConfigImportDUnitTest
> testImportWithRunningServerWithData 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.ClusterConfigImportDUnitTest.before(ClusterConfigImportDUnitTest.java:63)

org.apache.geode.management.internal.configuration.ClusterConfigImportDUnitTest
> testImportWithMultipleLocators 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.ClusterConfigImportDUnitTest.before(ClusterConfigImportDUnitTest.java:63)

org.apache.geode.management.internal.configuration.ClusterConfigDistributionDUnitTest
> 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.ClusterConfigDistributionDUnitTest.before(ClusterConfigDistributionDUnitTest.java:66)

org.apache.geode.management.internal.configuration.ClusterConfigDistributionDUnitTest
> testIndexAndAsyncEventQueueCommands 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.ClusterConfigDistributionDUnitTest.before(ClusterConfigDistributionDUnitTest.java:66)

6812 tests completed, 13 failed, 601 skipped
:geode-core:distributedTest FAILED

On Tue, Mar 28, 2017 at 3:20 PM, Swapnil Bawaskar 
wrote:

> +1
>
> - Built from source
> - start a few members/created regions/inserted data from gfsh
> - verified that GEODE-2670 is fixed.
>
> On Mon, Mar 27, 2017 at 10:18 PM Anthony Baker  wrote:
>
> > This is the second release candidate of the release for Apache Geode,
> > version 1.1.1.
> >
> > It fixes the following issues:
> >
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?proje
> ctId=12318420=12340271
> >
> > *** Please download, test and vote by Thursday, March 30, 2200 hrs US
> > Pacific. ***
> >
> > Note that we are voting upon the source (tag):
> >   rel/v1.1.1.RC2
> >
> > https://git-wip-us.apache.org/repos/asf?p=geode.git;a=tag;h=
> refs/tags/rel/v1.1.1.RC2
> >
> > Commit ID: e2081044ea0afca1cb38d62c7f34e7363b45ad97
> >
> > Source and binary files:
> >   https://dist.apache.org/repos/dist/dev/geode/1.1.1.RC2/
> >
> > Maven staging repo:
> >   https://repository.apache.org/content/repositories/orgapachegeode-1018
> >
> > Geode's KEYS file containing PGP keys we use to sign the release:
> >   https://github.com/apache/geode/blob/release/1.1.1/KEYS
> >
> > pub  4096R/C72CFB64 2015-10-01
> > Fingerprint=948E 8234 14BE 693A 7F74  ABBE 19DB CAEE C72C FB64
> >
> >
> > Thanks,
> > Anthony
> >
>

Re: Geode 1.2.0 should not ship with failing tests

2017-03-28 Thread Kirk Lund

Oops, I mean "v1.1.1 RC2"


On Tue, Mar 28, 2017 at 5:16 PM, Kirk Lund  wrote:

> Is anyone working on stabilizing ClusterConfigImportDUnitTest?
>
> This is a recently created test. One criteria for shipping Geode 1.2.0
> should be no failures in new tests including this one.
>
> [...truncated 105.03 KB...]
> 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.
> ClusterConfigImportDUnitTest.before(ClusterConfigImportDUnitTest.java:63)
>
> org.apache.geode.management.internal.configuration.ClusterConfigImportDUnitTest
> > testImportWithRunningServerWithData 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.
> ClusterConfigImportDUnitTest.before(ClusterConfigImportDUnitTest.java:63)
>
> org.apache.geode.management.internal.configuration.ClusterConfigImportDUnitTest
> > testImportWithMultipleLocators 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.
> ClusterConfigImportDUnitTest.before(ClusterConfigImportDUnitTest.java:63)
>
> org.apache.geode.management.internal.configuration.
> ClusterConfigDistributionDUnitTest > 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.
> ClusterConfigDistributionDUnitTest.before(ClusterConfigDistributionDUnit
> Test.java:66)
>
> org.apache.geode.management.internal.configuration.
> ClusterConfigDistributionDUnitTest > testIndexAndAsyncEventQueueCommands
> 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.
> ClusterConfigDistributionDUnitTest.before(ClusterConfigDistributionDUnit
> Test.java:66)
>
> 6812 tests completed, 13 failed, 601 skipped
> :geode-core:distributedTest FAILED
>

Geode 1.2.0 should not ship with failing tests

2017-03-28 Thread Kirk Lund

Is anyone working on stabilizing ClusterConfigImportDUnitTest?

This is a recently created test. One criteria for shipping Geode 1.2.0
should be no failures in new tests including this one.

[...truncated 105.03 KB...]
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.ClusterConfigImportDUnitTest.before(ClusterConfigImportDUnitTest.java:63)

org.apache.geode.management.internal.configuration.ClusterConfigImportDUnitTest
> testImportWithRunningServerWithData 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.ClusterConfigImportDUnitTest.before(ClusterConfigImportDUnitTest.java:63)

org.apache.geode.management.internal.configuration.ClusterConfigImportDUnitTest
> testImportWithMultipleLocators 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.ClusterConfigImportDUnitTest.before(ClusterConfigImportDUnitTest.java:63)

org.apache.geode.management.internal.configuration.ClusterConfigDistributionDUnitTest
> 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.ClusterConfigDistributionDUnitTest.before(ClusterConfigDistributionDUnitTest.java:66)

org.apache.geode.management.internal.configuration.ClusterConfigDistributionDUnitTest
> testIndexAndAsyncEventQueueCommands 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.ClusterConfigDistributionDUnitTest.before(ClusterConfigDistributionDUnitTest.java:66)

6812 tests completed, 13 failed, 601 skipped
:geode-core:distributedTest FAILED

[GitHub] geode-native issue #75: GEODE-2513 Unbrand .NET API docs section

2017-03-28 Thread karensmolermiller

Github user karensmolermiller commented on the issue:

https://github.com/apache/geode-native/pull/75
  
All corrections have been made.  I will merge this PR into develop as soon 
as the CI build finishes in the green.  Thanks for the helpful reviews.


---
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-2513) Geode Native docs: rebrand to match open-source software

2017-03-28 Thread ASF GitHub Bot (JIRA)


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

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

Github user karensmolermiller commented on the issue:

https://github.com/apache/geode-native/pull/75
  
All corrections have been made.  I will merge this PR into develop as soon 
as the CI build finishes in the green.  Thanks for the helpful reviews.


> Geode Native docs: rebrand to match open-source software
> 
>
> Key: GEODE-2513
> URL: https://issues.apache.org/jira/browse/GEODE-2513
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Dave Barnes
>
> The newly-contributed Geode Native doc sources contain some GemFire artifacts 
> that have been purged from the open-source code. Docs should be updated to 
> match. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode-native pull request #78: GEODE-2513 Unbranding docs: security

2017-03-28 Thread davebarnes97

GitHub user davebarnes97 opened a pull request:

https://github.com/apache/geode-native/pull/78

GEODE-2513 Unbranding docs: security

The scope of this pull request is to eliminate occurrences of `gemfire` and 
`native` from the terminology, along with proprietary-ish names such as `GFCPP`.
The actual procedures in this section may be out-of-date, but updating them 
is a separate task.

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

$ git pull https://github.com/davebarnes97/geode-native 
feature/GEODE-2513-security

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

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


commit 49609436786b48144b2ce3c39b22cb29c92b82cd
Author: Dave Barnes 
Date:   2017-03-28T23:16:11Z

GEODE-2513 Unbranding docs: security




---
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-2513) Geode Native docs: rebrand to match open-source software

2017-03-28 Thread ASF GitHub Bot (JIRA)


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

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

GitHub user davebarnes97 opened a pull request:

https://github.com/apache/geode-native/pull/78

GEODE-2513 Unbranding docs: security

The scope of this pull request is to eliminate occurrences of `gemfire` and 
`native` from the terminology, along with proprietary-ish names such as `GFCPP`.
The actual procedures in this section may be out-of-date, but updating them 
is a separate task.

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

$ git pull https://github.com/davebarnes97/geode-native 
feature/GEODE-2513-security

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

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


commit 49609436786b48144b2ce3c39b22cb29c92b82cd
Author: Dave Barnes 
Date:   2017-03-28T23:16:11Z

GEODE-2513 Unbranding docs: security




> Geode Native docs: rebrand to match open-source software
> 
>
> Key: GEODE-2513
> URL: https://issues.apache.org/jira/browse/GEODE-2513
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Dave Barnes
>
> The newly-contributed Geode Native doc sources contain some GemFire artifacts 
> that have been purged from the open-source code. Docs should be updated to 
> match. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

2017-03-28 Thread Spring CI


---
Spring Data GemFire > Nightly-ApacheGeode > #507 was successful.
---
Scheduled
1682 tests in total.

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





--
This message is automatically generated by Atlassian Bamboo

[jira] [Commented] (GEODE-2513) Geode Native docs: rebrand to match open-source software

2017-03-28 Thread ASF GitHub Bot (JIRA)


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

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

GitHub user karensmolermiller opened a pull request:

https://github.com/apache/geode-native/pull/77

GEODE-2513 Unbrand docs section Configuring the Native Client Cache

- namespace updates
- fix typos

@davebarnes97 @joeymcallister @PivotalSarge @echobravopapa @dgkimura 
@mmartell @mhansonp
Please review, paying particular attention to the namespace changes.

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

$ git pull https://github.com/karensmolermiller/geode-native 
feature/GEODE-2513-15

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

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


commit 8f4925b775284ff48d0cc9ee20aa328c564aad60
Author: Karen Miller 
Date:   2017-03-28T22:25:23Z

GEODE-2513 Unbrand docs section Configuring the Native Client Cache

- namespace updates
- fix typos




> Geode Native docs: rebrand to match open-source software
> 
>
> Key: GEODE-2513
> URL: https://issues.apache.org/jira/browse/GEODE-2513
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Dave Barnes
>
> The newly-contributed Geode Native doc sources contain some GemFire artifacts 
> that have been purged from the open-source code. Docs should be updated to 
> match. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode-native pull request #77: GEODE-2513 Unbrand docs section Configuring t...

2017-03-28 Thread karensmolermiller

GitHub user karensmolermiller opened a pull request:

https://github.com/apache/geode-native/pull/77

GEODE-2513 Unbrand docs section Configuring the Native Client Cache

- namespace updates
- fix typos

@davebarnes97 @joeymcallister @PivotalSarge @echobravopapa @dgkimura 
@mmartell @mhansonp
Please review, paying particular attention to the namespace changes.

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

$ git pull https://github.com/karensmolermiller/geode-native 
feature/GEODE-2513-15

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

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


commit 8f4925b775284ff48d0cc9ee20aa328c564aad60
Author: Karen Miller 
Date:   2017-03-28T22:25:23Z

GEODE-2513 Unbrand docs section Configuring the Native Client Cache

- namespace updates
- fix typos




---
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: Review Request 58010: GEODE-2716: export logs default behavior changed from filtering at log level INFO to ALL.

2017-03-28 Thread Patrick Rhomberg


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

(Updated March 28, 2017, 10:34 p.m.)


Review request for geode, Jinmei Liao, Jared Stewart, Kevin Duling, Ken Howe, 
Kirk Lund, and Swapnil Bawaskar.


Repository: geode


Description
---

Added DUnit test that fails under previous behavior.


Diffs
-

  geode-core/src/main/java/org/apache/geode/internal/logging/LogService.java 
1f8a564a8111b036f5e5cce6393931c714985c9c 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/ExportLogsFunction.java
 cbdf1c4bc28554a8fbec3740c566ee07c69b4ac9 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsDUnitTest.java
 95edd426da8b8f39bb1486661d8c307d43f170d6 


Diff: https://reviews.apache.org/r/58010/diff/1/


Testing (updated)
---

Added DUnit passes under new behavior.

===

While `LogService.DEFAULT_LOG_LEVEL` is only used by the export logs command, I 
don't know if that is the best place to make this update.  Should that stay 
`INFO` and a new variable `DEFAULT_EXPORT_LOG_LEVEL` be established?


Thanks,

Patrick Rhomberg

Review Request 58010: GEODE-2716: export logs default behavior changed from filtering at log level INFO to ALL.

2017-03-28 Thread Patrick Rhomberg


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

Review request for geode, Jinmei Liao, Jared Stewart, Kevin Duling, Ken Howe, 
Kirk Lund, and Swapnil Bawaskar.


Repository: geode


Description
---

Added DUnit test that fails under previous behavior.


Diffs
-

  geode-core/src/main/java/org/apache/geode/internal/logging/LogService.java 
1f8a564a8111b036f5e5cce6393931c714985c9c 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/ExportLogsFunction.java
 cbdf1c4bc28554a8fbec3740c566ee07c69b4ac9 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsDUnitTest.java
 95edd426da8b8f39bb1486661d8c307d43f170d6 


Diff: https://reviews.apache.org/r/58010/diff/1/


Testing
---

Added DUnit passes under new behavior.


Thanks,

Patrick Rhomberg

Re: [VOTE] Apache Geode release - v1.1.1 RC2

2017-03-28 Thread Swapnil Bawaskar

+1

- Built from source
- start a few members/created regions/inserted data from gfsh
- verified that GEODE-2670 is fixed.

On Mon, Mar 27, 2017 at 10:18 PM Anthony Baker  wrote:

> This is the second release candidate of the release for Apache Geode,
> version 1.1.1.
>
> It fixes the following issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318420=12340271
>
> *** Please download, test and vote by Thursday, March 30, 2200 hrs US
> Pacific. ***
>
> Note that we are voting upon the source (tag):
>   rel/v1.1.1.RC2
>
> https://git-wip-us.apache.org/repos/asf?p=geode.git;a=tag;h=refs/tags/rel/v1.1.1.RC2
>
> Commit ID: e2081044ea0afca1cb38d62c7f34e7363b45ad97
>
> Source and binary files:
>   https://dist.apache.org/repos/dist/dev/geode/1.1.1.RC2/
>
> Maven staging repo:
>   https://repository.apache.org/content/repositories/orgapachegeode-1018
>
> Geode's KEYS file containing PGP keys we use to sign the release:
>   https://github.com/apache/geode/blob/release/1.1.1/KEYS
>
> pub  4096R/C72CFB64 2015-10-01
> Fingerprint=948E 8234 14BE 693A 7F74  ABBE 19DB CAEE C72C FB64
>
>
> Thanks,
> Anthony
>

[jira] [Commented] (GEODE-2231) Create new partitioning example

2017-03-28 Thread ASF GitHub Bot (JIRA)


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

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

Github user jhuynh1 commented on a diff in the pull request:

https://github.com/apache/geode-examples/pull/3#discussion_r108542421
  
--- Diff: 
partitioned/src/test/java/org/apache/geode/examples/partitioned/PartitionedTest.java
 ---
@@ -0,0 +1,165 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more 
contributor license
+ * agreements. See the NOTICE file distributed with this work for 
additional information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache 
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the 
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software 
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF 
ANY KIND, either express
+ * or implied. See the License for the specific language governing 
permissions and limitations under
+ * the License.
+ */
+package org.apache.geode.examples.partitioned;
+
+import static org.hamcrest.core.Is.*;
+import static org.junit.Assert.*;
+import static org.junit.Assume.*;
+
+import java.io.IOException;
+import java.net.ServerSocket;
+import java.util.Map;
+import java.util.concurrent.TimeUnit;
+import java.util.logging.Level;
+import java.util.logging.Logger;
+
+import org.apache.commons.exec.CommandLine;
+import org.apache.commons.exec.DefaultExecuteResultHandler;
+import org.apache.commons.exec.ExecuteException;
+import org.apache.commons.exec.environment.EnvironmentUtils;
+import org.apache.geode.examples.utils.ShellUtil;
+import org.junit.After;
+import org.junit.Before;
+import org.junit.Rule;
+import org.junit.Test;
+import org.junit.rules.TemporaryFolder;
+
+/**
+ * Tests for the shell scripts of the partitioned example
+ */
+public class PartitionedTest {
+
+  // TODO: parameterize
--- End diff --

Is this TODO still relevant?


> Create new partitioning example
> ---
>
> Key: GEODE-2231
> URL: https://issues.apache.org/jira/browse/GEODE-2231
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Karen Smoler Miller
>Assignee: Karen Smoler Miller
>Priority: Minor
>
> Add a new example to the geode-examples that demonstrates partitioning.
> The example will use the same structure as the replicated example, starting 2 
> servers that host a partitioned region (with no redundant copies).  Run the 
> producer to populate the region.  Run the consumer to see the contents of the 
> region. Then, stop one of the servers and run the consumer again to notice 
> that only roughly half (with 2 servers and hopefully a reasonable hash) of 
> the entries are present.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2231) Create new partitioning example

2017-03-28 Thread ASF GitHub Bot (JIRA)


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

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

Github user jhuynh1 commented on a diff in the pull request:

https://github.com/apache/geode-examples/pull/3#discussion_r108541629
  
--- Diff: partitioned/README.md ---
@@ -0,0 +1,156 @@
+
+
+# Geode partitioned region example
+
+This example demonstrates the basic property of partitioning.
+The basic property of partitioning is that data entries are distributed 
+across all servers that host a region.
+The distribution is like database sharding, except that the distribution
+occurs automatically. It is also similar to data striping on disks,
+except that the distribution is not based on hardware.
+
+In this example,
+two servers host a single partitioned region. 
+There is no redundancy, so that the basic property of partitioning
+may be observed.
+The Producer code puts the 10 entries into the region.
+The Consumer gets and prints the entries from the region.
+Because the region is partitioned,
+its entries are distributed among the two servers hosting the region.
+Since there is no redundancy of the data within the region,
+when one of the servers goes away,
+the entries hosted within that server are also gone.
+
+## Demonstration of Partitioning
+1. Set directory ```geode-examples/partitioned``` to be the
+current working directory.
+Each step in this example specifies paths relative to that directory.
+
+1. Build the jar (with the ```EmployeeKey``` and ```EmployeeData``` 
classes):
+
+```
+$   ../gradlew build
+```
+1. Run a script that starts a locator and two servers.
+The built JAR will be placed onto the classpath when the script 
+starts the servers:
+
+```
+$ scripts/startAll.sh
+```
+Each of the servers hosts the partitioned region.
+
+1. Run the producer to put 10 entries into the ```EmployeeRegion```.
+
+```
+$ ../gradlew run -Pmain=Producer
+...
+... 
+INFO: Inserted 10 entries in EmployeeRegion.
+```
+
+1. There are several ways to see the contents of the region.
+Run the consumer to get and print all 10 entries in the `EmployeeRegion`.
+
+```
+$ ../gradlew run -Pmain=Consumer
+...
+INFO: 10 entries in EmployeeRegion on the server(s).
+...
+```
+
+If desired, use a ```gfsh``` query to see contents of the region keys:
+
+```
+$ $GEODE_HOME/bin/gfsh
+...
+gfsh>connect
+gfsh>query --query="select e.key from /EmployeeRegion.entries e"
+...
+```
+
+Note that the quantity of entries may also be observed with `gfsh`:
+ 
+```
+gfsh>describe region --name=EmployeeRegion
+..
+Name: EmployeeRegion
+Data Policy : partition
+Hosting Members : server2
+  server1
+
+Non-Default Attributes Shared By Hosting Members  
+
+ Type  |Name | Value
+-- | --- | -
+Region | size| 10
+   | data-policy | PARTITION
+```
+
+As an alternative, `gfsh` maybe used to identify how many entries
+are in the region on each server by looking at statistics.
+
+```
+gfsh>show metrics --categories=partition --region=/EmployeeRegion 
--member=server1
+```
+
+Within the output, the result for `totalBucketSize` identifies
+the number of entries hosted on the specified server.
+Vary the command to see statistics for both `server1` and `server2`.
+
+1. The region entries are distributed across both servers.
+Kill one of the servers:
+
+```
+$ $GEODE_HOME/bin/gfsh
+...
+gfsh>connect
+gfsh>stop server --name=server1
+gfsh>quit
+```
+
+1. Run the consumer a second time, and notice that approximately half of
+the entries of the ```EmployeeRegion``` are still available on the 
+remaining server.
+Those hosted by the server that was stopped were lost.
--- End diff --

As someone who might not know Geode that well, it may alarm a user that 
their entries were "lost."  Do we really need to show them/explain this step?  
The next step is shutting down the entire cluster anyways?


> Create new partitioning example
> ---
>
> Key: GEODE-2231
> URL: https://issues.apache.org/jira/browse/GEODE-2231
> Project: Geode
>

[jira] [Commented] (GEODE-2231) Create new partitioning example

2017-03-28 Thread ASF GitHub Bot (JIRA)


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

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

Github user jhuynh1 commented on a diff in the pull request:

https://github.com/apache/geode-examples/pull/3#discussion_r108542208
  
--- Diff: 
partitioned/src/main/java/org/apache/geode/examples/partitioned/Producer.java 
---
@@ -0,0 +1,102 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more 
contributor license
+ * agreements. See the NOTICE file distributed with this work for 
additional information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache 
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the 
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software 
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF 
ANY KIND, either express
+ * or implied. See the License for the specific language governing 
permissions and limitations under
+ * the License.
+ */
+package org.apache.geode.examples.partitioned;
+
+import org.apache.geode.cache.client.ClientCache;
+import org.apache.geode.cache.Region;
+import org.apache.geode.cache.client.ClientCacheFactory;
+import org.apache.geode.cache.client.ClientRegionShortcut;
+
+import java.util.logging.Logger;
+
+public class Producer {
+
+  static final Logger logger = Logger.getAnonymousLogger();
+  // protected ClientCache clientCache;
--- End diff --

Should this commented code be removed?


> Create new partitioning example
> ---
>
> Key: GEODE-2231
> URL: https://issues.apache.org/jira/browse/GEODE-2231
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Karen Smoler Miller
>Assignee: Karen Smoler Miller
>Priority: Minor
>
> Add a new example to the geode-examples that demonstrates partitioning.
> The example will use the same structure as the replicated example, starting 2 
> servers that host a partitioned region (with no redundant copies).  Run the 
> producer to populate the region.  Run the consumer to see the contents of the 
> region. Then, stop one of the servers and run the consumer again to notice 
> that only roughly half (with 2 servers and hopefully a reasonable hash) of 
> the entries are present.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode-examples pull request #3: GEODE-2231 A partitioned region example

2017-03-28 Thread jhuynh1

Github user jhuynh1 commented on a diff in the pull request:

https://github.com/apache/geode-examples/pull/3#discussion_r108541629
  
--- Diff: partitioned/README.md ---
@@ -0,0 +1,156 @@
+
+
+# Geode partitioned region example
+
+This example demonstrates the basic property of partitioning.
+The basic property of partitioning is that data entries are distributed 
+across all servers that host a region.
+The distribution is like database sharding, except that the distribution
+occurs automatically. It is also similar to data striping on disks,
+except that the distribution is not based on hardware.
+
+In this example,
+two servers host a single partitioned region. 
+There is no redundancy, so that the basic property of partitioning
+may be observed.
+The Producer code puts the 10 entries into the region.
+The Consumer gets and prints the entries from the region.
+Because the region is partitioned,
+its entries are distributed among the two servers hosting the region.
+Since there is no redundancy of the data within the region,
+when one of the servers goes away,
+the entries hosted within that server are also gone.
+
+## Demonstration of Partitioning
+1. Set directory ```geode-examples/partitioned``` to be the
+current working directory.
+Each step in this example specifies paths relative to that directory.
+
+1. Build the jar (with the ```EmployeeKey``` and ```EmployeeData``` 
classes):
+
+```
+$   ../gradlew build
+```
+1. Run a script that starts a locator and two servers.
+The built JAR will be placed onto the classpath when the script 
+starts the servers:
+
+```
+$ scripts/startAll.sh
+```
+Each of the servers hosts the partitioned region.
+
+1. Run the producer to put 10 entries into the ```EmployeeRegion```.
+
+```
+$ ../gradlew run -Pmain=Producer
+...
+... 
+INFO: Inserted 10 entries in EmployeeRegion.
+```
+
+1. There are several ways to see the contents of the region.
+Run the consumer to get and print all 10 entries in the `EmployeeRegion`.
+
+```
+$ ../gradlew run -Pmain=Consumer
+...
+INFO: 10 entries in EmployeeRegion on the server(s).
+...
+```
+
+If desired, use a ```gfsh``` query to see contents of the region keys:
+
+```
+$ $GEODE_HOME/bin/gfsh
+...
+gfsh>connect
+gfsh>query --query="select e.key from /EmployeeRegion.entries e"
+...
+```
+
+Note that the quantity of entries may also be observed with `gfsh`:
+ 
+```
+gfsh>describe region --name=EmployeeRegion
+..
+Name: EmployeeRegion
+Data Policy : partition
+Hosting Members : server2
+  server1
+
+Non-Default Attributes Shared By Hosting Members  
+
+ Type  |Name | Value
+-- | --- | -
+Region | size| 10
+   | data-policy | PARTITION
+```
+
+As an alternative, `gfsh` maybe used to identify how many entries
+are in the region on each server by looking at statistics.
+
+```
+gfsh>show metrics --categories=partition --region=/EmployeeRegion 
--member=server1
+```
+
+Within the output, the result for `totalBucketSize` identifies
+the number of entries hosted on the specified server.
+Vary the command to see statistics for both `server1` and `server2`.
+
+1. The region entries are distributed across both servers.
+Kill one of the servers:
+
+```
+$ $GEODE_HOME/bin/gfsh
+...
+gfsh>connect
+gfsh>stop server --name=server1
+gfsh>quit
+```
+
+1. Run the consumer a second time, and notice that approximately half of
+the entries of the ```EmployeeRegion``` are still available on the 
+remaining server.
+Those hosted by the server that was stopped were lost.
--- End diff --

As someone who might not know Geode that well, it may alarm a user that 
their entries were "lost."  Do we really need to show them/explain this step?  
The next step is shutting down the entire cluster anyways?


---
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-examples pull request #3: GEODE-2231 A partitioned region example

2017-03-28 Thread jhuynh1

Github user jhuynh1 commented on a diff in the pull request:

https://github.com/apache/geode-examples/pull/3#discussion_r108542421
  
--- Diff: 
partitioned/src/test/java/org/apache/geode/examples/partitioned/PartitionedTest.java
 ---
@@ -0,0 +1,165 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more 
contributor license
+ * agreements. See the NOTICE file distributed with this work for 
additional information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache 
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the 
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software 
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF 
ANY KIND, either express
+ * or implied. See the License for the specific language governing 
permissions and limitations under
+ * the License.
+ */
+package org.apache.geode.examples.partitioned;
+
+import static org.hamcrest.core.Is.*;
+import static org.junit.Assert.*;
+import static org.junit.Assume.*;
+
+import java.io.IOException;
+import java.net.ServerSocket;
+import java.util.Map;
+import java.util.concurrent.TimeUnit;
+import java.util.logging.Level;
+import java.util.logging.Logger;
+
+import org.apache.commons.exec.CommandLine;
+import org.apache.commons.exec.DefaultExecuteResultHandler;
+import org.apache.commons.exec.ExecuteException;
+import org.apache.commons.exec.environment.EnvironmentUtils;
+import org.apache.geode.examples.utils.ShellUtil;
+import org.junit.After;
+import org.junit.Before;
+import org.junit.Rule;
+import org.junit.Test;
+import org.junit.rules.TemporaryFolder;
+
+/**
+ * Tests for the shell scripts of the partitioned example
+ */
+public class PartitionedTest {
+
+  // TODO: parameterize
--- End diff --

Is this TODO still relevant?


---
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-examples pull request #3: GEODE-2231 A partitioned region example

2017-03-28 Thread jhuynh1

Github user jhuynh1 commented on a diff in the pull request:

https://github.com/apache/geode-examples/pull/3#discussion_r108542208
  
--- Diff: 
partitioned/src/main/java/org/apache/geode/examples/partitioned/Producer.java 
---
@@ -0,0 +1,102 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more 
contributor license
+ * agreements. See the NOTICE file distributed with this work for 
additional information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache 
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the 
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software 
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF 
ANY KIND, either express
+ * or implied. See the License for the specific language governing 
permissions and limitations under
+ * the License.
+ */
+package org.apache.geode.examples.partitioned;
+
+import org.apache.geode.cache.client.ClientCache;
+import org.apache.geode.cache.Region;
+import org.apache.geode.cache.client.ClientCacheFactory;
+import org.apache.geode.cache.client.ClientRegionShortcut;
+
+import java.util.logging.Logger;
+
+public class Producer {
+
+  static final Logger logger = Logger.getAnonymousLogger();
+  // protected ClientCache clientCache;
--- End diff --

Should this commented code be removed?


---
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-native pull request #76: GEODE-2726: Add Packer Build Files for VS 201...

2017-03-28 Thread mmartell

GitHub user mmartell opened a pull request:

https://github.com/apache/geode-native/pull/76

GEODE-2726: Add Packer Build Files for VS 2017

Added new packer files to support building Visual Studio 2017 environments.

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

$ git pull https://github.com/mmartell/geode-native feature/GEODE-2726

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

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


commit 59fd2f36db519831b5bc13d8539e3f60b0ffaaf6
Author: Mike Martell 
Date:   2017-03-28T20:49:36Z

GEODE-2726: Add Packer Build Scripts for VS 2017




---
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 #433: GEODE-2640: Removing javadoc links causing build wa...

2017-03-28 Thread asfgit

Github user asfgit closed the pull request at:

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


---
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-2640) Building geode-lucene generates javadoc warnings

2017-03-28 Thread ASF GitHub Bot (JIRA)


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

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

Github user asfgit closed the pull request at:

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


> Building geode-lucene generates javadoc warnings
> 
>
> Key: GEODE-2640
> URL: https://issues.apache.org/jira/browse/GEODE-2640
> Project: Geode
>  Issue Type: Bug
>  Components: build, lucene
>Reporter: Kirk Lund
>
> Need to delete or fix the broken @link tags:
> :geode-lucene:javadoc/tmp/build/ae3c03f4/geode/geode-lucene/src/main/java/org/apache/geode/cache/lucene/LuceneQuery.java:42:
>  warning - Tag @link: reference not found: org.apache.lucene.search
> /tmp/build/ae3c03f4/geode/geode-lucene/src/main/java/org/apache/geode/cache/lucene/LuceneResultStruct.java:46:
>  warning - Tag @link: reference not found: org.apache.lucene.search
> /tmp/build/ae3c03f4/geode/geode-lucene/src/main/java/org/apache/geode/cache/lucene/LuceneResultStruct.java:46:
>  warning - Tag @link: reference not found: org.apache.lucene.search



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2640) Building geode-lucene generates javadoc warnings

2017-03-28 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on GEODE-2640:


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

GEODE-2640: Removing javadoc links causing build warnings.

This closes #433


> Building geode-lucene generates javadoc warnings
> 
>
> Key: GEODE-2640
> URL: https://issues.apache.org/jira/browse/GEODE-2640
> Project: Geode
>  Issue Type: Bug
>  Components: build, lucene
>Reporter: Kirk Lund
>
> Need to delete or fix the broken @link tags:
> :geode-lucene:javadoc/tmp/build/ae3c03f4/geode/geode-lucene/src/main/java/org/apache/geode/cache/lucene/LuceneQuery.java:42:
>  warning - Tag @link: reference not found: org.apache.lucene.search
> /tmp/build/ae3c03f4/geode/geode-lucene/src/main/java/org/apache/geode/cache/lucene/LuceneResultStruct.java:46:
>  warning - Tag @link: reference not found: org.apache.lucene.search
> /tmp/build/ae3c03f4/geode/geode-lucene/src/main/java/org/apache/geode/cache/lucene/LuceneResultStruct.java:46:
>  warning - Tag @link: reference not found: org.apache.lucene.search



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-2726) Add Packer Build Files for VS 2017

2017-03-28 Thread Michael Martell (JIRA)


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

Michael Martell updated GEODE-2726:
---
Summary: Add Packer Build Files for VS 2017  (was: Add Packer Build Scripts 
for VS 2017)

> Add Packer Build Files for VS 2017
> --
>
> Key: GEODE-2726
> URL: https://issues.apache.org/jira/browse/GEODE-2726
> Project: Geode
>  Issue Type: New Feature
>  Components: native client
>Reporter: Michael Martell
>
> As a developer I want to setup an image to build nativeclient products using 
> Visual Studio 2017.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (GEODE-2716) export logs should honor the log level set on the server

2017-03-28 Thread Patrick Rhomberg (JIRA)


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

Patrick Rhomberg reassigned GEODE-2716:
---

Assignee: Patrick Rhomberg

> export logs should honor the log level set on the server
> 
>
> Key: GEODE-2716
> URL: https://issues.apache.org/jira/browse/GEODE-2716
> Project: Geode
>  Issue Type: Sub-task
>  Components: configuration, gfsh
>Reporter: Swapnil Bawaskar
>Assignee: Patrick Rhomberg
>
> When no log level is specified, {{export logs}} gets only the info level 
> logs. This is confusing; export logs should get the entire log file from the 
> server when log level is not specified.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: ClientCache / PDX best practice

2017-03-28 Thread Jacob Barrett

On Tue, Mar 28, 2017 at 11:43 AM John Blum  wrote:

> that you use, say, the *Composite* Design Pattern
>  [1] to "compose" a
> collection of PdxSerializer implementations that are specific to each type
> of POJO.  This is even preferable over having each POJO implement Geode's
> PdxSerializable interface which affords you similar fine grained control.
>

This needs to be a first class feature of Geode already!

[jira] [Created] (GEODE-2726) Add Packer Build Scripts for VS 2017

2017-03-28 Thread Michael Martell (JIRA)

Michael Martell created GEODE-2726:
--

 Summary: Add Packer Build Scripts for VS 2017
 Key: GEODE-2726
 URL: https://issues.apache.org/jira/browse/GEODE-2726
 Project: Geode
  Issue Type: New Feature
  Components: native client
Reporter: Michael Martell


As a developer I want to setup an image to build nativeclient products using 
Visual Studio 2017.




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2513) Geode Native docs: rebrand to match open-source software

2017-03-28 Thread ASF GitHub Bot (JIRA)


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

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

Github user PivotalSarge commented on a diff in the pull request:

https://github.com/apache/geode-native/pull/75#discussion_r108524165
  
--- Diff: 
docs/geode-native-book/master_middleman/source/subnavs/geode-nc-nav.erb ---
@@ -439,7 +439,7 @@ limitations under the License.
 
 
 
-Serialize
 with the GemFire IGFSerializable Interface
+Serialize
 with the Geode IGFSerializable Interface
--- End diff --

I believe `IGFSerializable` has been replaced with `IGeodeSerializable`.


> Geode Native docs: rebrand to match open-source software
> 
>
> Key: GEODE-2513
> URL: https://issues.apache.org/jira/browse/GEODE-2513
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Dave Barnes
>
> The newly-contributed Geode Native doc sources contain some GemFire artifacts 
> that have been purged from the open-source code. Docs should be updated to 
> match. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode-native pull request #75: GEODE-2513 Unbrand .NET API docs section

2017-03-28 Thread PivotalSarge

Github user PivotalSarge commented on a diff in the pull request:

https://github.com/apache/geode-native/pull/75#discussion_r108524165
  
--- Diff: 
docs/geode-native-book/master_middleman/source/subnavs/geode-nc-nav.erb ---
@@ -439,7 +439,7 @@ limitations under the License.
 
 
 
-Serialize
 with the GemFire IGFSerializable Interface
+Serialize
 with the Geode IGFSerializable Interface
--- End diff --

I believe `IGFSerializable` has been replaced with `IGeodeSerializable`.


---
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: ClientCache / PDX best practice

2017-03-28 Thread Michael Stolz

I think you may be confusing ClientCache with Region.

The Region is the abstraction similar to Named Cache in several other
projects or Table in a database.

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

On Tue, Mar 28, 2017 at 10:47 AM, Olivier NOUGUIER <
olivier.nougu...@gmail.com> wrote:

> Hi,
>  In a reactive extension to connect Apache Geode with akka-stream in
> alpakka community project [0], I don't know how to use ClientCache in an
> efficient  way.
>
> Given:
>
>- 2 Pojos: Animal and Person
>- 2 Regions for each
>
> Should I use 2 ClientCaches with 2 custom PDXSerializer or only one
> ClientCache with a more generic PDXSerializer ?
>
> Another way to ask, if ClientCache is expensive to instanciate.
>
> Thanks in advance.
>
> PS: I've hesitate to post this on the user list...
>
>
> [0]: https://github.com/cheleb/alpakka/tree/geode/geode
>

Re: ClientCache / PDX best practice

2017-03-28 Thread John Blum

I should also add that using the *Composite* Design Pattern is preferable
over a single, "bloated" PdxSerializer implementation (which I see all too
often in user applications) handling multiple domain object types (),
particularly when the ReflectionBasedAutoSerializer is not, or cannot be
used.

Food for thought.

On Tue, Mar 28, 2017 at 11:43 AM, John Blum  wrote:

> +1 to what Udo stated; additionally..
>
> It is also advisable, if you required more fine grained control over the
> serialization of your POJOs (i.e. necessarily more than the
> ReflectionBasedAutoSerializer
> 
>  [2]), that you use, say, the *Composite* Design Pattern
>  [1] to "compose" a
> collection of PdxSerializer implementations that are specific to each
> type of POJO.  This is even preferable over having each POJO implement
> Geode's PdxSerializable interface which affords you similar fine grained
> control.
>
> It is unfortunate that you cannot register more than 1 PdxSerializer per
> cache instance for different domain object, but essentially, you can
> achieve a similar effect using the Composite Design Pattern.  Here is 1
> example...
>
> https://github.com/spring-projects/spring-data-gemfire/
> blob/master/src/test/java/org/springframework/data/gemfire/function/
> ClientCacheFunctionExecutionWithPdxIntegrationTest.java#L312-L348
>
> This "*ComposablePdxSerializer*" is composed of 2 PdxSerializer
> implementations, 1 for each domain object...
>
> // PersonPdxSerializer
>
> https://github.com/spring-projects/spring-data-gemfire/
> blob/master/src/test/java/org/springframework/data/gemfire/function/
> ClientCacheFunctionExecutionWithPdxIntegrationTest.java#L408-L430
>
> // AddressPdxSerializer
>
> https://github.com/spring-projects/spring-data-gemfire/
> blob/master/src/test/java/org/springframework/data/gemfire/function/
> ClientCacheFunctionExecutionWithPdxIntegrationTest.java#L382-L407
>
> And then the "*ComposablePdxSerializer*" (and individual, POJO based
> PdxSerializer implementations) are configured and registered
> accordingly...
>
> https://github.com/spring-projects/spring-data-gemfire/
> blob/master/src/test/resources/org/springframework/data/gemfire/function/
> ClientCacheFunctionExecutionWithPdxIntegrationTest-server-
> context.xml#L28-L42
>
> Of course, this will all shown in *Spring Data Geode* (XML)
> configuration, but a similar configuration can be achieved using the
> equivalent Geode config where *Spring* (*Data Geode*) is not used.
>
> -j
>
>
>
> [1] https://en.wikipedia.org/wiki/Composite_pattern
> [2] http://geode.apache.org/releases/latest/javadoc/org/apache/geode/pdx/
> ReflectionBasedAutoSerializer.html
>
>
> On Tue, Mar 28, 2017 at 11:20 AM, Udo Kohlmeyer 
> wrote:
>
>> Hi there Olivier.
>>
>> It is hard to say what you are trying to do... but to answer your
>> question... The typical approach is to start a clientcache which spans
>> lifetime of the client application. It is not something that I would want
>> to start/stop as the mood strikes.
>>
>> As for generic PdxSerializer vs Pojo specific serializer, I would error
>> on the side of Pojo specific serializer, as the serialization logic is
>> defined on the pojo. BUT if you don't want to "taint" your pojo with
>> serialization code, you could use a generic PDXSerializer. In this case you
>> can write your own or use the provided ReflectionBasedAutoSerializer. [0]
>>
>> So to *hopefully* answer your question. 1 clientcache, with either 1
>> generic PdxSerializer (custom or ReflectionAutoSerializer) or 2 pojo
>> specific PdxSerializable implementations.
>>
>> --Udo
>>
>> [0] - https://geode.apache.org/docs/guide/developing/data_serializ
>> ation/gemfire_pdx_serialization.html
>>
>>
>>
>>
>> On 3/28/17 10:47, Olivier NOUGUIER wrote:
>>
>>> Hi,
>>>   In a reactive extension to connect Apache Geode with akka-stream in
>>> alpakka community project [0], I don't know how to use ClientCache in an
>>> efficient  way.
>>>
>>> Given:
>>>
>>> - 2 Pojos: Animal and Person
>>> - 2 Regions for each
>>>
>>> Should I use 2 ClientCaches with 2 custom PDXSerializer or only one
>>> ClientCache with a more generic PDXSerializer ?
>>>
>>> Another way to ask, if ClientCache is expensive to instanciate.
>>>
>>> Thanks in advance.
>>>
>>> PS: I've hesitate to post this on the user list...
>>>
>>>
>>> [0]: https://github.com/cheleb/alpakka/tree/geode/geode
>>>
>>>
>>
>
>
> --
> -John
> john.blum10101 (skype)
>



-- 
-John
john.blum10101 (skype)

Re: ClientCache / PDX best practice

2017-03-28 Thread John Blum

+1 to what Udo stated; additionally..

It is also advisable, if you required more fine grained control over the
serialization of your POJOs (i.e. necessarily more than the
ReflectionBasedAutoSerializer

[2]),
that you use, say, the *Composite* Design Pattern
 [1] to "compose" a
collection of PdxSerializer implementations that are specific to each type
of POJO.  This is even preferable over having each POJO implement Geode's
PdxSerializable interface which affords you similar fine grained control.

It is unfortunate that you cannot register more than 1 PdxSerializer per
cache instance for different domain object, but essentially, you can
achieve a similar effect using the Composite Design Pattern.  Here is 1
example...

https://github.com/spring-projects/spring-data-gemfire/blob/master/src/test/java/org/springframework/data/gemfire/function/ClientCacheFunctionExecutionWithPdxIntegrationTest.java#L312-L348

This "*ComposablePdxSerializer*" is composed of 2 PdxSerializer
implementations, 1 for each domain object...

// PersonPdxSerializer

https://github.com/spring-projects/spring-data-gemfire/blob/master/src/test/java/org/springframework/data/gemfire/function/ClientCacheFunctionExecutionWithPdxIntegrationTest.java#L408-L430

// AddressPdxSerializer

https://github.com/spring-projects/spring-data-gemfire/blob/master/src/test/java/org/springframework/data/gemfire/function/ClientCacheFunctionExecutionWithPdxIntegrationTest.java#L382-L407

And then the "*ComposablePdxSerializer*" (and individual, POJO based
PdxSerializer implementations) are configured and registered accordingly...

https://github.com/spring-projects/spring-data-gemfire/blob/master/src/test/resources/org/springframework/data/gemfire/function/ClientCacheFunctionExecutionWithPdxIntegrationTest-server-context.xml#L28-L42

Of course, this will all shown in *Spring Data Geode* (XML) configuration,
but a similar configuration can be achieved using the equivalent Geode
config where *Spring* (*Data Geode*) is not used.

-j

[1] https://en.wikipedia.org/wiki/Composite_pattern
[2]
http://geode.apache.org/releases/latest/javadoc/org/apache/geode/pdx/ReflectionBasedAutoSerializer.html

On Tue, Mar 28, 2017 at 11:20 AM, Udo Kohlmeyer 
wrote:

> Hi there Olivier.
>
> It is hard to say what you are trying to do... but to answer your
> question... The typical approach is to start a clientcache which spans
> lifetime of the client application. It is not something that I would want
> to start/stop as the mood strikes.
>
> As for generic PdxSerializer vs Pojo specific serializer, I would error on
> the side of Pojo specific serializer, as the serialization logic is defined
> on the pojo. BUT if you don't want to "taint" your pojo with serialization
> code, you could use a generic PDXSerializer. In this case you can write
> your own or use the provided ReflectionBasedAutoSerializer. [0]
>
> So to *hopefully* answer your question. 1 clientcache, with either 1
> generic PdxSerializer (custom or ReflectionAutoSerializer) or 2 pojo
> specific PdxSerializable implementations.
>
> --Udo
>
> [0] - https://geode.apache.org/docs/guide/developing/data_serializ
> ation/gemfire_pdx_serialization.html
>
>
>
>
> On 3/28/17 10:47, Olivier NOUGUIER wrote:
>
>> Hi,
>>   In a reactive extension to connect Apache Geode with akka-stream in
>> alpakka community project [0], I don't know how to use ClientCache in an
>> efficient  way.
>>
>> Given:
>>
>> - 2 Pojos: Animal and Person
>> - 2 Regions for each
>>
>> Should I use 2 ClientCaches with 2 custom PDXSerializer or only one
>> ClientCache with a more generic PDXSerializer ?
>>
>> Another way to ask, if ClientCache is expensive to instanciate.
>>
>> Thanks in advance.
>>
>> PS: I've hesitate to post this on the user list...
>>
>>
>> [0]: https://github.com/cheleb/alpakka/tree/geode/geode
>>
>>
>

-- 
-John
john.blum10101 (skype)

Re: Review Request 57822: GEODE-1274: Migration from PulseLogWriter to Log4j standard.

2017-03-28 Thread Patrick Rhomberg



> On March 23, 2017, 5:39 p.m., Jared Stewart wrote:
> > Is there a log4j configuration being applied somewhere?  I'm wondering 
> > where I should expect the new Pulse logs to show up.

I'm not entirely clear on how log4j workst.  That said...

All the pulse loggers are now being instantiated directly from log4j's 
LogManager.  LogService (in geode-core) extends LogManager and adds the 
configurations.  It appears that those configurations are then loaded into the 
LogManager class.  So in theory, those should propogate to the pulse log4j 
things.  I did some cursory testing on gfsh directly, and it appears that logs 
are showing up in the locator's logs.  (Does `start pulse` target the locator?  
Are the locator and manager separate things?  They're both being listed on the 
same member within pulse, so I don't know if the appenders just happen to be 
sharing that log file.)  [update:] Looking at it again, I'm not 100% sure those 
aren't the REST API calls that were already showing up in the logs.  But there 
is a marked difference in logging present between the current `develop` branch 
and this patch, so I was led to believe that we are in fact capturing the pulse 
log calls.

Could this be a potential problem in a standalone deployment of pulse?

==

After some testing, it looks like, when run embedded, that the LogService's 
managing of Log4J settings percolates through.  Formatting and location should 
be updated by the log4j configurations.


- Patrick


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


On March 22, 2017, 10:33 p.m., Patrick Rhomberg wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57822/
> ---
> 
> (Updated March 22, 2017, 10:33 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Kevin Duling, Ken Howe, 
> Kirk Lund, and Swapnil Bawaskar.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> To avoid dependency on geode-core, the pulse loggers are instantiated 
> directly from LogManager, rather than canonical LogService (which itself 
> extends LogManager).
> 
> Significant reduction of logging level state checks, relying on Log4j 
> handling.
> Significant reduction of string concatenation, relying on Log4j2 string 
> substitutions.
> Reduction of logging using an exception e.getMessage, favoring instead 
> passing the exception itself for the stacktrace.
> Multiple identical exception blocks collapsed.
> 
> 
> 
> Explicitly not addressed in this ticket:
> - A great deal of logging could do with localization.
> - A number of exception blocks catch one or more types of exception and only 
> log the exception before moving.  These are specific exceptions and not the 
> general `Exception` class.  The catches could be simplified, but could that 
> lead to a catch an error that would otherwise be raised?
> 
> The original ticket was not about updating from a depreciated class, but 
> about how logs were not being collected.  The answer to this was that Log4j 
> wasn't tracking them, so they weren't being gathered; extending Log4j to do 
> Pulse tracking should resolve the issue, but is it okay that this is only 
> tangentally answering the problem?
> 
> 
> Diffs
> -
> 
>   geode-pulse/build.gradle a038f734266939f3c12b713ce0745c013b4adb91 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/PulseAppListener.java
>  e1666ecf38331983d8c47c4b46b3b7e87faaf854 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/controllers/ExceptionHandlingAdvice.java
>  80a3c63b5d9170cf9933c43edf56da78dc62bf46 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/controllers/PulseController.java
>  12b6172cbbc79651e972179532f2b79623a1992e 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/data/Cluster.java
>  e71388d134c96549ee9995c4c874615ee66fe7c1 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/data/DataBrowser.java
>  03077c27003811718e3974575a15b6892f6d8e2f 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/data/JMXDataUpdater.java
>  9633b9a1f50df051b8fb9b4f4787a1d25a0ab019 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/data/JmxManagerFinder.java
>  fa2b5b79f40a95b0a20be38c20e61d9e94a39688 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/data/PulseConfig.java
>  dc643b49462af9365859d899f2c798f0f2448b72 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/data/PulseConstants.java
>  b36c283630fcd3d143c1398ac0fecf45eec0eb54 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/data/Repository.java
>

Re: Review Request 57822: GEODE-1274: Migration from PulseLogWriter to Log4j standard.

2017-03-28 Thread Patrick Rhomberg



> On March 24, 2017, 4:10 p.m., Jinmei Liao wrote:
> > We will need to verify that the logs went to the same place as before, or 
> > at least went to a reasonable place.

[The below should be struck-through but isn't rendering that way on my end...]
~~It appears that, at least in my testing, the Pulse logs are sent to the home 
directory `~/PULSELOG.log`.  This appears to be the case whether Pulse is in 
the stand-alone deployment or embedded.~~

~~Do we want to try to merge this log in with the Geode log in the event that 
Pulse is running embedded?~~
[The above should be struck-through but isn't rendering that way on my end...]

It looks like the OLD behavior was that the PulseLogWriter would write to the 
home directory `~/PULSELOG_#.log`.  Now it is correctly controlled by the 
Log4J's wrapper and should appear with the rest of the Geode logs when run 
embedded.  When run standalone, it appears in the server's logs as expected (in 
my case, `/usr/local/Cellar/tomcat/8.5.12/libexec/logs/localhost.[date].log`.  
This should still be influenced when a `pulse.properties` is somewhere in the 
webserver's path for Pulse to find.


- Patrick


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


On March 22, 2017, 10:33 p.m., Patrick Rhomberg wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57822/
> ---
> 
> (Updated March 22, 2017, 10:33 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Kevin Duling, Ken Howe, 
> Kirk Lund, and Swapnil Bawaskar.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> To avoid dependency on geode-core, the pulse loggers are instantiated 
> directly from LogManager, rather than canonical LogService (which itself 
> extends LogManager).
> 
> Significant reduction of logging level state checks, relying on Log4j 
> handling.
> Significant reduction of string concatenation, relying on Log4j2 string 
> substitutions.
> Reduction of logging using an exception e.getMessage, favoring instead 
> passing the exception itself for the stacktrace.
> Multiple identical exception blocks collapsed.
> 
> 
> 
> Explicitly not addressed in this ticket:
> - A great deal of logging could do with localization.
> - A number of exception blocks catch one or more types of exception and only 
> log the exception before moving.  These are specific exceptions and not the 
> general `Exception` class.  The catches could be simplified, but could that 
> lead to a catch an error that would otherwise be raised?
> 
> The original ticket was not about updating from a depreciated class, but 
> about how logs were not being collected.  The answer to this was that Log4j 
> wasn't tracking them, so they weren't being gathered; extending Log4j to do 
> Pulse tracking should resolve the issue, but is it okay that this is only 
> tangentally answering the problem?
> 
> 
> Diffs
> -
> 
>   geode-pulse/build.gradle a038f734266939f3c12b713ce0745c013b4adb91 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/PulseAppListener.java
>  e1666ecf38331983d8c47c4b46b3b7e87faaf854 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/controllers/ExceptionHandlingAdvice.java
>  80a3c63b5d9170cf9933c43edf56da78dc62bf46 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/controllers/PulseController.java
>  12b6172cbbc79651e972179532f2b79623a1992e 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/data/Cluster.java
>  e71388d134c96549ee9995c4c874615ee66fe7c1 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/data/DataBrowser.java
>  03077c27003811718e3974575a15b6892f6d8e2f 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/data/JMXDataUpdater.java
>  9633b9a1f50df051b8fb9b4f4787a1d25a0ab019 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/data/JmxManagerFinder.java
>  fa2b5b79f40a95b0a20be38c20e61d9e94a39688 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/data/PulseConfig.java
>  dc643b49462af9365859d899f2c798f0f2448b72 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/data/PulseConstants.java
>  b36c283630fcd3d143c1398ac0fecf45eec0eb54 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/data/Repository.java
>  b228e4a754100fe07c9dbec232d5e88809aefeef 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/log/LogWriter.java
>  6f90e7a48a10ab2778ee00cf3d707a476ebe91eb 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/log/MessageFormatter.java
>  924520d3ba70a48379bd6ff9a6ce4d6e0d4ed804 
>   
>

Re: a new example needs your review

2017-03-28 Thread Dick Cavender


+1

After going through the example and providing comments on the PR.

On 2/23/2017 12:10 PM, Karen Miller wrote:

Calling all Geode devs:

I've put together a new, and quite basic example that attempts to
demonstrate
what partitioning does.  Please review and see the PR at
   https://github.com/apache/geode-examples/pull/3

When reviewing this example, please keep in mind that my goal is to
tightly focus on partitioning, so it really doesn't do too much.  Other
(future)
examples will demonstrate other and more complex aspects of using or
developing
with Geode.

Here's the comment I placed in the PR, as you'd want to see this in order to
run the example yourself:

   This example intends to demonstrate what partitioning does (distributes

entries across buckets, and therefore across servers). It also illustrates
what goes wrong when a bad hashcode is used, such that all entries end up
in the same bucket.
Running the example is explained in the partitioned/README.md file. It
assumes that the reader has already read and followed the minimal
directions in the README.md file at the root of the geode-examples repo.

[jira] [Commented] (GEODE-2513) Geode Native docs: rebrand to match open-source software

2017-03-28 Thread ASF GitHub Bot (JIRA)


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

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

Github user PivotalSarge commented on a diff in the pull request:

https://github.com/apache/geode-native/pull/75#discussion_r108500455
  
--- Diff: 
docs/geode-native-book/master_middleman/source/subnavs/geode-nc-nav.erb ---
@@ -473,7 +473,7 @@ limitations under the License.
 Resolving
 the Error
 
 
-Using 
GemStone.GemFire.Cache.dll As a Private Assembly
+Using 
Apache.Geode.Client.dll As a Private Assembly
--- End diff --

I don't see `Apache.Geode.Client.dll`, only `Apache.Geode.dll`, after a 
Windows installation.


> Geode Native docs: rebrand to match open-source software
> 
>
> Key: GEODE-2513
> URL: https://issues.apache.org/jira/browse/GEODE-2513
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Dave Barnes
>
> The newly-contributed Geode Native doc sources contain some GemFire artifacts 
> that have been purged from the open-source code. Docs should be updated to 
> match. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode-native pull request #75: GEODE-2513 Unbrand .NET API docs section

2017-03-28 Thread PivotalSarge

Github user PivotalSarge commented on a diff in the pull request:

https://github.com/apache/geode-native/pull/75#discussion_r108500455
  
--- Diff: 
docs/geode-native-book/master_middleman/source/subnavs/geode-nc-nav.erb ---
@@ -473,7 +473,7 @@ limitations under the License.
 Resolving
 the Error
 
 
-Using 
GemStone.GemFire.Cache.dll As a Private Assembly
+Using 
Apache.Geode.Client.dll As a Private Assembly
--- End diff --

I don't see `Apache.Geode.Client.dll`, only `Apache.Geode.dll`, after a 
Windows installation.


---
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-native pull request #75: GEODE-2513 Unbrand .NET API docs section

2017-03-28 Thread PivotalSarge

Github user PivotalSarge commented on a diff in the pull request:

https://github.com/apache/geode-native/pull/75#discussion_r108496561
  
--- Diff: 
docs/geode-native-docs/dotnet-caching-api/implementing-igfserializable.html.md.erb
 ---
@@ -31,21 +31,21 @@ Examples follow the procedure.
 void ToData(DataOutput output)
 ```
 
-The `ToData` function is responsible for copying all of the data 
fields for the object to the object stream. The `DataOutput` class represents 
the output stream and provides methods for writing the primitives in a network 
byte order. For details, see the API documentation for `DataOutput` at 
[http://gemfire-apis.docs.pivotal.io](http://gemfire-apis.docs.pivotal.io).
+The `ToData` function is responsible for copying all of the data 
fields for the object to the object stream. The `DataOutput` class represents 
the output stream and provides methods for writing the primitives in a network 
byte order.
 
 2.  Implement the `FromData` function that consumes a data input stream 
and repopulates the data fields for the object:
 
 ``` pre
 void fromData (DataInput& input)
 ```
 
-The `DataInput` class represents the input stream and provides methods 
for reading input elements. The `FromData` function must read the elements of 
the input stream in the same order that they were written by `ToData`. For more 
about this, see the API documentation for `DataInput` at 
[http://gemfire-apis.docs.pivotal.io](http://gemfire-apis.docs.pivotal.io).
+The `DataInput` class represents the input stream and provides methods 
for reading input elements. The `FromData` function must read the elements of 
the input stream in the same order that they were written by `ToData`.
 
 3.  Implement the `ClassId` function to return an integer which is unique 
for your class (in the set of all of your user-defined classes).
 
 ## Simple BankAccount Class
 
-This example shows a simple class, `BankAccount`, that encapsulates two 
`ints`: `customerId` and `accountId`:
+This example shows a simple class, `BankAccount`, that encapsulates the 
two `ints` `customerId` and `accountId`:
--- End diff --

Maybe a comma between `ints` and `customerId`?


---
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-2513) Geode Native docs: rebrand to match open-source software

2017-03-28 Thread ASF GitHub Bot (JIRA)


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

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

Github user PivotalSarge commented on a diff in the pull request:

https://github.com/apache/geode-native/pull/75#discussion_r108496561
  
--- Diff: 
docs/geode-native-docs/dotnet-caching-api/implementing-igfserializable.html.md.erb
 ---
@@ -31,21 +31,21 @@ Examples follow the procedure.
 void ToData(DataOutput output)
 ```
 
-The `ToData` function is responsible for copying all of the data 
fields for the object to the object stream. The `DataOutput` class represents 
the output stream and provides methods for writing the primitives in a network 
byte order. For details, see the API documentation for `DataOutput` at 
[http://gemfire-apis.docs.pivotal.io](http://gemfire-apis.docs.pivotal.io).
+The `ToData` function is responsible for copying all of the data 
fields for the object to the object stream. The `DataOutput` class represents 
the output stream and provides methods for writing the primitives in a network 
byte order.
 
 2.  Implement the `FromData` function that consumes a data input stream 
and repopulates the data fields for the object:
 
 ``` pre
 void fromData (DataInput& input)
 ```
 
-The `DataInput` class represents the input stream and provides methods 
for reading input elements. The `FromData` function must read the elements of 
the input stream in the same order that they were written by `ToData`. For more 
about this, see the API documentation for `DataInput` at 
[http://gemfire-apis.docs.pivotal.io](http://gemfire-apis.docs.pivotal.io).
+The `DataInput` class represents the input stream and provides methods 
for reading input elements. The `FromData` function must read the elements of 
the input stream in the same order that they were written by `ToData`.
 
 3.  Implement the `ClassId` function to return an integer which is unique 
for your class (in the set of all of your user-defined classes).
 
 ## Simple BankAccount Class
 
-This example shows a simple class, `BankAccount`, that encapsulates two 
`ints`: `customerId` and `accountId`:
+This example shows a simple class, `BankAccount`, that encapsulates the 
two `ints` `customerId` and `accountId`:
--- End diff --

Maybe a comma between `ints` and `customerId`?


> Geode Native docs: rebrand to match open-source software
> 
>
> Key: GEODE-2513
> URL: https://issues.apache.org/jira/browse/GEODE-2513
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Dave Barnes
>
> The newly-contributed Geode Native doc sources contain some GemFire artifacts 
> that have been purged from the open-source code. Docs should be updated to 
> match. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2662) Gfsh displays field value on wrong line!

2017-03-28 Thread Kevin Duling (JIRA)


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

Kevin Duling commented on GEODE-2662:
-

The data returning to gfsh appears to be the issue.  Telephone isn't lining up 
in the JSON response.

{code}
{
  "contentType": "composite",
  "data": {
"content": {
  "__sections__-STEP_SECTION": {
"NEXT_STEP_NAME": "SELECT_DISPLAY"
  },
  "__sections__-ARG_SECTION": {
"Result": true,
"startCount": 0,
"endCount": 20,
"Rows": 3,
"__tables__-0": {
  "content": {
"firstName": [
  "Jane",
  "John",
  "Tom"
],
"lastName": [
  "Doe",
  "Doe",
  "Smith"
],
"telephone": [
  "(512) 333-",
  null,
  null
]
  }
}
  }
},
"footer": "",
"header": "",
"type-class": 
"org.apache.geode.management.internal.cli.CommandResponse.Data"
  },
  "debugInfo": "\n[info 2017/03/28 10:43:18.994 PDT RMI TCP 
Connection(15)-10.118.33.209 tid=0x5e] (msgTID=94 msgSN=69) Executing query 
--query=\"select * from /Customer c\" --step-name=SELECT_EXEC\n\n",
  "failedToPersist": false,
  "page": "1/1",
  "sender": "locator",
  "status": 0,
  "tokenAccessor": "__NULL__",
  "type-class": "org.apache.geode.management.internal.cli.CommandResponse",
  "version": "1.2.0-SNAPSHOT",
  "when": "3/28/17 10:43 AM"
}
{code}

> Gfsh displays field value on wrong line!
> 
>
> Key: GEODE-2662
> URL: https://issues.apache.org/jira/browse/GEODE-2662
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: Eitan Suez
>
> scenario:
> start a locator, a server
> write a client that stores several records of a given type, using pdx 
> serialization
> modify the type in question by adding a field
> write one more record to gemfire, populating all fields, including the new 
> field
> invoke a gfsh query command "select * from /"
> the new field value will display always on the first line of the result set, 
> not on the line associated with the object it actually belongs to.
> example:
> Customer
>  firstName, lastName
> write a customer object:
>  John Doe
> now modify Customer, add telephoneNumber
>  write another customer object:
> Sam Smith, 512.333.
> now run:
> query --query="select c from /Customer c"
> will print:
> firstName | lastName | telephoneNumber
> - |  | ---
> John  | Doe  | 512.333.
> Sam   | Smith| null
> even though the query "select c from /Customer c where c.firstName = 'Sam'" 
> clearly shows the phone number is associated with sam.
> this bug has existed in gemfire at least since v8 and verified to still exist 
> in latest version 9.0.1



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

ClientCache / PDX best practice

2017-03-28 Thread Olivier NOUGUIER

Hi,
 In a reactive extension to connect Apache Geode with akka-stream in
alpakka community project [0], I don't know how to use ClientCache in an
efficient  way.

Given:

   - 2 Pojos: Animal and Person
   - 2 Regions for each

Should I use 2 ClientCaches with 2 custom PDXSerializer or only one
ClientCache with a more generic PDXSerializer ?

Another way to ask, if ClientCache is expensive to instanciate.

Thanks in advance.

PS: I've hesitate to post this on the user list...


[0]: https://github.com/cheleb/alpakka/tree/geode/geode

[jira] [Commented] (GEODE-2725) export logs does not honor --dir

2017-03-28 Thread Wes Williams (JIRA)


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

Wes Williams commented on GEODE-2725:
-

The --dir option works but you need to say --dir=./tmp.  Still, the program 
should default to the current directory and not the Geode install directory.

> export logs does not honor --dir
> 
>
> Key: GEODE-2725
> URL: https://issues.apache.org/jira/browse/GEODE-2725
> Project: Geode
>  Issue Type: Sub-task
>  Components: gfsh, logging
>Reporter: Swapnil Bawaskar
>
> When connected to locator via jmx, run the following command:
> {noformat}
> gfsh>export logs --dir=tmp
> {noformat}
> Observer that the dir option is ignored:
> {noformat}
> Logs exported to the connected member's file system: 
> /Users/sbawaskar/apache/geode/geode-assembly/build/install/apache-geode/loc1/exportedLogs_1490721273215.zip
> {noformat}
> The --tmp option is honored when connected via http.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2725) export logs does not honor --dir

2017-03-28 Thread Swapnil Bawaskar (JIRA)

Swapnil Bawaskar created GEODE-2725:
---

 Summary: export logs does not honor --dir
 Key: GEODE-2725
 URL: https://issues.apache.org/jira/browse/GEODE-2725
 Project: Geode
  Issue Type: Sub-task
  Components: gfsh, logging
Reporter: Swapnil Bawaskar


When connected to locator via jmx, run the following command:
{noformat}
gfsh>export logs --dir=tmp
{noformat}
Observer that the dir option is ignored:
{noformat}
Logs exported to the connected member's file system: 
/Users/sbawaskar/apache/geode/geode-assembly/build/install/apache-geode/loc1/exportedLogs_1490721273215.zip
{noformat}
The --tmp option is honored when connected via http.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Build failed in Jenkins: Geode-release #50

2017-03-28 Thread Apache Jenkins Server

See 


Changes:

[abaker] bump release version

[abaker] GEODE-2670: Update pulse endpoint interceptors

--
[...truncated 105.03 KB...]
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.ClusterConfigImportDUnitTest.before(ClusterConfigImportDUnitTest.java:63)

org.apache.geode.management.internal.configuration.ClusterConfigImportDUnitTest 
> testImportWithRunningServerWithData 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.ClusterConfigImportDUnitTest.before(ClusterConfigImportDUnitTest.java:63)

org.apache.geode.management.internal.configuration.ClusterConfigImportDUnitTest 
> testImportWithMultipleLocators 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.ClusterConfigImportDUnitTest.before(ClusterConfigImportDUnitTest.java:63)

org.apache.geode.management.internal.configuration.ClusterConfigDistributionDUnitTest
 > 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.ClusterConfigDistributionDUnitTest.before(ClusterConfigDistributionDUnitTest.java:66)

org.apache.geode.management.internal.configuration.ClusterConfigDistributionDUnitTest
 > testIndexAndAsyncEventQueueCommands 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.ClusterConfigDistributionDUnitTest.before(ClusterConfigDistributionDUnitTest.java:66)

6812 tests completed, 13 failed, 601 skipped
:geode-core:distributedTest FAILED
:geode-core:flakyTest
:geode-core:integrationTest
:geode-cq:assemble
:geode-cq: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-cq:processTestResources
:geode-cq:testClasses
:geode-cq:checkMissedTests
:geode-cq:spotlessJavaCheck
:geode-cq:spotlessCheck
:geode-cq:test
:geode-cq:check
:geode-cq:build
:geode-cq:distributedTest
:geode-cq:flakyTest
:geode-cq:integrationTest
:geode-json:assemble
: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

[jira] [Commented] (GEODE-2472) Oplog.flush method doesn't verify that the entry gets written

2017-03-28 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on GEODE-2472:


Commit 8d1426d8cae24f9bb001d04f0e473359811555a7 in geode's branch 
refs/heads/feature/GEODE-2420 from [~agingade]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=8d1426d ]

GEODE-2472 changes are made to ensure byte array is completely flushed to oplog 
channel.

The Oplog and OverflowOplog flush(OplogFile olf, ByteBuffer b1, ByteBuffer b2) 
method doesn't check the results of the channel.write() call.

It could so happen partial byte array is written to the channel. The check is 
added to make sure the bytes are completely written to the file channel.


> Oplog.flush method doesn't verify that the entry gets written
> -
>
> Key: GEODE-2472
> URL: https://issues.apache.org/jira/browse/GEODE-2472
> Project: Geode
>  Issue Type: Improvement
>  Components: persistence
>Reporter: Kenneth Howe
>Assignee: Anilkumar Gingade
> Fix For: 1.2.0
>
>
> The Oplog.flush(OplogFile olf, ByteBuffer b1, ByteBuffer b2) method doesn't 
> check the results of the channel.write() call. The other Oplog.flush() method 
> that performs a channel write wraps the write() call in the loop
> {code}
> do {
> ...
> } while (hasRemaining);
> {code}
> to make sure the Oplog entry is written to the OplogFile.
> This method is implemented without the check loop, making the assumption that 
> the write() completely writes everything from both buffers. Defensive 
> programming would suggest that the results of lower level calls are checked.
> Failure to recognize a partial write to the OplogFile can result in a corrupt 
> oplog that isn't found until the persistent disk store is recovered.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2395) PulseDataExportTest.dataBrowserExportWorksAsExpected fails intermittently with ComparisonFailure

2017-03-28 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on GEODE-2395:


Commit e10b75c353b419503ff32cc3bf154e7a778d63a0 in geode's branch 
refs/heads/feature/GEODE-2420 from [~jinmeiliao]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=e10b75c ]

GEODE-2395: use random ports when starting the jmx manager and http services

* be able to configure the various aspects of the rules before starting the 
server when declaring the rules.
* delete the unnecessary abstract test classes
* allowing tests to use default ports if needed
* created HttpClientRule to ease the connection to to pulse server


> PulseDataExportTest.dataBrowserExportWorksAsExpected fails intermittently 
> with ComparisonFailure
> 
>
> Key: GEODE-2395
> URL: https://issues.apache.org/jira/browse/GEODE-2395
> Project: Geode
>  Issue Type: Bug
>  Components: pulse, tests
>Reporter: Kirk Lund
>Assignee: Jinmei Liao
>  Labels: Flaky
>
> {noformat}
> 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.tools.pulse.PulseDataExportTest.before(PulseDataExportTest.java:85)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
>   at sun.reflect.GeneratedMethodAccessor26.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
>   at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
>   at 
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109)
>   at

[jira] [Commented] (GEODE-2395) PulseDataExportTest.dataBrowserExportWorksAsExpected fails intermittently with ComparisonFailure

2017-03-28 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on GEODE-2395:


Commit 5ca576ff29a2c5c79182f0a182447ee2c46c4763 in geode's branch 
refs/heads/feature/GEODE-2420 from [~jinmeiliao]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=5ca576f ]

GEODE-2395: use random ports when starting the jmx manager and http services - 
spotless


> PulseDataExportTest.dataBrowserExportWorksAsExpected fails intermittently 
> with ComparisonFailure
> 
>
> Key: GEODE-2395
> URL: https://issues.apache.org/jira/browse/GEODE-2395
> Project: Geode
>  Issue Type: Bug
>  Components: pulse, tests
>Reporter: Kirk Lund
>Assignee: Jinmei Liao
>  Labels: Flaky
>
> {noformat}
> 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.tools.pulse.PulseDataExportTest.before(PulseDataExportTest.java:85)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
>   at sun.reflect.GeneratedMethodAccessor26.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
>   at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
>   at 
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109)
>   at sun.reflect.GeneratedMethodAccessor25.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
>

[jira] [Created] (GEODE-2724) NPE shutting down locator

2017-03-28 Thread Bruce Schuchardt (JIRA)

Bruce Schuchardt created GEODE-2724:
---

 Summary: NPE shutting down locator
 Key: GEODE-2724
 URL: https://issues.apache.org/jira/browse/GEODE-2724
 Project: Geode
  Issue Type: Bug
  Components: pulse
Reporter: Bruce Schuchardt


Locator shutdown threw an NPE when stopping a Jetty server in Pulse code:

{code}
[warning 2017/03/28 08:56:25.493 IST locator1  tid=0x4a] Failed to 
stop the HTTP service because: null
java.lang.NullPointerException
at 
org.apache.geode.tools.pulse.internal.data.Repository.removeAllClusters(Repository.java:225)
at 
org.apache.geode.tools.pulse.internal.PulseAppListener.contextDestroyed(PulseAppListener.java:84)
at 
org.eclipse.jetty.server.handler.ContextHandler.callContextDestroyed(ContextHandler.java:843)
at 
org.eclipse.jetty.servlet.ServletContextHandler.callContextDestroyed(ServletContextHandler.java:543)
at 
org.eclipse.jetty.server.handler.ContextHandler.stopContext(ContextHandler.java:824)
at 
org.eclipse.jetty.servlet.ServletContextHandler.stopContext(ServletContextHandler.java:353)
at 
org.eclipse.jetty.webapp.WebAppContext.stopWebapp(WebAppContext.java:1385)
at 
org.eclipse.jetty.webapp.WebAppContext.stopContext(WebAppContext.java:1349)
at 
org.eclipse.jetty.server.handler.ContextHandler.doStop(ContextHandler.java:872)
at 
org.eclipse.jetty.servlet.ServletContextHandler.doStop(ServletContextHandler.java:269)
at org.eclipse.jetty.webapp.WebAppContext.doStop(WebAppContext.java:541)
at 
org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
at 
org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:143)
at 
org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:161)
at 
org.eclipse.jetty.server.handler.AbstractHandler.doStop(AbstractHandler.java:73)
at 
org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
at 
org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:143)
at 
org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:161)
at 
org.eclipse.jetty.server.handler.AbstractHandler.doStop(AbstractHandler.java:73)
at org.eclipse.jetty.server.Server.doStop(Server.java:476)
at 
org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
at 
org.apache.geode.management.internal.ManagementAgent.stopHttpService(ManagementAgent.java:328)
at 
org.apache.geode.management.internal.ManagementAgent.stopAgent(ManagementAgent.java:156)
at 
org.apache.geode.management.internal.SystemManagementService.close(SystemManagementService.java:265)
at 
org.apache.geode.management.internal.beans.ManagementAdapter.handleCacheRemoval(ManagementAdapter.java:735)
at 
org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:117)
at 
org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2146)
at 
org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:536)
at 
org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:2149)
at 
org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:1314)
at 
org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:964)
at 
org.apache.geode.management.internal.beans.MemberMBeanBridge$1.run(MemberMBeanBridge.java:1000)
at java.lang.Thread.run(Thread.java:745)

[error 2017/03/28 08:56:25.494 IST locator1  tid=0x4a] Failed to 
properly release resources held by the HTTP service: !STOPPED
java.lang.IllegalStateException: !STOPPED
at 
org.eclipse.jetty.server.handler.HandlerWrapper.destroy(HandlerWrapper.java:134)
at 
org.apache.geode.management.internal.ManagementAgent.stopHttpService(ManagementAgent.java:333)
at 
org.apache.geode.management.internal.ManagementAgent.stopAgent(ManagementAgent.java:156)
at 
org.apache.geode.management.internal.SystemManagementService.close(SystemManagementService.java:265)
at 
org.apache.geode.management.internal.beans.ManagementAdapter.handleCacheRemoval(ManagementAdapter.java:735)
at 
org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:117)
at 
org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2146)
at 
org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:536)
at 
org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:2149)
at

[jira] [Commented] (GEODE-2619) Function execution on server must handle CacheClosedException

2017-03-28 Thread ASF GitHub Bot (JIRA)


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

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

GitHub user nabarunnag opened a pull request:

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

GEODE-2619: Lucene APIs unwrap function exception and throw the cause.

* This is done so that users do not encounter Function Exceptions while 
executing Lucene APIs.

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

$ git pull https://github.com/nabarunnag/incubator-geode feature/GEODE-2619

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

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


commit 5fd28d7408e6b0b386efdee21fea36b46a7ab4d2
Author: nabarun 
Date:   2017-03-28T07:16:44Z

GEODE-2619: Lucene APIs unwrap function exception and throw the cause.

* This is done so that users do not encounter Function Exceptions while 
executing Lucene APIs.




> Function execution on server must handle CacheClosedException
> -
>
> Key: GEODE-2619
> URL: https://issues.apache.org/jira/browse/GEODE-2619
> Project: Geode
>  Issue Type: Bug
>  Components: functions
>Reporter: nabarun
>
> While a client is executing a function on a server, and the connection is 
> disconnected, it must throw a CacheClosedException.
> Currently, executeOnServer method in ServerRegionFunctionExecutor class wraps 
> the CacheClosedException into a FunctionException and throws it.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2640) Building geode-lucene generates javadoc warnings

2017-03-28 Thread ASF GitHub Bot (JIRA)


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

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

GitHub user nabarunnag opened a pull request:

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

GEODE-2640: Removing javadoc links causing build warnings.



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

$ git pull https://github.com/nabarunnag/incubator-geode feature/GEODE-2640

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

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


commit 68f3bc7dca3af2135cb7c795c272d1d810f04ba6
Author: nabarun 
Date:   2017-03-28T07:03:54Z

GEODE-2640: Removing javadoc links causing build warnings.




> Building geode-lucene generates javadoc warnings
> 
>
> Key: GEODE-2640
> URL: https://issues.apache.org/jira/browse/GEODE-2640
> Project: Geode
>  Issue Type: Bug
>  Components: build, lucene
>Reporter: Kirk Lund
>
> Need to delete or fix the broken @link tags:
> :geode-lucene:javadoc/tmp/build/ae3c03f4/geode/geode-lucene/src/main/java/org/apache/geode/cache/lucene/LuceneQuery.java:42:
>  warning - Tag @link: reference not found: org.apache.lucene.search
> /tmp/build/ae3c03f4/geode/geode-lucene/src/main/java/org/apache/geode/cache/lucene/LuceneResultStruct.java:46:
>  warning - Tag @link: reference not found: org.apache.lucene.search
> /tmp/build/ae3c03f4/geode/geode-lucene/src/main/java/org/apache/geode/cache/lucene/LuceneResultStruct.java:46:
>  warning - Tag @link: reference not found: org.apache.lucene.search



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (GEODE-2690) Use a different thread pool for flush operations

2017-03-28 Thread nabarun (JIRA)


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

nabarun resolved GEODE-2690.

   Resolution: Fixed
Fix Version/s: 1.2.0

> Use a different thread pool for flush operations
> 
>
> Key: GEODE-2690
> URL: https://issues.apache.org/jira/browse/GEODE-2690
> Project: Geode
>  Issue Type: Bug
>Reporter: nabarun
>Assignee: nabarun
> Fix For: 1.2.0
>
>
> WaitUntilParallelGatewaySenderFlushedCoordinator's waitUntilFlushed should 
> use a thread pool with a limited number of thread so that the system doesn't 
> create an exceptionally high number of threads while flushing buckets.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

58 matches

Mail list logo