[jira] [Commented] (GEODE-5656) Upgrade build to use Gradle 4.10

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-5656:


Commit be5430d92966733fbdfe9d63e60bc7ef0168ea76 in geode's branch 
refs/heads/develop from Jacob Barrett
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=be5430d ]

GEODE-5656: Upgrades Gradle to 4.10 (#2397)



> Upgrade build to use Gradle 4.10
> 
>
> Key: GEODE-5656
> URL: https://issues.apache.org/jira/browse/GEODE-5656
> Project: Geode
>  Issue Type: Improvement
>  Components: build
>Reporter: Jacob S. Barrett
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> https://docs.gradle.org/4.10/release-notes.html



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GEODE-5636) DescribeClientCommandDUnitTest fails on Windows

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-5636:


Commit 238706c1c851a6ae8c11ed216354cf2599917256 in geode's branch 
refs/heads/develop from [~jens.deppe]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=238706c ]

GEODE-5636: DescribeClientCommandDUnitTest fails on Windows (#2382)



> DescribeClientCommandDUnitTest fails on Windows
> ---
>
> Key: GEODE-5636
> URL: https://issues.apache.org/jira/browse/GEODE-5636
> Project: Geode
>  Issue Type: Bug
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> The test was making incorrect assumptions about the order of `list members`
> {noformat}
> org.apache.geode.management.internal.cli.commands.DescribeClientCommandDUnitTest
>  > describeClient FAILED
> org.junit.ComparisonFailure: 
> expected:<"10.0.0.4([locator-0:9816:locator):32773 [Coordinator]]"> 
> but was:<"10.0.0.4([server-1:9292):32772]">
> 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.cli.commands.DescribeClientCommandDUnitTest.validateResults(DescribeClientCommandDUnitTest.java:144)
> at 
> org.apache.geode.management.internal.cli.commands.DescribeClientCommandDUnitTest.describeClient(DescribeClientCommandDUnitTest.java:103)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GEODE-5661) Pulse does not work when legacy SSL options are used

[Jens Deppe (JIRA)]

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

Jens Deppe updated GEODE-5661:
--
Description: 
Similar to GEODE-5230, if the legacy SSL configuration options are used, 
({{cluster-ssl-*}}, {{jmx-manager-ssl-*}}, etc.), then Pulse does not work 
correctly and a user will see an error similar to the following in the UI:
{noformat}
Failed to retrieve RMIServer stub: javax.naming.CommunicationException [Root 
exception is java.rmi.ConnectIOException: error during JRMP connection 
establishment; nested exception is: javax.net.ssl.SSLHandshakeException: 
sun.security.validator.ValidatorException: PKIX path building failed: 
sun.security.provider.certpath.SunCertPathBuilderException: unable to find 
valid certification path to requested target]
{noformat}

  was:
Similar to GEODE-5230, if the legacy SSL configuration options are used, 
({{cluster-ssl-*}}, {{jmx-manager-ssl-*}}, etc.), then Pulse does not work 
correctly and a user will see an error similar to the following in the UI:
{noformat}

{noformat}


> Pulse does not work when legacy SSL options are used
> 
>
> Key: GEODE-5661
> URL: https://issues.apache.org/jira/browse/GEODE-5661
> Project: Geode
>  Issue Type: Bug
>  Components: pulse
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
>
> Similar to GEODE-5230, if the legacy SSL configuration options are used, 
> ({{cluster-ssl-*}}, {{jmx-manager-ssl-*}}, etc.), then Pulse does not work 
> correctly and a user will see an error similar to the following in the UI:
> {noformat}
> Failed to retrieve RMIServer stub: javax.naming.CommunicationException [Root 
> exception is java.rmi.ConnectIOException: error during JRMP connection 
> establishment; nested exception is: javax.net.ssl.SSLHandshakeException: 
> sun.security.validator.ValidatorException: PKIX path building failed: 
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find 
> valid certification path to requested target]
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Reopened] (GEODE-5230) Pulse does not work when SSL is enabled for JMX

[Jens Deppe (JIRA)]

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

Jens Deppe reopened GEODE-5230:
---
  Assignee: Jens Deppe

> Pulse does not work when SSL is enabled for JMX
> ---
>
> Key: GEODE-5230
> URL: https://issues.apache.org/jira/browse/GEODE-5230
> Project: Geode
>  Issue Type: Bug
>  Components: pulse
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.7.0
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> If I start a locator with SSL enabled {{ssl-components=ALL}} then Pulse does 
> not work. When logging in I see an error message like:
> {noformat}
> Connecting ...
> Failed to retrieve RMIServer stub: javax.naming.CommunicationException [Root 
> exception is java.rmi.ConnectIOException: error during JRMP connection 
> establishment; nested exception is: javax.net.ssl.SSLHandshakeException: 
> sun.security.validator.ValidatorException: PKIX path building failed: 
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find 
> valid certification path to requested target]
> {noformat}
> pulse.log shows the same:
> {noformat}
> Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable 
> to find valid certification path to requested target
> at 
> sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:141)
>  ~[?:1.8.0_161]
> at 
> sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:126)
>  ~[?:1.8.0_161]
> at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:280) 
> ~[?:1.8.0_161]
> at 
> sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:392) 
> ~[?:1.8.0_161]
> at 
> sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:302) 
> ~[?:1.8.0_161]
> at sun.security.validator.Validator.validate(Validator.java:260) 
> ~[?:1.8.0_161]
> at 
> sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:324) 
> ~[?:1.8.0_161]
> at 
> sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:229)
>  ~[?:1.8.0_161]
> at 
> sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:124)
>  ~[?:1.8.0_161]
> at 
> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1596)
>  ~[?:1.8.0_161]
> at 
> sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216) 
> ~[?:1.8.0_161]
> at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1052) 
> ~[?:1.8.0_161]
> at sun.security.ssl.Handshaker.process_record(Handshaker.java:987) 
> ~[?:1.8.0_161]
> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1072) 
> ~[?:1.8.0_161]
> at 
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1385)
>  ~[?:1.8.0_161]
> at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:757) 
> ~[?:1.8.0_161]
> at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:123) 
> ~[?:1.8.0_161]
> at 
> java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82) 
> ~[?:1.8.0_161]
> at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140) 
> ~[?:1.8.0_161]
> at java.io.DataOutputStream.flush(DataOutputStream.java:123) 
> ~[?:1.8.0_161]
> at 
> sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:229) 
> ~[?:1.8.0_161]
> at 
> sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:202) 
> ~[?:1.8.0_161]
> at sun.rmi.server.UnicastRef.newCall(UnicastRef.java:338) 
> ~[?:1.8.0_161]
> at 
> sun.rmi.registry.RegistryImpl_Stub.lookup(RegistryImpl_Stub.java:112) 
> ~[?:1.8.0_161]
> at 
> com.sun.jndi.rmi.registry.RegistryContext.lookup(RegistryContext.java:132) 
> ~[?:1.8.0_161]
> at 
> com.sun.jndi.toolkit.url.GenericURLContext.lookup(GenericURLContext.java:205) 
> ~[?:1.8.0_161]
> at javax.naming.InitialContext.lookup(InitialContext.java:417) 
> ~[?:1.8.0_161]
> at 
> javax.management.remote.rmi.RMIConnector.findRMIServerJNDI(RMIConnector.java:1955)
>  ~[?:1.8.0_161]
> at 
> javax.management.remote.rmi.RMIConnector.findRMIServer(RMIConnector.java:1922)
>  ~[?:1.8.0_161]
> at 
> javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:287) 
> ~[?:1.8.0_161]
> ... 92 more
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (GEODE-5230) Pulse does not work when SSL is enabled for JMX

[Jens Deppe (JIRA)]

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

Jens Deppe resolved GEODE-5230.
---
Resolution: Fixed

> Pulse does not work when SSL is enabled for JMX
> ---
>
> Key: GEODE-5230
> URL: https://issues.apache.org/jira/browse/GEODE-5230
> Project: Geode
>  Issue Type: Bug
>  Components: pulse
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.7.0
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> If I start a locator with SSL enabled {{ssl-components=ALL}} then Pulse does 
> not work. When logging in I see an error message like:
> {noformat}
> Connecting ...
> Failed to retrieve RMIServer stub: javax.naming.CommunicationException [Root 
> exception is java.rmi.ConnectIOException: error during JRMP connection 
> establishment; nested exception is: javax.net.ssl.SSLHandshakeException: 
> sun.security.validator.ValidatorException: PKIX path building failed: 
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find 
> valid certification path to requested target]
> {noformat}
> pulse.log shows the same:
> {noformat}
> Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable 
> to find valid certification path to requested target
> at 
> sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:141)
>  ~[?:1.8.0_161]
> at 
> sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:126)
>  ~[?:1.8.0_161]
> at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:280) 
> ~[?:1.8.0_161]
> at 
> sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:392) 
> ~[?:1.8.0_161]
> at 
> sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:302) 
> ~[?:1.8.0_161]
> at sun.security.validator.Validator.validate(Validator.java:260) 
> ~[?:1.8.0_161]
> at 
> sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:324) 
> ~[?:1.8.0_161]
> at 
> sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:229)
>  ~[?:1.8.0_161]
> at 
> sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:124)
>  ~[?:1.8.0_161]
> at 
> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1596)
>  ~[?:1.8.0_161]
> at 
> sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216) 
> ~[?:1.8.0_161]
> at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1052) 
> ~[?:1.8.0_161]
> at sun.security.ssl.Handshaker.process_record(Handshaker.java:987) 
> ~[?:1.8.0_161]
> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1072) 
> ~[?:1.8.0_161]
> at 
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1385)
>  ~[?:1.8.0_161]
> at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:757) 
> ~[?:1.8.0_161]
> at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:123) 
> ~[?:1.8.0_161]
> at 
> java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82) 
> ~[?:1.8.0_161]
> at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140) 
> ~[?:1.8.0_161]
> at java.io.DataOutputStream.flush(DataOutputStream.java:123) 
> ~[?:1.8.0_161]
> at 
> sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:229) 
> ~[?:1.8.0_161]
> at 
> sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:202) 
> ~[?:1.8.0_161]
> at sun.rmi.server.UnicastRef.newCall(UnicastRef.java:338) 
> ~[?:1.8.0_161]
> at 
> sun.rmi.registry.RegistryImpl_Stub.lookup(RegistryImpl_Stub.java:112) 
> ~[?:1.8.0_161]
> at 
> com.sun.jndi.rmi.registry.RegistryContext.lookup(RegistryContext.java:132) 
> ~[?:1.8.0_161]
> at 
> com.sun.jndi.toolkit.url.GenericURLContext.lookup(GenericURLContext.java:205) 
> ~[?:1.8.0_161]
> at javax.naming.InitialContext.lookup(InitialContext.java:417) 
> ~[?:1.8.0_161]
> at 
> javax.management.remote.rmi.RMIConnector.findRMIServerJNDI(RMIConnector.java:1955)
>  ~[?:1.8.0_161]
> at 
> javax.management.remote.rmi.RMIConnector.findRMIServer(RMIConnector.java:1922)
>  ~[?:1.8.0_161]
> at 
> javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:287) 
> ~[?:1.8.0_161]
> ... 92 more
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GEODE-5660) Add ability to lookup the GEODE-WEB-API war file from the classpath

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot updated GEODE-5660:
--
Labels: pull-request-available  (was: )

> Add ability to lookup the GEODE-WEB-API war file from the classpath
> ---
>
> Key: GEODE-5660
> URL: https://issues.apache.org/jira/browse/GEODE-5660
> Project: Geode
>  Issue Type: Improvement
>  Components: rest (admin), rest (dev)
>Reporter: Udo Kohlmeyer
>Assignee: Udo Kohlmeyer
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.8.0
>
>
> The current AgentUtil class only makes provision to lookup the 
> `geode-web-api` and `geode-web` war files from known locations.
>  When referencing the `geode-web-api` and `geode-web` war's from a 
> repository, the HTTP Services will fail, due to the requirement of having set 
> `GEODE_HOME` to the locally deployed GEODE distribution.
> A way is required to reference the relevant war files from a repository and 
> not requiring the `GEODE_HOME` property to be specifically set.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GEODE-5660) Add ability to lookup the GEODE-WEB-API war file from the classpath

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-5660:


Commit 4121388fb8a611f6303b621d12e1a267a303bc13 in geode's branch 
refs/heads/feature/GEODE-5660 from [~ukohlmeyer]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=4121388 ]

GEODE-5660: Added method to lookup war file from classpath
within AgentUtil.java. This is to address problem where
http server is started from Java API (Spring Data Geode specifically)
Now, the application can reference the `geode-web-api` war from repo
and not have to specifically set `GEODE-HOME` property


> Add ability to lookup the GEODE-WEB-API war file from the classpath
> ---
>
> Key: GEODE-5660
> URL: https://issues.apache.org/jira/browse/GEODE-5660
> Project: Geode
>  Issue Type: Improvement
>  Components: rest (admin), rest (dev)
>Reporter: Udo Kohlmeyer
>Assignee: Udo Kohlmeyer
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.8.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The current AgentUtil class only makes provision to lookup the 
> `geode-web-api` and `geode-web` war files from known locations.
>  When referencing the `geode-web-api` and `geode-web` war's from a 
> repository, the HTTP Services will fail, due to the requirement of having set 
> `GEODE_HOME` to the locally deployed GEODE distribution.
> A way is required to reference the relevant war files from a repository and 
> not requiring the `GEODE_HOME` property to be specifically set.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GEODE-5657) Make Build job in develop pipeline similar to test jobs

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot updated GEODE-5657:
--
Labels: pull-request-available  (was: )

> Make Build job in develop pipeline similar to test jobs
> ---
>
> Key: GEODE-5657
> URL: https://issues.apache.org/jira/browse/GEODE-5657
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
>  Labels: pull-request-available
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GEODE-5660) Add ability to lookup the GEODE-WEB-API war file from the classpath

[Udo Kohlmeyer (JIRA)]

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

Udo Kohlmeyer updated GEODE-5660:
-
Description: 
The current AgentUtil class only makes provision to lookup the `geode-web-api` 
and `geode-web` war files from known locations.
 When referencing the `geode-web-api` and `geode-web` war's from a repository, 
the HTTP Services will fail, due to the requirement of having set `GEODE_HOME` 
to the locally deployed GEODE distribution.

A way is required to reference the relevant war files from a repository and not 
requiring the `GEODE_HOME` property to be specifically set.

  was:
The current AgentUtil class only makes provision to lookup the `geode-web-api` 
and `geode-web` war files from known locations.
When referencing the `geode-web-api` and `geode-web` war's from a repository, 
the HTTP Services will fail, due to the requirement of having set `GEODE_HOME` 
to the locally deployed GEODE distribution.

A way is required to reference the relevant war files from a repository and not 
requiring the `GEODE_HOME` property to be specifically set.


> Add ability to lookup the GEODE-WEB-API war file from the classpath
> ---
>
> Key: GEODE-5660
> URL: https://issues.apache.org/jira/browse/GEODE-5660
> Project: Geode
>  Issue Type: Improvement
>  Components: rest (admin), rest (dev)
>Reporter: Udo Kohlmeyer
>Assignee: Udo Kohlmeyer
>Priority: Major
> Fix For: 1.8.0
>
>
> The current AgentUtil class only makes provision to lookup the 
> `geode-web-api` and `geode-web` war files from known locations.
>  When referencing the `geode-web-api` and `geode-web` war's from a 
> repository, the HTTP Services will fail, due to the requirement of having set 
> `GEODE_HOME` to the locally deployed GEODE distribution.
> A way is required to reference the relevant war files from a repository and 
> not requiring the `GEODE_HOME` property to be specifically set.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (GEODE-5660) Add ability to lookup the GEODE-WEB-API war file from the classpath

[Udo Kohlmeyer (JIRA)]

Udo Kohlmeyer created GEODE-5660:


 Summary: Add ability to lookup the GEODE-WEB-API war file from the 
classpath
 Key: GEODE-5660
 URL: https://issues.apache.org/jira/browse/GEODE-5660
 Project: Geode
  Issue Type: Improvement
  Components: rest (admin), rest (dev)
Reporter: Udo Kohlmeyer
 Fix For: 1.8.0


The current AgentUtil class only makes provision to lookup the `geode-web-api` 
and `geode-web` war files from known locations.
When referencing the `geode-web-api` and `geode-web` war's from a repository, 
the HTTP Services will fail, due to the requirement of having set `GEODE_HOME` 
to the locally deployed GEODE distribution.

