geode - stored procedures

[Marios Sofocleous/IT/CREDITSAFE]

Hi Markito,

Here in Creditsafe we are planning to lift oracles stored procedures up to the 
geode cluster running as Functions.
Could you please assists us by providing best practices , or any demo related 
to this.
If you are not aware of this particular application , I would appreciate it you 
can provide any contact details of somebody
might experience on running SP on cluster.

Thanks
Marios
Notes:
Terms and Conditions: 'All quotes, offers, contracts and agreements verbal or 
written are subject to our Standard Terms and Conditions as displayed on our 
website www.creditsafeuk.com and detailed in the Order Confirmation, quotation 
or invoice. Nothing in this correspondence shall be taken to vary our standard 
Terms and Conditions unless written confirmation is received from a Senior 
Creditsafe Director or the UK & Ireland Legal Manager' 
 
Disclaimer: This e-mail is confidential and intended solely for the use of the 
individual to whom it is addressed. Any views or opinions presented are solely 
those of the author and do not represent those of Creditsafe. If you are not 
the intended recipient, be advised that you have received this mail in error 
and that any use, dissemination, forwarding, printing or copying of this e-mail 
is strictly prohibited.
 
Please Note: Telephone calls and Emails may be recorded or monitored and used 
for training and quality control purposes. Creditsafe reserve the right to use 
these recordings to aid the resolution of any disputes that may arise.
 
Creditsafe Registered name: Creditsafe Business Solutions Limited. Registered 
in Wales: Company Number 03836192. Registered Address: Bryn House, Caerphilly 
Business Park, Van Road, Caerphilly,
CF83 3GG.

Build failed in Jenkins: Geode-nightly-flaky #72

[Apache Jenkins Server]

See 


Changes:

[jstewart] GEODE-3217: Reimplement gfsh query as a single-step command

[jiliao] GEODE-393: GetRegionFunction uses the cache in the FunctionContext

[jiliao] GEODE-3231: do not use temporary folder as workingdir or log to file by

[jiliao] GEODE-393: revert - GetRegionFunction uses the cache in the

[gzhou] GEODE-3206 : Corrected order of lucene search results based on score.

[ukohlmeyer] GEODE-3213: Refactor ProtoBuf handler flow. This now closes #646

[upthewaterspout] GEODE-2900: DUnit test of moving primary during AEQ 
dispatching

--
[...truncated 98.27 KB...]
Download 
https://repo1.maven.org/maven2/io/springfox/springfox-spring-web/2.6.1/springfox-spring-web-2.6.1.pom
Download 
https://repo1.maven.org/maven2/com/fasterxml/classmate/1.3.1/classmate-1.3.1.pom
Download 
https://repo1.maven.org/maven2/org/springframework/plugin/spring-plugin-core/1.2.0.RELEASE/spring-plugin-core-1.2.0.RELEASE.pom
Download 
https://repo1.maven.org/maven2/org/springframework/plugin/spring-plugin/1.2.0.RELEASE/spring-plugin-1.2.0.RELEASE.pom
Download 
https://repo1.maven.org/maven2/org/springframework/plugin/spring-plugin-metadata/1.2.0.RELEASE/spring-plugin-metadata-1.2.0.RELEASE.pom
Download 
https://repo1.maven.org/maven2/org/mapstruct/mapstruct/1.0.0.Final/mapstruct-1.0.0.Final.pom
Download 
https://repo1.maven.org/maven2/org/mapstruct/mapstruct-parent/1.0.0.Final/mapstruct-parent-1.0.0.Final.pom
Download 
https://repo1.maven.org/maven2/io/springfox/springfox-core/2.6.1/springfox-core-2.6.1.pom
Download 
https://repo1.maven.org/maven2/com/fasterxml/jackson/module/jackson-module-scala_2.10/2.8.6/jackson-module-scala_2.10-2.8.6.jar
Download 
https://repo1.maven.org/maven2/io/springfox/springfox-swagger2/2.6.1/springfox-swagger2-2.6.1.jar
Download 
https://repo1.maven.org/maven2/io/springfox/springfox-swagger-ui/2.6.1/springfox-swagger-ui-2.6.1.jar
Download 
https://repo1.maven.org/maven2/org/springframework/hateoas/spring-hateoas/0.23.0.RELEASE/spring-hateoas-0.23.0.RELEASE.jar
Download 
https://repo1.maven.org/maven2/com/fasterxml/jackson/module/jackson-module-paranamer/2.8.6/jackson-module-paranamer-2.8.6.jar
Download 
https://repo1.maven.org/maven2/io/swagger/swagger-annotations/1.5.10/swagger-annotations-1.5.10.jar
Download 
https://repo1.maven.org/maven2/io/swagger/swagger-models/1.5.10/swagger-models-1.5.10.jar
Download 
https://repo1.maven.org/maven2/io/springfox/springfox-spi/2.6.1/springfox-spi-2.6.1.jar
Download 
https://repo1.maven.org/maven2/io/springfox/springfox-schema/2.6.1/springfox-schema-2.6.1.jar
Download 
https://repo1.maven.org/maven2/io/springfox/springfox-swagger-common/2.6.1/springfox-swagger-common-2.6.1.jar
Download 
https://repo1.maven.org/maven2/io/springfox/springfox-spring-web/2.6.1/springfox-spring-web-2.6.1.jar
Download 
https://repo1.maven.org/maven2/org/springframework/plugin/spring-plugin-core/1.2.0.RELEASE/spring-plugin-core-1.2.0.RELEASE.jar
Download 
https://repo1.maven.org/maven2/org/springframework/plugin/spring-plugin-metadata/1.2.0.RELEASE/spring-plugin-metadata-1.2.0.RELEASE.jar
Download 
https://repo1.maven.org/maven2/org/mapstruct/mapstruct/1.0.0.Final/mapstruct-1.0.0.Final.jar
Download 
https://repo1.maven.org/maven2/com/thoughtworks/paranamer/paranamer/2.8/paranamer-2.8.jar
Download 
https://repo1.maven.org/maven2/io/springfox/springfox-core/2.6.1/springfox-core-2.6.1.jar
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
:geode-web-api:processResources
:geode-web-api:classes
:geode-assembly:docs
:geode-assembly:gfshDepsJar
:geode-common:javadocJar
:geode-common:sourcesJar
:geode-common:signArchives SKIPPED
:geode-core:javadocJar
:geode-core:raJar
:geode-core:jcaJar
:geode-core:sourcesJar
:geode-core:signArchives SKIPPED
:geode-core:webJar
:geode-cq:jar
:geode-cq:javadoc
:geode-cq:javadocJar
:geode-cq:sourcesJar
:geode-cq:signArchives SKIPPED
:geode-json:javadocJar
:geode-json:sourcesJar
:geode-json:signArchives SKIPPED
:geode-lucene:jar
:geode-lucene:javadoc
:geode-lucene:javadocJar
:geode-lucene:sourcesJar
:geode-lucene:signArchives SKIPPED
:geode-old-client-support:jar
:geode-old-client-support:javadoc
:geode-old-client-support:javadocJar
:geode-old-client-support:sourcesJar
:geode-old-client-support:signArchives SKIPPED
:geode-protobuf:jar
:geode-protobuf:javadoc
:geode-protobuf:javadocJar
:geode-protobuf:sourcesJar
:geode-protobuf:signArchives SKIPPED
:geode-pulse:javadoc
:geode-pulse:javadocJar
:geode-pulse:sourcesJar
:geode-pulse:war
:geode-pulse:signArchives SKIPPED
:geode-rebalancer:jar
:geode-rebalancer:javadoc
:geode-rebalancer:javadocJar
:geode-rebalancer:sourcesJar
:geode-rebalancer:signArchives SKIPPED
:geode-wan:jar
:geode-wan:javadoc
:geode-wan:javadocJar
:geode-wan:sourcesJar
:geode-wan:signArchives SKIPPED
:geode-web:javadoc UP-TO-DATE
:geode-web:javadocJar
:g

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

