[jira] [Commented] (GEODE-3140) CI Failure: FileSystemJUnitTest.testExport

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/geode/pull/608#discussion_r124434616
  
--- Diff: 
geode-lucene/src/test/java/org/apache/geode/cache/lucene/LuceneQueriesPersistenceIntegrationTest.java
 ---
@@ -48,13 +49,13 @@
 public class LuceneQueriesPersistenceIntegrationTest extends 
LuceneIntegrationTest {
 
   @Rule
-  public DiskDirRule diskDirRule = new DiskDirRule();
+  public TemporaryFolder tempFolderRule = new TemporaryFolder(new 
File("."));
--- End diff --

Is there any reason we want to pass in a parentFolder of current dir? Can 
we just use the temp folder that we don't care about where it is?


> CI Failure: FileSystemJUnitTest.testExport
> --
>
> Key: GEODE-3140
> URL: https://issues.apache.org/jira/browse/GEODE-3140
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Jason Huynh
>Assignee: David Anuta
>
> A few travis ci runs have seen the following error:
> org.apache.geode.cache.lucene.internal.filesystem.FileSystemJUnitTest > 
> testExport FAILED
> java.lang.RuntimeException: Could not delete disk dir: 
> ./DiskDirRule-37255322000983
> Caused by:
> java.nio.file.NoSuchFileException: ./DiskDirRule-37255322000983
> We can either modify the existing disk dir to ignore FileNotFoundExceptions 
> (we meant to delete the file anyways and if it is not there, do we really 
> care if it's not found?)
> Or we can change out the DiskDir rule for the TemporaryFileRule.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (GEODE-3142) Update ACE to 6.4.3

[Jacob S. Barrett (JIRA)]

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

Jacob S. Barrett closed GEODE-3142.
---

> Update ACE to 6.4.3
> ---
>
> Key: GEODE-3142
> URL: https://issues.apache.org/jira/browse/GEODE-3142
> Project: Geode
>  Issue Type: Improvement
>  Components: native client
>Reporter: Jacob S. Barrett
>Assignee: Jacob S. Barrett
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (GEODE-3142) Update ACE to 6.4.3

[Jacob S. Barrett (JIRA)]

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

Jacob S. Barrett resolved GEODE-3142.
-
Resolution: Fixed
  Assignee: Jacob S. Barrett

> Update ACE to 6.4.3
> ---
>
> Key: GEODE-3142
> URL: https://issues.apache.org/jira/browse/GEODE-3142
> Project: Geode
>  Issue Type: Improvement
>  Components: native client
>Reporter: Jacob S. Barrett
>Assignee: Jacob S. Barrett
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (GEODE-3058) Remove low fragmentation heap feature enablement

[Jacob S. Barrett (JIRA)]

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

Jacob S. Barrett resolved GEODE-3058.
-
Resolution: Fixed
  Assignee: Jacob S. Barrett

> Remove low fragmentation heap feature enablement 
> -
>
> Key: GEODE-3058
> URL: https://issues.apache.org/jira/browse/GEODE-3058
> Project: Geode
>  Issue Type: Task
>  Components: native client
>Reporter: Jacob S. Barrett
>Assignee: Jacob S. Barrett
>
> Low fragmentation heap feature is effectively deprecated since Windows Vista 
> era.
> [https://msdn.microsoft.com/en-us/library/windows/desktop/aa366750(v=vs.85).aspx]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (GEODE-3058) Remove low fragmentation heap feature enablement

[Jacob S. Barrett (JIRA)]

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

Jacob S. Barrett closed GEODE-3058.
---

> Remove low fragmentation heap feature enablement 
> -
>
> Key: GEODE-3058
> URL: https://issues.apache.org/jira/browse/GEODE-3058
> Project: Geode
>  Issue Type: Task
>  Components: native client
>Reporter: Jacob S. Barrett
>Assignee: Jacob S. Barrett
>
> Low fragmentation heap feature is effectively deprecated since Windows Vista 
> era.
> [https://msdn.microsoft.com/en-us/library/windows/desktop/aa366750(v=vs.85).aspx]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3058) Remove low fragmentation heap feature enablement

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-3058:


Commit 25f2a923bacfc40a63ce0505746cfdba209df4ce in geode-native's branch 
refs/heads/develop from Jacob Barrett
[ https://git-wip-us.apache.org/repos/asf?p=geode-native.git;h=25f2a92 ]

GEODE-3058: Removes Windows LFH enablement.


> Remove low fragmentation heap feature enablement 
> -
>
> Key: GEODE-3058
> URL: https://issues.apache.org/jira/browse/GEODE-3058
> Project: Geode
>  Issue Type: Task
>  Components: native client
>Reporter: Jacob S. Barrett
>
> Low fragmentation heap feature is effectively deprecated since Windows Vista 
> era.
> [https://msdn.microsoft.com/en-us/library/windows/desktop/aa366750(v=vs.85).aspx]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (GEODE-3058) Remove low fragmentation heap feature enablement

[Jacob S. Barrett (JIRA)]

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

Jacob S. Barrett updated GEODE-3058:

Description: 
Low fragmentation heap feature is effectively deprecated since Windows Vista 
era.

[https://msdn.microsoft.com/en-us/library/windows/desktop/aa366750(v=vs.85).aspx]

  was:The setLFH() function was being called implicitly to change the process 
space's memory settings to use a low fragmentation feature in windows. It is 
dangerous to assume that all applications linking with geode-native would want 
this behavior change. It is no longer called implicitly and should be moved to 
a helper for explicit use if client code wishes.

Summary: Remove low fragmentation heap feature enablement   (was: Move 
setLFH() function to a process helper class.)

Updated ticket to reflect the current state of LFH feature.

> Remove low fragmentation heap feature enablement 
> -
>
> Key: GEODE-3058
> URL: https://issues.apache.org/jira/browse/GEODE-3058
> Project: Geode
>  Issue Type: Task
>  Components: native client
>Reporter: Jacob S. Barrett
>
> Low fragmentation heap feature is effectively deprecated since Windows Vista 
> era.
> [https://msdn.microsoft.com/en-us/library/windows/desktop/aa366750(v=vs.85).aspx]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Reopened] (GEODE-3135) Update to OpenSSL 1.0.2 LTS

[Karen Smoler Miller (JIRA)]

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

Karen Smoler Miller reopened GEODE-3135:


Re-opening this ticket to do the needed docs revision.


> Update to OpenSSL 1.0.2 LTS
> ---
>
> Key: GEODE-3135
> URL: https://issues.apache.org/jira/browse/GEODE-3135
> Project: Geode
>  Issue Type: Improvement
>  Components: docs, native client
>Reporter: Jacob S. Barrett
>Assignee: Karen Smoler Miller
>
> Update to OpenSSL 1.0.2 LTS, which has support until end of 2019 
> [https://www.openssl.org/policies/releasestrat.html].
> OpenSSL 1.0.1 has been out of support in 2016.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3140) CI Failure: FileSystemJUnitTest.testExport

[ASF GitHub Bot (JIRA)]

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

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

Github user DivineEnder commented on the issue:

https://github.com/apache/geode/pull/608
  
@ladyVader @nabarunnag @boglesby @jhuynh1 @upthewaterspout @gesterzhou 


> CI Failure: FileSystemJUnitTest.testExport
> --
>
> Key: GEODE-3140
> URL: https://issues.apache.org/jira/browse/GEODE-3140
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Jason Huynh
>Assignee: David Anuta
>
> A few travis ci runs have seen the following error:
> org.apache.geode.cache.lucene.internal.filesystem.FileSystemJUnitTest > 
> testExport FAILED
> java.lang.RuntimeException: Could not delete disk dir: 
> ./DiskDirRule-37255322000983
> Caused by:
> java.nio.file.NoSuchFileException: ./DiskDirRule-37255322000983
> We can either modify the existing disk dir to ignore FileNotFoundExceptions 
> (we meant to delete the file anyways and if it is not there, do we really 
> care if it's not found?)
> Or we can change out the DiskDir rule for the TemporaryFileRule.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3140) CI Failure: FileSystemJUnitTest.testExport

[ASF GitHub Bot (JIRA)]

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

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

GitHub user DivineEnder opened a pull request:

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

GEODE-3140: Removed DiskDirRule and replaced use with TemporaryFolder…

… rule

Thank you for submitting a contribution to Apache Geode.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

### For all changes:
- [ ] Is there a JIRA ticket associated with this PR? Is it referenced in 
the commit message?

- [ ] Has your PR been rebased against the latest commit within the target 
branch (typically `develop`)?

- [ ] Is your initial contribution a single, squashed commit?

- [ ] Does `gradlew build` run cleanly?

- [ ] Have you written or updated unit tests to verify your changes?

- [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and
submit an update to your PR as soon as possible. If you need help, please 
send an
email to d...@geode.apache.org.


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

$ git pull https://github.com/DivineEnder/geode feature/GEODE-3140

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

https://github.com/apache/geode/pull/608.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #608


commit 8e43d6139c13ad5de6355f34637d92af8e9d699e
Author: David Anuta 
Date:   2017-06-28T00:00:00Z

GEODE-3140: Removed DiskDirRule and replaced use with TemporaryFolder rule




> CI Failure: FileSystemJUnitTest.testExport
> --
>
> Key: GEODE-3140
> URL: https://issues.apache.org/jira/browse/GEODE-3140
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Jason Huynh
>Assignee: David Anuta
>
> A few travis ci runs have seen the following error:
> org.apache.geode.cache.lucene.internal.filesystem.FileSystemJUnitTest > 
> testExport FAILED
> java.lang.RuntimeException: Could not delete disk dir: 
> ./DiskDirRule-37255322000983
> Caused by:
> java.nio.file.NoSuchFileException: ./DiskDirRule-37255322000983
> We can either modify the existing disk dir to ignore FileNotFoundExceptions 
> (we meant to delete the file anyways and if it is not there, do we really 
> care if it's not found?)
> Or we can change out the DiskDir rule for the TemporaryFileRule.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (GEODE-3140) CI Failure: FileSystemJUnitTest.testExport

[David Anuta (JIRA)]

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

David Anuta reassigned GEODE-3140:
--

Assignee: David Anuta

> CI Failure: FileSystemJUnitTest.testExport
> --
>
> Key: GEODE-3140
> URL: https://issues.apache.org/jira/browse/GEODE-3140
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Jason Huynh
>Assignee: David Anuta
>
> A few travis ci runs have seen the following error:
> org.apache.geode.cache.lucene.internal.filesystem.FileSystemJUnitTest > 
> testExport FAILED
> java.lang.RuntimeException: Could not delete disk dir: 
> ./DiskDirRule-37255322000983
> Caused by:
> java.nio.file.NoSuchFileException: ./DiskDirRule-37255322000983
> We can either modify the existing disk dir to ignore FileNotFoundExceptions 
> (we meant to delete the file anyways and if it is not there, do we really 
> care if it's not found?)
> Or we can change out the DiskDir rule for the TemporaryFileRule.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (GEODE-3135) Update to OpenSSL 1.0.2 LTS

[Jacob S. Barrett (JIRA)]

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

Jacob S. Barrett reassigned GEODE-3135:
---

Assignee: Karen Smoler Miller  (was: Jacob S. Barrett)

> Update to OpenSSL 1.0.2 LTS
> ---
>
> Key: GEODE-3135
> URL: https://issues.apache.org/jira/browse/GEODE-3135
> Project: Geode
>  Issue Type: Improvement
>  Components: docs, native client
>Reporter: Jacob S. Barrett
>Assignee: Karen Smoler Miller
>
> Update to OpenSSL 1.0.2 LTS, which has support until end of 2019 
> [https://www.openssl.org/policies/releasestrat.html].
> OpenSSL 1.0.1 has been out of support in 2016.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (GEODE-3135) Update to OpenSSL 1.0.2 LTS

[Jacob S. Barrett (JIRA)]

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

Jacob S. Barrett reassigned GEODE-3135:
---

Assignee: Jacob S. Barrett

> Update to OpenSSL 1.0.2 LTS
> ---
>
> Key: GEODE-3135
> URL: https://issues.apache.org/jira/browse/GEODE-3135
> Project: Geode
>  Issue Type: Improvement
>  Components: docs, native client
>Reporter: Jacob S. Barrett
>Assignee: Jacob S. Barrett
>
> Update to OpenSSL 1.0.2 LTS, which has support until end of 2019 
> [https://www.openssl.org/policies/releasestrat.html].
> OpenSSL 1.0.1 has been out of support in 2016.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3135) Update to OpenSSL 1.0.2 LTS

[Jacob S. Barrett (JIRA)]

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

Jacob S. Barrett commented on GEODE-3135:
-

Updated in 3df84703f834aa1cdd6ccda18e88fc125e159510.

> Update to OpenSSL 1.0.2 LTS
> ---
>
> Key: GEODE-3135
> URL: https://issues.apache.org/jira/browse/GEODE-3135
> Project: Geode
>  Issue Type: Improvement
>  Components: docs, native client
>Reporter: Jacob S. Barrett
>
> Update to OpenSSL 1.0.2 LTS, which has support until end of 2019 
> [https://www.openssl.org/policies/releasestrat.html].
> OpenSSL 1.0.1 has been out of support in 2016.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (GEODE-3135) Update to OpenSSL 1.0.2 LTS

[Jacob S. Barrett (JIRA)]

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

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

> Update to OpenSSL 1.0.2 LTS
> ---
>
> Key: GEODE-3135
> URL: https://issues.apache.org/jira/browse/GEODE-3135
> Project: Geode
>  Issue Type: Improvement
>  Components: docs, native client
>Reporter: Jacob S. Barrett
>Assignee: Jacob S. Barrett
>
> Update to OpenSSL 1.0.2 LTS, which has support until end of 2019 
> [https://www.openssl.org/policies/releasestrat.html].
> OpenSSL 1.0.1 has been out of support in 2016.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (GEODE-3142) Update ACE to 6.4.3

[Jacob S. Barrett (JIRA)]

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

 Summary: Update ACE to 6.4.3
 Key: GEODE-3142
 URL: https://issues.apache.org/jira/browse/GEODE-3142
 Project: Geode
  Issue Type: Improvement
  Components: native client
Reporter: Jacob S. Barrett






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (GEODE-3141) New flow: GetRegion

[Brian Baynes (JIRA)]

Brian Baynes created GEODE-3141:
---

 Summary: New flow: GetRegion
 Key: GEODE-3141
 URL: https://issues.apache.org/jira/browse/GEODE-3141
 Project: Geode
  Issue Type: Sub-task
  Components: client/server
Reporter: Brian Baynes


Users of the new client/server protocol need to be able to verify a region 
exists in the cache. Implement GetRegion message/handler, returning boolean 
success(/failure) based on the existence of a Region when passed a Region name.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3105) New flow: GetRegions

[ASF GitHub Bot (JIRA)]

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

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

GitHub user WireBaron opened a pull request:

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

GEODE-3105: adding GetRegion handler for protobuf protocol

Added a handler which will catch incoming getRegion requests and will call 
into the cache's rootRegion and return the names of the region it finds.
Added unit test verifying hanlder behavior.
Added integration test verifying module correctness for getRegion.

Signed-off-by: Hitesh Khamesra 

Thank you for submitting a contribution to Apache Geode.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

### For all changes:
- [x] Is there a JIRA ticket associated with this PR? Is it referenced in 
the commit message?

- [x] Has your PR been rebased against the latest commit within the target 
branch (typically `develop`)?

- [x] Is your initial contribution a single, squashed commit?

- [x] Does `gradlew build` run cleanly?

- [x] Have you written or updated unit tests to verify your changes?

- [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and
submit an update to your PR as soon as possible. If you need help, please 
send an
email to d...@geode.apache.org.


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

$ git pull https://github.com/WireBaron/geode feature/GEODE-3105

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

https://github.com/apache/geode/pull/607.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #607


commit f2d55db4e3eabfb51d13284c7cb0b0bacf5b2c05
Author: Brian Rowe 
Date:   2017-06-27T23:15:53Z

GEODE-3105: adding GetRegion handler for protobuf protocol

Added a handler which will catch incoming getRegion requests and will call 
into the cache's rootRegion and return the names of the region it finds.
Added unit test verifying hanlder behavior.
Added integration test verifying module correctness for getRegion.

Signed-off-by: Brian Rowe 
Signed-off-by: Hitesh Khamesra 




> New flow: GetRegions
> 
>
> Key: GEODE-3105
> URL: https://issues.apache.org/jira/browse/GEODE-3105
> Project: Geode
>  Issue Type: Sub-task
>  Components: client/server
>Reporter: Brian Baynes
>
> Users of the new client/server protocol need to be able to receive a list of 
> the existing regions.  Implement GetRegions message/handler.  Proto message 
> definition has already been created.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (GEODE-3140) CI Failure: FileSystemJUnitTest.testExport

[Jason Huynh (JIRA)]

Jason Huynh created GEODE-3140:
--

 Summary: CI Failure: FileSystemJUnitTest.testExport
 Key: GEODE-3140
 URL: https://issues.apache.org/jira/browse/GEODE-3140
 Project: Geode
  Issue Type: Bug
  Components: lucene
Reporter: Jason Huynh


A few travis ci runs have seen the following error:

org.apache.geode.cache.lucene.internal.filesystem.FileSystemJUnitTest > 
testExport FAILED
java.lang.RuntimeException: Could not delete disk dir: 
./DiskDirRule-37255322000983
Caused by:
java.nio.file.NoSuchFileException: ./DiskDirRule-37255322000983

We can either modify the existing disk dir to ignore FileNotFoundExceptions (we 
meant to delete the file anyways and if it is not there, do we really care if 
it's not found?)

Or we can change out the DiskDir rule for the TemporaryFileRule.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (GEODE-1731) CI Failure: ConcurrentParallelGatewaySenderDUnitTest.testPartitionedParallelPropagationHA

[David Anuta (JIRA)]

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

David Anuta reassigned GEODE-1731:
--

Assignee: David Anuta

> CI Failure: 
> ConcurrentParallelGatewaySenderDUnitTest.testPartitionedParallelPropagationHA
> -
>
> Key: GEODE-1731
> URL: https://issues.apache.org/jira/browse/GEODE-1731
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Reporter: Scott Jewell
>Assignee: David Anuta
>  Labels: ci
>
> GEODE DISTRIBUTED TESTS build 3520
> com.gemstone.gemfire.test.dunit.RMIException: While invoking 
> com.gemstone.gemfire.internal.cache.wan.concurrent.ConcurrentParallelGatewaySenderDUnitTest$$Lambda$549/1107609909.run
>  in VM 2 running on Host rooktwo.gemstone.com with 8 VMs
>   at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:389)
>   at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:355)
>   at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:293)
>   at 
> com.gemstone.gemfire.internal.cache.wan.concurrent.ConcurrentParallelGatewaySenderDUnitTest.testPartitionedParallelPropagationHA(ConcurrentParallelGatewaySenderDUnitTest.java:631)
>   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:497)
>   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:114)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
>   at sun.reflect.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:497)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
>   at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
>   at 
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109)
>   at sun.reflect.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:497)
>   at 
> 

[jira] [Commented] (GEODE-3072) Events do not get removed from the client queue when 1.0 clients connect to 1.2 servers

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-3072:


Commit e479ed5e551528a8455d6c568842604dd81b1e8f in geode's branch 
refs/heads/release/1.2.0 from [~bschuchardt]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=e479ed5 ]

GEODE-3072: Events do not get removed from the client queue for 1.0 clients

EventID and ThreadIdentifier hold the serialized form of portions of an
InternalDistributedMember identifier.  This serialized form changed in
v1.0.0 and was causing .equals and .hashCode for these objects to return
false when they should have returned true owing to additional data being
in the serialized form of the identifier.

This change set modifies the equals and hashCode methods of the classes
to ensure that they return the correct results in the presence of this
additional ID data.

I created a dunit test to reproduce the problem but I think the behavior
of HARegionQueues isn't reliable enough to check in that test.  I'm
afraid that it would end up being a "flaky" test that fails periodically.
Instead, I'm relying on a new junit test and the test that Barry already
checked in.

Note: I've also included two other things in this change set.

First, LocalRegion.dumpBackingMap() is a test-hook that should log its
results at "info" level.  I used it in debugging this problem.

Second, I've added a new backward-compatibility version so now we have
100 and 110.

(cherry picked from commit ff6cbf317ab24bb0e582a3eca01c23e7b435ef35)


> Events do not get removed from the client queue when 1.0 clients connect to 
> 1.2 servers
> ---
>
> Key: GEODE-3072
> URL: https://issues.apache.org/jira/browse/GEODE-3072
> Project: Geode
>  Issue Type: Bug
>  Components: client queues, serialization
>Reporter: Barry Oglesby
>Assignee: Barry Oglesby
> Fix For: 1.2.0
>
>
> The EventID is created in Put65 cmdExecute on the server here:
> {noformat}
> java.lang.Exception: Stack trace
>   at java.lang.Thread.dumpStack(Thread.java:1329)
>   at org.apache.geode.internal.cache.EventID.(EventID.java:242)
>   at 
> org.apache.geode.internal.cache.tier.sockets.command.Put65.cmdExecute(Put65.java:201)
>   at 
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:165)
>   at 
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMsg(ServerConnection.java:780)
>   at 
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doOneMessage(ServerConnection.java:911)
>   at 
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1166)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at 
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl$1$1.run(AcceptorImpl.java:523)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}
> like:
> {noformat}
> new EventID(serverConnection.getEventMemberIDByteArray(), threadId, 
> sequenceId)
> {noformat}
> This causes a 38 byte membership id to be generated:
> {noformat}
> ServerConnection on port 61938 Thread 2:  EventID.EventID 3 
> membershipIDLength=38
> ServerConnection on port 61938 Thread 0:  
> CacheClientNotifier.processDispatchedMessage eidMembershipIdLength=55
> {noformat}
> The PeriodicAck sends in a 55 byte membership id:
> {noformat}
> ServerConnection on port 61938 Thread 0: DurableHARegionQueue.setAckedEvents 
> ackedEventsSize=1
>   tid=ThreadId[1]; membershipIdLength=55
> {noformat}
> HARegionQueue remove calls HARegionQueue checkEventForRemoval before it 
> removes an event from the queue. When the comparison is made in HARegionQueue 
> checkEventForRemoval, it returns false every time. Its false because the 
> input ThreadIdentifier is not the same as the one in the currDurableMap. 
> Their toStrings are the same, but they are not equal because their 
> membershipIDs are not equal. This is why the events aren't being removed.
> Here is some debugging that shows the difference:
> {noformat}
> DurableHARegionQueue.checkEventForRemoval 
> threadId=ThreadId[192.168.2.4(client-feeder:loner):61201:70bec7a3:client-feeder;
>  thread 1]; membershipIdLength=38
> DurableHARegionQueue.checkEventForRemoval 
> currDurableMapKey=ThreadId[192.168.2.4(client-feeder:loner):61201:70bec7a3:client-feeder;
>  thread 1]; membershipIdLength=55
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-2991) "destroy gateway-sender" command not in documentation

[Joey McAllister (JIRA)]

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

Joey McAllister commented on GEODE-2991:


D'oh. Never mind. Getting my destroy gateway senders and destroy gateway 
receivers crossed.

> "destroy gateway-sender" command not in documentation
> -
>
> Key: GEODE-2991
> URL: https://issues.apache.org/jira/browse/GEODE-2991
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Emily Yeh
>Priority: Minor
>
> Documentation for the {{destroy gateway-sender}} command (handled by the 
> {{destroyGatewaySender}} method under {{WanCommands.java}}) isn't available 
> in the docs yet.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (GEODE-3139) remove geode-core/src/main artifacts from classpath of backward-compatibility tests

[Bruce Schuchardt (JIRA)]

Bruce Schuchardt created GEODE-3139:
---

 Summary: remove geode-core/src/main artifacts from classpath of 
backward-compatibility tests
 Key: GEODE-3139
 URL: https://issues.apache.org/jira/browse/GEODE-3139
 Project: Geode
  Issue Type: Bug
  Components: build
Reporter: Bruce Schuchardt


When a JVM is launched to run an old version of GEODE its classpath currently 
includes the old version's jars but also includes the current version's 
classes, resources and generated-resources directories.  This could cause the 
JVM to function differently than expected if the test happens to reference some 
new class or an API that doesn't exist in the old version.

I removed these directories from the classpath and found that the tests all 
break when the couldn't find InternalClientCache, a new interface that is now 
referenced by the test framework.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (GEODE-2991) "destroy gateway-sender" command not in documentation

[Emily Yeh (JIRA)]

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

Emily Yeh updated GEODE-2991:
-
Description: Documentation for the {{destroy gateway-sender}} command 
(handled by the {{destroyGatewaySender}} method under {{WanCommands.java}}) 
isn't available in the docs yet.  (was: Documentation for the "destroy 
gateway-sender" command (handled by the destroyGatewaySender method under 
WanCommands.java) isn't available in the docs yet.)

> "destroy gateway-sender" command not in documentation
> -
>
> Key: GEODE-2991
> URL: https://issues.apache.org/jira/browse/GEODE-2991
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Emily Yeh
>Priority: Minor
>
> Documentation for the {{destroy gateway-sender}} command (handled by the 
> {{destroyGatewaySender}} method under {{WanCommands.java}}) isn't available 
> in the docs yet.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-2996) New flow: put/get