A way is required to reference the relevant war files from a repository and not 
requiring the `GEODE_HOME` property to be specifically set.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (GEODE-5660) Add ability to lookup the GEODE-WEB-API war file from the classpath

[Udo Kohlmeyer (JIRA)]

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

Udo Kohlmeyer reassigned GEODE-5660:


Assignee: Udo Kohlmeyer

> Add ability to lookup the GEODE-WEB-API war file from the classpath
> ---
>
> Key: GEODE-5660
> URL: https://issues.apache.org/jira/browse/GEODE-5660
> Project: Geode
>  Issue Type: Improvement
>  Components: rest (admin), rest (dev)
>Reporter: Udo Kohlmeyer
>Assignee: Udo Kohlmeyer
>Priority: Major
> Fix For: 1.8.0
>
>
> The current AgentUtil class only makes provision to lookup the 
> `geode-web-api` and `geode-web` war files from known locations.
> When referencing the `geode-web-api` and `geode-web` war's from a repository, 
> the HTTP Services will fail, due to the requirement of having set 
> `GEODE_HOME` to the locally deployed GEODE distribution.
> A way is required to reference the relevant war files from a repository and 
> not requiring the `GEODE_HOME` property to be specifically set.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (GEODE-5648) Native Client docs: Add a page describing Continuous Queries

[Dave Barnes (JIRA)]

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

Dave Barnes reassigned GEODE-5648:
--

Assignee: Dave Barnes

> Native Client docs: Add a page describing Continuous Queries
> 
>
> Key: GEODE-5648
> URL: https://issues.apache.org/jira/browse/GEODE-5648
> Project: Geode
>  Issue Type: New Feature
>  Components: docs
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.8.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (GEODE-5648) Native Client docs: Add a page describing Continuous Queries

[Dave Barnes (JIRA)]

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

Dave Barnes resolved GEODE-5648.

   Resolution: Fixed
Fix Version/s: 1.8.0

> Native Client docs: Add a page describing Continuous Queries
> 
>
> Key: GEODE-5648
> URL: https://issues.apache.org/jira/browse/GEODE-5648
> Project: Geode
>  Issue Type: New Feature
>  Components: docs
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.8.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GEODE-5648) Native Client docs: Add a page describing Continuous Queries

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-5648:


Commit 232e5caf4913dd0e33a59124bfea267327513ae4 in geode-native's branch 
refs/heads/develop from [~dbarnes97]
[ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=232e5ca ]

GEODE-5648: Native client user guide - add a page describing Continuous Queries 
(#340)



> Native Client docs: Add a page describing Continuous Queries
> 
>
> Key: GEODE-5648
> URL: https://issues.apache.org/jira/browse/GEODE-5648
> Project: Geode
>  Issue Type: New Feature
>  Components: docs
>Reporter: Dave Barnes
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 20m
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (GEODE-5657) Make Build job in develop pipeline similar to test jobs

[Patrick Rhomberg (JIRA)]

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

Patrick Rhomberg reassigned GEODE-5657:
---

Assignee: Patrick Rhomberg

> Make Build job in develop pipeline similar to test jobs
> ---
>
> Key: GEODE-5657
> URL: https://issues.apache.org/jira/browse/GEODE-5657
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (GEODE-5659) Unify build script with execute_tests script.

[Patrick Rhomberg (JIRA)]

Patrick Rhomberg created GEODE-5659:
---

 Summary: Unify build script with execute_tests script.
 Key: GEODE-5659
 URL: https://issues.apache.org/jira/browse/GEODE-5659
 Project: Geode
  Issue Type: Sub-task
Reporter: Patrick Rhomberg


There is a great deal of similarity between these scripts.  As the differences 
between Build and test infrastructure are reduced, a single script may be able 
to perform both build and testing tasks.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (GEODE-5657) Make Build job in develop pipeline similar to test jobs

[Patrick Rhomberg (JIRA)]

Patrick Rhomberg created GEODE-5657:
---

 Summary: Make Build job in develop pipeline similar to test jobs
 Key: GEODE-5657
 URL: https://issues.apache.org/jira/browse/GEODE-5657
 Project: Geode
  Issue Type: Sub-task
Reporter: Patrick Rhomberg






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (GEODE-5658) Make Build job in pull-requests pipeline similar to test jobs

[Patrick Rhomberg (JIRA)]

Patrick Rhomberg created GEODE-5658:
---

 Summary: Make Build job in pull-requests pipeline similar to test 
jobs
 Key: GEODE-5658
 URL: https://issues.apache.org/jira/browse/GEODE-5658
 Project: Geode
  Issue Type: Sub-task
Reporter: Patrick Rhomberg






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GEODE-5637) Flaky: SingleHopClientExecutorSubmitTaskWithExceptionTest fails intermittently

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-5637:


Commit 34ec00147c01b043ebc5094e6e699469756245b4 in geode's branch 
refs/heads/develop from [~apa...@the9muses.net]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=34ec001 ]

GEODE-5637: disable SingleHopClientExecutorWithLoggingIntegrationTest

This test is super flaky and seems to consistently fail on Windows. It's
trying to use SystemErrRule to test logging which doesn't really work
very well. I think the test needs to be rewritten with a Log4J2 Appender
instead of trying to use stdout or stderr. I'm going to disable it with
Ignore until I can get this rewritten.

Discussed with and reviewed by Sai.


> Flaky: SingleHopClientExecutorSubmitTaskWithExceptionTest fails intermittently
> --
>
> Key: GEODE-5637
> URL: https://issues.apache.org/jira/browse/GEODE-5637
> Project: Geode
>  Issue Type: Bug
>  Components: tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
>  Labels: flaky, pull-request-available, swat
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> This test should also be an integration test but it's in the test src set.
> {noformat}
> > Task :geode-core:test
> org.apache.geode.cache.client.internal.SingleHopClientExecutorSubmitTaskWithExceptionTest
>  > submittedTaskShouldLogFailure FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition 
> defined as a lambda expression in 
> org.apache.geode.cache.client.internal.SingleHopClientExecutorSubmitTaskWithExceptionTest
>  
> Expecting:
>  <"">
> to contain:
>  <"I am expecting this to be logged">  within 2 minutes.
> at 
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:145)
> at 
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:122)
> at 
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:32)
> at 
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:890)
> at 
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:711)
> at 
> org.apache.geode.cache.client.internal.SingleHopClientExecutorSubmitTaskWithExceptionTest.submittedTaskShouldLogFailure(SingleHopClientExecutorSubmitTaskWithExceptionTest.java:54)
> Caused by:
> java.lang.AssertionError: 
> Expecting:
>  <"">
> to contain:
>  <"I am expecting this to be logged"> 
> at 
> org.apache.geode.cache.client.internal.SingleHopClientExecutorSubmitTaskWithExceptionTest.lambda$submittedTaskShouldLogFailure$1(SingleHopClientExecutorSubmitTaskWithExceptionTest.java:54)
> 4490 tests completed, 1 failed, 9 skipped
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GEODE-5637) Flaky: SingleHopClientExecutorSubmitTaskWithExceptionTest fails intermittently

[Kirk Lund (JIRA)]

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

Kirk Lund commented on GEODE-5637:
--

This test is super flaky and seems to consistently fail on Windows. It's trying 
to use SystemErrRule to test logging which doesn't really work very well. I 
think the test needs to be rewritten with a Log4J2 Appender instead of trying 
to use stdout or stderr. I'm going to disable it with Ignore until I can get 
this rewritten.

> Flaky: SingleHopClientExecutorSubmitTaskWithExceptionTest fails intermittently
> --
>
> Key: GEODE-5637
> URL: https://issues.apache.org/jira/browse/GEODE-5637
> Project: Geode
>  Issue Type: Bug
>  Components: tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
>  Labels: flaky, pull-request-available, swat
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> This test should also be an integration test but it's in the test src set.
> {noformat}
> > Task :geode-core:test
> org.apache.geode.cache.client.internal.SingleHopClientExecutorSubmitTaskWithExceptionTest
>  > submittedTaskShouldLogFailure FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition 
> defined as a lambda expression in 
> org.apache.geode.cache.client.internal.SingleHopClientExecutorSubmitTaskWithExceptionTest
>  
> Expecting:
>  <"">
> to contain:
>  <"I am expecting this to be logged">  within 2 minutes.
> at 
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:145)
> at 
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:122)
> at 
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:32)
> at 
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:890)
> at 
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:711)
> at 
> org.apache.geode.cache.client.internal.SingleHopClientExecutorSubmitTaskWithExceptionTest.submittedTaskShouldLogFailure(SingleHopClientExecutorSubmitTaskWithExceptionTest.java:54)
> Caused by:
> java.lang.AssertionError: 
> Expecting:
>  <"">
> to contain:
>  <"I am expecting this to be logged"> 
> at 
> org.apache.geode.cache.client.internal.SingleHopClientExecutorSubmitTaskWithExceptionTest.lambda$submittedTaskShouldLogFailure$1(SingleHopClientExecutorSubmitTaskWithExceptionTest.java:54)
> 4490 tests completed, 1 failed, 9 skipped
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GEODE-5656) Upgrade build to use Gradle 4.10

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot updated GEODE-5656:
--
Labels: pull-request-available  (was: )

> Upgrade build to use Gradle 4.10
> 
>
> Key: GEODE-5656
> URL: https://issues.apache.org/jira/browse/GEODE-5656
> Project: Geode
>  Issue Type: Improvement
>  Components: build
>Reporter: Jacob S. Barrett
>Priority: Major
>  Labels: pull-request-available
>
> https://docs.gradle.org/4.10/release-notes.html



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (GEODE-5639) Replace usage of CatchException with AssertJ and remove CatchException dependency

[Kirk Lund (JIRA)]

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

Kirk Lund resolved GEODE-5639.
--
   Resolution: Fixed
Fix Version/s: 1.7.0

> Replace usage of CatchException with AssertJ and remove CatchException 
> dependency
> -
>
> Key: GEODE-5639
> URL: https://issues.apache.org/jira/browse/GEODE-5639
> Project: Geode
>  Issue Type: Wish
>  Components: build, tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.7.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> We have a small number of tests using 
> com.googlecode.catchexception.CatchException. This project isn't very active 
> and AssertJ provides better support for testing expected exceptions and 
> throwables. Most Geode developers are already using AssertJ for expected 
> exceptions.
> The tests using CatchException should be updated to instead use AssertJ and 
> then remove our testing dependency on CatchException.
> The recommended ways of handling expected exception testing would then 
> involve using following AssertJ APIs:
> 1) Basic assertion about an expected exception
> Use: org.assertj.core.api.Assertions.assertThatThrownBy
> Example from JdbcWriterTest:
> {noformat}
> assertThatThrownBy(() -> writer.beforeUpdate(entryEvent))
> .isInstanceOf(IllegalArgumentException.class);
> {noformat}
> 2) Complex assertion about an expected exception (potentially with many 
> nested causes with messages that we want to validate as well)
> Use: org.assertj.core.api.Assertions.catchThrowable
> Example from DeltaPropagationFailureRegressionTest:
> {noformat}
> Throwable thrown = server1.invoke(() -> catchThrowable(() -> 
> putDelta(FROM_DELTA)));
> assertThat(thrown).isInstanceOf(DeltaSerializationException.class)
> .hasMessageContaining("deserializing delta 
> bytes").hasCauseInstanceOf(EOFException.class);
> {noformat}
> 3) Simple assertion that an invocation should not thrown (probably used in a 
> regression test)
> Use: org.assertj.core.api.Assertions.assertThatCode
> Example from RegisterInterestDistributedTest:
> {noformat}
> assertThatCode(() -> 
> clientCache.readyForEvents()).doesNotThrowAnyException();
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GEODE-5639) Replace usage of CatchException with AssertJ and remove CatchException dependency

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-5639:


Commit f550cc48b15ccca2f4c91891b93adb16a044af06 in geode's branch 
refs/heads/develop from [~apa...@the9muses.net]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=f550cc4 ]

GEODE-5639: use AssertJ instead of CatchException

* Move PdxAttributesJUnitTest to distributedTest


> Replace usage of CatchException with AssertJ and remove CatchException 
> dependency
> -
>
> Key: GEODE-5639
> URL: https://issues.apache.org/jira/browse/GEODE-5639
> Project: Geode
>  Issue Type: Wish
>  Components: build, tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> We have a small number of tests using 
> com.googlecode.catchexception.CatchException. This project isn't very active 
> and AssertJ provides better support for testing expected exceptions and 
> throwables. Most Geode developers are already using AssertJ for expected 
> exceptions.
> The tests using CatchException should be updated to instead use AssertJ and 
> then remove our testing dependency on CatchException.
> The recommended ways of handling expected exception testing would then 
> involve using following AssertJ APIs:
> 1) Basic assertion about an expected exception
> Use: org.assertj.core.api.Assertions.assertThatThrownBy
> Example from JdbcWriterTest:
> {noformat}
> assertThatThrownBy(() -> writer.beforeUpdate(entryEvent))
> .isInstanceOf(IllegalArgumentException.class);
> {noformat}
> 2) Complex assertion about an expected exception (potentially with many 
> nested causes with messages that we want to validate as well)
> Use: org.assertj.core.api.Assertions.catchThrowable
> Example from DeltaPropagationFailureRegressionTest:
> {noformat}
> Throwable thrown = server1.invoke(() -> catchThrowable(() -> 
> putDelta(FROM_DELTA)));
> assertThat(thrown).isInstanceOf(DeltaSerializationException.class)
> .hasMessageContaining("deserializing delta 
> bytes").hasCauseInstanceOf(EOFException.class);
> {noformat}
> 3) Simple assertion that an invocation should not thrown (probably used in a 
> regression test)
> Use: org.assertj.core.api.Assertions.assertThatCode
> Example from RegisterInterestDistributedTest:
> {noformat}
> assertThatCode(() -> 
> clientCache.readyForEvents()).doesNotThrowAnyException();
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GEODE-5639) Replace usage of CatchException with AssertJ and remove CatchException dependency

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-5639:


Commit 281492aed8c290eff9bf83917439ded02bffef36 in geode's branch 
refs/heads/develop from [~apa...@the9muses.net]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=281492a ]

GEODE-5639: remove CatchException dependencies from Gradle


> Replace usage of CatchException with AssertJ and remove CatchException 
> dependency
> -
>
> Key: GEODE-5639
> URL: https://issues.apache.org/jira/browse/GEODE-5639
> Project: Geode
>  Issue Type: Wish
>  Components: build, tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> We have a small number of tests using 
> com.googlecode.catchexception.CatchException. This project isn't very active 
> and AssertJ provides better support for testing expected exceptions and 
> throwables. Most Geode developers are already using AssertJ for expected 
> exceptions.
> The tests using CatchException should be updated to instead use AssertJ and 
> then remove our testing dependency on CatchException.
> The recommended ways of handling expected exception testing would then 
> involve using following AssertJ APIs:
> 1) Basic assertion about an expected exception
> Use: org.assertj.core.api.Assertions.assertThatThrownBy
> Example from JdbcWriterTest:
> {noformat}
> assertThatThrownBy(() -> writer.beforeUpdate(entryEvent))
> .isInstanceOf(IllegalArgumentException.class);
> {noformat}
> 2) Complex assertion about an expected exception (potentially with many 
> nested causes with messages that we want to validate as well)
> Use: org.assertj.core.api.Assertions.catchThrowable
> Example from DeltaPropagationFailureRegressionTest:
> {noformat}
> Throwable thrown = server1.invoke(() -> catchThrowable(() -> 
> putDelta(FROM_DELTA)));
> assertThat(thrown).isInstanceOf(DeltaSerializationException.class)
> .hasMessageContaining("deserializing delta 
> bytes").hasCauseInstanceOf(EOFException.class);
> {noformat}
> 3) Simple assertion that an invocation should not thrown (probably used in a 
> regression test)
> Use: org.assertj.core.api.Assertions.assertThatCode
> Example from RegisterInterestDistributedTest:
> {noformat}
> assertThatCode(() -> 
> clientCache.readyForEvents()).doesNotThrowAnyException();
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GEODE-5594) Enable endpoint validation during using SSL handshake

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-5594:


Commit fd29e625c482c9b983d69a4b1ad2abee3775a69b in geode's branch 
refs/heads/concourse-staging from [~sai.boorlaga...@gmail.com]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=fd29e62 ]