[Apache Jenkins Server]

See 

[GitHub] geode pull request #506: GEODE-2900: DUnit test of moving primary during AEQ...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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 #646: GEODE-3213: Refactor ProtoBuf handler flow

[asfgit]

Github user asfgit closed the pull request at:

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


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

[GitHub] geode issue #647: GEODE-3271: Refactor WanCommands

[YehEmily]

Github user YehEmily commented on the issue:

https://github.com/apache/geode/pull/647
  
@PurelyApplied Updated! Thanks for the feedback!


---
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 #648: GEODE-3206 : Corrected order of lucene search resul...

[asfgit]

Github user asfgit closed the pull request at:

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


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

[GitHub] geode issue #643: GEODE-3192,GEODE-3229: Change API and implementation of pr...

[PurelyApplied]

Github user PurelyApplied commented on the issue:

https://github.com/apache/geode/pull/643
  
If you are using IntelliJ as your IDE, please remember to update your style 
file to that located in `geode/etc/intellij-java-modified-google-style.xml` to 
be consistent with Geode's established style guide.  This file was updated June 
13 with commit `a561bd12` to be consistent with documented expectations.  If 
you are using Eclipse, please import both style guide files, also located in 
`geode/etc/`.

After having done so, please optimize the imports to the correct order in 
each of the `.java` files touched. 



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

[GitHub] geode issue #646: GEODE-3213: Refactor ProtoBuf handler flow

[PurelyApplied]

Github user PurelyApplied commented on the issue:

https://github.com/apache/geode/pull/646
  
If you are using IntelliJ as your IDE, please remember to update your style 
file to that located in `geode/etc/intellij-java-modified-google-style.xml` to 
be consistent with Geode's established style guide.  This file was updated June 
13 with commit `a561bd12` to be consistent with documented expectations.  If 
you are using Eclipse, please import both style guidefiles, also located in 
`geode/etc/`.

After having done so, please optimize the imports to the correct order and 
to eliminate the use of the wildcard imports from the 25 offending files this 
pull request touches. 



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

[GitHub] geode issue #647: GEODE-3271: Refactor WanCommands

[PurelyApplied]

Github user PurelyApplied commented on the issue:

https://github.com/apache/geode/pull/647
  
+1 as it stands.

Unimportant nitpicks, rambling observations, and "it could be even better 
if...":

* `punePort` appears in these tests a lot.  I have no idea what `pune` is 
supposed to mean.  Maybe `dsIdPort` would be better, glancing at the 
implementation of `createFirstLocatorWithDSId`?

* There are five instances in `WANCommandsTestBase` that has a loop like 
this

```
for (GatewaySender s : senders) {
  if (s.getId().equals(senderId)) {
sender = (AbstractGatewaySender) s;
break;
  }
}
```

that my hatred of `break` as function control thinks it would read a lot 
better as 

```
AbstractGatewaySender sender =
(AbstractGatewaySender) senders.stream().filter(s -> 
s.getId().equalsIgnoreCase(senderId)).findFirst().orElse(null);
```
* I'd take the Inspection-suggested change in `WANCommandBaseTest.java:489` 
to turn the string `indexOf(...) != -1` to be `contains(...)`.


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

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

[Spring CI]

---
Spring Data GemFire > Nightly-ApacheGeode > #623 was successful.
---
Scheduled
1986 tests in total.

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





--
This message is automatically generated by Atlassian Bamboo

Re: Geode PR pile up

[Xiaojian Zhou]

I'm merging PR 648 now

On Fri, Jul 21, 2017 at 3:32 PM, Jacob Barrett  wrote:

> All,
>
> I followed up on the issue regarding abandoned PRs. The only way to close
> them if the user has walked away is to do an empty commit. Thanks to Mark
> for finding this ticket with explanation
> https://issues.apache.org/jira/browse/INFRA-13690 and instructions on how
> to do it.
>
> I would say any PR that goes unanswered for a reasonable period should get
> closed out. Please make attempts to get the user to close them if we can
> though.
>
> -Jake
>
> On Thu, Jul 20, 2017 at 10:01 AM Udo Kohlmeyer 
> wrote:
>
> > Hi there fellow Geode devs.
> >
> > I've just been cleaning up some PR's, and I'm seeing that we 33 odd PR's
> > open, 20 of them older than 30 days.
> >
> > Not beat on the pedantic drum, but it would be really nice to have the
> > PR's either applied, addressed or closed(rejected).
> >
> > Does anyone have any ideas how we can keep our PR backlog small and
> > manageable vs a backlog that keeps on growing.
> >
> > --Udo
> >
> >
>