[ASF GitHub Bot (JIRA)]

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

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

Github user asfgit closed the pull request at:

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


> New flow: put/get
> -
>
> Key: GEODE-2996
> URL: https://issues.apache.org/jira/browse/GEODE-2996
> Project: Geode
>  Issue Type: Sub-task
>  Components: client/server
>Reporter: Brian Baynes
>
> Create proto message definitions and op handler for put/get messages.
> Client should be able to complete put/get of primitives and JSON with 
> response.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-2996) New flow: put/get

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2996:


Commit 565e61f74409d59cc96c9fbf1ad75d331b728301 in geode's branch 
refs/heads/develop from Alexander Murmann
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=565e61f ]

GEODE-2996: incorporating review feedback and adding integration test

Addresses review feedback for GEODE-2996, mainly refactoring getOpertionHandler 
to handle failures like the putOperationHandler
Adding put operations to the RoundTripCacheConnectionJUnitTest, which is the 
integration test for the protobuf module
Removing service loading for protobuf operations and instead have the 
ProtobufStreamProcessor populate its OperationHandlerRegistry
Remove exception throwing from OperationHandler.process calls and remove 
TypeEncodingException

Signed-off-by: Brian Rowe 
Signed-off-by: Alexander Murmann 

This closes #605


> New flow: put/get
> -
>
> Key: GEODE-2996
> URL: https://issues.apache.org/jira/browse/GEODE-2996
> Project: Geode
>  Issue Type: Sub-task
>  Components: client/server
>Reporter: Brian Baynes
>
> Create proto message definitions and op handler for put/get messages.
> Client should be able to complete put/get of primitives and JSON with 
> response.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (GEODE-3127) Add function execution to new protocol