GEODE-5594: Enable endpoint identification during using SSL handshake. (#2346)

   User can enable endpoint identification during SSL handshake
   to validate server's hostname with server's identity.

   New boolean property ssl-endpoint-validation-enabled is added.

> Enable endpoint validation during using SSL handshake
> -
>
> Key: GEODE-5594
> URL: https://issues.apache.org/jira/browse/GEODE-5594
> Project: Geode
>  Issue Type: Improvement
>  Components: client/server, docs
>Reporter: Sai Boorlagadda
>Assignee: Sai Boorlagadda
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.7.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> Users can set `ssl-endpoint-identification-enabled` to true to enable 
> validation of hostname in server's identity when using SSL to harden against 
> certain man-in-the-middle attacks 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GEODE-5604) Make Geode build Gradle-5.0 ready

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-5604:


Commit b3cf86b7f8b0e27abe9ffc4cdb0fd18b7df0c3e2 in geode's branch 
refs/heads/concourse-staging from [~rhoughton]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=b3cf86b ]

GEODE-5604 Update gradle syntax to comply with 5.0 (#2350)

* Fix subproject names for gradle 5.0
** stop using '/' and use preferred ':' character for nested projects
* Update performance profiling plug-in to be Gradle 5.0 compliant
* Fix input/output warnings on geode-old-versions
* Don't use custom configuration in geode-modules-assembly
* All test configurations inherit annotationProcessor from mainSourceSet
* Using strict maven-publish plugin

Co-authored-by: Dick Cavender 
Co-authored-by: Jacob Barrett 
Co-authored-by: Patrick Rhomberg 
Co-authored-by: Robert Houghton 


> Make Geode build Gradle-5.0 ready
> -
>
> Key: GEODE-5604
> URL: https://issues.apache.org/jira/browse/GEODE-5604
> Project: Geode
>  Issue Type: Improvement
>  Components: build
>Reporter: Robert Houghton
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 2h 20m
>  Remaining Estimate: 0h
>
> Gradle is giving warnings about unsupported or deprecated features from our 
> 3.xx days. Clean them up.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GEODE-5608) Meta pipeline can generate images and instances with names longer than max allowed by GCP

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-5608:


Commit aa915c2ba7d07a641c8ec65f473dd60f44806606 in geode's branch 
refs/heads/concourse-staging from FSOUTHERLAND
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=aa915c2 ]

GEODE-5608 truncate fork/branch names in image/instance naming (#2390)

* GEODE-5608 truncate fork/branch names in image/instance naming (#2363)

Co-authored-by: Jacob Barrett 
Co-authored-by: Finn Southerland 
Co-authored-by: Robert Houghton 


> Meta pipeline can generate images and instances with names longer than max 
> allowed by GCP
> -
>
> Key: GEODE-5608
> URL: https://issues.apache.org/jira/browse/GEODE-5608
> Project: Geode
>  Issue Type: Task
>  Components: ci
>Reporter: Finn Southerland
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> GCP does not allow names with more than 64 characters, so we should somehow 
> ensure that we do not generate names that are longer than this. Contributors 
> to especially long names are long fork/branch names especially.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GEODE-5641) DiskDirRule should have a public no-arg constructor

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-5641:


Commit ebe44c22d30774a916beca33c2316289a44ca3c5 in geode's branch 
refs/heads/concourse-staging from [~apa...@the9muses.net]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=ebe44c2 ]

GEODE-5641: add no-arg constructor to DiskDirRule

To redirect default disk store to a TemporaryFolder, you can simply
add this to any test:

@Rule
public DiskDirRule diskDirRule = new DiskDirRule();

Or in a DistributedTest use:

@Rule
public DistributedDiskDirRule diskDirRule = new DistributedDiskDirRule();


> DiskDirRule should have a public no-arg constructor
> ---
>
> Key: GEODE-5641
> URL: https://issues.apache.org/jira/browse/GEODE-5641
> Project: Geode
>  Issue Type: Wish
>  Components: tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.7.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> DiskDirRule should have a public no-arg constructor for this usage:
> {noformat}
> @Rule
> public DiskDirRule diskDirRule = new DiskDirRule();
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GEODE-5650) Improve ClusterStartupRule tear down

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-5650:


Commit 8382f8cff8120076fa9af7816e8454575c3a189c in geode's branch 
refs/heads/concourse-staging from [~sai.boorlaga...@gmail.com]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=8382f8c ]

GEODE-5650: Improve ClusterStartupRule tear down (#2392)



> Improve ClusterStartupRule tear down
> 
>
> Key: GEODE-5650
> URL: https://issues.apache.org/jira/browse/GEODE-5650
> Project: Geode
>  Issue Type: Improvement
>  Components: tests
>Reporter: Sai Boorlagadda
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.7.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> in CSRule teardown if we close suspect buffer before closing cache can cause 
> some background threads (eg: client pool) to keep sending events and log 
> exceptions (if any) could result in the next test to fail for suspects. So 
> close the suspect buffer after closing cache in all VMs.
> {code:java}
>   protected void after() {
> try {
>   DUnitLauncher.closeAndCheckForSuspects();
> } finally {
>   MemberStarterRule.disconnectDSIfAny();
>   // stop all the members in the order of clients, servers and locators
>   List vms = new ArrayList<>();
>   vms.addAll(
>   occupiedVMs.values().stream().filter(x -> 
> x.isClient()).collect(Collectors.toSet()));
>   vms.addAll(
>   occupiedVMs.values().stream().filter(x -> 
> x.isServer()).collect(Collectors.toSet()));
>   vms.addAll(
>   occupiedVMs.values().stream().filter(x -> 
> x.isLocator()).collect(Collectors.toSet()));
>   vms.forEach(x -> x.stop());
>   // delete any file under root dir
>   Arrays.stream(getWorkingDirRoot().listFiles()).filter(File::isFile)
>   .forEach(FileUtils::deleteQuietly);
>   restoreSystemProperties.after();
> }
>   }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GEODE-5633) PR pipelines deployed by meta should include fork name AND branch name

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-5633:


Commit 7b6f5fa0ca05fa21a713070fc8ad87badd3e4684 in geode's branch 
refs/heads/concourse-staging from FSOUTHERLAND
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=7b6f5fa ]

GEODE-5633 pr pipeline name has fork and branch (#2391)

Authored-by: Finn Southerland 

> PR pipelines deployed by meta should include fork name AND branch name
> --
>
> Key: GEODE-5633
> URL: https://issues.apache.org/jira/browse/GEODE-5633
> Project: Geode
>  Issue Type: Task
>  Components: ci
>Reporter: Finn Southerland
>Priority: Major
>
> The name for pr pipelines created on forks currently is `pr-<>`. 
> This is inconsistent with the other pipelines and risks naming collisions. 
> This should be easy to fix as the name is only referenced on creation.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GEODE-5608) Meta pipeline can generate images and instances with names longer than max allowed by GCP

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-5608:


Commit aa915c2ba7d07a641c8ec65f473dd60f44806606 in geode's branch 
refs/heads/concourse-staging from FSOUTHERLAND
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=aa915c2 ]

GEODE-5608 truncate fork/branch names in image/instance naming (#2390)

* GEODE-5608 truncate fork/branch names in image/instance naming (#2363)

Co-authored-by: Jacob Barrett 
Co-authored-by: Finn Southerland 
Co-authored-by: Robert Houghton 


> Meta pipeline can generate images and instances with names longer than max 
> allowed by GCP
> -
>
> Key: GEODE-5608
> URL: https://issues.apache.org/jira/browse/GEODE-5608
> Project: Geode
>  Issue Type: Task
>  Components: ci
>Reporter: Finn Southerland
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> GCP does not allow names with more than 64 characters, so we should somehow 
> ensure that we do not generate names that are longer than this. Contributors 
> to especially long names are long fork/branch names especially.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GEODE-5637) Flaky: SingleHopClientExecutorSubmitTaskWithExceptionTest fails intermittently

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-5637:


Commit b66beba19c8457eaa684a3d03100c2755c68aab0 in geode's branch 
refs/heads/concourse-staging from [~apa...@the9muses.net]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=b66beba ]

GEODE-5637: move SingleHopClientExecutorSubmitTaskWithExceptionTest to 
integrationTest

* Increase Awaitility timeout due to flaky failure
* Cleanup test and use AssertJ


> Flaky: SingleHopClientExecutorSubmitTaskWithExceptionTest fails intermittently
> --
>
> Key: GEODE-5637
> URL: https://issues.apache.org/jira/browse/GEODE-5637
> Project: Geode
>  Issue Type: Bug
>  Components: tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
>  Labels: flaky, pull-request-available, swat
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> This test should also be an integration test but it's in the test src set.
> {noformat}
> > Task :geode-core:test
> org.apache.geode.cache.client.internal.SingleHopClientExecutorSubmitTaskWithExceptionTest
>  > submittedTaskShouldLogFailure FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition 
> defined as a lambda expression in 
> org.apache.geode.cache.client.internal.SingleHopClientExecutorSubmitTaskWithExceptionTest
>  
> Expecting:
>  <"">
> to contain:
>  <"I am expecting this to be logged">  within 2 minutes.
> at 
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:145)
> at 
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:122)
> at 
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:32)
> at 
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:890)
> at 
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:711)
> at 
> org.apache.geode.cache.client.internal.SingleHopClientExecutorSubmitTaskWithExceptionTest.submittedTaskShouldLogFailure(SingleHopClientExecutorSubmitTaskWithExceptionTest.java:54)
> Caused by:
> java.lang.AssertionError: 
> Expecting:
>  <"">
> to contain:
>  <"I am expecting this to be logged"> 
> at 
> org.apache.geode.cache.client.internal.SingleHopClientExecutorSubmitTaskWithExceptionTest.lambda$submittedTaskShouldLogFailure$1(SingleHopClientExecutorSubmitTaskWithExceptionTest.java:54)
> 4490 tests completed, 1 failed, 9 skipped
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GEODE-5608) Meta pipeline can generate images and instances with names longer than max allowed by GCP

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-5608:


Commit 366594ca6f4807b6dfaa1fc9162f3760ecd18a58 in geode's branch 
refs/heads/concourse-staging from Jacob Barrett
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=366594c ]

Revert "GEODE-5608 truncate fork/branch names in image/instance naming (#2363)"

This reverts commit 58e4035f7678e7198bb3c59f719d94a27a9144b2.


> Meta pipeline can generate images and instances with names longer than max 
> allowed by GCP
> -
>
> Key: GEODE-5608
> URL: https://issues.apache.org/jira/browse/GEODE-5608
> Project: Geode
>  Issue Type: Task
>  Components: ci
>Reporter: Finn Southerland
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> GCP does not allow names with more than 64 characters, so we should somehow 
> ensure that we do not generate names that are longer than this. Contributors 
> to especially long names are long fork/branch names especially.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (GEODE-5656) Upgrade build to use Gradle 4.10

[Jacob S. Barrett (JIRA)]

Jacob S. Barrett created GEODE-5656:
---

 Summary: Upgrade build to use Gradle 4.10
 Key: GEODE-5656
 URL: https://issues.apache.org/jira/browse/GEODE-5656
 Project: Geode
  Issue Type: Improvement
  Components: build
Reporter: Jacob S. Barrett


https://docs.gradle.org/4.10/release-notes.html



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GEODE-5655) Flaky: org.apache.geode.session.tests.Jetty9Test.containersShouldShareDataRemovals fails intermittently

[Kirk Lund (JIRA)]

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

Kirk Lund updated GEODE-5655:
-
Description: 
Failed in build 
https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/321
{noformat}
> Task :geode-assembly:distributedTest

org.apache.geode.session.tests.Jetty9Test > containersShouldShareDataRemovals 
FAILED
org.codehaus.cargo.container.ContainerException: Failed to stop the Jetty 
9.4.8.v20171121 container. Check the 
[/home/geode/geode/geode-assembly/build/distributedTest108/cargo_logs/JETTY9_peer-to-peer_containersShouldShareDataRemovals_0_835922884062/container.log]
 file containing the container logs for more details.

Caused by:
org.codehaus.cargo.container.ContainerException: Server port 21121 did 
not shutdown within the timeout period [12]

166 tests completed, 1 failed

> Task :geode-assembly:distributedTest FAILED
{noformat}

  was:
{noformat}
> Task :geode-assembly:distributedTest

org.apache.geode.session.tests.Jetty9Test > containersShouldShareDataRemovals 
FAILED
org.codehaus.cargo.container.ContainerException: Failed to stop the Jetty 
9.4.8.v20171121 container. Check the 
[/home/geode/geode/geode-assembly/build/distributedTest108/cargo_logs/JETTY9_peer-to-peer_containersShouldShareDataRemovals_0_835922884062/container.log]
 file containing the container logs for more details.

Caused by:
org.codehaus.cargo.container.ContainerException: Server port 21121 did 
not shutdown within the timeout period [12]

166 tests completed, 1 failed

> Task :geode-assembly:distributedTest FAILED
{noformat}


> Flaky: 
> org.apache.geode.session.tests.Jetty9Test.containersShouldShareDataRemovals 
> fails intermittently
> ---
>
> Key: GEODE-5655
> URL: https://issues.apache.org/jira/browse/GEODE-5655
> Project: Geode
>  Issue Type: Bug
>  Components: http session, tests
>Reporter: Kirk Lund
>Priority: Major
>  Labels: Flaky, swat
>
> Failed in build 
> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/321
> {noformat}
> > Task :geode-assembly:distributedTest
> org.apache.geode.session.tests.Jetty9Test > containersShouldShareDataRemovals 
> FAILED
> org.codehaus.cargo.container.ContainerException: Failed to stop the Jetty 
> 9.4.8.v20171121 container. Check the 
> [/home/geode/geode/geode-assembly/build/distributedTest108/cargo_logs/JETTY9_peer-to-peer_containersShouldShareDataRemovals_0_835922884062/container.log]
>  file containing the container logs for more details.
> Caused by:
> org.codehaus.cargo.container.ContainerException: Server port 21121 
> did not shutdown within the timeout period [12]
> 166 tests completed, 1 failed
> > Task :geode-assembly:distributedTest FAILED
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GEODE-5655) Flaky: org.apache.geode.session.tests.Jetty9Test.containersShouldShareDataRemovals fails intermittently

[Kirk Lund (JIRA)]

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

Kirk Lund updated GEODE-5655:
-
Component/s: http session

> Flaky: 
> org.apache.geode.session.tests.Jetty9Test.containersShouldShareDataRemovals 
> fails intermittently
> ---
>
> Key: GEODE-5655
> URL: https://issues.apache.org/jira/browse/GEODE-5655
> Project: Geode
>  Issue Type: Bug
>  Components: http session, tests
>Reporter: Kirk Lund
>Priority: Major
>  Labels: Flaky, swat
>
> {noformat}
> > Task :geode-assembly:distributedTest
> org.apache.geode.session.tests.Jetty9Test > containersShouldShareDataRemovals 
> FAILED
> org.codehaus.cargo.container.ContainerException: Failed to stop the Jetty 
> 9.4.8.v20171121 container. Check the 
> [/home/geode/geode/geode-assembly/build/distributedTest108/cargo_logs/JETTY9_peer-to-peer_containersShouldShareDataRemovals_0_835922884062/container.log]
>  file containing the container logs for more details.
> Caused by:
> org.codehaus.cargo.container.ContainerException: Server port 21121 
> did not shutdown within the timeout period [12]
> 166 tests completed, 1 failed
> > Task :geode-assembly:distributedTest FAILED
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GEODE-1585) CI failure: SystemAdminDUnitTest.testPrintStacks

[Kirk Lund (JIRA)]

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

Kirk Lund updated GEODE-1585:
-
Component/s: tests

> CI failure: SystemAdminDUnitTest.testPrintStacks
> 
>
> Key: GEODE-1585
> URL: https://issues.apache.org/jira/browse/GEODE-1585
> Project: Geode
>  Issue Type: Bug
>  Components: management, tests
>Reporter: Hitesh Khamesra
>Priority: Major
>  Labels: CI, Flaky, swat
>
> https://builds.apache.org/job/Geode-nightly/507/testReport/com.gemstone.gemfire.distributed/SystemAdminDUnitTest/testPrintStacks/
> java.lang.AssertionError: found a Management Task thread in stack dump in 
> SystemAdminDUnitTest_testPrintStacks1.txt
> Stacktrace
> java.lang.AssertionError: found a Management Task thread in stack dump in 
> SystemAdminDUnitTest_testPrintStacks1.txt
>   at org.junit.Assert.fail(Assert.java:88)
>   at org.junit.Assert.assertTrue(Assert.java:41)
>   at org.junit.Assert.assertFalse(Assert.java:64)
>   at 
> com.gemstone.gemfire.distributed.SystemAdminDUnitTest.checkStackDumps(SystemAdminDUnitTest.java:117)
>   at 
> com.gemstone.gemfire.distributed.SystemAdminDUnitTest.testPrintStacks(SystemAdminDUnitTest.java:84)
>   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.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   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:112)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56)
>   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.GeneratedMethodAccessor6.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.messaging.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.GeneratedMethodAccessor5.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> 