Re: Geode PR pile up

[Jacob Barrett]

All,

I followed up on the issue regarding abandoned PRs. The only way to close
them if the user has walked away is to do an empty commit. Thanks to Mark
for finding this ticket with explanation
https://issues.apache.org/jira/browse/INFRA-13690 and instructions on how
to do it.

I would say any PR that goes unanswered for a reasonable period should get
closed out. Please make attempts to get the user to close them if we can
though.

-Jake

On Thu, Jul 20, 2017 at 10:01 AM Udo Kohlmeyer  wrote:

> Hi there fellow Geode devs.
>
> I've just been cleaning up some PR's, and I'm seeing that we 33 odd PR's
> open, 20 of them older than 30 days.
>
> Not beat on the pedantic drum, but it would be really nice to have the
> PR's either applied, addressed or closed(rejected).
>
> Does anyone have any ideas how we can keep our PR backlog small and
> manageable vs a backlog that keeps on growing.
>
> --Udo
>
>

Fixed: apache/geode#3235 (develop - 56d964f)

[Travis CI]

Build Update for apache/geode
-

Build: #3235
Status: Fixed

Duration: 18 minutes and 49 seconds
Commit: 56d964f (develop)
Author: Jinmei Liao
Message: GEODE-393: revert - GetRegionFunction uses the cache in the 
FunctionContext

View the changeset: 
https://github.com/apache/geode/compare/0ea489ea52bb...56d964f867cd

View the full build log and details: 
https://travis-ci.org/apache/geode/builds/256221030?utm_source=email&utm_medium=notification

--

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

Broken: apache/geode#3233 (develop - 0ea489e)

[Travis CI]

Build Update for apache/geode
-

Build: #3233
Status: Broken

Duration: 10 minutes and 25 seconds
Commit: 0ea489e (develop)
Author: Jinmei Liao
Message: GEODE-3231: do not use temporary folder as workingdir or log to file 
by default when using the member starter rules

* do not create a workingDir and sets the user.dir by default for 
Locator/ServerStarterRule
* do not use a temp folder for all vms workingDir by default when using 
LocatorServerStarterRule.
* only bounce the vm when changing the workingdir of vms, otherwise, just 
cleanup the persisted files after each test.

View the changeset: 
https://github.com/apache/geode/compare/5551b3feb1e8...0ea489ea52bb

View the full build log and details: 
https://travis-ci.org/apache/geode/builds/256204652?utm_source=email&utm_medium=notification

--

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

Broken: apache/geode#3232 (develop - 5551b3f)

[Travis CI]

Build Update for apache/geode
-

Build: #3232
Status: Broken

Duration: 11 minutes and 58 seconds
Commit: 5551b3f (develop)
Author: Jinmei Liao
Message: GEODE-393: GetRegionFunction uses the cache in the FunctionContext

View the changeset: 
https://github.com/apache/geode/compare/564a94b912e7...5551b3feb1e8

View the full build log and details: 
https://travis-ci.org/apache/geode/builds/256203154?utm_source=email&utm_medium=notification

--

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

Re: Review Request 60974: GEODE-3231: do not log to file by default when using the member starter rules

[Jinmei Liao]

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

(Updated July 21, 2017, 8:05 p.m.)


Review request for geode, Emily Yeh, Jared Stewart, Ken Howe, Kirk Lund, and 
Patrick Rhomberg.


Repository: geode


Description
---

* do not log to file by default, only when withLogInFile is called
* do not create a workingDir and sets the user.dir by default, only when 
withWorkingDir is called
* For LocatorServerStarterRule, also do not set the workingDir if not asked to, 
and only bounce the VM if the VM is started with a workingDir


Diffs
-

  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/DeployCommandRedeployDUnitTest.java
 e494bcdd8aab49864516d61ca1eee78b50a3e7ee 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/DeployCommandsDUnitTest.java
 846a8d9ab93de73e612a85a4efa781b6cc1ac4a1 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsDUnitTest.java
 045e13edc798f2bd3460dc17bbfeec28ac5022e4 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsIntegrationTest.java
 4ca625a436ad9d181f1fecd11afc7a0cf1157aa6 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsOnServerManagerDUnit.java
 a78b26fb560c17c96b794ecedc09e10c87766ef0 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsStatsDUnitTest.java
 33439e6063150b87938f21f13e647d3b0ecc4896 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsWithMemberGroupDUnitTest.java
 e5cca279d8a8082726fc67eab8a5cfd91ce90529 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ShowMissingDiskStoresDUnitTest.java
 766f25ada3b446df71d840d70bb6fae797a85a00 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/ExportLogsFunctionIntegrationTest.java
 d98641849eed458b4c830e1fa198f4d986b0c4ce 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/SizeExportLogsFunctionTest.java
 510a4e7fef1aff5a1aa8f00f569cd6422b7816ab 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/util/LogExporterIntegrationTest.java
 a8b498ddbecb9d8733ed4f98c1c80cb18da5c37e 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/util/MergeLogsDUnitTest.java
 9166642044055071b2cced88edfe3ae660976ef7 
  
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigDeployJarDUnitTest.java
 3b105a4e412542160e763d7016970e10e8c2adcf 
  
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigDistributionDUnitTest.java
 4b003a8b2b4b0ac1df19f851be23b3442fca975f 
  
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigImportDUnitTest.java
 066f8828f64b7caa9c9748683f9214868105fed8 
  
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigStartMemberDUnitTest.java
 c84a7c12f62a5ee28fec24aa82ba7da6f62a7d3d 
  
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigTestBase.java
 fd8fb46f44edcea2a068ec47d2a8577c933fd319 
  
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigWithSecurityDUnitTest.java
 bb45b0d9acbed901fa17ef39d1bb0ca1153e0458 
  
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ImportClusterConfigDistributedTest.java
 4274d677d6d06a6f9b14dd362fef9d8fcd10f410 
  