[Brian Baynes (JIRA)]

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

Brian Baynes updated GEODE-3127:

Description: 
As a Geode developer using the new client/server protocol, I need the ability 
to execute server-side functions, a key feature of Geode.
Add parameter-less function execution to the new protocol, verifying users can 
execute functions and receive expected results.  (Functions with parameters are 
covered in GEODE-3138)

  was:
As a Geode developer using the new client/server protocol, I need the ability 
to execute server-side functions, a key feature of Geode.
Add function execution to the new protocol, verifying users can execute 
functions and receive expected results. 


> Add function execution to new protocol
> --
>
> Key: GEODE-3127
> URL: https://issues.apache.org/jira/browse/GEODE-3127
> Project: Geode
>  Issue Type: New Feature
>  Components: client/server
>Reporter: Brian Baynes
>
> As a Geode developer using the new client/server protocol, I need the ability 
> to execute server-side functions, a key feature of Geode.
> Add parameter-less function execution to the new protocol, verifying users 
> can execute functions and receive expected results.  (Functions with 
> parameters are covered in GEODE-3138)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (GEODE-3138) Add function execution *with parameters* to new protocol

[Brian Baynes (JIRA)]

Brian Baynes created GEODE-3138:
---

 Summary: Add function execution *with parameters* to new protocol
 Key: GEODE-3138
 URL: https://issues.apache.org/jira/browse/GEODE-3138
 Project: Geode
  Issue Type: Sub-task
  Components: client/server