[jira] [Updated] (GEODE-5655) Flaky: org.apache.geode.session.tests.Jetty9Test.containersShouldShareDataRemovals fails intermittently

[Kirk Lund (JIRA)]

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

Kirk Lund updated GEODE-5655:
-
Labels: Flaky swat  (was: )

> Flaky: 
> org.apache.geode.session.tests.Jetty9Test.containersShouldShareDataRemovals 
> fails intermittently
> ---
>
> Key: GEODE-5655
> URL: https://issues.apache.org/jira/browse/GEODE-5655
> Project: Geode
>  Issue Type: Bug
>  Components: tests
>Reporter: Kirk Lund
>Priority: Major
>  Labels: Flaky, swat
>
> {noformat}
> > Task :geode-assembly:distributedTest
> org.apache.geode.session.tests.Jetty9Test > containersShouldShareDataRemovals 
> FAILED
> org.codehaus.cargo.container.ContainerException: Failed to stop the Jetty 
> 9.4.8.v20171121 container. Check the 
> [/home/geode/geode/geode-assembly/build/distributedTest108/cargo_logs/JETTY9_peer-to-peer_containersShouldShareDataRemovals_0_835922884062/container.log]
>  file containing the container logs for more details.
> Caused by:
> org.codehaus.cargo.container.ContainerException: Server port 21121 
> did not shutdown within the timeout period [12]
> 166 tests completed, 1 failed
> > Task :geode-assembly:distributedTest FAILED
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Reopened] (GEODE-1585) CI failure: SystemAdminDUnitTest.testPrintStacks

[Kirk Lund (JIRA)]

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

Kirk Lund reopened GEODE-1585:
--

This failure reoccurred in 
https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/320

{noformat}
> Task :geode-core:distributedTest

org.apache.geode.distributed.SystemAdminDUnitTest > testPrintStacks FAILED
java.lang.AssertionError: found a Management Task thread in stack dump in 
SystemAdminDUnitTest_testPrintStacks1.txt
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertFalse(Assert.java:64)
at 
org.apache.geode.distributed.SystemAdminDUnitTest.checkStackDumps(SystemAdminDUnitTest.java:119)
at 
org.apache.geode.distributed.SystemAdminDUnitTest.testPrintStacks(SystemAdminDUnitTest.java:83)

8176 tests completed, 1 failed, 494 skipped

> Task :geode-core:distributedTest FAILED
{noformat}


> CI failure: SystemAdminDUnitTest.testPrintStacks
> 
>
> Key: GEODE-1585
> URL: https://issues.apache.org/jira/browse/GEODE-1585
> Project: Geode
>  Issue Type: Bug
>  Components: management
>Reporter: Hitesh Khamesra
>Priority: Major
>  Labels: CI, Flaky, swat
>
> https://builds.apache.org/job/Geode-nightly/507/testReport/com.gemstone.gemfire.distributed/SystemAdminDUnitTest/testPrintStacks/
> java.lang.AssertionError: found a Management Task thread in stack dump in 
> SystemAdminDUnitTest_testPrintStacks1.txt
> Stacktrace
> java.lang.AssertionError: found a Management Task thread in stack dump in 
> SystemAdminDUnitTest_testPrintStacks1.txt
>   at org.junit.Assert.fail(Assert.java:88)
>   at org.junit.Assert.assertTrue(Assert.java:41)
>   at org.junit.Assert.assertFalse(Assert.java:64)
>   at 
> com.gemstone.gemfire.distributed.SystemAdminDUnitTest.checkStackDumps(SystemAdminDUnitTest.java:117)
>   at 
> com.gemstone.gemfire.distributed.SystemAdminDUnitTest.testPrintStacks(SystemAdminDUnitTest.java:84)
>   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.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   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:112)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56)
>   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.GeneratedMethodAccessor6.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>  

[jira] [Updated] (GEODE-1585) CI failure: SystemAdminDUnitTest.testPrintStacks

[Kirk Lund (JIRA)]

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

Kirk Lund updated GEODE-1585:
-
Labels: CI Flaky swat  (was: CI Flaky)

> CI failure: SystemAdminDUnitTest.testPrintStacks
> 
>
> Key: GEODE-1585
> URL: https://issues.apache.org/jira/browse/GEODE-1585
> Project: Geode
>  Issue Type: Bug
>  Components: management
>Reporter: Hitesh Khamesra
>Priority: Major
>  Labels: CI, Flaky, swat
>
> https://builds.apache.org/job/Geode-nightly/507/testReport/com.gemstone.gemfire.distributed/SystemAdminDUnitTest/testPrintStacks/
> java.lang.AssertionError: found a Management Task thread in stack dump in 
> SystemAdminDUnitTest_testPrintStacks1.txt
> Stacktrace
> java.lang.AssertionError: found a Management Task thread in stack dump in 
> SystemAdminDUnitTest_testPrintStacks1.txt
>   at org.junit.Assert.fail(Assert.java:88)
>   at org.junit.Assert.assertTrue(Assert.java:41)
>   at org.junit.Assert.assertFalse(Assert.java:64)
>   at 
> com.gemstone.gemfire.distributed.SystemAdminDUnitTest.checkStackDumps(SystemAdminDUnitTest.java:117)
>   at 
> com.gemstone.gemfire.distributed.SystemAdminDUnitTest.testPrintStacks(SystemAdminDUnitTest.java:84)
>   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.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   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:112)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56)
>   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.GeneratedMethodAccessor6.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.messaging.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.GeneratedMethodAccessor5.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> 

[jira] [Created] (GEODE-5655) Flaky: org.apache.geode.session.tests.Jetty9Test.containersShouldShareDataRemovals fails intermittently

[Kirk Lund (JIRA)]

Kirk Lund created GEODE-5655:


 Summary: Flaky: 
org.apache.geode.session.tests.Jetty9Test.containersShouldShareDataRemovals 
fails intermittently
 Key: GEODE-5655
 URL: https://issues.apache.org/jira/browse/GEODE-5655
 Project: Geode
  Issue Type: Bug
  Components: tests
Reporter: Kirk Lund


{noformat}
> Task :geode-assembly:distributedTest

org.apache.geode.session.tests.Jetty9Test > containersShouldShareDataRemovals 
FAILED
org.codehaus.cargo.container.ContainerException: Failed to stop the Jetty 
9.4.8.v20171121 container. Check the 
[/home/geode/geode/geode-assembly/build/distributedTest108/cargo_logs/JETTY9_peer-to-peer_containersShouldShareDataRemovals_0_835922884062/container.log]
 file containing the container logs for more details.

Caused by:
org.codehaus.cargo.container.ContainerException: Server port 21121 did 
not shutdown within the timeout period [12]

166 tests completed, 1 failed

> Task :geode-assembly:distributedTest FAILED
{noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (GEODE-5641) DiskDirRule should have a public no-arg constructor

[Kirk Lund (JIRA)]

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

Kirk Lund resolved GEODE-5641.
--
   Resolution: Fixed
Fix Version/s: 1.7.0

> DiskDirRule should have a public no-arg constructor
> ---
>
> Key: GEODE-5641
> URL: https://issues.apache.org/jira/browse/GEODE-5641
> Project: Geode
>  Issue Type: Wish
>  Components: tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.7.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> DiskDirRule should have a public no-arg constructor for this usage:
> {noformat}
> @Rule
> public DiskDirRule diskDirRule = new DiskDirRule();
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GEODE-5641) DiskDirRule should have a public no-arg constructor

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-5641:


Commit ebe44c22d30774a916beca33c2316289a44ca3c5 in geode's branch 
refs/heads/develop from [~apa...@the9muses.net]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=ebe44c2 ]

GEODE-5641: add no-arg constructor to DiskDirRule

To redirect default disk store to a TemporaryFolder, you can simply
add this to any test:

@Rule
public DiskDirRule diskDirRule = new DiskDirRule();

Or in a DistributedTest use:

@Rule
public DistributedDiskDirRule diskDirRule = new DistributedDiskDirRule();


> DiskDirRule should have a public no-arg constructor
> ---
>
> Key: GEODE-5641
> URL: https://issues.apache.org/jira/browse/GEODE-5641
> Project: Geode
>  Issue Type: Wish
>  Components: tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> DiskDirRule should have a public no-arg constructor for this usage:
> {noformat}
> @Rule
> public DiskDirRule diskDirRule = new DiskDirRule();
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GEODE-5652) ExecutorServiceRule should create newCachedThreadPool by default

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot updated GEODE-5652:
--
Labels: pull-request-available  (was: )

> ExecutorServiceRule should create newCachedThreadPool by default
> 
>
> Key: GEODE-5652
> URL: https://issues.apache.org/jira/browse/GEODE-5652
> Project: Geode
>  Issue Type: Wish
>  Components: tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
>  Labels: pull-request-available
>
> ExecutorServiceRule currently defaults to creating a newFixedThreadPool of 
> size 1. Creating a newCachedThreadPool is a better default.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GEODE-5654) ThreadsMonitoringIntegrationTest is run as a UnitTest despite implicitly being an IntegrationTest

[Patrick Rhomberg (JIRA)]

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

Patrick Rhomberg updated GEODE-5654:

Labels: pull-request-available  (was: )

> ThreadsMonitoringIntegrationTest is run as a UnitTest despite implicitly 
> being an IntegrationTest
> -
>
> Key: GEODE-5654
> URL: https://issues.apache.org/jira/browse/GEODE-5654
> Project: Geode
>  Issue Type: Improvement
>  Components: tests
>Reporter: Patrick Rhomberg
>Priority: Major
>  Labels: pull-request-available
>
> This is causing failures as we attempt to reduce the infrastructure required 
> by the {{Build}} task in Concourse.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (GEODE-5654) ThreadsMonitoringIntegrationTest is run as a UnitTest despite implicitly being an IntegrationTest

[Patrick Rhomberg (JIRA)]

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

Patrick Rhomberg reassigned GEODE-5654:
---

Assignee: Patrick Rhomberg

> ThreadsMonitoringIntegrationTest is run as a UnitTest despite implicitly 
> being an IntegrationTest
> -
>
> Key: GEODE-5654
> URL: https://issues.apache.org/jira/browse/GEODE-5654
> Project: Geode
>  Issue Type: Improvement
>  Components: tests
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
>  Labels: pull-request-available
>
> This is causing failures as we attempt to reduce the infrastructure required 
> by the {{Build}} task in Concourse.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (GEODE-5654) ThreadsMonitoringIntegrationTest is run as a UnitTest despite implicitly being an IntegrationTest

[Patrick Rhomberg (JIRA)]

Patrick Rhomberg created GEODE-5654:
---

 Summary: ThreadsMonitoringIntegrationTest is run as a UnitTest 
despite implicitly being an IntegrationTest
 Key: GEODE-5654
 URL: https://issues.apache.org/jira/browse/GEODE-5654
 Project: Geode
  Issue Type: Improvement
  Components: tests
Reporter: Patrick Rhomberg


This is causing failures as we attempt to reduce the infrastructure required by 
the {{Build}} task in Concourse.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GEODE-5604) Make Geode build Gradle-5.0 ready

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-5604:


Commit b3cf86b7f8b0e27abe9ffc4cdb0fd18b7df0c3e2 in geode's branch 
refs/heads/develop from [~rhoughton]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=b3cf86b ]

GEODE-5604 Update gradle syntax to comply with 5.0 (#2350)

* Fix subproject names for gradle 5.0
** stop using '/' and use preferred ':' character for nested projects
* Update performance profiling plug-in to be Gradle 5.0 compliant
* Fix input/output warnings on geode-old-versions
* Don't use custom configuration in geode-modules-assembly
* All test configurations inherit annotationProcessor from mainSourceSet
* Using strict maven-publish plugin

Co-authored-by: Dick Cavender 
Co-authored-by: Jacob Barrett 
Co-authored-by: Patrick Rhomberg 
Co-authored-by: Robert Houghton 


> Make Geode build Gradle-5.0 ready
> -
>
> Key: GEODE-5604
> URL: https://issues.apache.org/jira/browse/GEODE-5604
> Project: Geode
>  Issue Type: Improvement
>  Components: build
>Reporter: Robert Houghton
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 2h 20m
>  Remaining Estimate: 0h
>
> Gradle is giving warnings about unsupported or deprecated features from our 
> 3.xx days. Clean them up.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GEODE-5601) AcceptanceTests are run in parallel without using containers, resulting in port conflicts

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot updated GEODE-5601:
--
Labels: flaky pull-request-available swat  (was: flaky swat)

> AcceptanceTests are run in parallel without using containers, resulting in 
> port conflicts
> -
>
> Key: GEODE-5601
> URL: https://issues.apache.org/jira/browse/GEODE-5601
> Project: Geode
>  Issue Type: Bug
>  Components: tests
>Reporter: Jacob S. Barrett
>Assignee: Kenneth Howe
>Priority: Major
>  Labels: flaky, pull-request-available, swat
>
> {noformat}
> org.apache.geode.management.internal.cli.commands.DeployWithLargeJarTest > 
> deployLargeSetOfJars FAILED
> org.junit.ComparisonFailure: expected:<[0]> but was:<[1]>
> 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.test.junit.rules.gfsh.GfshScript.awaitIfNecessary(GfshScript.java:117)
> at 
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:135)
> at 
> org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:106)
> at 
> org.apache.geode.management.internal.cli.commands.DeployWithLargeJarTest.deployLargeSetOfJars(DeployWithLargeJarTest.java:41)
> {noformat}
> Passes: 
> https://concourse.apachegeode-ci.info/teams/main/pipelines/pr-develop/jobs/AcceptanceTest/builds/721
> Fails: 
> https://concourse.apachegeode-ci.info/teams/main/pipelines/pr-develop/jobs/AcceptanceTest/builds/728



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GEODE-5633) PR pipelines deployed by meta should include fork name AND branch name

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-5633:


Commit 7b6f5fa0ca05fa21a713070fc8ad87badd3e4684 in geode's branch 
refs/heads/develop from FSOUTHERLAND
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=7b6f5fa ]