geode-core/src/test/java/org/apache/geode/management/internal/security/MemberMBeanSecurityJUnitTest.java
 e6b50d210dad844aca5e37fcb3cf58d7aace4b3e 
  
geode-core/src/test/java/org/apache/geode/security/ClusterConfigWithoutSecurityDUnitTest.java
 e90bc0a69222998322e02fcfad1b6bad3c97f4d1 
  
geode-core/src/test/java/org/apache/geode/security/PDXPostProcessorDUnitTest.java
 c4a25470bab75a2fdfcdb55126564d21ecd9403d 
  
geode-core/src/test/java/org/apache/geode/security/PeerAuthenticatorDUnitTest.java
 b977b50e28b8d518fd3d9da6c03b55f8b7cbff34 
  
geode-core/src/test/java/org/apache/geode/test/dunit/rules/LocatorServerStartupRule.java
 62ae2e223f019c78000ff7492510c24aba9c930c 
  
geode-core/src/test/java/org/apache/geode/test/dunit/rules/MemberStarterRule.java
 226fd6c24bb1ef818fd2de2bd010d713b59872e8 
  geode-core/src/test/java/org/apache/geode/test/dunit/rules/MemberVM.java 
7e5ce1f1e41eff125c5d2e75f389f5ea8b1f90ed 
  
geode-core/src/test/java/org/apache/geode/test/dunit/rules/ServerStarterRule.java
 6ea2d0336f74956ff81efee94fc1ac2504383520 
  
geode-core/src/test/java/org/apache/geode/test/dunit/rules/test/MemberStarterRuleTest.java
 7dada04cc63aaa2668e103524bd63d3c58310257 
  
geode-lucene/src/test/java/org/apache/geode/cache/lucene/internal/configuration/LuceneClusterConfigurationDUnitTest.java
 cac45ebb5b68227

[GitHub] geode pull request #649: GEODE-2997: Change new protocol GetAllResponse.

[kohlmu-pivotal]

Github user kohlmu-pivotal commented on a diff in the pull request:

https://github.com/apache/geode/pull/649#discussion_r128848930
  