Reporter: Brian Baynes


As a Geode user, I want to be able to call server-side functions with 
parameters (such as a Region name to run a function against).
Expand function execution to include functions with parameters.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3130) Refactor communication mode handling in AcceptorImpl.handleNewClientConnection

[ASF GitHub Bot (JIRA)]

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

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

Github user asfgit closed the pull request at:

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


> Refactor communication mode handling in AcceptorImpl.handleNewClientConnection
> --
>
> Key: GEODE-3130
> URL: https://issues.apache.org/jira/browse/GEODE-3130
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Reporter: Brian Rowe
>
> This is pending review feedback from the implementation of 2995 which didn't 
> get addressed prior to the merge.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3130) Refactor communication mode handling in AcceptorImpl.handleNewClientConnection

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-3130:


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

GEODE-3130: Refactoring AcceptorImpl

We extracted a switch statement in AcceptorImpl.handleNewClientConnection to a 
new method.

Signed-off-by: Alexander Murmann 

This closes #602


> Refactor communication mode handling in AcceptorImpl.handleNewClientConnection
> --
>
> Key: GEODE-3130
> URL: https://issues.apache.org/jira/browse/GEODE-3130
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Reporter: Brian Rowe
>
> This is pending review feedback from the implementation of 2995 which didn't 
> get addressed prior to the merge.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3072) Events do not get removed from the client queue when 1.0 clients connect to 1.2 servers

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-3072:


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

GEODE-3072: Events do not get removed from the client queue for 1.0 clients

EventID and ThreadIdentifier hold the serialized form of portions of an
InternalDistributedMember identifier.  This serialized form changed in
v1.0.0 and was causing .equals and .hashCode for these objects to return
false when they should have returned true owing to additional data being
in the serialized form of the identifier.

This change set modifies the equals and hashCode methods of the classes
to ensure that they return the correct results in the presence of this
additional ID data.

I created a dunit test to reproduce the problem but I think the behavior
of HARegionQueues isn't reliable enough to check in that test.  I'm
afraid that it would end up being a "flaky" test that fails periodically.
Instead, I'm relying on a new junit test and the test that Barry already
checked in.

Note: I've also included two other things in this change set.

First, LocalRegion.dumpBackingMap() is a test-hook that should log its
results at "info" level.  I used it in debugging this problem.

Second, I've added a new backward-compatibility version so now we have
100 and 110.


> Events do not get removed from the client queue when 1.0 clients connect to 
> 1.2 servers
> ---
>
> Key: GEODE-3072
> URL: https://issues.apache.org/jira/browse/GEODE-3072
> Project: Geode
>  Issue Type: Bug
>  Components: client queues, serialization
>Reporter: Barry Oglesby
>Assignee: Barry Oglesby
> Fix For: 1.2.0
>
>
> The EventID is created in Put65 cmdExecute on the server here:
> {noformat}
> java.lang.Exception: Stack trace
>   at java.lang.Thread.dumpStack(Thread.java:1329)
>   at org.apache.geode.internal.cache.EventID.(EventID.java:242)
>   at 
> org.apache.geode.internal.cache.tier.sockets.command.Put65.cmdExecute(Put65.java:201)
>   at 
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:165)
>   at 
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMsg(ServerConnection.java:780)
>   at 
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doOneMessage(ServerConnection.java:911)
>   at 
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1166)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at 
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl$1$1.run(AcceptorImpl.java:523)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}
> like:
> {noformat}
> new EventID(serverConnection.getEventMemberIDByteArray(), threadId, 
> sequenceId)
> {noformat}
> This causes a 38 byte membership id to be generated:
> {noformat}
> ServerConnection on port 61938 Thread 2:  EventID.EventID 3 
> membershipIDLength=38
> ServerConnection on port 61938 Thread 0:  
> CacheClientNotifier.processDispatchedMessage eidMembershipIdLength=55
> {noformat}
> The PeriodicAck sends in a 55 byte membership id:
> {noformat}
> ServerConnection on port 61938 Thread 0: DurableHARegionQueue.setAckedEvents 
> ackedEventsSize=1
>   tid=ThreadId[1]; membershipIdLength=55
> {noformat}
> HARegionQueue remove calls HARegionQueue checkEventForRemoval before it 
> removes an event from the queue. When the comparison is made in HARegionQueue 
> checkEventForRemoval, it returns false every time. Its false because the 
> input ThreadIdentifier is not the same as the one in the currDurableMap. 
> Their toStrings are the same, but they are not equal because their 
> membershipIDs are not equal. This is why the events aren't being removed.
> Here is some debugging that shows the difference:
> {noformat}
> DurableHARegionQueue.checkEventForRemoval 
> threadId=ThreadId[192.168.2.4(client-feeder:loner):61201:70bec7a3:client-feeder;
>  thread 1]; membershipIdLength=38
> DurableHARegionQueue.checkEventForRemoval 
> currDurableMapKey=ThreadId[192.168.2.4(client-feeder:loner):61201:70bec7a3:client-feeder;
>  thread 1]; membershipIdLength=55
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3135) Update to OpenSSL 1.0.2 LTS

[Karen Smoler Miller (JIRA)]

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

Karen Smoler Miller commented on GEODE-3135:


Here are locations in the documentation (in the docs/geode-native-docs 
directory) that reference version 1.0.1, and likely need to be updated:

- ./introduction/client-configurations.html.md.erb:The client requires OpenSSL 
1.0.1t or later. For Windows platforms, you can use either the regular or the 
OpenSSL "Light" version.
- ./introduction/quickstart.html.md.erb:If you plan to run the security 
examples, download the latest version of release 1.0.1 (must be 1.0.1) from the 
[OpenSSL website] (http://www.openssl.org/source/).
- ./security/sslclientserver.html.md.erb:The native client requires OpenSSL 
1.0.1t or later. For Windows platforms, you can use either the regular or the 
OpenSSL 1.0.1t "Light" version.
- ./security/sslclientserver.html.md.erb:$ tar xvzf openssl-1.0.1u.tar.gz
- ./security/sslclientserver.html.md.erb:x openssl-1.0.1u/ACKNOWLEDGMENTS
- ./security/sslclientserver.html.md.erb:x openssl-1.0.1u/apps/
- ./security/sslclientserver.html.md.erb:x openssl-1.0.1u/apps/app_rand.c
- ./security/sslclientserver.html.md.erb:$ cd openssl-1.0.1u

> Update to OpenSSL 1.0.2 LTS
> ---
>
> Key: GEODE-3135
> URL: https://issues.apache.org/jira/browse/GEODE-3135
> Project: Geode
>  Issue Type: Improvement
>  Components: docs, native client
>Reporter: Jacob S. Barrett
>
> Update to OpenSSL 1.0.2 LTS, which has support until end of 2019 
> [https://www.openssl.org/policies/releasestrat.html].
> OpenSSL 1.0.1 has been out of support in 2016.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (GEODE-3135) Update to OpenSSL 1.0.2 LTS

[Karen Smoler Miller (JIRA)]

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

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

> Update to OpenSSL 1.0.2 LTS
> ---
>
> Key: GEODE-3135
> URL: https://issues.apache.org/jira/browse/GEODE-3135
> Project: Geode
>  Issue Type: Improvement
>  Components: docs, native client
>Reporter: Jacob S. Barrett
>
> Update to OpenSSL 1.0.2 LTS, which has support until end of 2019 
> [https://www.openssl.org/policies/releasestrat.html].
> OpenSSL 1.0.1 has been out of support in 2016.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-1958) Remove PasswordUtil

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-1958:


Commit 137ced6bea482209efe5db7d87b58edefd9b7222 in geode's branch 
refs/heads/feature/GEODE-2804v3 from YehEmily
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=137ced6 ]

GEODE-1958: Rolling back changes to decrypt method

* this closes #600


> Remove PasswordUtil 
> 
>
> Key: GEODE-1958
> URL: https://issues.apache.org/jira/browse/GEODE-1958
> Project: Geode
>  Issue Type: Bug
>  Components: security
>Reporter: Diane Hardman
>Assignee: Emily Yeh
>Priority: Minor
>
> PasswordUtil was used to encrypt a password to be stored in cache.xml. This 
> was not secure since anyone could copy the "encrypted" string to another 
> cache.xml to gain access. Therefore this utility was not particularly useful 
> and should be removed.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-2919) Provide finer grained security

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2919:


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