GEODE-5633 pr pipeline name has fork and branch (#2391)

Authored-by: Finn Southerland 

> PR pipelines deployed by meta should include fork name AND branch name
> --
>
> Key: GEODE-5633
> URL: https://issues.apache.org/jira/browse/GEODE-5633
> Project: Geode
>  Issue Type: Task
>  Components: ci
>Reporter: Finn Southerland
>Priority: Major
>
> The name for pr pipelines created on forks currently is `pr-<>`. 
> This is inconsistent with the other pipelines and risks naming collisions. 
> This should be easy to fix as the name is only referenced on creation.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (GEODE-5624) JTA transaction does not clean up TXState due to IllegalMonitorStateException

[Eric Shu (JIRA)]

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

Eric Shu resolved GEODE-5624.
-
   Resolution: Fixed
Fix Version/s: 1.7.0

> JTA transaction does not clean up TXState due to IllegalMonitorStateException
> -
>
> Key: GEODE-5624
> URL: https://issues.apache.org/jira/browse/GEODE-5624
> Project: Geode
>  Issue Type: Bug
>  Components: transactions
>Affects Versions: 1.7.0
>Reporter: Eric Shu
>Assignee: Eric Shu
>Priority: Major
> Fix For: 1.7.0
>
>
> When server has different threads handling JTA beforeCompletion and 
> afterCompletion, IllegalMonitorStateException can be thrown when release 
> locks held. This causes the TXState not being cleaned up.
> {noformat}
> java.lang.IllegalMonitorStateException: attempt to unlock read lock, not 
> locked by current thread
> at 
> java.util.concurrent.locks.ReentrantReadWriteLock$Sync.unmatchedUnlockException(ReentrantReadWriteLock.java:444)
> at 
> java.util.concurrent.locks.ReentrantReadWriteLock$Sync.tryReleaseShared(ReentrantReadWriteLock.java:428)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.releaseShared(AbstractQueuedSynchronizer.java:1341)
> at 
> java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.unlock(ReentrantReadWriteLock.java:881)
> at 
> org.apache.geode.internal.util.concurrent.StoppableReentrantReadWriteLock$StoppableReadLock.unlock(StoppableReentrantReadWriteLock.java:144)
> at 
> org.apache.geode.internal.cache.locks.TXLockServiceImpl.releaseRecoveryReadLock(TXLockServiceImpl.java:275)
> at 
> org.apache.geode.internal.cache.locks.TXLockServiceImpl.release(TXLockServiceImpl.java:240)
> at 
> org.apache.geode.internal.cache.TXLockRequest.releaseDistributed(TXLockRequest.java:109)
> at 
> org.apache.geode.internal.cache.TXLockRequest.cleanup(TXLockRequest.java:142)
> at org.apache.geode.internal.cache.TXState.cleanup(TXState.java:870)
> at org.apache.geode.internal.cache.TXState.commit(TXState.java:514)
> at 
> org.apache.geode.internal.cache.TXState.doAfterCompletion(TXState.java:1103)
> at 
> org.apache.geode.internal.cache.TXState.afterCompletion(TXState.java:1084)
> at 
> org.apache.geode.internal.cache.TXStateProxyImpl.afterCompletion(TXStateProxyImpl.java:452)
> at 
> org.apache.geode.internal.cache.tier.sockets.command.TXSynchronizationCommand.cmdExecute(TXSynchronizationCommand.java:140)
> at 
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:158)
> at 
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMsg(ServerConnection.java:869)
> at 
> org.apache.geode.internal.cache.tier.sockets.OriginalServerConnection.doOneMessage(OriginalServerConnection.java:77)
> at 
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1248)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at 
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl$4$1.run(AcceptorImpl.java:645)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GEODE-5624) JTA transaction does not clean up TXState due to IllegalMonitorStateException

[Eric Shu (JIRA)]

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

Eric Shu updated GEODE-5624:

Affects Version/s: 1.7.0

> JTA transaction does not clean up TXState due to IllegalMonitorStateException
> -
>
> Key: GEODE-5624
> URL: https://issues.apache.org/jira/browse/GEODE-5624
> Project: Geode
>  Issue Type: Bug
>  Components: transactions
>Affects Versions: 1.7.0
>Reporter: Eric Shu
>Assignee: Eric Shu
>Priority: Major
> Fix For: 1.7.0
>
>
> When server has different threads handling JTA beforeCompletion and 
> afterCompletion, IllegalMonitorStateException can be thrown when release 
> locks held. This causes the TXState not being cleaned up.
> {noformat}
> java.lang.IllegalMonitorStateException: attempt to unlock read lock, not 
> locked by current thread
> at 
> java.util.concurrent.locks.ReentrantReadWriteLock$Sync.unmatchedUnlockException(ReentrantReadWriteLock.java:444)
> at 
> java.util.concurrent.locks.ReentrantReadWriteLock$Sync.tryReleaseShared(ReentrantReadWriteLock.java:428)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.releaseShared(AbstractQueuedSynchronizer.java:1341)
> at 
> java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.unlock(ReentrantReadWriteLock.java:881)
> at 
> org.apache.geode.internal.util.concurrent.StoppableReentrantReadWriteLock$StoppableReadLock.unlock(StoppableReentrantReadWriteLock.java:144)
> at 
> org.apache.geode.internal.cache.locks.TXLockServiceImpl.releaseRecoveryReadLock(TXLockServiceImpl.java:275)
> at 
> org.apache.geode.internal.cache.locks.TXLockServiceImpl.release(TXLockServiceImpl.java:240)
> at 
> org.apache.geode.internal.cache.TXLockRequest.releaseDistributed(TXLockRequest.java:109)
> at 
> org.apache.geode.internal.cache.TXLockRequest.cleanup(TXLockRequest.java:142)
> at org.apache.geode.internal.cache.TXState.cleanup(TXState.java:870)
> at org.apache.geode.internal.cache.TXState.commit(TXState.java:514)
> at 
> org.apache.geode.internal.cache.TXState.doAfterCompletion(TXState.java:1103)
> at 
> org.apache.geode.internal.cache.TXState.afterCompletion(TXState.java:1084)
> at 
> org.apache.geode.internal.cache.TXStateProxyImpl.afterCompletion(TXStateProxyImpl.java:452)
> at 
> org.apache.geode.internal.cache.tier.sockets.command.TXSynchronizationCommand.cmdExecute(TXSynchronizationCommand.java:140)
> at 
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:158)
> at 
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMsg(ServerConnection.java:869)
> at 
> org.apache.geode.internal.cache.tier.sockets.OriginalServerConnection.doOneMessage(OriginalServerConnection.java:77)
> at 
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1248)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at 
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl$4$1.run(AcceptorImpl.java:645)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (GEODE-5653) Race between put of parallel WAN sender event and distributed clear causes off-heap orphan

[Ryan McMahon (JIRA)]

Ryan McMahon created GEODE-5653:
---

 Summary: Race between put of parallel WAN sender event and 
distributed clear causes off-heap orphan
 Key: GEODE-5653
 URL: https://issues.apache.org/jira/browse/GEODE-5653
 Project: Geode
  Issue Type: Bug
  Components: offheap, regions, wan
Reporter: Ryan McMahon


A race resulting in an off-heap orphan can occur with Parallel WAN when 
off-heap is enabled on the cache and user's data region.  It is the result of 
the put occurring in two distinct steps without proper synchronization.  The 
initial value of the region entry is Token.REMOVED_PHASE_1 (step 1) then later 
is replaced with actual GatewaySenderEvent (step 2).  If a distributed clear is 
processed between these two steps, it can result in an orphan.  More details on 
the race are described below.

The race is between:
*Thread 1*. A put of a {{GatewaySenderEvent}} containing an off-heap value to 
one of the WAN "shadow" region's {{BucketRegionQueue}}
and
*Thread 2*. A distributed clear on the {{BucketRegionQueue}} containing that 
value

The race occurs as follows:
*Thread 1 (Put)*: Put results in a new region entry where the value is 
{{Token.REMOVED_PHASE1}} and put it into the {{CustomEntryConcurrentHashMap}} 
owned by the {{AbstractRegionMap}}.
*Thread 2 (Clear)*: Iterates through bucket region's segments and clears the 
entries.  At this time the value is still {{Token.REMOVED_PHASE_1}}.
*Thread 1 (Put)*: The {{Token.REMOVED_PHASE_1}} is replaced with the actual 
{{GatewaySenderEvent}} in the region entry.  However, the entry was removed via 
the clear above.  When the entry is removed from the region, its off-heap is 
orphaned because it is no longer in the {{CustomEntryConcurrentHashMap}}.




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GEODE-5645) Client cache misses invalidate

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot updated GEODE-5645:
--
Labels: pull-request-available  (was: )

> Client cache misses invalidate
> --
>
> Key: GEODE-5645
> URL: https://issues.apache.org/jira/browse/GEODE-5645
> Project: Geode
>  Issue Type: Bug
>  Components: client queues
>Reporter: Bruce Schuchardt
>Priority: Major
>  Labels: pull-request-available
>
> In a test with four clients and four servers with the clients performing 
> concurrent operations on the same keys one of the clients missed an 
> "invalidate" event and ended up being inconsistent.
> There was a cache entry in the servers sitting at version 2.  Client4 is the 
> cache that ends up being inconsistent by way of its subscription feed.
> client1 does v3 invalidate with server1
> client2 does v4 update with server2
> client3 does v5 invalidate with server3
> server4 receives v3 invalidate and informs clients
> client4 gets v3 invalidate through subscription
> server4 receives v5 invalidate and ignores it because its already invalidated
> server4 receives v4 update from server2
> server4 throws concurrency conflict exception for v4 update
> client4 gets v4 update (applied as a create) from server4 through subscription
> Clients with queues on other servers get the ops in order and end up with an 
> invalidated entry.
> client4 does not get the final invalidate event and is inconsistent wrt other 
> clients and the servers.
> With fine level logging the log statement that shows the problem happening is 
> this:
> {noformat}
> mapInvalidate: Entry already invalid: 'Object_1683'
> {noformat}
> Where Object_1683 is the key for the entry we're dealing with.
> The code doing this is in AbstractRegionMap's invalidate() method:
> {code}
> if (oldRe.isInvalid()) {
> // was already invalid, do not invoke listeners or 
> increment stat
> if (isDebugEnabled) {
>   logger.debug("mapInvalidate: Entry already invalid: 
> '{}'",
>   event.getKey());
> }
> processVersionTag(oldRe, event);
> try {
>   oldRe.setValue(owner, oldRe.getValueInVM(owner)); 
> // OFFHEAP noop setting
> 
> // an already invalid to
> 
> // invalid; No need to
> 
> // call
> 
> // prepareValueForCache
> 
> // since it is an
> 
> // invalid token.
> } catch (RegionClearedException e) {
>   // that's okay - when writing an invalid into a 
> disk, the
>   // region has been cleared (including this token)
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GEODE-5637) Flaky: SingleHopClientExecutorSubmitTaskWithExceptionTest fails intermittently

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-5637:


Commit b66beba19c8457eaa684a3d03100c2755c68aab0 in geode's branch 
refs/heads/develop from [~apa...@the9muses.net]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=b66beba ]

GEODE-5637: move SingleHopClientExecutorSubmitTaskWithExceptionTest to 
integrationTest

* Increase Awaitility timeout due to flaky failure
* Cleanup test and use AssertJ


> Flaky: SingleHopClientExecutorSubmitTaskWithExceptionTest fails intermittently
> --
>
> Key: GEODE-5637
> URL: https://issues.apache.org/jira/browse/GEODE-5637
> Project: Geode
>  Issue Type: Bug
>  Components: tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
>  Labels: flaky, pull-request-available, swat
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> This test should also be an integration test but it's in the test src set.
> {noformat}
> > Task :geode-core:test
> org.apache.geode.cache.client.internal.SingleHopClientExecutorSubmitTaskWithExceptionTest
>  > submittedTaskShouldLogFailure FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition 
> defined as a lambda expression in 
> org.apache.geode.cache.client.internal.SingleHopClientExecutorSubmitTaskWithExceptionTest
>  
> Expecting:
>  <"">
> to contain:
>  <"I am expecting this to be logged">  within 2 minutes.
> at 
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:145)
> at 
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:122)
> at 
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:32)
> at 
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:890)
> at 
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:711)
> at 
> org.apache.geode.cache.client.internal.SingleHopClientExecutorSubmitTaskWithExceptionTest.submittedTaskShouldLogFailure(SingleHopClientExecutorSubmitTaskWithExceptionTest.java:54)
> Caused by:
> java.lang.AssertionError: 
> Expecting:
>  <"">
> to contain:
>  <"I am expecting this to be logged"> 
> at 
> org.apache.geode.cache.client.internal.SingleHopClientExecutorSubmitTaskWithExceptionTest.lambda$submittedTaskShouldLogFailure$1(SingleHopClientExecutorSubmitTaskWithExceptionTest.java:54)
> 4490 tests completed, 1 failed, 9 skipped
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GEODE-5338) Geode client to support Trust and Keystore rotation

[Sai Boorlagadda (JIRA)]

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

Sai Boorlagadda updated GEODE-5338:
---
Fix Version/s: 1.7.0

> Geode client to support Trust and Keystore rotation
> ---
>
> Key: GEODE-5338
> URL: https://issues.apache.org/jira/browse/GEODE-5338
> Project: Geode
>  Issue Type: Improvement
>  Components: docs, security
>Reporter: Pulkit Chandra
>Assignee: Sai Boorlagadda
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.7.0
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> WHY: Cloud Foundry provides ability to rotate certs pretty frequently. By 
> default the certs are rotated every day and change be changed to rotate every 
> hour. Which creates a issue with Java applications. This rotation is 
> essential to provide a strong security stance on client applications.
> WHAT: Today Geode client applications, when establishing a TLS connection to 
> the servers requires a path to the certificate, since these files would be 
> changing we need a mechanism in Geode which will watch for these changes and 
> use the new certs without causing service disruption.
>  
> Solution options:
> Some options to consider
>  # Cloud Foundry has a lib which watches for changes to these certs (which 
> are in pem format)and converts them and creates inmemory objects of 
> TrustStore and KeyStore. If we have a mechanism in Geode to pass these 
> objects instead of path to them, we might have a solution. Also, these 
> objects gets updates after rotation so the geode code needs to consider that 
> as well.
>  # Geode can develop its own capability to watch for change on the files and 
> convert them to right format using OpenSSL and create files and pass them in. 
> Update these file everytime someone updates the certs
>  # Geode starts accepting pem files and watches them directly for changes.
>  
> Key Outcomes to watch for:
>  1. Provide ability to rotate cert easily without downtime.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (GEODE-5338) Geode client to support Trust and Keystore rotation

[Sai Boorlagadda (JIRA)]

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

Sai Boorlagadda reassigned GEODE-5338:
--

Assignee: Sai Boorlagadda

> Geode client to support Trust and Keystore rotation
> ---
>
> Key: GEODE-5338
> URL: https://issues.apache.org/jira/browse/GEODE-5338
> Project: Geode
>  Issue Type: Improvement
>  Components: docs, security
>Reporter: Pulkit Chandra
>Assignee: Sai Boorlagadda
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.7.0
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> WHY: Cloud Foundry provides ability to rotate certs pretty frequently. By 
> default the certs are rotated every day and change be changed to rotate every 
> hour. Which creates a issue with Java applications. This rotation is 
> essential to provide a strong security stance on client applications.
> WHAT: Today Geode client applications, when establishing a TLS connection to 
> the servers requires a path to the certificate, since these files would be 
> changing we need a mechanism in Geode which will watch for these changes and 
> use the new certs without causing service disruption.
>  
> Solution options:
> Some options to consider
>  # Cloud Foundry has a lib which watches for changes to these certs (which 
> are in pem format)and converts them and creates inmemory objects of 
> TrustStore and KeyStore. If we have a mechanism in Geode to pass these 
> objects instead of path to them, we might have a solution. Also, these 
> objects gets updates after rotation so the geode code needs to consider that 
> as well.
>  # Geode can develop its own capability to watch for change on the files and 
> convert them to right format using OpenSSL and create files and pass them in. 
> Update these file everytime someone updates the certs
>  # Geode starts accepting pem files and watches them directly for changes.
>  
> Key Outcomes to watch for:
>  1. Provide ability to rotate cert easily without downtime.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GEODE-5338) Geode client to support Trust and Keystore rotation

[Sai Boorlagadda (JIRA)]

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

Sai Boorlagadda updated GEODE-5338:
---
Component/s: docs

> Geode client to support Trust and Keystore rotation
> ---
>
> Key: GEODE-5338
> URL: https://issues.apache.org/jira/browse/GEODE-5338
> Project: Geode
>  Issue Type: Improvement
>  Components: docs, security
>Reporter: Pulkit Chandra
>Assignee: Sai Boorlagadda
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.7.0
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> WHY: Cloud Foundry provides ability to rotate certs pretty frequently. By 
> default the certs are rotated every day and change be changed to rotate every 
> hour. Which creates a issue with Java applications. This rotation is 
> essential to provide a strong security stance on client applications.
> WHAT: Today Geode client applications, when establishing a TLS connection to 
> the servers requires a path to the certificate, since these files would be 
> changing we need a mechanism in Geode which will watch for these changes and 
> use the new certs without causing service disruption.
>  
> Solution options:
> Some options to consider
>  # Cloud Foundry has a lib which watches for changes to these certs (which 
> are in pem format)and converts them and creates inmemory objects of 
> TrustStore and KeyStore. If we have a mechanism in Geode to pass these 
> objects instead of path to them, we might have a solution. Also, these 
> objects gets updates after rotation so the geode code needs to consider that 
> as well.
>  # Geode can develop its own capability to watch for change on the files and 
> convert them to right format using OpenSSL and create files and pass them in. 
> Update these file everytime someone updates the certs
>  # Geode starts accepting pem files and watches them directly for changes.
>  
> Key Outcomes to watch for:
>  1. Provide ability to rotate cert easily without downtime.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (GEODE-5650) Improve ClusterStartupRule tear down

[Sai Boorlagadda (JIRA)]

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

Sai Boorlagadda resolved GEODE-5650.

   Resolution: Fixed