--- Diff: geode-protobuf/src/main/proto/basicTypes.proto ---
@@ -62,4 +62,14 @@ message Region {
 
 message Server {
 string url = 1;
-}
\ No newline at end of file
+}
+
+message Error {
+int32 errorCode = 1;
+string message = 2;
+}
+
+message ErrorEntry {
--- End diff --

Tbh, I'm not ecstatic about the name. I'd prefer `FailedEntry`


---
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 #649: GEODE-2997: Change new protocol GetAllResponse.

[kohlmu-pivotal]

Github user kohlmu-pivotal commented on a diff in the pull request:

https://github.com/apache/geode/pull/649#discussion_r128847166
  
--- Diff: geode-protobuf/src/main/proto/clientProtocol.proto ---
@@ -66,7 +66,7 @@ message Response {
 RemoveAllResponse removeAllResponse = 7;
 ListKeysResponse listKeysResponse = 8;
 
-ErrorResponse errorResponse = 13;
+Error error = 13;
--- End diff --

Why has this been renamed to Error from ErrorResponse? Imo, we are 
following the pattern (good or bad) that a ClientProtocol.Response contains an 
Operation specific response. To now have a non-"Response" message sort of 
breaks the mold.


---
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 60935: GEODE-3115 Added changes to check for persistent region during pdx type registry.

[anilkumar gingade]

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

(Updated July 21, 2017, 7:18 p.m.)


Review request for geode, Darrel Schneider, Eric Shu, Lynn Gallinat, and Nick 
Reich.


Changes
---

Changes as suggested in review comments.


Repository: geode


Description
---

The pdx registry needs to be persisted to use pdx with persistent region. 
Currently while creating pdx the system checks, to see if there is a disk store 
with data instead of looking for persistent region in the system. In cases 
where persistent region is created and dropped, the system doesn't allow 
creating pdx witout setting pdx persistence.


Diffs (updated)
-

  
geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java 
de5fd88 
  geode-core/src/main/java/org/apache/geode/internal/cache/InternalCache.java 
aed439c 
  
geode-core/src/main/java/org/apache/geode/internal/cache/xmlcache/CacheCreation.java
 db5f7ca 
  
geode-core/src/main/java/org/apache/geode/pdx/internal/PeerTypeRegistration.java
 065255b 
  geode-core/src/test/java/org/apache/geode/pdx/PdxAttributesJUnitTest.java 
ef15cd5 


Diff: https://reviews.apache.org/r/60935/diff/2/

Changes: https://reviews.apache.org/r/60935/diff/1-2/


Testing
---

Added new test.
Precheckin started.


Thanks,

anilkumar gingade

[GitHub] geode issue #580: GEODE-2936: Refactoring OrderByComparator

[YehEmily]

Github user YehEmily commented on the issue:

https://github.com/apache/geode/pull/580
  
@jhuynh1 Thanks for the suggestion! I updated the tests in 
`OrderByComparatorJUnitTest.java` to cover all the cases in 
`OrderByComparator.java` and updated the PR.


---
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 61042: GEODE-3214: Remove support for multistep gfsh commands.

[Jinmei Liao]

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


Ship it!




Ship It!

- Jinmei Liao


On July 21, 2017, 5:36 p.m., Jared Stewart wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/61042/
> ---
> 
> (Updated July 21, 2017, 5:36 p.m.)
> 
> 
> Review request for geode, Emily Yeh, Jared Stewart, Ken Howe, Kirk Lund, and 
> Patrick Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-3214: Remove support for multistep gfsh commands.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/i18n/CliStrings.java
>  5621b2497050d6a1003078dc993861a90fad4000 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/multistep/CLIMultiStepHelper.java
>  4eeb2279cc041adbd12127a5ad68e862a6e72871 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/multistep/CLIRemoteStep.java
>  4c38a313f7b6b7244c092dd4363c778bb810e18c 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/multistep/CLIStep.java
>  a037f518a89258bc5e6da00f42f6c7b102bc0e2c 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/multistep/CLIStepExecption.java
>  389e72f4f91dd8a30e4086391d3c882e003943f3 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/multistep/MultiStepCommand.java
>  75925f782b54c5d55c8fb921b803cf7ae4443252 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/remote/RemoteExecutionStrategy.java
>  89cb9adee00b72c3775896a5f553256205a0b7cb 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/shell/GfshExecutionStrategy.java
>  1cbdb157d2e65a5976edd906f9db82272caad4c4 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/support/LoginHandlerInterceptor.java
>  5e502f55e781a5bf3a656d17d0156175088891b2 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/web/http/ClientHttpRequest.java
>  43657b9888d7e588d2d6e55584671478940c1d28 
> 
> 
> Diff: https://reviews.apache.org/r/61042/diff/1/
> 
> 
> Testing
> ---
> 
> Precheckin running
> 
> 
> Thanks,
> 
> Jared Stewart
> 
>

[GitHub] geode pull request #650: GEODE-3253: Refactoring ClientCommands and related ...

[YehEmily]

GitHub user YehEmily opened a pull request:

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

GEODE-3253: Refactoring ClientCommands and related tests

[View the JIRA ticket 
here.](https://issues.apache.org/jira/browse/GEODE-3253)

`ClientCommands.java` was a large class that contained multiple commands. 
In this PR, each command was refactored into a separate class. 
`ClientCommandsDUnitTest.java` was also refactored and split into 
`DescribeClientCommandDUnitTest.java` and `ListClientCommandDUnitTest.java`. 
Methods shared by these two tests were moved into a new class, 
`ClientCommandsTestUtils.java`.

- [x] JIRA Ticket referenced

- [x] PR rebased against develop

- [x] Initial contribution is a single squashed commit

- [x] `gradlew build` runs cleanly

- [x] Tests updated to verify changes

**Testing status**: **Precheckin currently running**

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

$ git pull https://github.com/YehEmily/geode GEODE-3253

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

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


commit bf623e78ed44621f3efd6e5884f3d97d0cac31ee
Author: YehEmily 
Date:   2017-07-20T23:54:22Z

GEODE-3253: Refactoring ClientCommands and related tests




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

Review Request 61042: GEODE-3214: Remove support for multistep gfsh commands.

[Jared Stewart]

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

Review request for geode, Emily Yeh, Jared Stewart, Ken Howe, Kirk Lund, and 
Patrick Rhomberg.


Repository: geode


Description
---

GEODE-3214: Remove support for multistep gfsh commands.


Diffs
-

  
geode-core/src/main/java/org/apache/geode/management/internal/cli/i18n/CliStrings.java
 5621b2497050d6a1003078dc993861a90fad4000 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/multistep/CLIMultiStepHelper.java
 4eeb2279cc041adbd12127a5ad68e862a6e72871 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/multistep/CLIRemoteStep.java
 4c38a313f7b6b7244c092dd4363c778bb810e18c 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/multistep/CLIStep.java
 a037f518a89258bc5e6da00f42f6c7b102bc0e2c 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/multistep/CLIStepExecption.java
 389e72f4f91dd8a30e4086391d3c882e003943f3 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/multistep/MultiStepCommand.java
 75925f782b54c5d55c8fb921b803cf7ae4443252 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/remote/RemoteExecutionStrategy.java
 89cb9adee00b72c3775896a5f553256205a0b7cb 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/shell/GfshExecutionStrategy.java
 1cbdb157d2e65a5976edd906f9db82272caad4c4 
  
geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/support/LoginHandlerInterceptor.java
 5e502f55e781a5bf3a656d17d0156175088891b2 
  
geode-core/src/main/java/org/apache/geode/management/internal/web/http/ClientHttpRequest.java
 43657b9888d7e588d2d6e55584671478940c1d28 


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


Testing
---

Precheckin running


Thanks,

Jared Stewart

Jenkins build is back to normal : Geode-release-flaky #28

[Apache Jenkins Server]

See 

[GitHub] geode pull request #646: GEODE-3213: Refactor ProtoBuf handler flow

[kohlmu-pivotal]

Github user kohlmu-pivotal commented on a diff in the pull request:

https://github.com/apache/geode/pull/646#discussion_r128814031
  
--- Diff: 
geode-protobuf/src/main/java/org/apache/geode/protocol/protobuf/OperationContext.java
 ---
@@ -0,0 +1,57 @@
+/*
+ * 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.protocol.protobuf;
+
+import org.apache.geode.protocol.operations.OperationHandler;
+
+import java.util.function.Function;
+
+public class OperationContext {
--- End diff --

+1


---
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 60974: GEODE-3231: do not log to file by default when using the member starter rules

[Jinmei Liao]

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

(Updated July 21, 2017, 5:11 p.m.)


Review request for geode, Emily Yeh, Jared Stewart, Ken Howe, Kirk Lund, and 
Patrick Rhomberg.


Changes
---

Now only a handful of our tests will change the user.dir, for Dunit tests, this 
won't be a problem since we would bounce the VM afterwards if we did change it. 
Integration tests that still calls .withLogFile can be a problem. we can change 
it to be DUnit test if we want to.


Repository: geode


Description
---

* do not log to file by default, only when withLogInFile is called
* do not create a workingDir and sets the user.dir by default, only when 
withWorkingDir is called
* For LocatorServerStarterRule, also do not set the workingDir if not asked to, 
and only bounce the VM if the VM is started with a workingDir


Diffs (updated)
-

  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/DeployCommandRedeployDUnitTest.java
 e494bcdd8aab49864516d61ca1eee78b50a3e7ee 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/DeployCommandsDUnitTest.java
 846a8d9ab93de73e612a85a4efa781b6cc1ac4a1 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsDUnitTest.java
 045e13edc798f2bd3460dc17bbfeec28ac5022e4 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsIntegrationTest.java
 4ca625a436ad9d181f1fecd11afc7a0cf1157aa6 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsOnServerManagerDUnit.java
 a78b26fb560c17c96b794ecedc09e10c87766ef0 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsStatsDUnitTest.java
 33439e6063150b87938f21f13e647d3b0ecc4896 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsWithMemberGroupDUnitTest.java
 e5cca279d8a8082726fc67eab8a5cfd91ce90529 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ShowMissingDiskStoresDUnitTest.java
 766f25ada3b446df71d840d70bb6fae797a85a00 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/ExportLogsFunctionIntegrationTest.java
 d98641849eed458b4c830e1fa198f4d986b0c4ce 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/SizeExportLogsFunctionTest.java
 510a4e7fef1aff5a1aa8f00f569cd6422b7816ab 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/util/LogExporterIntegrationTest.java
 a8b498ddbecb9d8733ed4f98c1c80cb18da5c37e 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/util/MergeLogsDUnitTest.java
 9166642044055071b2cced88edfe3ae660976ef7 
  
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigDeployJarDUnitTest.java
 3b105a4e412542160e763d7016970e10e8c2adcf 
  
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigDistributionDUnitTest.java
 4b003a8b2b4b0ac1df19f851be23b3442fca975f 
  
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigImportDUnitTest.java
 066f8828f64b7caa9c9748683f9214868105fed8 
  
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigStartMemberDUnitTest.java
 c84a7c12f62a5ee28fec24aa82ba7da6f62a7d3d 
  
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigTestBase.java
 fd8fb46f44edcea2a068ec47d2a8577c933fd319 
  
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigWithSecurityDUnitTest.java
 bb45b0d9acbed901fa17ef39d1bb0ca1153e0458 
  
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ImportClusterConfigDistributedTest.java
 4274d677d6d06a6f9b14dd362fef9d8fcd10f410 
  
geode-core/src/test/java/org/apache/geode/management/internal/security/MemberMBeanSecurityJUnitTest.java
 e6b50d210dad844aca5e37fcb3cf58d7aace4b3e 
  
geode-core/src/test/java/org/apache/geode/security/ClusterConfigWithoutSecurityDUnitTest.java
 e90bc0a69222998322e02fcfad1b6bad3c97f4d1 
  
geode-core/src/test/java/org/apache/geode/security/PDXPostProcessorDUnitTest.java
 c4a25470bab75a2fdfcdb55126564d21ecd9403d 
  
geode-core/src/test/java/org/apache/geode/security/PeerAuthenticatorDUnitTest.java
 b977b50e28b8d518fd3d9da6c03b55f8b7cbff34 
  
geode-core/src/test/java/org/apache/geode/test/dunit/rules/LocatorServerStartupRule.java
 62ae2e223f019c78000ff7492510c24aba9c930c 
  
geode-core/src/test/java/org/apache/geode/test/dunit/rules/MemberStarterRule.java
 226fd6c24bb1ef818fd2de2bd010d713b59872e8 
  geode-core/src/test/java/org/apache/geode/test/dunit/rules/MemberVM.java 
7e5ce1f1e41eff125c5d2e75f389f5ea8b1f90ed 
  
geode-core/src/test/java/org/apache/geode/test/dunit/rules/ServerStarterRule.java
 6ea2d0336f74

[GitHub] geode pull request #646: GEODE-3213: Refactor ProtoBuf handler flow

[galen-pivotal]

Github user galen-pivotal commented on a diff in the pull request:

https://github.com/apache/geode/pull/646#discussion_r128811946
  
--- Diff: 
geode-protobuf/src/main/java/org/apache/geode/protocol/protobuf/OperationContext.java
 ---
@@ -0,0 +1,57 @@
+/*
+ * 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.protocol.protobuf;
+
+import org.apache.geode.protocol.operations.OperationHandler;
+
+import java.util.function.Function;
+
+public class OperationContext {
--- End diff --

I think it makes more sense to have these be implementations of an 
interface, since they're acting as an immutable collection of functions.


---
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 #646: GEODE-3213: Refactor ProtoBuf handler flow

[galen-pivotal]

Github user galen-pivotal commented on a diff in the pull request:

https://github.com/apache/geode/pull/646#discussion_r128811551
  
--- Diff: 
geode-protobuf/src/main/java/org/apache/geode/protocol/protobuf/utilities/ProtobufResponseUtilities.java
 ---
@@ -35,10 +37,9 @@
* @param errorMessage - description of the error
* @return An error response containing the above parameters
*/
-  public static ClientProtocol.Response createErrorResponse(String 
errorMessage) {
-ClientProtocol.ErrorResponse error =
-
ClientProtocol.ErrorResponse.newBuilder().setMessage(errorMessage).build();
-return 
ClientProtocol.Response.newBuilder().setErrorResponse(error).build();
+  public static Failure createFailureResult(String errorMessage) {
--- End diff --

@pivotal-amurmann @kohlmu-pivotal Did this get addressed?


---
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: Avoid mutating standard Java System Properties (even in tests)

[Kirk Lund]

There is no issue with setting GemFire-specific System Properties. Feel
free to use those. I'm talking about changing the values of System
Properties set by the JVM such as "user.dir" -- mutating or clearing these
values can cause weird bugs in the JDK or 3rd party libraries that are
harder to debug.

On Thu, Jul 20, 2017 at 7:33 PM, Galen O'Sullivan 
wrote:

> I have had a lot of tests fail because mcast-port is nonzero. So now I set
> that system property in a lot of new tests. Maybe the tests that set it to
> something other than the default should be passing a Properties object to
> CacheFactory rather than messing with system properties.
>
> I think the Cache configuration step should happen before the Cache starts.
> This way we can start the Cache with a configuration object and keep *all*
> XML parsing, system property reading, and the like out of core code. This
> way we can get system properties out of our tests, and have more confidence
> in our ability to test clean and reliable configurations.
>
> Granted, I'm not messing with core configuration, so it looks like the
> problems you're seeing may be of a bit of a different class from the ones
> I'm seeing.
>
> On Thu, Jul 20, 2017 at 11:45 AM, Jared Stewart 
> wrote:
>
> > Indeed, this is frowned upon by the JDK authors: http://bugs.java.com/
> > bugdatabase/view_bug.do?bug_id=4045688  > bugdatabase/view_bug.do?bug_id=4045688>
> >
> > In the long term, we need to change our code to no longer assume that
> > “user.dir” is the working directory of a given server/locator.  That
> > current assumption is what necessitates setting “user.dir” for certain
> > tests.
> >
> > In the interim, I added some time ago code (see MemberVM#stopMember) that
> > will automatically bounce any DUnit VM’s started by
> > LocatorServerStarterRule (the distributed version of MemberStarterRule)
> > that have swizzled “user.dir”.
> >
> > For non-dunit tests that change “user.dir”, I think the correct
> mitigation
> > is to include a RestoreSystemProperties rule.
> >
> > I completely agree that we should only dynamically change “user.dir” as
> an
> > option of last resort.
> >
> > - Jared
> >
> > > On Jul 20, 2017, at 11:33 AM, Kirk Lund  wrote:
> > >
> > > We found the cause of DiskStoreMXBeanSecurityJUnitTest failing in CI:
> > > https://issues.apache.org/jira/browse/GEODE-3251.
> > >
> > > I think we should avoid setting or clearing any standard Java System
> > > properties during runtime (even in tests). These are the properties
> that
> > > JVM automatically sets:
> > > https://docs.oracle.com/javase/tutorial/essential/
> > environment/sysprop.html.
> > >
> > > The alternative to swizzling something like "user.dir" at runtime is to
> > > always fork a JVM for any test that needs "user.dir" to point somewhere
> > > special.
> > >
> > > Hope this helps someone else to avoid a similar bug!
> > >
> > > GEODE-3251 is caused by:
> > >
> > > 1) The MemberStarterRule is swizzling the user.dir System property.
> > Jinmei
> > > has a pending change to not change the user.dir. In general, we should
> > > avoid changing that System property at runtime and only fork JVMs for
> > tests
> > > that need processes to run in a specific user.dir.
> > >
> > > 2) FastClasspathScanner throws NoSuchFileException because
> > > System.getProperty("user.dir") returns null. It's null because
> > > MemberStarterRule set it to null.
> > >
> > > 3) The call stack for ManagementAdapter#handleCacheCreation(
> > InternalCache)
> > > catches the NoSuchFileException and swallows it without logging it..
> The
> > > ManagementAgent then closes itself in the finally block of
> > > #handleCacheCreation.
> > >
> > > 4) When MBeanServerConnectionRule tries to connect to JMX RMI, it fails
> > > because JMX RMI was closed in #3 above. This throws IOException "Failed
> > to
> > > retrieve RMIServer stub".
> > >
> > > Here's the Exception stack trace that the Management Agent code was
> > > swallowing:
> > >
> > > java.lang.RuntimeException: java.lang.RuntimeException:
> > > java.nio.file.NoSuchFileException:
> > > /var/folders/28/m__9dv1906n60kmz7t71wm68gn/T/
> > junit7797861898628691451
> > > at
> > > io.github.lukehutch.fastclasspathscanner.FastClasspathScanner.scan(
> > FastClasspathScanner.java:1115)
> > > at
> > > io.github.lukehutch.fastclasspathscanner.FastClasspathScanner.scan(
> > FastClasspathScanner.java:1143)
> > > at
> > > io.github.lukehutch.fastclasspathscanner.FastClasspathScanner.scan(
> > FastClasspathScanner.java:1166)
> > > at
> > > org.apache.geode.management.internal.cli.util.ClasspathScanLoadHelper.
> > scanPackageForClassesImplementing(ClasspathScanLoadHelper.java:35)
> > > at
> > > org.apache.geode.management.internal.cli.CommandManager.
> > loadGeodeCommands(CommandManager.java:223)
> > > at
> > > org.apache.geode.management.internal.cli.CommandManager.
> > loadCommands(CommandManager.java:176)
> > > at
> > > org.apache.geode.management.internal.cli.Command

Re: Avoid mutating standard Java System Properties (even in tests)

[Jacob Barrett]

Come on guys, it's 2017 and we should not still be talking about using
system properties at all. I won't rant again about our prolific use of
system properties but I will rant on the testing using them. Unless your
test is a unit test that is asserting that your component picks up its
initial state from a system property then you should not be using system
properties at all. All other tests on this component should use the
component interface to set state and not system properties. Any test
dependent on this component should configure it via the API and not system
properties.

-Jake


On Thu, Jul 20, 2017 at 7:33 PM Galen O'Sullivan 
wrote:

> I have had a lot of tests fail because mcast-port is nonzero. So now I set
> that system property in a lot of new tests. Maybe the tests that set it to
> something other than the default should be passing a Properties object to
> CacheFactory rather than messing with system properties.
>
> I think the Cache configuration step should happen before the Cache starts.
> This way we can start the Cache with a configuration object and keep *all*
> XML parsing, system property reading, and the like out of core code. This
> way we can get system properties out of our tests, and have more confidence
> in our ability to test clean and reliable configurations.
>
> Granted, I'm not messing with core configuration, so it looks like the
> problems you're seeing may be of a bit of a different class from the ones
> I'm seeing.
>
> On Thu, Jul 20, 2017 at 11:45 AM, Jared Stewart 
> wrote:
>
> > Indeed, this is frowned upon by the JDK authors: http://bugs.java.com/
> > bugdatabase/view_bug.do?bug_id=4045688  > bugdatabase/view_bug.do?bug_id=4045688>
> >
> > In the long term, we need to change our code to no longer assume that
> > “user.dir” is the working directory of a given server/locator.  That
> > current assumption is what necessitates setting “user.dir” for certain
> > tests.
> >
> > In the interim, I added some time ago code (see MemberVM#stopMember) that
> > will automatically bounce any DUnit VM’s started by
> > LocatorServerStarterRule (the distributed version of MemberStarterRule)
> > that have swizzled “user.dir”.
> >
> > For non-dunit tests that change “user.dir”, I think the correct
> mitigation
> > is to include a RestoreSystemProperties rule.
> >
> > I completely agree that we should only dynamically change “user.dir” as
> an
> > option of last resort.
> >
> > - Jared
> >
> > > On Jul 20, 2017, at 11:33 AM, Kirk Lund  wrote:
> > >
> > > We found the cause of DiskStoreMXBeanSecurityJUnitTest failing in CI:
> > > https://issues.apache.org/jira/browse/GEODE-3251.
> > >
> > > I think we should avoid setting or clearing any standard Java System
> > > properties during runtime (even in tests). These are the properties
> that
> > > JVM automatically sets:
> > > https://docs.oracle.com/javase/tutorial/essential/
> > environment/sysprop.html.
> > >
> > > The alternative to swizzling something like "user.dir" at runtime is to
> > > always fork a JVM for any test that needs "user.dir" to point somewhere
> > > special.
> > >
> > > Hope this helps someone else to avoid a similar bug!
> > >
> > > GEODE-3251 is caused by:
> > >
> > > 1) The MemberStarterRule is swizzling the user.dir System property.
> > Jinmei
> > > has a pending change to not change the user.dir. In general, we should
> > > avoid changing that System property at runtime and only fork JVMs for
> > tests
> > > that need processes to run in a specific user.dir.
> > >
> > > 2) FastClasspathScanner throws NoSuchFileException because
> > > System.getProperty("user.dir") returns null. It's null because
> > > MemberStarterRule set it to null.
> > >
> > > 3) The call stack for ManagementAdapter#handleCacheCreation(
> > InternalCache)
> > > catches the NoSuchFileException and swallows it without logging it..
> The
> > > ManagementAgent then closes itself in the finally block of
> > > #handleCacheCreation.
> > >
> > > 4) When MBeanServerConnectionRule tries to connect to JMX RMI, it fails
> > > because JMX RMI was closed in #3 above. This throws IOException "Failed
> > to
> > > retrieve RMIServer stub".
> > >
> > > Here's the Exception stack trace that the Management Agent code was
> > > swallowing:
> > >
> > > java.lang.RuntimeException: java.lang.RuntimeException:
> > > java.nio.file.NoSuchFileException:
> > > /var/folders/28/m__9dv1906n60kmz7t71wm68gn/T/
> > junit7797861898628691451
> > > at
> > > io.github.lukehutch.fastclasspathscanner.FastClasspathScanner.scan(
> > FastClasspathScanner.java:1115)
> > > at
> > > io.github.lukehutch.fastclasspathscanner.FastClasspathScanner.scan(
> > FastClasspathScanner.java:1143)
> > > at
> > > io.github.lukehutch.fastclasspathscanner.FastClasspathScanner.scan(
> > FastClasspathScanner.java:1166)
> > > at
> > > org.apache.geode.management.internal.cli.util.ClasspathScanLoadHelper.
> > scanPackageForClassesImplementing(ClasspathScanLoadHelper.java:35)
> > > at