GEODE-2919: revert: fix lucene security tests


> Provide finer grained security
> --
>
> Key: GEODE-2919
> URL: https://issues.apache.org/jira/browse/GEODE-2919
> Project: Geode
>  Issue Type: Improvement
>  Components: docs, security
>Reporter: Swapnil Bawaskar
>
> In our current security model, a user with DATA:MANAGE can create regions, 
> create disk stores, WAN gateways etc. I think this is a very wide scope, 
> because an administrator may want to give create region privilege to a 
> developer, but not necessarily give them the ability to create disk stores or 
> send the data in that region over WAN. I propose that we refine the security 
> model to make it finer grained.
> Please see this discussion on the mailing list: 
> https://lists.apache.org/thread.html/f96842276e93d8a6c3080ad3982c72431d62d1e7c717ebbc50941968@%3Cdev.geode.apache.org%3E



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3017) On windows, we don't choose right interface for IPv6

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-3017:


Commit ea8840fc98c794e58f380fb6a82f1002f195152e in geode's branch 
refs/heads/feature/GEODE-2804v3 from [~hitesh.khamesra]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=ea8840f ]

 GEODE-2804 Caching the InetAddress for configured ip string

1. We keep configure host string in HostAddress class
2. We reuse InetsocketAddress if it is ipString.
3. Client has logic to retry thus we keep InetsocketAddress even if
   it is not ip string.

GEODE-3017 IPv6 issue on windows. Above changes fixed this issue.

GEODE-2940 Now we don't validate configure host string on start. As
there is possibility that host may not available.

1. Earlier wan config were failing because of that. Now we just keep
those configure host string. And try this later.

Added unit tests for it.


> On windows, we don't choose right interface for IPv6
> 
>
> Key: GEODE-3017
> URL: https://issues.apache.org/jira/browse/GEODE-3017
> Project: Geode
>  Issue Type: Bug
>  Components: membership
>Reporter: Hitesh Khamesra
>
> It seems changes related to GEODE-2804 causing this issue. In that change, we 
> use the hostname to connect to locator but with ipv6 on windows, it's not 
> working appropriately. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-2995) Introduce new protocol flow into core

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2995:


Commit a3c66e1afc88700bd7839f56d54a0f6d44f00432 in geode's branch 
refs/heads/feature/GEODE-2804v3 from [~WireBaron]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=a3c66e1 ]

GEODE-2995: incorporating even more review feedback

Addressing feedback from Udo and Hitesh
Refactored test locations to match new src layout

Signed-off-by: Galen O'Sullivan 
Signed-off-by: Brian Rowe 


> Introduce new protocol flow into core
> -
>
> Key: GEODE-2995
> URL: https://issues.apache.org/jira/browse/GEODE-2995
> Project: Geode
>  Issue Type: Sub-task
>  Components: client/server
>Reporter: Brian Baynes
>Assignee: Udo Kohlmeyer
>
> Create new protocol flow in core to handle incoming client messages, 
> serialize/de-serialize primitives and JSON, construct/de-construct messages, 
> and complete operations with response.
> New protocol flow should handle put/get messages with response, covering 
> primitives and JSON.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-2995) Introduce new protocol flow into core

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2995:


Commit db11ebc1efdf2371bdf1566a7828dc08ea621e2c in geode's branch 
refs/heads/feature/GEODE-2804v3 from [~gosullivan]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=db11ebc ]

merge GEODE-2995, GEODE-3775 into develop with integration test.

Signed-off-by: Brian Rowe 


> Introduce new protocol flow into core
> -
>
> Key: GEODE-2995
> URL: https://issues.apache.org/jira/browse/GEODE-2995
> Project: Geode
>  Issue Type: Sub-task
>  Components: client/server
>Reporter: Brian Baynes
>Assignee: Udo Kohlmeyer
>
> Create new protocol flow in core to handle incoming client messages, 
> serialize/de-serialize primitives and JSON, construct/de-construct messages, 
> and complete operations with response.
> New protocol flow should handle put/get messages with response, covering 
> primitives and JSON.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-2919) Provide finer grained security

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2919:


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

GEODE-2919: fix lucene security tests


> Provide finer grained security
> --
>
> Key: GEODE-2919
> URL: https://issues.apache.org/jira/browse/GEODE-2919
> Project: Geode
>  Issue Type: Improvement
>  Components: docs, security
>Reporter: Swapnil Bawaskar
>
> In our current security model, a user with DATA:MANAGE can create regions, 
> create disk stores, WAN gateways etc. I think this is a very wide scope, 
> because an administrator may want to give create region privilege to a 
> developer, but not necessarily give them the ability to create disk stores or 
> send the data in that region over WAN. I propose that we refine the security 
> model to make it finer grained.
> Please see this discussion on the mailing list: 
> https://lists.apache.org/thread.html/f96842276e93d8a6c3080ad3982c72431d62d1e7c717ebbc50941968@%3Cdev.geode.apache.org%3E



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3075) Bifurcate ServerConnection, create factory and feature toggle

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-3075:


Commit e62e825090db50f77faaa3e222595ee1026d7a6c in geode's branch 
refs/heads/feature/GEODE-2804v3 from [~gosullivan]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=e62e825 ]

GEODE-3075: fix an integration test.

I think the test fails because another test doesn't clean up system
properties when it's done.


> Bifurcate ServerConnection, create factory and feature toggle
> -
>
> Key: GEODE-3075
> URL: https://issues.apache.org/jira/browse/GEODE-3075
> Project: Geode
>  Issue Type: Sub-task
>  Components: client/server
>Reporter: Galen O'Sullivan
>Assignee: Galen O'Sullivan
> Fix For: 1.3.0
>
>
> Make a factory that creates instances of the new subclasses of 
> {{ServerConnection}} : {{NewClientServerConnection}} and 
> {{LegacyServerConnection}}. This will be the basis for future refactors. This 
> should involve minimal changes to {{AcceptorImpl}} and a minimal 
> implementation of {{NewClientServerConnection}}. All the existing 
> functionality of {{ServerConnection}} must still work.
> To do this, we will need a feature toggle so that the new client protocol 
> (which will now be in a broken state) never gets run in production, but can 
> be enabled for testing. This should probably be set via a hidden system 
> property and not through any config that is a part of the public API.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3017) On windows, we don't choose right interface for IPv6

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-3017:


Commit b73119046f845c02f160b85c9b70f54e870d8f03 in geode's branch 
refs/heads/feature/GEODE-2804v3 from [~hitesh.khamesra]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=b731190 ]

 GEODE-2804 Caching the InetAddress for configured ip string

1. We keep configure host string in HostAddress class
2. We reuse InetsocketAddress if it is ipString.
3. Client has logic to retry thus we keep InetsocketAddress even if
   it is not ip string.

GEODE-3017 IPv6 issue on windows. Above changes fixed this issue.

GEODE-2940 Now we don't validate configure host string on start. As
there is possibility that host may not available.

1. Earlier wan config were failing because of that. Now we just keep
those configure host string. And try this later.

Added unit tests for it.


> On windows, we don't choose right interface for IPv6
> 
>
> Key: GEODE-3017
> URL: https://issues.apache.org/jira/browse/GEODE-3017
> Project: Geode
>  Issue Type: Bug
>  Components: membership
>Reporter: Hitesh Khamesra
>
> It seems changes related to GEODE-2804 causing this issue. In that change, we 
> use the hostname to connect to locator but with ipv6 on windows, it's not 
> working appropriately. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-2940) Remove verification of locator host on start

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2940:


Commit b73119046f845c02f160b85c9b70f54e870d8f03 in geode's branch 
refs/heads/feature/GEODE-2804v3 from [~hitesh.khamesra]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=b731190 ]

 GEODE-2804 Caching the InetAddress for configured ip string

1. We keep configure host string in HostAddress class
2. We reuse InetsocketAddress if it is ipString.
3. Client has logic to retry thus we keep InetsocketAddress even if
   it is not ip string.

GEODE-3017 IPv6 issue on windows. Above changes fixed this issue.

GEODE-2940 Now we don't validate configure host string on start. As
there is possibility that host may not available.

1. Earlier wan config were failing because of that. Now we just keep
those configure host string. And try this later.

Added unit tests for it.