Fix Version/s: 1.7.0

> Improve ClusterStartupRule tear down
> 
>
> Key: GEODE-5650
> URL: https://issues.apache.org/jira/browse/GEODE-5650
> Project: Geode
>  Issue Type: Improvement
>  Components: tests
>Reporter: Sai Boorlagadda
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.7.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> in CSRule teardown if we close suspect buffer before closing cache can cause 
> some background threads (eg: client pool) to keep sending events and log 
> exceptions (if any) could result in the next test to fail for suspects. So 
> close the suspect buffer after closing cache in all VMs.
> {code:java}
>   protected void after() {
> try {
>   DUnitLauncher.closeAndCheckForSuspects();
> } finally {
>   MemberStarterRule.disconnectDSIfAny();
>   // stop all the members in the order of clients, servers and locators
>   List vms = new ArrayList<>();
>   vms.addAll(
>   occupiedVMs.values().stream().filter(x -> 
> x.isClient()).collect(Collectors.toSet()));
>   vms.addAll(
>   occupiedVMs.values().stream().filter(x -> 
> x.isServer()).collect(Collectors.toSet()));
>   vms.addAll(
>   occupiedVMs.values().stream().filter(x -> 
> x.isLocator()).collect(Collectors.toSet()));
>   vms.forEach(x -> x.stop());
>   // delete any file under root dir
>   Arrays.stream(getWorkingDirRoot().listFiles()).filter(File::isFile)
>   .forEach(FileUtils::deleteQuietly);
>   restoreSystemProperties.after();
> }
>   }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GEODE-5594) Enable endpoint validation during using SSL handshake

[Sai Boorlagadda (JIRA)]

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

Sai Boorlagadda updated GEODE-5594:
---
Fix Version/s: 1.7.0

> Enable endpoint validation during using SSL handshake
> -
>
> Key: GEODE-5594
> URL: https://issues.apache.org/jira/browse/GEODE-5594
> Project: Geode
>  Issue Type: Improvement
>  Components: client/server, docs
>Reporter: Sai Boorlagadda
>Assignee: Sai Boorlagadda
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.7.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> Users can set `ssl-endpoint-identification-enabled` to true to enable 
> validation of hostname in server's identity when using SSL to harden against 
> certain man-in-the-middle attacks 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (GEODE-5650) Improve ClusterStartupRule tear down

[Sai Boorlagadda (JIRA)]

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

Sai Boorlagadda closed GEODE-5650.
--

> Improve ClusterStartupRule tear down
> 
>
> Key: GEODE-5650
> URL: https://issues.apache.org/jira/browse/GEODE-5650
> Project: Geode
>  Issue Type: Improvement
>  Components: tests
>Reporter: Sai Boorlagadda
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.7.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> in CSRule teardown if we close suspect buffer before closing cache can cause 
> some background threads (eg: client pool) to keep sending events and log 
> exceptions (if any) could result in the next test to fail for suspects. So 
> close the suspect buffer after closing cache in all VMs.
> {code:java}
>   protected void after() {
> try {
>   DUnitLauncher.closeAndCheckForSuspects();
> } finally {
>   MemberStarterRule.disconnectDSIfAny();
>   // stop all the members in the order of clients, servers and locators
>   List vms = new ArrayList<>();
>   vms.addAll(
>   occupiedVMs.values().stream().filter(x -> 
> x.isClient()).collect(Collectors.toSet()));
>   vms.addAll(
>   occupiedVMs.values().stream().filter(x -> 
> x.isServer()).collect(Collectors.toSet()));
>   vms.addAll(
>   occupiedVMs.values().stream().filter(x -> 
> x.isLocator()).collect(Collectors.toSet()));
>   vms.forEach(x -> x.stop());
>   // delete any file under root dir
>   Arrays.stream(getWorkingDirRoot().listFiles()).filter(File::isFile)
>   .forEach(FileUtils::deleteQuietly);
>   restoreSystemProperties.after();
> }
>   }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GEODE-5650) Improve ClusterStartupRule tear down

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-5650:


Commit 8382f8cff8120076fa9af7816e8454575c3a189c in geode's branch 
refs/heads/develop from [~sai.boorlaga...@gmail.com]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=8382f8c ]

GEODE-5650: Improve ClusterStartupRule tear down (#2392)



> Improve ClusterStartupRule tear down
> 
>
> Key: GEODE-5650
> URL: https://issues.apache.org/jira/browse/GEODE-5650
> Project: Geode
>  Issue Type: Improvement
>  Components: tests
>Reporter: Sai Boorlagadda
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> in CSRule teardown if we close suspect buffer before closing cache can cause 
> some background threads (eg: client pool) to keep sending events and log 
> exceptions (if any) could result in the next test to fail for suspects. So 
> close the suspect buffer after closing cache in all VMs.
> {code:java}
>   protected void after() {
> try {
>   DUnitLauncher.closeAndCheckForSuspects();
> } finally {
>   MemberStarterRule.disconnectDSIfAny();
>   // stop all the members in the order of clients, servers and locators
>   List vms = new ArrayList<>();
>   vms.addAll(
>   occupiedVMs.values().stream().filter(x -> 
> x.isClient()).collect(Collectors.toSet()));
>   vms.addAll(
>   occupiedVMs.values().stream().filter(x -> 
> x.isServer()).collect(Collectors.toSet()));
>   vms.addAll(
>   occupiedVMs.values().stream().filter(x -> 
> x.isLocator()).collect(Collectors.toSet()));
>   vms.forEach(x -> x.stop());
>   // delete any file under root dir
>   Arrays.stream(getWorkingDirRoot().listFiles()).filter(File::isFile)
>   .forEach(FileUtils::deleteQuietly);
>   restoreSystemProperties.after();
> }
>   }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GEODE-5608) Meta pipeline can generate images and instances with names longer than max allowed by GCP

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-5608:


Commit aa915c2ba7d07a641c8ec65f473dd60f44806606 in geode's branch 
refs/heads/feature/GEODE-5338 from FSOUTHERLAND
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=aa915c2 ]

GEODE-5608 truncate fork/branch names in image/instance naming (#2390)

* GEODE-5608 truncate fork/branch names in image/instance naming (#2363)

Co-authored-by: Jacob Barrett 
Co-authored-by: Finn Southerland 
Co-authored-by: Robert Houghton 


> Meta pipeline can generate images and instances with names longer than max 
> allowed by GCP
> -
>
> Key: GEODE-5608
> URL: https://issues.apache.org/jira/browse/GEODE-5608
> Project: Geode
>  Issue Type: Task
>  Components: ci
>Reporter: Finn Southerland
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> GCP does not allow names with more than 64 characters, so we should somehow 
> ensure that we do not generate names that are longer than this. Contributors 
> to especially long names are long fork/branch names especially.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GEODE-5646) Client throws ToDataException when locator is shutting down

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-5646:


Commit 3651a9a9b3819948da18e02b7fc64c3493f6d886 in geode's branch 
refs/heads/feature/GEODE-5338 from [~bschuchardt]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=3651a9a ]

GEODE-5646 Client throws ToDataException when locator is shutting down

Catch and handle ToDataException.  Reviewed by mhanson


> Client throws ToDataException when locator is shutting down
> ---
>
> Key: GEODE-5646
> URL: https://issues.apache.org/jira/browse/GEODE-5646
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Reporter: Bruce Schuchardt
>Assignee: Bruce Schuchardt
>Priority: Major
> Fix For: 1.8.0
>
>
> This hasn't been seen in Geode but in an older version of Pivotal GemFire.  
> The code in question hasn't changed so we ought to fix it.
> {noformat}
> ERROR util.TestException: doEntryOperations caught Exception 
> com.gemstone.gemfire.ToDataException: toData failed on DataSerializable class 
> com.gemstone.gemfire.distributed.internal.ServerLocation
>   at 
> com.gemstone.gemfire.internal.InternalDataSerializer.invokeToData(InternalDataSerializer.java:2424)
>   at 
> com.gemstone.gemfire.cache.client.internal.locator.SerializationHelper.writeServerLocations(SerializationHelper.java:39)
>   at 
> com.gemstone.gemfire.cache.client.internal.locator.SerializationHelper.writeServerLocationSet(SerializationHelper.java:75)
>   at 
> com.gemstone.gemfire.cache.client.internal.locator.ClientConnectionRequest.toData(ClientConnectionRequest.java:44)
>   at 
> com.gemstone.gemfire.internal.InternalDataSerializer.invokeToData(InternalDataSerializer.java:2411)
>   at 
> com.gemstone.gemfire.internal.InternalDataSerializer.writeDSFID(InternalDataSerializer.java:1382)
>   at 
> com.gemstone.gemfire.internal.InternalDataSerializer.basicWriteObject(InternalDataSerializer.java:2156)
>   at 
> com.gemstone.gemfire.DataSerializer.writeObject(DataSerializer.java:3181)
>   at 
> com.gemstone.org.jgroups.stack.tcpserver.TcpClient.requestToServer(TcpClient.java:115)
>   at 
> com.gemstone.org.jgroups.stack.tcpserver.TcpClient.requestToServer(TcpClient.java:78)
>   at 
> com.gemstone.gemfire.cache.client.internal.AutoConnectionSourceImpl.queryOneLocator(AutoConnectionSourceImpl.java:188)
>   at 
> com.gemstone.gemfire.cache.client.internal.AutoConnectionSourceImpl.queryLocators(AutoConnectionSourceImpl.java:220)
>   at 
> com.gemstone.gemfire.cache.client.internal.AutoConnectionSourceImpl.findServer(AutoConnectionSourceImpl.java:132)
>   at 
> com.gemstone.gemfire.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:227)
>   at 
> com.gemstone.gemfire.cache.client.internal.pooling.ConnectionManagerImpl.exchangeConnection(ConnectionManagerImpl.java:421)
>   at 
> com.gemstone.gemfire.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:173)
>   at 
> com.gemstone.gemfire.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:115)
>   at 
> com.gemstone.gemfire.cache.client.internal.PoolImpl.execute(PoolImpl.java:702)
>   at 
> com.gemstone.gemfire.cache.client.internal.KeySetOp.execute(KeySetOp.java:38)
>   at 
> com.gemstone.gemfire.cache.client.internal.ServerRegionProxy.keySet(ServerRegionProxy.java:348)
>   at 
> com.gemstone.gemfire.internal.cache.LocalRegion.keySetOnServer(LocalRegion.java:4159)
> {noformat}
> The client is trying to serialize ServerLocation objects and send them to a 
> locator. AutoConnectionSourceImpl.queryOneLocator() has code to handle 
> IOException and report the locator as being down but since ServerLocation 
> isn't a DataSerializableFixedID instance the serialization code throws a 
> ToDataException instead of an IOException. Adding ToDataException handling to 
> queryOneLocator() should fix the problem.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GEODE-5608) Meta pipeline can generate images and instances with names longer than max allowed by GCP

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-5608:


Commit aa915c2ba7d07a641c8ec65f473dd60f44806606 in geode's branch 
refs/heads/feature/GEODE-5338 from FSOUTHERLAND
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=aa915c2 ]

GEODE-5608 truncate fork/branch names in image/instance naming (#2390)

* GEODE-5608 truncate fork/branch names in image/instance naming (#2363)

Co-authored-by: Jacob Barrett 
Co-authored-by: Finn Southerland 
Co-authored-by: Robert Houghton 


> Meta pipeline can generate images and instances with names longer than max 
> allowed by GCP
> -
>
> Key: GEODE-5608
> URL: https://issues.apache.org/jira/browse/GEODE-5608
> Project: Geode
>  Issue Type: Task
>  Components: ci
>Reporter: Finn Southerland
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> GCP does not allow names with more than 64 characters, so we should somehow 
> ensure that we do not generate names that are longer than this. Contributors 
> to especially long names are long fork/branch names especially.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GEODE-5618) FunctionService.onServer() and FunctionService.onRegion() fail when multiuser-authentication=true

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-5618:


Commit 60ea939e85e7d94da9d8eb64d5b88dd62edb2618 in geode's branch 
refs/heads/feature/GEODE-5338 from Juan José Ramos
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=60ea939 ]

GEODE-5618: Auth Attributes in FunctionService (#2360)

   * When a client executes a function using the id instead of the actual 
instance, an internal invocation to the `GetFunctionAttributeOp` function is 
executed to get the metadata about the original function itself. This 
invocation doesn't set the user attributes requried by the authentication 
mechanism, so the entire invocation fails.
   * Added distributed tests.
   * Classes `ServerFunctionExecutor` and `ServerRegionFunctionExecutor` now 
set the `userAttributes` in the local thread before getting the metadata when 
the function is executed by id.

> FunctionService.onServer() and FunctionService.onRegion() fail when 
> multiuser-authentication=true
> -
>
> Key: GEODE-5618
> URL: https://issues.apache.org/jira/browse/GEODE-5618
> Project: Geode
>  Issue Type: Bug
>  Components: functions, security
>Reporter: Juan José Ramos Cassella
>Assignee: Juan José Ramos Cassella
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> The problem resides within the {{ServerFunctionExecutor}} class, specifically 
> in the following section of code:
> {code:title=ServerFunctionExecutor.java|borderStyle=solid}
> public ResultCollector execute(final String functionName) {
> (...)
>  byte[] functionAttributes = getFunctionAttributes(functionName);
>  if (functionAttributes == null) {
>  Object obj = GetFunctionAttributeOp.execute(this.pool, functionName);
>  functionAttributes = (byte[]) obj;
>  addFunctionAttributes(functionName, functionAttributes);
>  }
> (..)
> }
> {code}
> We are specifically executing an internal function (namely 
> {{GetFunctionAttributeOp}}) to retrieve the metadata for the function 
> executed by the client *without setting the user attributes* required by the 
> authentication mechanism and, as such, the execution fails for this 
> particular function instead of the one executed by the client (it's not even 
> part of the stack trace):
> {noformat}
> Exception in thread "main" java.lang.UnsupportedOperationException: Use Pool 
> APIs for doing operations when multiuser-secure-mode-enabled is set to true.
>  at 
> org.apache.geode.cache.client.internal.PoolImpl.authenticateIfRequired(PoolImpl.java:1549)
>  at 
> org.apache.geode.cache.client.internal.PoolImpl.authenticateIfRequired(PoolImpl.java:1531)
>  at org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:781)
>  at 
> org.apache.geode.cache.client.internal.GetFunctionAttributeOp.execute(GetFunctionAttributeOp.java:24)
>  at 
> org.apache.geode.internal.cache.execute.ServerFunctionExecutor.execute(ServerFunctionExecutor.java:310)
> {noformat}
> The other top-level methods from {{ServerFunctionExecutor}} and 
> {{ServerRegionFunctionExecutor}} configure the user attributes before 
> actually executing the function, that's why (as a workaround), the user can 
> use {{FunctionService.onServer(regionService).execute(new MyFunction())}}, 
> works as expected:
> {code}
>  if (proxyCache != null) {
>  if (this.proxyCache.isClosed()) {
>  throw proxyCache.getCacheClosedException("Cache is closed for this user.");
>  }
>  UserAttributes.userAttributes.set(this.proxyCache.getUserAttributes());
>  }
> {code}
> The solution would be to add the same _pre-operation logic_ to the buggy 
> method.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GEODE-5620) Add project property to control fork parallelism

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-5620:


Commit 0cbf8e5e5221b9d397edbca26a03995c8ed20a68 in geode's branch 
refs/heads/feature/GEODE-5338 from [~bschuchardt]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=0cbf8e5 ]

GEODE-5620: Adds project property to control test forking

Fixing testMaxParalleForks property handling.  The code was using
the character code for the number assigned to the property.  It needed
to parse the value to turn it into the requested number.


> Add project property to control fork parallelism
> 
>
> Key: GEODE-5620
> URL: https://issues.apache.org/jira/browse/GEODE-5620
> Project: Geode
>  Issue Type: Improvement
>  Components: build
>Reporter: Jacob S. Barrett
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Add {{-PtestMaxParallelForks}} project property to control max parallel forks.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GEODE-5608) Meta pipeline can generate images and instances with names longer than max allowed by GCP

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-5608:


Commit 366594ca6f4807b6dfaa1fc9162f3760ecd18a58 in geode's branch 
refs/heads/feature/GEODE-5338 from Jacob Barrett
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=366594c ]

Revert "GEODE-5608 truncate fork/branch names in image/instance naming (#2363)"

This reverts commit 58e4035f7678e7198bb3c59f719d94a27a9144b2.