[GitHub] geode pull request #646: GEODE-3213: Refactor ProtoBuf handler flow

[pivotal-amurmann]

Github user pivotal-amurmann commented on a diff in the pull request:

https://github.com/apache/geode/pull/646#discussion_r128793895
  
--- Diff: 
geode-protobuf/src/main/java/org/apache/geode/protocol/protobuf/utilities/ProtobufResponseUtilities.java
 ---
@@ -50,47 +38,14 @@
* @param ex - exception which should be logged
* @return An error response containing the first three parameters.
*/
-  public static ClientProtocol.Response createAndLogErrorResponse(String 
errorMessage,
+  public static ClientProtocol.ErrorResponse 
createAndLogFailureResponse(String errorMessage,
--- End diff --

I think those were to changes that were made independently. Syncing this up 
right now


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

Build failed in Jenkins: Geode-release #79

[Apache Jenkins Server]

See 

--
[...truncated 1.19 MB...]
at org.jgroups.JChannel.connect(JChannel.java:288)
at org.jgroups.JChannel.connect(JChannel.java:279)
at 
org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger.start(JGroupsMessenger.java:342)
at 
org.apache.geode.distributed.internal.membership.gms.Services.start(Services.java:147)
at 
org.apache.geode.distributed.internal.membership.gms.GMSMemberFactory.newMembershipManager(GMSMemberFactory.java:102)
at 
org.apache.geode.distributed.internal.membership.MemberFactory.newMembershipManager(MemberFactory.java:89)
at 
org.apache.geode.distributed.internal.DistributionManager.(DistributionManager.java:1153)
at 
org.apache.geode.distributed.internal.DistributionManager.(DistributionManager.java:1201)
at 
org.apache.geode.distributed.internal.DistributionManager.create(DistributionManager.java:572)
at 
org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:697)
at 
org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:305)
at 
org.apache.geode.distributed.DistributedSystem.connect(DistributedSystem.java:205)
at 
org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:697)
at 
org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:324)
at org.apache.geode.distributed.Locator.startLocator(Locator.java:253)
at 
org.apache.geode.distributed.Locator.startLocatorAndDS(Locator.java:202)
at 
org.apache.geode.cache.client.internal.LocatorTestBase.startLocator(LocatorTestBase.java:131)
at 
org.apache.geode.cache.client.internal.LocatorTestBase$2.run(LocatorTestBase.java:142)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at hydra.MethExecutor.executeObject(MethExecutor.java:245)
at 
org.apache.geode.test.dunit.standalone.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:70)
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 sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:346)
at sun.rmi.transport.Transport$1.run(Transport.java:200)
at sun.rmi.transport.Transport$1.run(Transport.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
at 
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:568)
at 
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:826)
at 
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:683)
at java.security.AccessController.doPrivileged(Native Method)
at 
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:682)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:748)

org.apache.geode.cache.wan.GatewayReceiverAutoConnectionSourceDUnitTest > 
testBridgeServerAndGatewayReceiverClientWithoutGroupServerWithGroup FAILED
java.lang.AssertionError: Suspicious strings were written to the log during 
this run.
Fix the strings or use IgnoredException.addIgnoredException to ignore.
---
Found suspect string in log4j at line 379

[error 2017/07/21 13:58:31.668 UTC  
tid=0x13] failed setting interface to /127.0.1.1: java.net.SocketException: bad 
argument for IP_MULTICAST_IF: address not bound to any interface
java.net.SocketException: bad argument for IP_MULTICAST_IF: address not 
bound to any interface
at java.net.PlainDatagramSocketImpl.socketSetOption0(Native Method)
at 
java.net.PlainDatagramSocketImpl.socketSetOption(PlainDatagramSocketImpl.java:74)
at 
java.net.AbstractPlainDatagramSocketImpl.setOption(AbstractPlainDatagramSocketImpl.java:309)
at java.net.MulticastSocket.setInterface(MulticastSocket.java:471)
at org.jgroups.protocols.UDP.setInterface(UDP.java:443)
at org.jgroups.protocols.UDP.createMul