> Remove verification of locator host on start
> 
>
> Key: GEODE-2940
> URL: https://issues.apache.org/jira/browse/GEODE-2940
> Project: Geode
>  Issue Type: New Feature
>  Components: membership
>Reporter: Brian Baynes
>
> We configure locator list to start the cache. This locator list is validated 
> while creating the cache. We verify whether locator host exists or not. Now 
> we need to remove this verification as in cloud environment host may not 
> available for time being.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-2804) Allow a locator host to be taken off line and replaced with a different machine having the same host name

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2804:


Commit b73119046f845c02f160b85c9b70f54e870d8f03 in geode's branch 
refs/heads/feature/GEODE-2804v3 from [~hitesh.khamesra]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=b731190 ]

 GEODE-2804 Caching the InetAddress for configured ip string

1. We keep configure host string in HostAddress class
2. We reuse InetsocketAddress if it is ipString.
3. Client has logic to retry thus we keep InetsocketAddress even if
   it is not ip string.

GEODE-3017 IPv6 issue on windows. Above changes fixed this issue.

GEODE-2940 Now we don't validate configure host string on start. As
there is possibility that host may not available.

1. Earlier wan config were failing because of that. Now we just keep
those configure host string. And try this later.

Added unit tests for it.


> Allow a locator host to be taken off line and replaced with a different 
> machine having the same host name
> -
>
> Key: GEODE-2804
> URL: https://issues.apache.org/jira/browse/GEODE-2804
> Project: Geode
>  Issue Type: Improvement
>  Components: client/server, membership, native client
>Affects Versions: 1.1.1
>Reporter: Bruce Schuchardt
>Assignee: Hitesh Khamesra
>
> It is not unlikely that in a long-running system a machine hosting a locator 
> will break down and need to be replace, or that a virtual machine hosting a 
> locator will be stopped and restarted.  In either case the machine may have a 
> different IP address.
> Clients and servers currently cache the IP address of a locator and should be 
> changed to re-resolve the host name if the address stops being usable.
> Servers currently cannot be started if they are given a host name that can 
> not be resolved.  They should be changed to allow this and start up if they 
> are able to contact one or more of the other locators in their "locators" 
> setting.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3117) Gateway authentication throws NullPointerException

[ASF GitHub Bot (JIRA)]

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

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

Github user PurelyApplied commented on the issue:

https://github.com/apache/geode/pull/601
  
+1.  Huzzah for more test coverage.


> Gateway authentication throws NullPointerException
> --
>
> Key: GEODE-3117
> URL: https://issues.apache.org/jira/browse/GEODE-3117
> Project: Geode
>  Issue Type: Bug
>  Components: security, wan
>Reporter: Kirk Lund
>Assignee: Kirk Lund
> Attachments: geode-3117.tar
>
>
> {noformat}
> java.lang.NullPointerException
> at 
> org.apache.geode.security.templates.DummyAuthenticator.authenticate(DummyAuthenticator.java:50)
> at 
> org.apache.geode.internal.cache.tier.sockets.HandShake.verifyCredentials(HandShake.java:1699)
> at 
> org.apache.geode.internal.cache.tier.sockets.HandShake.checkIfAuthenticWanSite(HandShake.java:1746)
> at 
> org.apache.geode.internal.cache.tier.sockets.HandShake.readMessage(HandShake.java:1409)
> at 
> org.apache.geode.internal.cache.tier.sockets.HandShake.handshakeWithServer(HandShake.java:1258)
> at 
> org.apache.geode.cache.client.internal.ConnectionImpl.connect(ConnectionImpl.java:117)
> at 
> org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:136)
> at 
> org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:259)
> at 
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.borrowConnection(ConnectionManagerImpl.java:206)
> at 
> org.apache.geode.cache.client.internal.PoolImpl.acquireConnection(PoolImpl.java:898)
> at 
> org.apache.geode.internal.cache.wan.GatewaySenderEventRemoteDispatcher.initializeConnection(GatewaySenderEventRemoteDispatcher.java:402)
> at 
> org.apache.geode.internal.cache.wan.GatewaySenderEventRemoteDispatcher.getConnection(GatewaySenderEventRemoteDispatcher.java:317)
> at 
> org.apache.geode.internal.cache.wan.GatewaySenderEventRemoteDispatcher._dispatchBatch(GatewaySenderEventRemoteDispatcher.java:199)
> at 
> org.apache.geode.internal.cache.wan.GatewaySenderEventRemoteDispatcher.dispatchBatch(GatewaySenderEventRemoteDispatcher.java:148)
> at 
> org.apache.geode.internal.cache.wan.AbstractGatewaySenderEventProcessor.processQueue(AbstractGatewaySenderEventProcessor.java:609)
> at 
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderEventProcessor.run(SerialGatewaySenderEventProcessor.java:223)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3117) Gateway authentication throws NullPointerException

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/geode/pull/601#discussion_r124376469
  
--- Diff: 
geode-wan/src/test/java/org/apache/geode/internal/cache/wan/misc/GatewayLegacyAuthenticationRegressionTest.java
 ---
@@ -0,0 +1,429 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more 
contributor license
+ * agreements. See the NOTICE file distributed with this work for 
additional information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache 
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the 
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software 
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF 
ANY KIND, either express
+ * or implied. See the License for the specific language governing 
permissions and limitations under
+ * the License.
+ */
+package org.apache.geode.internal.cache.wan.misc;
+
+import static java.util.concurrent.TimeUnit.MINUTES;
+import static 
org.apache.geode.distributed.ConfigurationProperties.DISTRIBUTED_SYSTEM_ID;
+import static 
org.apache.geode.distributed.ConfigurationProperties.LOCATORS;
+import static 
org.apache.geode.distributed.ConfigurationProperties.MCAST_PORT;
+import static 
org.apache.geode.distributed.ConfigurationProperties.REMOTE_LOCATORS;
+import static 
org.apache.geode.distributed.ConfigurationProperties.SECURITY_CLIENT_AUTHENTICATOR;
+import static 
org.apache.geode.distributed.ConfigurationProperties.SECURITY_PEER_AUTHENTICATOR;
+import static 
org.apache.geode.distributed.ConfigurationProperties.SECURITY_PEER_AUTH_INIT;
+import static 
org.apache.geode.distributed.ConfigurationProperties.START_LOCATOR;
+import static org.apache.geode.test.dunit.Host.getHost;
+import static org.assertj.core.api.Assertions.assertThat;
+import static org.awaitility.Awaitility.await;
+import static org.awaitility.Awaitility.waitAtMost;
+
+import java.io.File;
+import java.io.IOException;
+import java.io.Serializable;
+import java.security.Principal;
+import java.util.Properties;
+import java.util.UUID;
+import java.util.concurrent.atomic.AtomicInteger;
+
+import org.junit.Before;
+import org.junit.Rule;
+import org.junit.Test;
+import org.junit.experimental.categories.Category;
+
+import org.apache.geode.LogWriter;
+import org.apache.geode.cache.AttributesFactory;
+import org.apache.geode.cache.Cache;
+import org.apache.geode.cache.CacheFactory;
+import org.apache.geode.cache.DataPolicy;
+import org.apache.geode.cache.DiskStore;
+import org.apache.geode.cache.DiskStoreFactory;
+import org.apache.geode.cache.Region;
+import org.apache.geode.cache.Scope;
+import org.apache.geode.cache.wan.GatewayReceiver;
+import org.apache.geode.cache.wan.GatewayReceiverFactory;
+import org.apache.geode.cache.wan.GatewaySender;
+import org.apache.geode.cache.wan.GatewaySenderFactory;
+import org.apache.geode.distributed.DistributedMember;
+import org.apache.geode.distributed.DistributedSystem;
+import org.apache.geode.internal.AvailablePortHelper;
+import org.apache.geode.internal.cache.wan.InternalGatewaySenderFactory;
+import org.apache.geode.security.AuthInitialize;
+import org.apache.geode.security.AuthenticationFailedException;
+import org.apache.geode.security.Authenticator;
+import org.apache.geode.test.dunit.DistributedTestCase;
+import org.apache.geode.test.dunit.VM;
+import org.apache.geode.test.junit.categories.DistributedTest;
+import org.apache.geode.test.junit.categories.SecurityTest;
+import org.apache.geode.test.junit.categories.WanTest;
+import 
org.apache.geode.test.junit.rules.serializable.SerializableTemporaryFolder;
+
+/**
+ * Reproduces bug GEODE-3117: "Gateway authentication throws 
NullPointerException" and validates the
+ * fix.
+ */
+@Category({DistributedTest.class, SecurityTest.class, WanTest.class})
+public class GatewayLegacyAuthenticationRegressionTest extends 
DistributedTestCase {
+
+  private static final String USER_NAME = "security-username";
+  private static final String PASSWORD = "security-password";
+
+  private static final AtomicInteger invokeAuthenticateCount = new 
AtomicInteger();
+
+  private static Cache cache;
+  private static GatewaySender 

[jira] [Commented] (GEODE-2940) Remove verification of locator host on start

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2940:


Commit 5c60b9696fdb42426c4df8f7ca78599fcb872cc0 in geode's branch 
refs/heads/feature/GEODE-2804 from [~hitesh.khamesra]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=5c60b96 ]

 GEODE-2804 Caching the InetAddress for configured ip string