> Meta pipeline can generate images and instances with names longer than max 
> allowed by GCP
> -
>
> Key: GEODE-5608
> URL: https://issues.apache.org/jira/browse/GEODE-5608
> Project: Geode
>  Issue Type: Task
>  Components: ci
>Reporter: Finn Southerland
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> GCP does not allow names with more than 64 characters, so we should somehow 
> ensure that we do not generate names that are longer than this. Contributors 
> to especially long names are long fork/branch names especially.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GEODE-5642) cleanAll task is no longer necessary

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-5642:


Commit 48fe306dcb699f64c15f8e8faba6fc2246ee45d1 in geode's branch 
refs/heads/feature/GEODE-5338 from FSOUTHERLAND
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=48fe306 ]

GEODE-5642 remove gradle task :cleanAll (#2385)

Co-authored-by: Finn Southerland 


> cleanAll task is no longer necessary
> 
>
> Key: GEODE-5642
> URL: https://issues.apache.org/jira/browse/GEODE-5642
> Project: Geode
>  Issue Type: Task
>  Components: build
>Reporter: Finn Southerland
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Because the project structure has changed, we no longer need a custom 
> 'cleanAll' task to delete the root build directory. We should remove it.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GEODE-5608) Meta pipeline can generate images and instances with names longer than max allowed by GCP

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-5608:


Commit 58e4035f7678e7198bb3c59f719d94a27a9144b2 in geode's branch 
refs/heads/feature/GEODE-5338 from FSOUTHERLAND
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=58e4035 ]

GEODE-5608 truncate fork/branch names in image/instance naming (#2363)


Co-authored-by: Jacob Barrett 
Co-authored-by: Finn Southerland 
Co-authored-by: Robert Houghton 


> Meta pipeline can generate images and instances with names longer than max 
> allowed by GCP
> -
>
> Key: GEODE-5608
> URL: https://issues.apache.org/jira/browse/GEODE-5608
> Project: Geode
>  Issue Type: Task
>  Components: ci
>Reporter: Finn Southerland
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> GCP does not allow names with more than 64 characters, so we should somehow 
> ensure that we do not generate names that are longer than this. Contributors 
> to especially long names are long fork/branch names especially.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GEODE-5594) Enable endpoint validation during using SSL handshake

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-5594:


Commit fd29e625c482c9b983d69a4b1ad2abee3775a69b in geode's branch 
refs/heads/feature/GEODE-5338 from [~sai.boorlaga...@gmail.com]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=fd29e62 ]

GEODE-5594: Enable endpoint identification during using SSL handshake. (#2346)

   User can enable endpoint identification during SSL handshake
   to validate server's hostname with server's identity.

   New boolean property ssl-endpoint-validation-enabled is added.

> Enable endpoint validation during using SSL handshake
> -
>
> Key: GEODE-5594
> URL: https://issues.apache.org/jira/browse/GEODE-5594
> Project: Geode
>  Issue Type: Improvement
>  Components: client/server, docs
>Reporter: Sai Boorlagadda
>Assignee: Sai Boorlagadda
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> Users can set `ssl-endpoint-identification-enabled` to true to enable 
> validation of hostname in server's identity when using SSL to harden against 
> certain man-in-the-middle attacks 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GEODE-5597) Upload geode maven snapshot artifacts from concourse

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-5597:


Commit 76af1dd2fc5dc35a80f61066645978bbb382f417 in geode's branch 
refs/heads/feature/GEODE-5338 from FSOUTHERLAND
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=76af1dd ]

GEODE-5597 Publish geode artifacts to maven repo on GCS (#2347)

* Uses vanilla maven-publish Gradle plugin, instead of nexus (nexus is
still used for release artifact publishing)
* GCS credentials are inherited from the concourse worker

Co-authored-by: Finn Southerland 
Co-authored-by: Jake Barrett 


> Upload geode maven snapshot artifacts from concourse
> 
>
> Key: GEODE-5597
> URL: https://issues.apache.org/jira/browse/GEODE-5597
> Project: Geode
>  Issue Type: Task
>  Components: ci
>Reporter: Finn Southerland
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 7h 50m
>  Remaining Estimate: 0h
>
> We would like to publish snapshots from concourse, rather than jenkins.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GEODE-5652) ExecutorServiceRule should create newCachedThreadPool by default

[Kirk Lund (JIRA)]

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

Kirk Lund updated GEODE-5652:
-
Description: ExecutorServiceRule currently defaults to creating a 
newFixedThreadPool of size 1. Unlimited is a better default .  (was: 
ExecutorServiceRule currently defaults to creating a fixed thread pool of size 
1. Unlimited is a better default .)

> ExecutorServiceRule should create newCachedThreadPool by default
> 
>
> Key: GEODE-5652
> URL: https://issues.apache.org/jira/browse/GEODE-5652
> Project: Geode
>  Issue Type: Wish
>  Components: tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
>
> ExecutorServiceRule currently defaults to creating a newFixedThreadPool of 
> size 1. Unlimited is a better default .



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GEODE-5652) ExecutorServiceRule should create newCachedThreadPool by default

[Kirk Lund (JIRA)]

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

Kirk Lund updated GEODE-5652:
-
Summary: ExecutorServiceRule should create newCachedThreadPool by default  
(was: ExecutorServiceRule should create unlimited thread pool by default)

> ExecutorServiceRule should create newCachedThreadPool by default
> 
>
> Key: GEODE-5652
> URL: https://issues.apache.org/jira/browse/GEODE-5652
> Project: Geode
>  Issue Type: Wish
>  Components: tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
>
> ExecutorServiceRule currently defaults to creating a fixed thread pool of 
> size 1. Unlimited is a better default .



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GEODE-5652) ExecutorServiceRule should create newCachedThreadPool by default

[Kirk Lund (JIRA)]

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

Kirk Lund updated GEODE-5652:
-
Description: ExecutorServiceRule currently defaults to creating a 
newFixedThreadPool of size 1. Creating a newCachedThreadPool is a better 
default.  (was: ExecutorServiceRule currently defaults to creating a 
newFixedThreadPool of size 1. Unlimited is a better default .)

> ExecutorServiceRule should create newCachedThreadPool by default
> 
>
> Key: GEODE-5652
> URL: https://issues.apache.org/jira/browse/GEODE-5652
> Project: Geode
>  Issue Type: Wish
>  Components: tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
>
> ExecutorServiceRule currently defaults to creating a newFixedThreadPool of 
> size 1. Creating a newCachedThreadPool is a better default.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (GEODE-5652) ExecutorServiceRule should create unlimited thread pool by default

[Kirk Lund (JIRA)]

Kirk Lund created GEODE-5652:


 Summary: ExecutorServiceRule should create unlimited thread pool 
by default
 Key: GEODE-5652
 URL: https://issues.apache.org/jira/browse/GEODE-5652
 Project: Geode
  Issue Type: Wish
  Components: tests
Reporter: Kirk Lund


ExecutorServiceRule currently defaults to creating a fixed thread pool of size 
1. Unlimited is a better default .



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (GEODE-5652) ExecutorServiceRule should create unlimited thread pool by default

[Kirk Lund (JIRA)]

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

Kirk Lund reassigned GEODE-5652:


Assignee: Kirk Lund

> ExecutorServiceRule should create unlimited thread pool by default
> --
>
> Key: GEODE-5652
> URL: https://issues.apache.org/jira/browse/GEODE-5652
> Project: Geode
>  Issue Type: Wish
>  Components: tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
>
> ExecutorServiceRule currently defaults to creating a fixed thread pool of 
> size 1. Unlimited is a better default .



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GEODE-5651) Fix _GEODE_FRIEND_STD_SHARED_PTR macro so we can upgrade to XCode version > 9.2

[Blake Bender (JIRA)]

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

Blake Bender updated GEODE-5651:

Description: 
This macro:
{code:java}
#if defined(_clang_)
#define _GEODE_FRIEND_STD_SHARED_PTR(_T) \
friend std::__libcpp_compressed_pair_imp, _T, 1>; \
friend std::__shared_ptr_emplace<_T, std::allocator<_T> >; \
friend std::default_delete<_T>;
#elif defined(_GNUC) || defined(_SUNPRO_CC){code}
Uses a couple of things from  that have gone away as of the XCode 9.3 
headers. We will be unable to upgrade XCode on any development machines until 
this is fixed.

  was:
This macro:

```
#if defined(__clang__)
#define _GEODE_FRIEND_STD_SHARED_PTR(_T) \
 friend std::__libcpp_compressed_pair_imp, _T, 1>; \
 friend std::__shared_ptr_emplace<_T, std::allocator<_T> >; \
 friend std::default_delete<_T>;
#elif defined(__GNUC__) || defined(__SUNPRO_CC)
```

Uses a couple of things from  that have gone away as of the XCode 9.3 
headers. We will be unable to upgrade XCode on any development machines until 
this is fixed.


> Fix _GEODE_FRIEND_STD_SHARED_PTR macro so we can upgrade to XCode version > 
> 9.2
> ---
>
> Key: GEODE-5651
> URL: https://issues.apache.org/jira/browse/GEODE-5651
> Project: Geode
>  Issue Type: Improvement
>  Components: native client
>Reporter: Blake Bender
>Priority: Major
>
> This macro:
> {code:java}
> #if defined(_clang_)
> #define _GEODE_FRIEND_STD_SHARED_PTR(_T) \
> friend std::__libcpp_compressed_pair_imp, _T, 1>; \
> friend std::__shared_ptr_emplace<_T, std::allocator<_T> >; \
> friend std::default_delete<_T>;
> #elif defined(_GNUC) || defined(_SUNPRO_CC){code}
> Uses a couple of things from  that have gone away as of the XCode 9.3 
> headers. We will be unable to upgrade XCode on any development machines until 
> this is fixed.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (GEODE-5651) Fix _GEODE_FRIEND_STD_SHARED_PTR macro so we can upgrade to XCode version > 9.2

[Blake Bender (JIRA)]

Blake Bender created GEODE-5651:
---

 Summary: Fix _GEODE_FRIEND_STD_SHARED_PTR macro so we can upgrade 
to XCode version > 9.2
 Key: GEODE-5651
 URL: https://issues.apache.org/jira/browse/GEODE-5651
 Project: Geode
  Issue Type: Improvement
  Components: native client
Reporter: Blake Bender


This macro:

```
#if defined(__clang__)
#define _GEODE_FRIEND_STD_SHARED_PTR(_T) \
 friend std::__libcpp_compressed_pair_imp, _T, 1>; \
 friend std::__shared_ptr_emplace<_T, std::allocator<_T> >; \
 friend std::default_delete<_T>;
#elif defined(__GNUC__) || defined(__SUNPRO_CC)
```

Uses a couple of things from  that have gone away as of the XCode 9.3 
headers. We will be unable to upgrade XCode on any development machines until 
this is fixed.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GEODE-5650) Improve ClusterStartupRule tear down

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot updated GEODE-5650:
--
Labels: pull-request-available  (was: )

> Improve ClusterStartupRule tear down
> 
>
> Key: GEODE-5650
> URL: https://issues.apache.org/jira/browse/GEODE-5650
> Project: Geode
>  Issue Type: Improvement
>  Components: tests
>Reporter: Sai Boorlagadda
>Priority: Major
>  Labels: pull-request-available
>
> in CSRule teardown if we close suspect buffer before closing cache can cause 
> some background threads (eg: client pool) to keep sending events and log 
> exceptions (if any) could result in the next test to fail for suspects. So 
> close the suspect buffer after closing cache in all VMs.
> {code:java}
>   protected void after() {
> try {
>   DUnitLauncher.closeAndCheckForSuspects();
> } finally {
>   MemberStarterRule.disconnectDSIfAny();
>   // stop all the members in the order of clients, servers and locators
>   List vms = new ArrayList<>();
>   vms.addAll(
>   occupiedVMs.values().stream().filter(x -> 
> x.isClient()).collect(Collectors.toSet()));
>   vms.addAll(
>   occupiedVMs.values().stream().filter(x -> 
> x.isServer()).collect(Collectors.toSet()));
>   vms.addAll(
>   occupiedVMs.values().stream().filter(x -> 
> x.isLocator()).collect(Collectors.toSet()));
>   vms.forEach(x -> x.stop());
>   // delete any file under root dir
>   Arrays.stream(getWorkingDirRoot().listFiles()).filter(File::isFile)
>   .forEach(FileUtils::deleteQuietly);
>   restoreSystemProperties.after();
> }
>   }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (GEODE-5650) Improve ClusterStartupRule tear down

[Sai Boorlagadda (JIRA)]

Sai Boorlagadda created GEODE-5650:
--

 Summary: Improve ClusterStartupRule tear down
 Key: GEODE-5650
 URL: https://issues.apache.org/jira/browse/GEODE-5650
 Project: Geode
  Issue Type: Improvement
  Components: tests
Reporter: Sai Boorlagadda


in CSRule teardown if we close suspect buffer before closing cache can cause 
some background threads (eg: client pool) to keep sending events and log 
exceptions (if any) could result in the next test to fail for suspects. So 
close the suspect buffer after closing cache in all VMs.

{code:java}
  protected void after() {
try {
  DUnitLauncher.closeAndCheckForSuspects();
} finally {
  MemberStarterRule.disconnectDSIfAny();

  // stop all the members in the order of clients, servers and locators
  List vms = new ArrayList<>();
  vms.addAll(
  occupiedVMs.values().stream().filter(x -> 
x.isClient()).collect(Collectors.toSet()));
  vms.addAll(
  occupiedVMs.values().stream().filter(x -> 
x.isServer()).collect(Collectors.toSet()));
  vms.addAll(
  occupiedVMs.values().stream().filter(x -> 
x.isLocator()).collect(Collectors.toSet()));
  vms.forEach(x -> x.stop());

  // delete any file under root dir
  Arrays.stream(getWorkingDirRoot().listFiles()).filter(File::isFile)
  .forEach(FileUtils::deleteQuietly);

  restoreSystemProperties.after();
}
  }
{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (GEODE-5649) getAll() does not trigger client metadata refresh when primary bucket not known

[Bruce Schuchardt (JIRA)]

Bruce Schuchardt created GEODE-5649:
---

 Summary: getAll() does not trigger client metadata refresh when 
primary bucket not known
 Key: GEODE-5649
 URL: https://issues.apache.org/jira/browse/GEODE-5649
 Project: Geode
  Issue Type: Bug
  Components: client/server
Reporter: Bruce Schuchardt


We observed in a test system that getAll() would suddenly become slow in one 
client cache while remaining fast in others.  Adding some debug logging showed 
that the client stopped doing single-hop operations and never recovered the 
ability to do them again.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GEODE-5626) Segfault in Region::registerAllKeys when getInitialValues set to true

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot updated GEODE-5626:
--
Labels: pull-request-available  (was: )

> Segfault in Region::registerAllKeys when getInitialValues set to true
> -
>
> Key: GEODE-5626
> URL: https://issues.apache.org/jira/browse/GEODE-5626
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Blake Bender
>Priority: Major
>  Labels: pull-request-available
>
> getInitialValues has a default value of false.  If you attempt to set it to 
> true, and the region isn't initially empty, it will segfault attempting to 
> insert a value in an internal map which is null.  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GEODE-5608) Meta pipeline can generate images and instances with names longer than max allowed by GCP

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-5608:


Commit aa915c2ba7d07a641c8ec65f473dd60f44806606 in geode's branch 
refs/heads/develop from FSOUTHERLAND
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=aa915c2 ]

GEODE-5608 truncate fork/branch names in image/instance naming (#2390)

* GEODE-5608 truncate fork/branch names in image/instance naming (#2363)

Co-authored-by: Jacob Barrett 
Co-authored-by: Finn Southerland 
Co-authored-by: Robert Houghton 


> Meta pipeline can generate images and instances with names longer than max 
> allowed by GCP
> -
>
> Key: GEODE-5608
> URL: https://issues.apache.org/jira/browse/GEODE-5608
> Project: Geode
>  Issue Type: Task
>  Components: ci
>Reporter: Finn Southerland
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> GCP does not allow names with more than 64 characters, so we should somehow 
> ensure that we do not generate names that are longer than this. Contributors 
> to especially long names are long fork/branch names especially.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GEODE-5608) Meta pipeline can generate images and instances with names longer than max allowed by GCP

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-5608:


Commit aa915c2ba7d07a641c8ec65f473dd60f44806606 in geode's branch 
refs/heads/develop from FSOUTHERLAND
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=aa915c2 ]