1. We keep configure host string in HostAddress class
2. We reuse InetsocketAddress if it is ipString.
3. Client has logic to retry thus we keep InetsocketAddress even if
   it is not ip string.

GEODE-3017 IPv6 issue on windows. Above changes fixed this issue.

GEODE-2940 Now we don't validate configure host string on start. As
there is possibility that host may not available.

1. Earlier wan config were failing because of that. Now we just keep
those configure host string. And try this later.

Added unit tests for it.


> Remove verification of locator host on start
> 
>
> Key: GEODE-2940
> URL: https://issues.apache.org/jira/browse/GEODE-2940
> Project: Geode
>  Issue Type: New Feature
>  Components: membership
>Reporter: Brian Baynes
>
> We configure locator list to start the cache. This locator list is validated 
> while creating the cache. We verify whether locator host exists or not. Now 
> we need to remove this verification as in cloud environment host may not 
> available for time being.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-2804) Allow a locator host to be taken off line and replaced with a different machine having the same host name

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2804:


Commit 5c60b9696fdb42426c4df8f7ca78599fcb872cc0 in geode's branch 
refs/heads/feature/GEODE-2804 from [~hitesh.khamesra]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=5c60b96 ]

 GEODE-2804 Caching the InetAddress for configured ip string

1. We keep configure host string in HostAddress class
2. We reuse InetsocketAddress if it is ipString.
3. Client has logic to retry thus we keep InetsocketAddress even if
   it is not ip string.

GEODE-3017 IPv6 issue on windows. Above changes fixed this issue.

GEODE-2940 Now we don't validate configure host string on start. As
there is possibility that host may not available.

1. Earlier wan config were failing because of that. Now we just keep
those configure host string. And try this later.

Added unit tests for it.


> Allow a locator host to be taken off line and replaced with a different 
> machine having the same host name
> -
>
> Key: GEODE-2804
> URL: https://issues.apache.org/jira/browse/GEODE-2804
> Project: Geode
>  Issue Type: Improvement
>  Components: client/server, membership, native client
>Affects Versions: 1.1.1
>Reporter: Bruce Schuchardt
>Assignee: Hitesh Khamesra
>
> It is not unlikely that in a long-running system a machine hosting a locator 
> will break down and need to be replace, or that a virtual machine hosting a 
> locator will be stopped and restarted.  In either case the machine may have a 
> different IP address.
> Clients and servers currently cache the IP address of a locator and should be 
> changed to re-resolve the host name if the address stops being usable.
> Servers currently cannot be started if they are given a host name that can 
> not be resolved.  They should be changed to allow this and start up if they 
> are able to contact one or more of the other locators in their "locators" 
> setting.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3017) On windows, we don't choose right interface for IPv6

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-3017:


Commit 5c60b9696fdb42426c4df8f7ca78599fcb872cc0 in geode's branch 
refs/heads/feature/GEODE-2804 from [~hitesh.khamesra]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=5c60b96 ]

 GEODE-2804 Caching the InetAddress for configured ip string

1. We keep configure host string in HostAddress class
2. We reuse InetsocketAddress if it is ipString.
3. Client has logic to retry thus we keep InetsocketAddress even if
   it is not ip string.

GEODE-3017 IPv6 issue on windows. Above changes fixed this issue.

GEODE-2940 Now we don't validate configure host string on start. As
there is possibility that host may not available.

1. Earlier wan config were failing because of that. Now we just keep
those configure host string. And try this later.

Added unit tests for it.


> On windows, we don't choose right interface for IPv6
> 
>
> Key: GEODE-3017
> URL: https://issues.apache.org/jira/browse/GEODE-3017
> Project: Geode
>  Issue Type: Bug
>  Components: membership
>Reporter: Hitesh Khamesra
>
> It seems changes related to GEODE-2804 causing this issue. In that change, we 
> use the hostname to connect to locator but with ipv6 on windows, it's not 
> working appropriately. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-2804) Allow a locator host to be taken off line and replaced with a different machine having the same host name

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2804:


Commit d303e7c953535c11df0547e2282cc27bad1d6f57 in geode's branch 
refs/heads/feature/GEODE-2804 from [~hitesh.khamesra]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=d303e7c ]

Revert "GEODE-2804 Caching the InetAddress for configured ip string"

This reverts commit 58afd6869980028e6b8d0e5848a8fc7a00270262.


> Allow a locator host to be taken off line and replaced with a different 
> machine having the same host name
> -
>
> Key: GEODE-2804
> URL: https://issues.apache.org/jira/browse/GEODE-2804
> Project: Geode
>  Issue Type: Improvement
>  Components: client/server, membership, native client
>Affects Versions: 1.1.1
>Reporter: Bruce Schuchardt
>Assignee: Hitesh Khamesra
>
> It is not unlikely that in a long-running system a machine hosting a locator 
> will break down and need to be replace, or that a virtual machine hosting a 
> locator will be stopped and restarted.  In either case the machine may have a 
> different IP address.
> Clients and servers currently cache the IP address of a locator and should be 
> changed to re-resolve the host name if the address stops being usable.
> Servers currently cannot be started if they are given a host name that can 
> not be resolved.  They should be changed to allow this and start up if they 
> are able to contact one or more of the other locators in their "locators" 
> setting.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-2996) New flow: put/get

[ASF GitHub Bot (JIRA)]

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

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

GitHub user WireBaron opened a pull request:

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

GEODE-2996: incorporating review feedback and adding integration test

Thank you for submitting a contribution to Apache Geode.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

### For all changes:
- [x] Is there a JIRA ticket associated with this PR? Is it referenced in 
the commit message?

- [x] Has your PR been rebased against the latest commit within the target 
branch (typically `develop`)?

- [x] Is your initial contribution a single, squashed commit?

- [x] Does `gradlew build` run cleanly?

- [ x] Have you written or updated unit tests to verify your changes?

- [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and
submit an update to your PR as soon as possible. If you need help, please 
send an
email to d...@geode.apache.org.


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

$ git pull https://github.com/WireBaron/geode feature/GEODE-2996

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

https://github.com/apache/geode/pull/605.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #605


commit 3a2d2573151d260e8f030403a03cd47c88e366bf
Author: Alexander Murmann 
Date:   2017-06-27T00:56:06Z

GEODE-2996: incorporating review feedback and adding integration test

Addresses review feedback for GEODE-2996, mainly refactoring 
getOpertionHandler to handle failures like the putOperationHandler
Adding put operations to the RoundTripCacheConnectionJUnitTest, which is 
the integration test for the protobuf module
Removing service loading for protobuf operations and instead have the 
ProtobufStreamProcessor populate its OperationHandlerRegistry
Remove exception throwing from OperationHandler.process calls and remove 
TypeEncodingException

Signed-off-by: Brian Rowe 
Signed-off-by: Alexander Murmann 




> New flow: put/get
> -
>
> Key: GEODE-2996
> URL: https://issues.apache.org/jira/browse/GEODE-2996
> Project: Geode
>  Issue Type: Sub-task
>  Components: client/server
>Reporter: Brian Baynes
>
> Create proto message definitions and op handler for put/get messages.
> Client should be able to complete put/get of primitives and JSON with 
> response.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-2940) Remove verification of locator host on start

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2940:


Commit 58afd6869980028e6b8d0e5848a8fc7a00270262 in geode's branch 
refs/heads/feature/GEODE-2804 from [~hitesh.khamesra]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=58afd68 ]

GEODE-2804 Caching the InetAddress for configured ip string

1. We keep configure host string in HostAddress class
2. We reuse InetsocketAddress if it is ipString.
3. Client has logic to retry thus we keep InetsocketAddress even if
   it is not ip string.

GEODE-3017 IPv6 issue on windows. Above changes fixed this issue.

GEODE-2940 Now we don't validate configure host string on start. As
there is possibility that host may not available.

1. Earlier wan config were failing because of that. Now we just keep
those configure host string. And try this later.

Added unit tests for it.


> Remove verification of locator host on start
> 
>
> Key: GEODE-2940
> URL: https://issues.apache.org/jira/browse/GEODE-2940
> Project: Geode
>  Issue Type: New Feature
>  Components: membership
>Reporter: Brian Baynes
>
> We configure locator list to start the cache. This locator list is validated 
> while creating the cache. We verify whether locator host exists or not. Now 
> we need to remove this verification as in cloud environment host may not 
> available for time being.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3017) On windows, we don't choose right interface for IPv6

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-3017:


Commit 58afd6869980028e6b8d0e5848a8fc7a00270262 in geode's branch 
refs/heads/feature/GEODE-2804 from [~hitesh.khamesra]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=58afd68 ]

GEODE-2804 Caching the InetAddress for configured ip string

1. We keep configure host string in HostAddress class
2. We reuse InetsocketAddress if it is ipString.
3. Client has logic to retry thus we keep InetsocketAddress even if
   it is not ip string.

GEODE-3017 IPv6 issue on windows. Above changes fixed this issue.

GEODE-2940 Now we don't validate configure host string on start. As
there is possibility that host may not available.

1. Earlier wan config were failing because of that. Now we just keep
those configure host string. And try this later.