GEODE-5608 truncate fork/branch names in image/instance naming (#2390)

* GEODE-5608 truncate fork/branch names in image/instance naming (#2363)

Co-authored-by: Jacob Barrett 
Co-authored-by: Finn Southerland 
Co-authored-by: Robert Houghton 


> Meta pipeline can generate images and instances with names longer than max 
> allowed by GCP
> -
>
> Key: GEODE-5608
> URL: https://issues.apache.org/jira/browse/GEODE-5608
> Project: Geode
>  Issue Type: Task
>  Components: ci
>Reporter: Finn Southerland
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> GCP does not allow names with more than 64 characters, so we should somehow 
> ensure that we do not generate names that are longer than this. Contributors 
> to especially long names are long fork/branch names especially.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GEODE-5608) Meta pipeline can generate images and instances with names longer than max allowed by GCP

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-5608:


Commit 366594ca6f4807b6dfaa1fc9162f3760ecd18a58 in geode's branch 
refs/heads/develop from Jacob Barrett
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=366594c ]

Revert "GEODE-5608 truncate fork/branch names in image/instance naming (#2363)"

This reverts commit 58e4035f7678e7198bb3c59f719d94a27a9144b2.


> Meta pipeline can generate images and instances with names longer than max 
> allowed by GCP
> -
>
> Key: GEODE-5608
> URL: https://issues.apache.org/jira/browse/GEODE-5608
> Project: Geode
>  Issue Type: Task
>  Components: ci
>Reporter: Finn Southerland
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> GCP does not allow names with more than 64 characters, so we should somehow 
> ensure that we do not generate names that are longer than this. Contributors 
> to especially long names are long fork/branch names especially.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GEODE-5594) Enable endpoint validation during using SSL handshake

[Sai Boorlagadda (JIRA)]

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

Sai Boorlagadda updated GEODE-5594:
---
Component/s: docs

> Enable endpoint validation during using SSL handshake
> -
>
> Key: GEODE-5594
> URL: https://issues.apache.org/jira/browse/GEODE-5594
> Project: Geode
>  Issue Type: Improvement
>  Components: client/server, docs
>Reporter: Sai Boorlagadda
>Assignee: Sai Boorlagadda
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Users can set `ssl-endpoint-identification-enabled` to true to enable 
> validation of hostname in server's identity when using SSL to harden against 
> certain man-in-the-middle attacks 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GEODE-5608) Meta pipeline can generate images and instances with names longer than max allowed by GCP

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-5608:


Commit 58e4035f7678e7198bb3c59f719d94a27a9144b2 in geode's branch 
refs/heads/develop from FSOUTHERLAND
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=58e4035 ]

GEODE-5608 truncate fork/branch names in image/instance naming (#2363)


Co-authored-by: Jacob Barrett 
Co-authored-by: Finn Southerland 
Co-authored-by: Robert Houghton 


> Meta pipeline can generate images and instances with names longer than max 
> allowed by GCP
> -
>
> Key: GEODE-5608
> URL: https://issues.apache.org/jira/browse/GEODE-5608
> Project: Geode
>  Issue Type: Task
>  Components: ci
>Reporter: Finn Southerland
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> GCP does not allow names with more than 64 characters, so we should somehow 
> ensure that we do not generate names that are longer than this. Contributors 
> to especially long names are long fork/branch names especially.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GEODE-3209) Standard output is not redirected to log file

[Swapnil Bawaskar (JIRA)]

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

Swapnil Bawaskar updated GEODE-3209:

  Labels: EaseOfUse  (was: )
Priority: Minor  (was: Major)

> Standard output is not redirected to log file
> -
>
> Key: GEODE-3209
> URL: https://issues.apache.org/jira/browse/GEODE-3209
> Project: Geode
>  Issue Type: Bug
>  Components: logging
>Reporter: Swapnil Bawaskar
>Priority: Minor
>  Labels: EaseOfUse
>
> Standard output from Callbacks (CacheListeners, CacheWriters etc) should be 
> redirected to the log file.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GEODE-4805) Support a broad range of hostname port notations

[Swapnil Bawaskar (JIRA)]

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

Swapnil Bawaskar updated GEODE-4805:

Labels: EaseOfUse  (was: )

> Support a broad range of hostname port notations
> 
>
> Key: GEODE-4805
> URL: https://issues.apache.org/jira/browse/GEODE-4805
> Project: Geode
>  Issue Type: Improvement
>  Components: configuration
>Reporter: Swapnil Bawaskar
>Priority: Minor
>  Labels: EaseOfUse
>
> In addition to hostname[port] notation, we should support hostname:port and a 
> host of other notations commonly used. Here are a few commonly used examples: 
> https://github.com/google/guava/blob/master/guava/src/com/google/common/net/HostAndPort.java



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GEODE-2722) ReflectionBasedAutoSerializer should be used by default

[Swapnil Bawaskar (JIRA)]

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

Swapnil Bawaskar updated GEODE-2722:

Labels: EaseOfUse  (was: )

> ReflectionBasedAutoSerializer should be used by default
> ---
>
> Key: GEODE-2722
> URL: https://issues.apache.org/jira/browse/GEODE-2722
> Project: Geode
>  Issue Type: Improvement
>  Components: serialization
>Reporter: Swapnil Bawaskar
>Priority: Major
>  Labels: EaseOfUse
>
> We should not require the user to configure anything when inserting data in 
> Geode. ReflectionBasedAutoSerializer should be set by default on Cache
> startup (if one is not specified already). 
> Also, the pattern required to configure ReflectionBasedAutoSerializer should 
> be made optional: Please see:
> 
> Please look at this thread for discussion on the dev list: 
> https://lists.apache.org/thread.html/c89974d08d7675d3a636872bce5e838d578df5759c5c1acae611d322@%3Cdev.geode.apache.org%3E



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GEODE-47) GFSH can't start servers in foreground

[Swapnil Bawaskar (JIRA)]

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

Swapnil Bawaskar updated GEODE-47:
--
Labels: EaseOfUse StartLocatorCommand StartServerCommand gfsh gsoc2016  
(was: StartLocatorCommand StartServerCommand gfsh gsoc2016)

> GFSH can't start servers in foreground
> --
>
> Key: GEODE-47
> URL: https://issues.apache.org/jira/browse/GEODE-47
> Project: Geode
>  Issue Type: Improvement
>  Components: gfsh
>Reporter: William Markito Oliveira
>Priority: Minor
>  Labels: EaseOfUse, StartLocatorCommand, StartServerCommand, 
> gfsh, gsoc2016
>
> There are certain cases where users may want to use gfsh and start members 
> (locator or servers) in foreground.
> In old scripts there was an alternative to have servers started in foreground 
> but that's not available anymore. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GEODE-5551) Flaky unit test LoginHandlerInterceptorJUnitTest > testHandlerInterceptorThreadSafety

[Dan Smith (JIRA)]

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

Dan Smith commented on GEODE-5551:
--

More recent failure

https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/IntegrationTest/builds/319

{noformat}
org.apache.geode.cache.ProxyJUnitTest > testExpiration FAILED
java.lang.AssertionError: expected:<0> but was:<1>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:645)
at org.junit.Assert.assertEquals(Assert.java:631)
at 
org.apache.geode.cache.ProxyJUnitTest.testExpiration(ProxyJUnitTest.java:1130)
{noformat}

> Flaky unit test LoginHandlerInterceptorJUnitTest > 
> testHandlerInterceptorThreadSafety
> -
>
> Key: GEODE-5551
> URL: https://issues.apache.org/jira/browse/GEODE-5551
> Project: Geode
>  Issue Type: Bug
>  Components: tests
>Affects Versions: 1.8.0
>Reporter: Jacob S. Barrett
>Priority: Major
>  Labels: flaky, swat
>
> {noformat}
> > Task :geode-web:test
> org.apache.geode.management.internal.web.controllers.support.LoginHandlerInterceptorJUnitTest
>  > testHandlerInterceptorThreadSafety FAILED
> junit.framework.AssertionFailedError: expected:<0> but was:<3>
> not all expectations were satisfied
> expectations:
>   ! expected once, never invoked: 
> testHandlerInterceptorThreadSafety.HttpServletRequest.1.getParameterNames(); 
> returns 
> 
>   ! expected once, never invoked: 
> testHandlerInterceptorThreadSafety.HttpServletRequest.1.getHeader("security-username");
>  returns "admin"
>   ! expected once, never invoked: 
> testHandlerInterceptorThreadSafety.HttpServletRequest.1.getHeader("security-password");
>  returns "password"
>   ! expected once, never invoked: 
> testHandlerInterceptorThreadSafety.HttpServletRequest.1.getParameter("vf.gf.env.STAGE");
>  returns "test"
>   ! expected once, never invoked: 
> testHandlerInterceptorThreadSafety.HttpServletRequest.1.getParameter("vf.gf.env.GEODE_HOME");
>  returns "/path/to/gemfire/700"
>   expected once, already invoked 1 time: securityService.login(not null); 
> returns a default value
>   expected once, already invoked 1 time: securityService.logout()
>   expected once, already invoked 1 time: 
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getParameterNames(); 
> returns 
> 
>   expected once, already invoked 1 time: 
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getHeader("security-username");
>  returns "admin"
>   expected once, already invoked 1 time: 
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getHeader("security-password");
>  returns "password"
>   expected once, already invoked 1 time: 
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getParameter("vf.gf.env.HOST");
>  returns "localhost"
>   expected once, already invoked 1 time: 
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getParameter("vf.gf.env.GEODE_HOME");
>  returns "/path/to/gemfire/75"
>   ! expected once, never invoked: securityService.login(not null); 
> returns a default value
>   ! expected once, never invoked: securityService.logout()
> what happened before this:
>   
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getParameterNames()
>   
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getParameter("vf.gf.env.HOST")
>   
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getParameter("vf.gf.env.GEODE_HOME")
>   
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getHeader("security-username")
>   
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getHeader("security-password")
>   securityService.login(<{security-username=admin, 
> security-password=password}>)
>   securityService.logout()
> at 
> org.jmock.api.ExpectationError.notAllSatisfied(ExpectationError.java:27)
> at org.jmock.Mockery.assertIsSatisfied(Mockery.java:213)
> at 
> org.apache.geode.management.internal.web.controllers.support.LoginHandlerInterceptorJUnitTest.tearDown(LoginHandlerInterceptorJUnitTest.java:70)
> {noformat}
> Failing: 
> https://concourse.apachegeode-ci.info/teams/main/pipelines/pr-develop/jobs/Build/builds/558
> Passing: 
> https://concourse.apachegeode-ci.info/teams/main/pipelines/pr-develop/jobs/Build/builds/559



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GEODE-5094) ProxyJUnitTest fails intermittently in testExpiration

[Dan Smith (JIRA)]

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

Dan Smith updated GEODE-5094:
-
Labels: flaky swat  (was: flaky)

> ProxyJUnitTest fails intermittently in testExpiration
> -
>
> Key: GEODE-5094
> URL: https://issues.apache.org/jira/browse/GEODE-5094
> Project: Geode
>  Issue Type: Bug
>  Components: expiration
>Reporter: Darrel Schneider
>Priority: Major
>  Labels: flaky, swat
>
> {noformat}
> org.apache.geode.cache.ProxyJUnitTest > testExpiration FAILED
> org.apache.geode.cache.RegionDestroyedException: 
> org.apache.geode.internal.cache.DistributedRegion[path='/rEMPTY';scope=DISTRIBUTED_NO_ACK';dataPolicy=EMPTY;
>  concurrencyChecksEnabled]
> at 
> org.apache.geode.internal.cache.LocalRegion.checkRegionDestroyed(LocalRegion.java:7391)
> at 
> org.apache.geode.internal.cache.LocalRegion.checkReadiness(LocalRegion.java:2723)
> at 
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1356)
> at 
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1314)
> at 
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1299)
> at 
> org.apache.geode.internal.cache.AbstractRegion.get(AbstractRegion.java:313)
> at 
> org.apache.geode.cache.ProxyJUnitTest.testExpiration(ProxyJUnitTest.java:1106)
> {noformat}
> The test is scheduling a region to be destroyed if it is not used for 500 
> miliseconds. It then starting doing gets which will keep using the region. 
> But it is possible for the gets to lose the cpu and be prevented from using 
> the region and it then expiring. That is what is happening in this test.
> This test as currently written is flaky and needs to be rewritten.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (GEODE-5607) Replace org.jmock with mockito

[JIRA]

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

Juan José Ramos Cassella reassigned GEODE-5607:
---

Assignee: Juan José Ramos Cassella

> Replace org.jmock with mockito
> --
>
> Key: GEODE-5607
> URL: https://issues.apache.org/jira/browse/GEODE-5607
> Project: Geode
>  Issue Type: Improvement
>  Components: tests
>Reporter: Jens Deppe
>Assignee: Juan José Ramos Cassella
>Priority: Major
>
> We should consolidate on a single mocking framework. Older tests still use 
> jmock which should be replaced with mockito.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GEODE-5618) FunctionService.onServer() and FunctionService.onRegion() fail when multiuser-authentication=true

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-5618:


Commit 60ea939e85e7d94da9d8eb64d5b88dd62edb2618 in geode's branch 
refs/heads/develop from Juan José Ramos
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=60ea939 ]

GEODE-5618: Auth Attributes in FunctionService (#2360)

   * When a client executes a function using the id instead of the actual 
instance, an internal invocation to the `GetFunctionAttributeOp` function is 
executed to get the metadata about the original function itself. This 
invocation doesn't set the user attributes requried by the authentication 
mechanism, so the entire invocation fails.
   * Added distributed tests.
   * Classes `ServerFunctionExecutor` and `ServerRegionFunctionExecutor` now 
set the `userAttributes` in the local thread before getting the metadata when 
the function is executed by id.

> FunctionService.onServer() and FunctionService.onRegion() fail when 
> multiuser-authentication=true
> -
>
> Key: GEODE-5618
> URL: https://issues.apache.org/jira/browse/GEODE-5618
> Project: Geode
>  Issue Type: Bug
>  Components: functions, security
>Reporter: Juan José Ramos Cassella
>Assignee: Juan José Ramos Cassella
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> The problem resides within the {{ServerFunctionExecutor}} class, specifically 
> in the following section of code:
> {code:title=ServerFunctionExecutor.java|borderStyle=solid}
> public ResultCollector execute(final String functionName) {
> (...)
>  byte[] functionAttributes = getFunctionAttributes(functionName);
>  if (functionAttributes == null) {
>  Object obj = GetFunctionAttributeOp.execute(this.pool, functionName);
>  functionAttributes = (byte[]) obj;
>  addFunctionAttributes(functionName, functionAttributes);
>  }
> (..)
> }
> {code}
> We are specifically executing an internal function (namely 
> {{GetFunctionAttributeOp}}) to retrieve the metadata for the function 
> executed by the client *without setting the user attributes* required by the 
> authentication mechanism and, as such, the execution fails for this 
> particular function instead of the one executed by the client (it's not even 
> part of the stack trace):
> {noformat}
> Exception in thread "main" java.lang.UnsupportedOperationException: Use Pool 
> APIs for doing operations when multiuser-secure-mode-enabled is set to true.
>  at 
> org.apache.geode.cache.client.internal.PoolImpl.authenticateIfRequired(PoolImpl.java:1549)
>  at 
> org.apache.geode.cache.client.internal.PoolImpl.authenticateIfRequired(PoolImpl.java:1531)
>  at org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:781)
>  at 
> org.apache.geode.cache.client.internal.GetFunctionAttributeOp.execute(GetFunctionAttributeOp.java:24)
>  at 
> org.apache.geode.internal.cache.execute.ServerFunctionExecutor.execute(ServerFunctionExecutor.java:310)
> {noformat}
> The other top-level methods from {{ServerFunctionExecutor}} and 
> {{ServerRegionFunctionExecutor}} configure the user attributes before 
> actually executing the function, that's why (as a workaround), the user can 
> use {{FunctionService.onServer(regionService).execute(new MyFunction())}}, 
> works as expected:
> {code}
>  if (proxyCache != null) {
>  if (this.proxyCache.isClosed()) {
>  throw proxyCache.getCacheClosedException("Cache is closed for this user.");
>  }
>  UserAttributes.userAttributes.set(this.proxyCache.getUserAttributes());
>  }
> {code}
> The solution would be to add the same _pre-operation logic_ to the buggy 
> method.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)