Added unit tests for it.


> On windows, we don't choose right interface for IPv6
> 
>
> Key: GEODE-3017
> URL: https://issues.apache.org/jira/browse/GEODE-3017
> Project: Geode
>  Issue Type: Bug
>  Components: membership
>Reporter: Hitesh Khamesra
>
> It seems changes related to GEODE-2804 causing this issue. In that change, we 
> use the hostname to connect to locator but with ipv6 on windows, it's not 
> working appropriately. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (GEODE-3136) Replace all public API time values with std::chrono types

[Jacob S. Barrett (JIRA)]

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

Jacob S. Barrett updated GEODE-3136:

Component/s: native client

> Replace all public API time values with std::chrono types
> -
>
> Key: GEODE-3136
> URL: https://issues.apache.org/jira/browse/GEODE-3136
> Project: Geode
>  Issue Type: Improvement
>  Components: native client
>Reporter: Jacob S. Barrett
>
> Remove ambiguity of time values by using 
> [{{std::chrono}}|http://en.cppreference.com/w/cpp/chrono] types in the public 
> API. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (GEODE-3137) Replace all time values internally with std::chrono types

[Jacob S. Barrett (JIRA)]

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

 Summary: Replace all time values internally with std::chrono types
 Key: GEODE-3137
 URL: https://issues.apache.org/jira/browse/GEODE-3137
 Project: Geode
  Issue Type: Improvement
  Components: native client
Reporter: Jacob S. Barrett


Remove ambiguity of time values by using 
[{{std::chrono}}|http://en.cppreference.com/w/cpp/chrono] types used 
internally. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (GEODE-3136) Replace all public API time values with std::chrono types

[Jacob S. Barrett (JIRA)]

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

 Summary: Replace all public API time values with std::chrono types
 Key: GEODE-3136
 URL: https://issues.apache.org/jira/browse/GEODE-3136
 Project: Geode
  Issue Type: Improvement
Reporter: Jacob S. Barrett


Remove ambiguity of time values by using 
[{{std::chrono}}|http://en.cppreference.com/w/cpp/chrono] types in the public 
API. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (GEODE-3135) Update to OpenSSL 1.0.2 LTS

[Jacob S. Barrett (JIRA)]

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

 Summary: Update to OpenSSL 1.0.2 LTS
 Key: GEODE-3135
 URL: https://issues.apache.org/jira/browse/GEODE-3135
 Project: Geode
  Issue Type: Improvement
  Components: native client
Reporter: Jacob S. Barrett


Update to OpenSSL 1.0.2 LTS, which has support until end of 2019 
[https://www.openssl.org/policies/releasestrat.html].

OpenSSL 1.0.1 has been out of support in 2016.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (GEODE-3093) Update support for OpenSSL to 1.2

[Jacob S. Barrett (JIRA)]

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

Jacob S. Barrett updated GEODE-3093:

Priority: Minor  (was: Major)
 Summary: Update support for OpenSSL to 1.2  (was: Update support for 
OpenSSL to 1.1)

Changing and delaying until OpenSSL 1.2 LTS comes out.

> Update support for OpenSSL to 1.2
> -
>
> Key: GEODE-3093
> URL: https://issues.apache.org/jira/browse/GEODE-3093
> Project: Geode
>  Issue Type: Improvement
>  Components: docs, native client
>Reporter: Jacob S. Barrett
>Assignee: Jacob S. Barrett
>Priority: Minor
>
> OpenSSL's current stable line is 1.1 and we should update our support to that 
> line for security purposes.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-2919) Provide finer grained security

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2919:


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

GEODE-2919: revert: fix lucene security tests


> Provide finer grained security
> --
>
> Key: GEODE-2919
> URL: https://issues.apache.org/jira/browse/GEODE-2919
> Project: Geode
>  Issue Type: Improvement
>  Components: docs, security
>Reporter: Swapnil Bawaskar
>
> In our current security model, a user with DATA:MANAGE can create regions, 
> create disk stores, WAN gateways etc. I think this is a very wide scope, 
> because an administrator may want to give create region privilege to a 
> developer, but not necessarily give them the ability to create disk stores or 
> send the data in that region over WAN. I propose that we refine the security 
> model to make it finer grained.
> Please see this discussion on the mailing list: 
> https://lists.apache.org/thread.html/f96842276e93d8a6c3080ad3982c72431d62d1e7c717ebbc50941968@%3Cdev.geode.apache.org%3E



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (GEODE-3134) fix LuceneCommandsSecurityDUnitTest

[Jinmei Liao (JIRA)]

Jinmei Liao created GEODE-3134:
--

 Summary: fix LuceneCommandsSecurityDUnitTest
 Key: GEODE-3134
 URL: https://issues.apache.org/jira/browse/GEODE-3134
 Project: Geode
  Issue Type: Bug
Reporter: Jinmei Liao






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3055) waitUntilFlush did not check the brq's tempQueue, which caused data mismatch

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-3055:


Commit 1ceb97c7a9be2143f8cb5a4c4c38e8c8e2d216e3 in geode's branch 
refs/heads/feature/GEM-1483 from zhouxh
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=1ceb97c ]

GEODE-3055: The old primary's the shadow bucket is not
initialized when rebalance remove it. Thus the new primary candidate can
never initialize from it. The fix is to wait until new primary exists before
remove the old primary's bucket in rebalance.


> waitUntilFlush did not check the brq's tempQueue, which caused data mismatch
> 
>
> Key: GEODE-3055
> URL: https://issues.apache.org/jira/browse/GEODE-3055
> Project: Geode
>  Issue Type: Bug
>Reporter: xiaojian zhou
>Assignee: xiaojian zhou
>  Labels: lucene
>
> /export/buglogs_bvt/xzhou/lucene/concParRegHAPersist-0601-171739
> lucene/concParRegHAPersist.conf
> A=accessor
> B=dataStore
> accessorHosts=1
> accessorThreadsPerVM=5
> accessorVMsPerHost=1
> dataStoreHosts=6
> dataStoreThreadsPerVM=5
> dataStoreVMsPerHost=1
> numVMsToStop=2
> redundantCopies=0
> no local.conf
> In dataStoregemfire5_7483/system.log, thread tid=0xdf, putAll Object_11066
> 17:22:27.135 tid=0xdf] generated tag {v1; rv13 shadowKey=2939
> 17:22:27.136 _partitionedRegionPARALLELGATEWAYSENDER_QUEUE_1 bucket : null // 
> brq is not ready yet
> is enqueued to the tempQueue
> 17:22:27.272 tid=0xdf] generated tag {v3; rv15 shadowKey=3278
> 17:22:33.111 Subregion created: 
> /_PR/_BAsyncEventQueueindex#partitionedRegionPARALLELGATEWAYSENDER_QUEUE_1
> vm_3_dataStore3_r02-s28_28143.log:
> 17:22:33.120 Put successfully in the queue shadowKey= 2939
> 17:22:33.156 tid=0x7fe started query
> 17:22:33.176 Peeked shadowKey= 2939
> So the root cause is: the event is still in tempQueue before it's processed, 
> the query happened. WaitUntilFlush should wait until tempQueue is also 
> flushed.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-2919) Provide finer grained security

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2919:


Commit e5204ce1224581425a2ebdc98515dae0044421ee in geode's branch 
refs/heads/feature/GEM-1483 from [~jinmeiliao]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=e5204ce ]

GEODE-2919: fix lucene security tests


> Provide finer grained security
> --
>
> Key: GEODE-2919
> URL: https://issues.apache.org/jira/browse/GEODE-2919
> Project: Geode
>  Issue Type: Improvement
>  Components: docs, security
>Reporter: Swapnil Bawaskar
>
> In our current security model, a user with DATA:MANAGE can create regions, 
> create disk stores, WAN gateways etc. I think this is a very wide scope, 
> because an administrator may want to give create region privilege to a 
> developer, but not necessarily give them the ability to create disk stores or 
> send the data in that region over WAN. I propose that we refine the security 
> model to make it finer grained.
> Please see this discussion on the mailing list: 
> https://lists.apache.org/thread.html/f96842276e93d8a6c3080ad3982c72431d62d1e7c717ebbc50941968@%3Cdev.geode.apache.org%3E



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-2919) Provide finer grained security

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2919:


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

GEODE-2919: fix lucene security tests


> Provide finer grained security
> --
>
> Key: GEODE-2919
> URL: https://issues.apache.org/jira/browse/GEODE-2919
> Project: Geode
>  Issue Type: Improvement
>  Components: docs, security
>Reporter: Swapnil Bawaskar
>
> In our current security model, a user with DATA:MANAGE can create regions, 
> create disk stores, WAN gateways etc. I think this is a very wide scope, 
> because an administrator may want to give create region privilege to a 
> developer, but not necessarily give them the ability to create disk stores or 
> send the data in that region over WAN. I propose that we refine the security 
> model to make it finer grained.
> Please see this discussion on the mailing list: 
> https://lists.apache.org/thread.html/f96842276e93d8a6c3080ad3982c72431d62d1e7c717ebbc50941968@%3Cdev.geode.apache.org%3E



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)