Re: Review Request 58397: check off-heap limit during disk recovery

[Darrel Schneider]

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

(Updated April 12, 2017, 4:42 p.m.)


Review request for geode, anilkumar gingade, Eric Shu, and Lynn Gallinat.


Changes
---

added MemoryMonitor interface based on Anil's feedback
change method to use lruStatistics (the param) instead of stats (the inst var).


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


Repository: geode


Description
---

During disk recovery, the code now checks the offheap LRU limit instead of the 
heap LRU limit for offheap regions.
A unit test has been added that without this fix would run out of offheap 
memory during recovery.


Diffs (updated)
-

  
geode-core/src/main/java/org/apache/geode/internal/cache/AbstractLRURegionMap.java
 328ff35b940239bfbcf817d144d97f886506b33a 
  
geode-core/src/main/java/org/apache/geode/internal/cache/AbstractRegionMap.java 
eaababaf6be6041c72156a338c69fa81f10db4c5 
  geode-core/src/main/java/org/apache/geode/internal/cache/LocalRegion.java 
d0aacc2d95fa38b1bc9faf68de795af5ef3d9090 
  
geode-core/src/main/java/org/apache/geode/internal/cache/PlaceHolderDiskRegion.java
 db01162aeeba8113c208565d683e71a41d0f6d00 
  geode-core/src/main/java/org/apache/geode/internal/cache/ProxyRegionMap.java 
92c7b6f8e90a3382e7ce00064581d69f9706fcd3 
  
geode-core/src/main/java/org/apache/geode/internal/cache/control/HeapMemoryMonitor.java
 afc9a23aafba2c1f993b30546f24cd2b5d6a0126 
  
geode-core/src/main/java/org/apache/geode/internal/cache/control/InternalResourceManager.java
 d16cd98bbb3eefc785a22f41441c1490060d0781 
  
geode-core/src/main/java/org/apache/geode/internal/cache/control/MemoryMonitor.java
 PRE-CREATION 
  
geode-core/src/main/java/org/apache/geode/internal/cache/control/OffHeapMemoryMonitor.java
 414036747a5062ab556b60cdb58c5ce490312c78 
  geode-core/src/main/java/org/apache/geode/internal/cache/lru/EnableLRU.java 
6aaf8cc914c3b8c2e308446930bbd3215c9f58ca 
  
geode-core/src/main/java/org/apache/geode/internal/cache/lru/HeapLRUCapacityController.java
 5e86ce87b99fc4e8793461e881853c141fdfec1f 
  
geode-core/src/main/java/org/apache/geode/internal/cache/lru/LRUCapacityController.java
 3596a07df407960c3558057ac33e92c89bd5ba22 
  
geode-core/src/main/java/org/apache/geode/internal/cache/lru/LRUMapCallbacks.java
 27a4ec019ae3b5fd29a26ffc451d0d9feb75f903 
  
geode-core/src/main/java/org/apache/geode/internal/cache/lru/MemLRUCapacityController.java
 2c2e8ec1a805b7485e6e59858a12122fa8d88de1 
  
geode-core/src/test/java/org/apache/geode/internal/cache/lru/LRUClockJUnitTest.java
 8095d5ac483be061199623a78b63618697e09d9d 
  
geode-core/src/test/java/org/apache/geode/internal/offheap/OffHeapLRURecoveryRegressionTest.java
 PRE-CREATION 


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

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


Testing
---

precheckin


Thanks,

Darrel Schneider

Re: Review Request 58397: check off-heap limit during disk recovery

[Darrel Schneider]

> On April 12, 2017, 2:50 p.m., Eric Shu wrote:
> > geode-core/src/main/java/org/apache/geode/internal/cache/lru/LRUCapacityController.java
> > Lines 294 (patched)
> > 
> >
> > lruStatistics or stats passed in?

Good catch. The intent here was to use the parameter; not the instance variable.
I think in most (perhaps all cases) they end up being the same thing.


- Darrel


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


On April 12, 2017, 11:55 a.m., Darrel Schneider wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58397/
> ---
> 
> (Updated April 12, 2017, 11:55 a.m.)
> 
> 
> Review request for geode, anilkumar gingade, Eric Shu, and Lynn Gallinat.
> 
> 
> Bugs: GEODE-2097
> https://issues.apache.org/jira/browse/GEODE-2097
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> During disk recovery, the code now checks the offheap LRU limit instead of 
> the heap LRU limit for offheap regions.
> A unit test has been added that without this fix would run out of offheap 
> memory during recovery.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/AbstractLRURegionMap.java
>  328ff35b940239bfbcf817d144d97f886506b33a 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/AbstractRegionMap.java
>  eaababaf6be6041c72156a338c69fa81f10db4c5 
>   geode-core/src/main/java/org/apache/geode/internal/cache/LocalRegion.java 
> d0aacc2d95fa38b1bc9faf68de795af5ef3d9090 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/PlaceHolderDiskRegion.java
>  db01162aeeba8113c208565d683e71a41d0f6d00 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/ProxyRegionMap.java 
> 92c7b6f8e90a3382e7ce00064581d69f9706fcd3 
>   geode-core/src/main/java/org/apache/geode/internal/cache/lru/EnableLRU.java 
> 6aaf8cc914c3b8c2e308446930bbd3215c9f58ca 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/lru/HeapLRUCapacityController.java
>  5e86ce87b99fc4e8793461e881853c141fdfec1f 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/lru/LRUCapacityController.java
>  3596a07df407960c3558057ac33e92c89bd5ba22 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/lru/LRUMapCallbacks.java
>  27a4ec019ae3b5fd29a26ffc451d0d9feb75f903 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/lru/MemLRUCapacityController.java
>  2c2e8ec1a805b7485e6e59858a12122fa8d88de1 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/lru/LRUClockJUnitTest.java
>  8095d5ac483be061199623a78b63618697e09d9d 
>   
> geode-core/src/test/java/org/apache/geode/internal/offheap/OffHeapLRURecoveryRegressionTest.java
>  PRE-CREATION 
> 
> 
> Diff: https://reviews.apache.org/r/58397/diff/1/
> 
> 
> Testing
> ---
> 
> precheckin
> 
> 
> Thanks,
> 
> Darrel Schneider
> 
>

Re: Review Request 58397: check off-heap limit during disk recovery

[Darrel Schneider]

> On April 12, 2017, 3:44 p.m., anilkumar gingade wrote:
> > geode-core/src/main/java/org/apache/geode/internal/cache/lru/HeapLRUCapacityController.java
> > Line 283 (original), 274 (patched)
> > 
> >
> > Is it more readable if it is:
> > 
> > if (offHeap) {
> >   use offheap monitor
> > } else {
> >   heap monitor
> > }

I agree. I will do some refactoring and get rid of this if/else


- Darrel


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


On April 12, 2017, 11:55 a.m., Darrel Schneider wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58397/
> ---
> 
> (Updated April 12, 2017, 11:55 a.m.)
> 
> 
> Review request for geode, anilkumar gingade, Eric Shu, and Lynn Gallinat.
> 
> 
> Bugs: GEODE-2097
> https://issues.apache.org/jira/browse/GEODE-2097
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> During disk recovery, the code now checks the offheap LRU limit instead of 
> the heap LRU limit for offheap regions.
> A unit test has been added that without this fix would run out of offheap 
> memory during recovery.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/AbstractLRURegionMap.java
>  328ff35b940239bfbcf817d144d97f886506b33a 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/AbstractRegionMap.java
>  eaababaf6be6041c72156a338c69fa81f10db4c5 
>   geode-core/src/main/java/org/apache/geode/internal/cache/LocalRegion.java 
> d0aacc2d95fa38b1bc9faf68de795af5ef3d9090 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/PlaceHolderDiskRegion.java
>  db01162aeeba8113c208565d683e71a41d0f6d00 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/ProxyRegionMap.java 
> 92c7b6f8e90a3382e7ce00064581d69f9706fcd3 
>   geode-core/src/main/java/org/apache/geode/internal/cache/lru/EnableLRU.java 
> 6aaf8cc914c3b8c2e308446930bbd3215c9f58ca 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/lru/HeapLRUCapacityController.java
>  5e86ce87b99fc4e8793461e881853c141fdfec1f 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/lru/LRUCapacityController.java
>  3596a07df407960c3558057ac33e92c89bd5ba22 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/lru/LRUMapCallbacks.java
>  27a4ec019ae3b5fd29a26ffc451d0d9feb75f903 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/lru/MemLRUCapacityController.java
>  2c2e8ec1a805b7485e6e59858a12122fa8d88de1 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/lru/LRUClockJUnitTest.java
>  8095d5ac483be061199623a78b63618697e09d9d 
>   
> geode-core/src/test/java/org/apache/geode/internal/offheap/OffHeapLRURecoveryRegressionTest.java
>  PRE-CREATION 
> 
> 
> Diff: https://reviews.apache.org/r/58397/diff/1/
> 
> 
> Testing
> ---
> 
> precheckin
> 
> 
> Thanks,
> 
> Darrel Schneider
> 
>

[jira] [Commented] (GEODE-2730) Refactor ServerStarterRule and LocatorStarterRule

[ASF GitHub Bot (JIRA)]

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

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

Github user jinmeiliao closed the pull request at:

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


> Refactor ServerStarterRule and LocatorStarterRule
> -
>
> Key: GEODE-2730
> URL: https://issues.apache.org/jira/browse/GEODE-2730
> Project: Geode
>  Issue Type: Improvement
>  Components: management
>Reporter: Jared Stewart
>Assignee: Jared Stewart
>
> Right now many tests that use ServerStarterRule and LocatorStarterRule are 
> flaky due to relying on default ports that intermittently cause 
> BindExceptions when those ports are in use. They also do not consistently use 
> the @Rule lifecycle to manage starting the member, but can optionally start 
> members when the rule is instantiated.



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

[jira] [Commented] (GEODE-2730) Refactor ServerStarterRule and LocatorStarterRule

[ASF GitHub Bot (JIRA)]

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

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

Github user jinmeiliao commented on the issue:

https://github.com/apache/geode/pull/452
  
resort back to review board.


> Refactor ServerStarterRule and LocatorStarterRule
> -
>
> Key: GEODE-2730
> URL: https://issues.apache.org/jira/browse/GEODE-2730
> Project: Geode
>  Issue Type: Improvement
>  Components: management
>Reporter: Jared Stewart
>Assignee: Jared Stewart
>
> Right now many tests that use ServerStarterRule and LocatorStarterRule are 
> flaky due to relying on default ports that intermittently cause 
> BindExceptions when those ports are in use. They also do not consistently use 
> the @Rule lifecycle to manage starting the member, but can optionally start 
> members when the rule is instantiated.



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

[GitHub] geode issue #452: GEODE-2730: refactor rules

[jinmeiliao]

Github user jinmeiliao commented on the issue:

https://github.com/apache/geode/pull/452
  
resort back to review board.


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

[GitHub] geode pull request #452: GEODE-2730: refactor rules

[jinmeiliao]

Github user jinmeiliao closed the pull request at:

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


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

Re: Review Request 58388: GEODE-2730: refactor rules

[Jinmei Liao]

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

(Updated April 12, 2017, 11:32 p.m.)


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


Repository: geode


Description (updated)
---

Finally the reviewboard is behaving now. This is good for review now. I will 
close the PR.

* consolidated the two sets of rules.
* do not allow member start up at test initialization time.
* validate properties in @Before
* use provider in the chained rules to get the appropriate ports in @Before

Jared and I tried to use ServerLauncher/LocatorLauncher to start the respective 
member in the rules, but precheckin yields many failures. Looks like it has two 
problems:
1) by passing in the workingDir in the launcher alone does not make all the 
logs go there. I still have to set the user.dir env variable to make some tests 
pass.
2) launcher.stop does not stop the cache/locator/server cleanly. Subsequent 
tests fail due to insufficient cleanup.
Due to the above two reasons, I reverted back to use the old way to start 
server/locator. This looks like a lean and mean way to get what we needed.

We also investigated the use of Builder in the rules. At least for now, it 
doesn't buy us much since we need to do validation/startup servers in @Before 
of the rules. And it yeilds some duplication code and make the usage not that 
intuitive.

As for using AvailablePort.Keeper, Jared and I found out it doesn't really keep 
the ports, so revert that back as well.


Diffs (updated)
-

  
geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityIntegrationTest.java
 cbd83e382116dcfc06b0199b69bf91486be22f06 
  
geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityPostProcessorTest.java
 e93561c0b5fc4fa7f89c03ff4055515d6bbb21be 
  
geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityWithSSLTest.java
 14113c06532d42833ee67f4fbf97ba24d535f2d3 
  
geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestServersJUnitTest.java
 2a3a036782fbde22f8969337973ca5794a7172b0 
  
geode-assembly/src/test/java/org/apache/geode/rest/internal/web/SwaggerVerificationTest.java
 a8ab19c0ac7f5cb94148fff725093c5f07858e93 
  
geode-assembly/src/test/java/org/apache/geode/test/dunit/rules/EmbeddedPulseRule.java
 PRE-CREATION 
  
geode-assembly/src/test/java/org/apache/geode/test/dunit/rules/HttpClientRule.java
 49351d9bba854eef08c20d47b99eb3ce467cabaa 
  
geode-assembly/src/test/java/org/apache/geode/tools/pulse/PulseDataExportTest.java
 10ca43b8fc171f75887519deb72700f464f24149 
  
geode-assembly/src/test/java/org/apache/geode/tools/pulse/PulseVerificationTest.java
 5a300a15b06b948603b5e82acba1190e1905b41a 
  geode-core/src/test/java/org/apache/geode/cache/ConnectionPoolDUnitTest.java 
2ac5120a673ed53f7a8f4b1ed077902566e7865d 
  geode-core/src/test/java/org/apache/geode/cache/ProxyJUnitTest.java 
05228addb74b070a4eac13bd61e84b055916a503 
  
geode-core/src/test/java/org/apache/geode/cache/partition/PartitionRegionHelperDUnitTest.java
 c57ce5beebc7bc4e4d7b826d8795d5a8e367f245 
  
geode-core/src/test/java/org/apache/geode/cache/query/BaseLineAndCompareQueryPerfJUnitTest.java
 de2f8d3e159ed199c1bd4b740ce7dd8ed5b82a5f 
  
geode-core/src/test/java/org/apache/geode/cache/query/dunit/QueryIndexDUnitTest.java
 d121fe9993e13e07dcea4817a173b80a8342e169 
  
geode-core/src/test/java/org/apache/geode/cache/query/dunit/RemoteQueryDUnitTest.java
 5f48dae54cd14beb2affeae8a8f3387f3e7bfae0 
  
geode-core/src/test/java/org/apache/geode/cache/query/functional/IndexWithSngleFrmAndMultCondQryJUnitTest.java
 d5195a6b2c8f1b62955ddd127e28ee74bc63ab21 
  
geode-core/src/test/java/org/apache/geode/cache/query/functional/LimitClauseJUnitTest.java
 1661cc8d5ba42b782e08251338605c001c526c97 
  
geode-core/src/test/java/org/apache/geode/cache/query/internal/QueryUtilsJUnitTest.java
 85305560669544d5fb3493a88f7bf93d86b8ac91 
  
geode-core/src/test/java/org/apache/geode/cache/query/internal/index/IndexMaintenanceJUnitTest.java
 b7b590ac2918e3176f2aa9625f4bbe7d06113c87 
  
geode-core/src/test/java/org/apache/geode/cache/query/partitioned/PRQueryDUnitHelper.java
 e07990d88061d174f2a7a69e4158abb1ed3ac679 
  geode-core/src/test/java/org/apache/geode/cache30/CacheLoaderTestCase.java 
164221776bcb187fc5d2d1fe199d40cfd37a0c63 
  geode-core/src/test/java/org/apache/geode/cache30/CacheXml66DUnitTest.java 
738ef3f778da58375d495bb1ad294f07161133db 
  geode-core/src/test/java/org/apache/geode/cache30/DiskRegionDUnitTest.java 
c3553b7ece3b91ce142ad5e0acd4ecc1845e9869 
  geode-core/src/test/java/org/apache/geode/cache30/DiskRegionTestImpl.java 
301c23267995dd0201566bac9472d4b7db3c60fd 
  
geode-core/src/test/java/org/apache/geode/cache30/DistributedAckRegionCCEDUnitTest.java
 dcb6cf37a5458e40d4638b944c1394fb63a52da2 
  

Re: Review Request 58395: GEODE-2773: Checking region version based on WaitCriterion only with async invocation

[anilkumar gingade]

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


Ship it!




Ship It!

- anilkumar gingade


On April 12, 2017, 6:34 p.m., Eric Shu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58395/
> ---
> 
> (Updated April 12, 2017, 6:34 p.m.)
> 
> 
> Review request for geode, anilkumar gingade, Darrel Schneider, and Lynn 
> Gallinat.
> 
> 
> Bugs: GEODE-2773
> https://issues.apache.org/jira/browse/GEODE-2773
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> The current checking of region version in async call is incorrect as it can 
> fail due to newer region versions caused by other operations.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/GIIDeltaDUnitTest.java
>  d07227b 
> 
> 
> Diff: https://reviews.apache.org/r/58395/diff/1/
> 
> 
> Testing
> ---
> 
> precheckin.
> 
> 
> Thanks,
> 
> Eric Shu
> 
>

[jira] [Commented] (GEODE-2730) Refactor ServerStarterRule and LocatorStarterRule

[ASF GitHub Bot (JIRA)]

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

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

Github user jinmeiliao commented on the issue:

https://github.com/apache/geode/pull/452
  
review board is having some trouble updating my old reviews. I am using the 
pull request. It should addressed all the points that Ken wrote in the old 
review. But, please review more. Thanks!


> Refactor ServerStarterRule and LocatorStarterRule
> -
>
> Key: GEODE-2730
> URL: https://issues.apache.org/jira/browse/GEODE-2730
> Project: Geode
>  Issue Type: Improvement
>  Components: management
>Reporter: Jared Stewart
>Assignee: Jared Stewart
>
> Right now many tests that use ServerStarterRule and LocatorStarterRule are 
> flaky due to relying on default ports that intermittently cause 
> BindExceptions when those ports are in use. They also do not consistently use 
> the @Rule lifecycle to manage starting the member, but can optionally start 
> members when the rule is instantiated.



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

[GitHub] geode issue #452: GEODE-2730: refactor rules

[jinmeiliao]

Github user jinmeiliao commented on the issue:

https://github.com/apache/geode/pull/452
  
review board is having some trouble updating my old reviews. I am using the 
pull request. It should addressed all the points that Ken wrote in the old 
review. But, please review more. Thanks!


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

[GitHub] geode pull request #452: GEODE-2730: refactor rules

[jinmeiliao]

GitHub user jinmeiliao opened a pull request:

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

GEODE-2730: refactor rules

* consolidate the two sets of server/locator starter rules
* do not allow member start up at test initialization time.
* validate properties in @Before
* use provider in the chained rules to get the appropriate ports in @Before

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

$ git pull https://github.com/jinmeiliao/geode rules

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

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


commit 330911c38b445d53aba49688488c2e014e457ebd
Author: Jinmei Liao 
Date:   2017-03-23T02:45:19Z

GEODE-2730: refactor rules

* consolidate the two sets of server/locator starter rules
* do not allow member start up at test initialization time.
* validate properties in @Before
* use provider in the chained rules to get the appropriate ports in @Before




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

[jira] [Commented] (GEODE-2730) Refactor ServerStarterRule and LocatorStarterRule

[ASF GitHub Bot (JIRA)]

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

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

GitHub user jinmeiliao opened a pull request:

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

GEODE-2730: refactor rules

* consolidate the two sets of server/locator starter rules
* do not allow member start up at test initialization time.
* validate properties in @Before
* use provider in the chained rules to get the appropriate ports in @Before

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

$ git pull https://github.com/jinmeiliao/geode rules

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

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


commit 330911c38b445d53aba49688488c2e014e457ebd
Author: Jinmei Liao 
Date:   2017-03-23T02:45:19Z

GEODE-2730: refactor rules

* consolidate the two sets of server/locator starter rules
* do not allow member start up at test initialization time.
* validate properties in @Before
* use provider in the chained rules to get the appropriate ports in @Before




> Refactor ServerStarterRule and LocatorStarterRule
> -
>
> Key: GEODE-2730
> URL: https://issues.apache.org/jira/browse/GEODE-2730
> Project: Geode
>  Issue Type: Improvement
>  Components: management
>Reporter: Jared Stewart
>Assignee: Jared Stewart
>
> Right now many tests that use ServerStarterRule and LocatorStarterRule are 
> flaky due to relying on default ports that intermittently cause 
> BindExceptions when those ports are in use. They also do not consistently use 
> the @Rule lifecycle to manage starting the member, but can optionally start 
> members when the rule is instantiated.



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

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

[Spring CI]

---
Spring Data GemFire > Nightly-ApacheGeode > #522 was successful.
---
Scheduled
1845 tests in total.

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





--
This message is automatically generated by Atlassian Bamboo

Re: Review Request 58397: check off-heap limit during disk recovery

[anilkumar gingade]

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




geode-core/src/main/java/org/apache/geode/internal/cache/lru/HeapLRUCapacityController.java
Line 283 (original), 274 (patched)


Is it more readable if it is:

if (offHeap) {
  use offheap monitor
} else {
  heap monitor
}


- anilkumar gingade


On April 12, 2017, 6:55 p.m., Darrel Schneider wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58397/
> ---
> 
> (Updated April 12, 2017, 6:55 p.m.)
> 
> 
> Review request for geode, anilkumar gingade, Eric Shu, and Lynn Gallinat.
> 
> 
> Bugs: GEODE-2097
> https://issues.apache.org/jira/browse/GEODE-2097
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> During disk recovery, the code now checks the offheap LRU limit instead of 
> the heap LRU limit for offheap regions.
> A unit test has been added that without this fix would run out of offheap 
> memory during recovery.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/AbstractLRURegionMap.java
>  328ff35b940239bfbcf817d144d97f886506b33a 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/AbstractRegionMap.java
>  eaababaf6be6041c72156a338c69fa81f10db4c5 
>   geode-core/src/main/java/org/apache/geode/internal/cache/LocalRegion.java 
> d0aacc2d95fa38b1bc9faf68de795af5ef3d9090 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/PlaceHolderDiskRegion.java
>  db01162aeeba8113c208565d683e71a41d0f6d00 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/ProxyRegionMap.java 
> 92c7b6f8e90a3382e7ce00064581d69f9706fcd3 
>   geode-core/src/main/java/org/apache/geode/internal/cache/lru/EnableLRU.java 
> 6aaf8cc914c3b8c2e308446930bbd3215c9f58ca 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/lru/HeapLRUCapacityController.java
>  5e86ce87b99fc4e8793461e881853c141fdfec1f 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/lru/LRUCapacityController.java
>  3596a07df407960c3558057ac33e92c89bd5ba22 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/lru/LRUMapCallbacks.java
>  27a4ec019ae3b5fd29a26ffc451d0d9feb75f903 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/lru/MemLRUCapacityController.java
>  2c2e8ec1a805b7485e6e59858a12122fa8d88de1 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/lru/LRUClockJUnitTest.java
>  8095d5ac483be061199623a78b63618697e09d9d 
>   
> geode-core/src/test/java/org/apache/geode/internal/offheap/OffHeapLRURecoveryRegressionTest.java
>  PRE-CREATION 
> 
> 
> Diff: https://reviews.apache.org/r/58397/diff/1/
> 
> 
> Testing
> ---
> 
> precheckin
> 
> 
> Thanks,
> 
> Darrel Schneider
> 
>

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

[Jared Stewart (JIRA)]

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

Jared Stewart updated GEODE-2724:
-
Fix Version/s: 1.2.0

> NPE shutting down locator
> -
>
> Key: GEODE-2724
> URL: https://issues.apache.org/jira/browse/GEODE-2724
> Project: Geode
>  Issue Type: Bug
>  Components: pulse
>Reporter: Bruce Schuchardt
>Assignee: Jared Stewart
> Fix For: 1.2.0
>
>
> Locator shutdown threw an NPE when stopping a Jetty server in Pulse code:
> {code}
> [warning 2017/03/28 08:56:25.493 IST locator1  tid=0x4a] Failed to 
> stop the HTTP service because: null
> java.lang.NullPointerException
> at 
> org.apache.geode.tools.pulse.internal.data.Repository.removeAllClusters(Repository.java:225)
> at 
> org.apache.geode.tools.pulse.internal.PulseAppListener.contextDestroyed(PulseAppListener.java:84)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.callContextDestroyed(ContextHandler.java:843)
> at 
> org.eclipse.jetty.servlet.ServletContextHandler.callContextDestroyed(ServletContextHandler.java:543)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.stopContext(ContextHandler.java:824)
> at 
> org.eclipse.jetty.servlet.ServletContextHandler.stopContext(ServletContextHandler.java:353)
> at 
> org.eclipse.jetty.webapp.WebAppContext.stopWebapp(WebAppContext.java:1385)
> at 
> org.eclipse.jetty.webapp.WebAppContext.stopContext(WebAppContext.java:1349)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doStop(ContextHandler.java:872)
> at 
> org.eclipse.jetty.servlet.ServletContextHandler.doStop(ServletContextHandler.java:269)
> at org.eclipse.jetty.webapp.WebAppContext.doStop(WebAppContext.java:541)
> at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
> at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:143)
> at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:161)
> at 
> org.eclipse.jetty.server.handler.AbstractHandler.doStop(AbstractHandler.java:73)
> at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
> at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:143)
> at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:161)
> at 
> org.eclipse.jetty.server.handler.AbstractHandler.doStop(AbstractHandler.java:73)
> at org.eclipse.jetty.server.Server.doStop(Server.java:476)
> at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
> at 
> org.apache.geode.management.internal.ManagementAgent.stopHttpService(ManagementAgent.java:328)
> at 
> org.apache.geode.management.internal.ManagementAgent.stopAgent(ManagementAgent.java:156)
> at 
> org.apache.geode.management.internal.SystemManagementService.close(SystemManagementService.java:265)
> at 
> org.apache.geode.management.internal.beans.ManagementAdapter.handleCacheRemoval(ManagementAdapter.java:735)
> at 
> org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:117)
> at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2146)
> at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:536)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:2149)
> at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:1314)
> at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:964)
> at 
> org.apache.geode.management.internal.beans.MemberMBeanBridge$1.run(MemberMBeanBridge.java:1000)
> at java.lang.Thread.run(Thread.java:745)
> [error 2017/03/28 08:56:25.494 IST locator1  tid=0x4a] Failed to 
> properly release resources held by the HTTP service: !STOPPED
> java.lang.IllegalStateException: !STOPPED
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.destroy(HandlerWrapper.java:134)
> at 
> org.apache.geode.management.internal.ManagementAgent.stopHttpService(ManagementAgent.java:333)
> at 
> org.apache.geode.management.internal.ManagementAgent.stopAgent(ManagementAgent.java:156)
> at 
> org.apache.geode.management.internal.SystemManagementService.close(SystemManagementService.java:265)
> at 
> org.apache.geode.management.internal.beans.ManagementAdapter.handleCacheRemoval(ManagementAdapter.java:735)
> at 
> org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:117)
> at 
> 

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

[Jared Stewart (JIRA)]

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

Jared Stewart commented on GEODE-2724:
--

I was able to reproduce this failure with Geode 1.1.0, but not with binaries 
built from the latest head of develop.  It appears that this bug was fixed 
incidentally by a recent commit:
{noformat}
31b6507 Patrick Rhomberg on 3/22/17 at 1:27 PM (committed by Jinmei Liao) 
GEODE-1274: Migration from PulseLogWriter to Log4j standard and removal of 
associated classes.
{noformat}

> NPE shutting down locator
> -
>
> Key: GEODE-2724
> URL: https://issues.apache.org/jira/browse/GEODE-2724
> Project: Geode
>  Issue Type: Bug
>  Components: pulse
>Reporter: Bruce Schuchardt
>
> Locator shutdown threw an NPE when stopping a Jetty server in Pulse code:
> {code}
> [warning 2017/03/28 08:56:25.493 IST locator1  tid=0x4a] Failed to 
> stop the HTTP service because: null
> java.lang.NullPointerException
> at 
> org.apache.geode.tools.pulse.internal.data.Repository.removeAllClusters(Repository.java:225)
> at 
> org.apache.geode.tools.pulse.internal.PulseAppListener.contextDestroyed(PulseAppListener.java:84)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.callContextDestroyed(ContextHandler.java:843)
> at 
> org.eclipse.jetty.servlet.ServletContextHandler.callContextDestroyed(ServletContextHandler.java:543)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.stopContext(ContextHandler.java:824)
> at 
> org.eclipse.jetty.servlet.ServletContextHandler.stopContext(ServletContextHandler.java:353)
> at 
> org.eclipse.jetty.webapp.WebAppContext.stopWebapp(WebAppContext.java:1385)
> at 
> org.eclipse.jetty.webapp.WebAppContext.stopContext(WebAppContext.java:1349)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doStop(ContextHandler.java:872)
> at 
> org.eclipse.jetty.servlet.ServletContextHandler.doStop(ServletContextHandler.java:269)
> at org.eclipse.jetty.webapp.WebAppContext.doStop(WebAppContext.java:541)
> at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
> at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:143)
> at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:161)
> at 
> org.eclipse.jetty.server.handler.AbstractHandler.doStop(AbstractHandler.java:73)
> at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
> at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:143)
> at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:161)
> at 
> org.eclipse.jetty.server.handler.AbstractHandler.doStop(AbstractHandler.java:73)
> at org.eclipse.jetty.server.Server.doStop(Server.java:476)
> at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
> at 
> org.apache.geode.management.internal.ManagementAgent.stopHttpService(ManagementAgent.java:328)
> at 
> org.apache.geode.management.internal.ManagementAgent.stopAgent(ManagementAgent.java:156)
> at 
> org.apache.geode.management.internal.SystemManagementService.close(SystemManagementService.java:265)
> at 
> org.apache.geode.management.internal.beans.ManagementAdapter.handleCacheRemoval(ManagementAdapter.java:735)
> at 
> org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:117)
> at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2146)
> at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:536)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:2149)
> at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:1314)
> at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:964)
> at 
> org.apache.geode.management.internal.beans.MemberMBeanBridge$1.run(MemberMBeanBridge.java:1000)
> at java.lang.Thread.run(Thread.java:745)
> [error 2017/03/28 08:56:25.494 IST locator1  tid=0x4a] Failed to 
> properly release resources held by the HTTP service: !STOPPED
> java.lang.IllegalStateException: !STOPPED
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.destroy(HandlerWrapper.java:134)
> at 
> org.apache.geode.management.internal.ManagementAgent.stopHttpService(ManagementAgent.java:333)
> at 
> org.apache.geode.management.internal.ManagementAgent.stopAgent(ManagementAgent.java:156)
> at 
> 

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

[Jared Stewart (JIRA)]

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

Jared Stewart reassigned GEODE-2724:


Assignee: Jared Stewart

> NPE shutting down locator
> -
>
> Key: GEODE-2724
> URL: https://issues.apache.org/jira/browse/GEODE-2724
> Project: Geode
>  Issue Type: Bug
>  Components: pulse
>Reporter: Bruce Schuchardt
>Assignee: Jared Stewart
>
> Locator shutdown threw an NPE when stopping a Jetty server in Pulse code:
> {code}
> [warning 2017/03/28 08:56:25.493 IST locator1  tid=0x4a] Failed to 
> stop the HTTP service because: null
> java.lang.NullPointerException
> at 
> org.apache.geode.tools.pulse.internal.data.Repository.removeAllClusters(Repository.java:225)
> at 
> org.apache.geode.tools.pulse.internal.PulseAppListener.contextDestroyed(PulseAppListener.java:84)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.callContextDestroyed(ContextHandler.java:843)
> at 
> org.eclipse.jetty.servlet.ServletContextHandler.callContextDestroyed(ServletContextHandler.java:543)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.stopContext(ContextHandler.java:824)
> at 
> org.eclipse.jetty.servlet.ServletContextHandler.stopContext(ServletContextHandler.java:353)
> at 
> org.eclipse.jetty.webapp.WebAppContext.stopWebapp(WebAppContext.java:1385)
> at 
> org.eclipse.jetty.webapp.WebAppContext.stopContext(WebAppContext.java:1349)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doStop(ContextHandler.java:872)
> at 
> org.eclipse.jetty.servlet.ServletContextHandler.doStop(ServletContextHandler.java:269)
> at org.eclipse.jetty.webapp.WebAppContext.doStop(WebAppContext.java:541)
> at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
> at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:143)
> at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:161)
> at 
> org.eclipse.jetty.server.handler.AbstractHandler.doStop(AbstractHandler.java:73)
> at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
> at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:143)
> at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:161)
> at 
> org.eclipse.jetty.server.handler.AbstractHandler.doStop(AbstractHandler.java:73)
> at org.eclipse.jetty.server.Server.doStop(Server.java:476)
> at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
> at 
> org.apache.geode.management.internal.ManagementAgent.stopHttpService(ManagementAgent.java:328)
> at 
> org.apache.geode.management.internal.ManagementAgent.stopAgent(ManagementAgent.java:156)
> at 
> org.apache.geode.management.internal.SystemManagementService.close(SystemManagementService.java:265)
> at 
> org.apache.geode.management.internal.beans.ManagementAdapter.handleCacheRemoval(ManagementAdapter.java:735)
> at 
> org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:117)
> at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2146)
> at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:536)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:2149)
> at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:1314)
> at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:964)
> at 
> org.apache.geode.management.internal.beans.MemberMBeanBridge$1.run(MemberMBeanBridge.java:1000)
> at java.lang.Thread.run(Thread.java:745)
> [error 2017/03/28 08:56:25.494 IST locator1  tid=0x4a] Failed to 
> properly release resources held by the HTTP service: !STOPPED
> java.lang.IllegalStateException: !STOPPED
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.destroy(HandlerWrapper.java:134)
> at 
> org.apache.geode.management.internal.ManagementAgent.stopHttpService(ManagementAgent.java:333)
> at 
> org.apache.geode.management.internal.ManagementAgent.stopAgent(ManagementAgent.java:156)
> at 
> org.apache.geode.management.internal.SystemManagementService.close(SystemManagementService.java:265)
> at 
> org.apache.geode.management.internal.beans.ManagementAdapter.handleCacheRemoval(ManagementAdapter.java:735)
> at 
> org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:117)
> at 
> 

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

[Jared Stewart (JIRA)]

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

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

> NPE shutting down locator
> -
>
> Key: GEODE-2724
> URL: https://issues.apache.org/jira/browse/GEODE-2724
> Project: Geode
>  Issue Type: Bug
>  Components: pulse
>Reporter: Bruce Schuchardt
>
> Locator shutdown threw an NPE when stopping a Jetty server in Pulse code:
> {code}
> [warning 2017/03/28 08:56:25.493 IST locator1  tid=0x4a] Failed to 
> stop the HTTP service because: null
> java.lang.NullPointerException
> at 
> org.apache.geode.tools.pulse.internal.data.Repository.removeAllClusters(Repository.java:225)
> at 
> org.apache.geode.tools.pulse.internal.PulseAppListener.contextDestroyed(PulseAppListener.java:84)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.callContextDestroyed(ContextHandler.java:843)
> at 
> org.eclipse.jetty.servlet.ServletContextHandler.callContextDestroyed(ServletContextHandler.java:543)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.stopContext(ContextHandler.java:824)
> at 
> org.eclipse.jetty.servlet.ServletContextHandler.stopContext(ServletContextHandler.java:353)
> at 
> org.eclipse.jetty.webapp.WebAppContext.stopWebapp(WebAppContext.java:1385)
> at 
> org.eclipse.jetty.webapp.WebAppContext.stopContext(WebAppContext.java:1349)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doStop(ContextHandler.java:872)
> at 
> org.eclipse.jetty.servlet.ServletContextHandler.doStop(ServletContextHandler.java:269)
> at org.eclipse.jetty.webapp.WebAppContext.doStop(WebAppContext.java:541)
> at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
> at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:143)
> at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:161)
> at 
> org.eclipse.jetty.server.handler.AbstractHandler.doStop(AbstractHandler.java:73)
> at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
> at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:143)
> at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:161)
> at 
> org.eclipse.jetty.server.handler.AbstractHandler.doStop(AbstractHandler.java:73)
> at org.eclipse.jetty.server.Server.doStop(Server.java:476)
> at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
> at 
> org.apache.geode.management.internal.ManagementAgent.stopHttpService(ManagementAgent.java:328)
> at 
> org.apache.geode.management.internal.ManagementAgent.stopAgent(ManagementAgent.java:156)
> at 
> org.apache.geode.management.internal.SystemManagementService.close(SystemManagementService.java:265)
> at 
> org.apache.geode.management.internal.beans.ManagementAdapter.handleCacheRemoval(ManagementAdapter.java:735)
> at 
> org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:117)
> at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2146)
> at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:536)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:2149)
> at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:1314)
> at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:964)
> at 
> org.apache.geode.management.internal.beans.MemberMBeanBridge$1.run(MemberMBeanBridge.java:1000)
> at java.lang.Thread.run(Thread.java:745)
> [error 2017/03/28 08:56:25.494 IST locator1  tid=0x4a] Failed to 
> properly release resources held by the HTTP service: !STOPPED
> java.lang.IllegalStateException: !STOPPED
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.destroy(HandlerWrapper.java:134)
> at 
> org.apache.geode.management.internal.ManagementAgent.stopHttpService(ManagementAgent.java:333)
> at 
> org.apache.geode.management.internal.ManagementAgent.stopAgent(ManagementAgent.java:156)
> at 
> org.apache.geode.management.internal.SystemManagementService.close(SystemManagementService.java:265)
> at 
> org.apache.geode.management.internal.beans.ManagementAdapter.handleCacheRemoval(ManagementAdapter.java:735)
> at 
> org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:117)
> at 
> 

[jira] [Commented] (GEODE-2689) If a region containing a Lucene index is created in one group and altered in another, a member in the other group will fail to start

[Diane Hardman (JIRA)]

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

Diane Hardman commented on GEODE-2689:
--

Barry,
When you say "the same test with OQL works", do you mean that the member is 
started WITH the index or without the index, due to the 
IndexNameConflictException?

My preference is to mimic as much as the OQL behavior as possible. I like your 
suggestion of throwing a  LuceneIndexExistsException and verifying that the 
indexes are the same. Is this done with OQL?

Thanks!

> If a region containing a Lucene index is created in one group and altered in 
> another, a member in the other group will fail to start
> 
>
> Key: GEODE-2689
> URL: https://issues.apache.org/jira/browse/GEODE-2689
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Barry Oglesby
>
> Steps to reproduce:
> - create lucene index --name=full_index --region=data --field=field1
> - create region --name=data --type=PARTITION_REDUNDANT
> - alter region --name=data --cache-listener=TestCacheListener --group=group1
> At this point, the cluster config xml looks like:
> {noformat}
> [info 2017/03/15 17:04:17.375 PDT server3  tid=0x1] 
>   ***
>   Configuration for  'cluster'
>   
>   Jar files to deployed
>   
>   http://geode.apache.org/schema/cache; 
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; copy-on-read="false" 
> is-server="false" lock-lease="120" lock-timeout="60" search-timeout="300" 
> version="1.0" xsi:schemaLocation="http://geode.apache.org/schema/cache 
> http://geode.apache.org/schema/cache/cache-1.0.xsd;>
>   
>data-policy="partition">
> 
>   
>   http://geode.apache.org/schema/lucene; 
> name="full_index">
>  analyzer="org.apache.lucene.analysis.standard.StandardAnalyzer" 
> name="field1"/>
>   
> 
>   
>   
>   ***
>   Configuration for  'group1'
>   
>   Jar files to deployed
>   
>   http://geode.apache.org/schema/cache; 
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; copy-on-read="false" 
> is-server="false" lock-lease="120" lock-timeout="60" search-timeout="300" 
> version="1.0" xsi:schemaLocation="http://geode.apache.org/schema/cache 
> http://geode.apache.org/schema/cache/cache-1.0.xsd;>
>   
>data-policy="partition">
> 
> 
>   TestCacheListener
> 
>   
>   http://geode.apache.org/schema/lucene; 
> name="full_index">
>  analyzer="org.apache.lucene.analysis.standard.StandardAnalyzer" 
> name="field1"/>
>   
> 
>   
> {noformat}
> If a member is started in the group (group1 in this case), it will fail to 
> start with the following error:
> {noformat}
> [error 2017/03/15 17:04:19.715 PDT  tid=0x1] Lucene index already 
> exists in region
> Exception in thread "main" java.lang.IllegalArgumentException: Lucene index 
> already exists in region
>   at 
> org.apache.geode.cache.lucene.internal.LuceneServiceImpl.registerDefinedIndex(LuceneServiceImpl.java:201)
>   at 
> org.apache.geode.cache.lucene.internal.LuceneServiceImpl.createIndex(LuceneServiceImpl.java:154)
>   at 
> org.apache.geode.cache.lucene.internal.xml.LuceneIndexCreation.beforeCreate(LuceneIndexCreation.java:85)
>   at 
> org.apache.geode.internal.cache.extension.SimpleExtensionPoint.beforeCreate(SimpleExtensionPoint.java:77)
>   at 
> org.apache.geode.internal.cache.xmlcache.RegionCreation.createRoot(RegionCreation.java:252)
>   at 
> org.apache.geode.internal.cache.xmlcache.CacheCreation.initializeRegions(CacheCreation.java:544)
>   at 
> org.apache.geode.internal.cache.xmlcache.CacheCreation.create(CacheCreation.java:495)
>   at 
> org.apache.geode.internal.cache.xmlcache.CacheXmlParser.create(CacheXmlParser.java:343)
>   at 
> org.apache.geode.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4479)
>   at 
> org.apache.geode.internal.cache.ClusterConfigurationLoader.applyClusterXmlConfiguration(ClusterConfigurationLoader.java:129)
>   at 
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1243)
>   at 
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate(GemFireCacheImpl.java:798)
>   at 
> org.apache.geode.internal.cache.GemFireCacheImpl.create(GemFireCacheImpl.java:783)
>   at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:178)
>   at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:218)
>   at TestBase.initializeServerCache(TestBase.java:22)
>   at TestServer.main(TestServer.java:7)
> {noformat}
> I made a quick 

[GitHub] geode pull request #451: GEODE-2768: Lucene Queries executed before index is...

[jhuynh1]

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

https://github.com/apache/geode/pull/451#discussion_r111275346
  
--- Diff: 
geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/distributed/LuceneQueryFunction.java
 ---
@@ -132,6 +133,25 @@ private LuceneIndexImpl getLuceneIndex(final Region 
region,
 try {
   index =
   (LuceneIndexImpl) service.getIndex(searchContext.getIndexName(), 
region.getFullPath());
+  if (index == null && service instanceof LuceneServiceImpl) {
+if (((LuceneServiceImpl) 
service).getDefinedIndex(searchContext.getIndexName(),
+region.getFullPath()) != null) {
+  // The node may be in the process of recovering, where we have 
the index defined but yet
+  // to be recovered
+  // If we retry fast enough, we could get a stack overflow based 
on the way function
+  // execution is currently written
+  // Instead we will add an artificial sleep to slow down the 
retry at this point
+  // Hopefully in the future, the function execution would retry 
without adding to the stack
+  // and this can be removed
+  try {
--- End diff --

This is really an artificial time that was to avoid the stack overflow from 
the function execution retry.  The smaller the time, the greater chance we hit 
the stack overflow but also the quicker we return to the user if the index 
really doesn't exist.  I can understand maybe bumping this up to a second but 
10 seems a bit long...


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

[jira] [Commented] (GEODE-2768) Lucene Queries executed before index is fully created should be retried

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/geode/pull/451#discussion_r111275346
  
--- Diff: 
geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/distributed/LuceneQueryFunction.java
 ---
@@ -132,6 +133,25 @@ private LuceneIndexImpl getLuceneIndex(final Region 
region,
 try {
   index =
   (LuceneIndexImpl) service.getIndex(searchContext.getIndexName(), 
region.getFullPath());
+  if (index == null && service instanceof LuceneServiceImpl) {
+if (((LuceneServiceImpl) 
service).getDefinedIndex(searchContext.getIndexName(),
+region.getFullPath()) != null) {
+  // The node may be in the process of recovering, where we have 
the index defined but yet
+  // to be recovered
+  // If we retry fast enough, we could get a stack overflow based 
on the way function
+  // execution is currently written
+  // Instead we will add an artificial sleep to slow down the 
retry at this point
+  // Hopefully in the future, the function execution would retry 
without adding to the stack
+  // and this can be removed
+  try {
--- End diff --

This is really an artificial time that was to avoid the stack overflow from 
the function execution retry.  The smaller the time, the greater chance we hit 
the stack overflow but also the quicker we return to the user if the index 
really doesn't exist.  I can understand maybe bumping this up to a second but 
10 seems a bit long...


> Lucene Queries executed before index is fully created should be retried
> ---
>
> Key: GEODE-2768
> URL: https://issues.apache.org/jira/browse/GEODE-2768
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Jason Huynh
>Assignee: Jason Huynh
>
> With the feature to destroy a Lucene Index, parts of the querying function 
> were changed to handle the event where we execute a query on an index that is 
> no longer present.  However, the scenario where we execute a query on an 
> index that is defined but has not been created can also arise. 
> We want to handle the case where we have defined the index, but have yet to 
> create it due to a brief window in restart.  



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

[GitHub] geode pull request #451: GEODE-2768: Lucene Queries executed before index is...

[nabarunnag]

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

https://github.com/apache/geode/pull/451#discussion_r111272945
  
--- Diff: 
geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/distributed/LuceneQueryFunction.java
 ---
@@ -132,6 +133,25 @@ private LuceneIndexImpl getLuceneIndex(final Region 
region,
 try {
   index =
   (LuceneIndexImpl) service.getIndex(searchContext.getIndexName(), 
region.getFullPath());
+  if (index == null && service instanceof LuceneServiceImpl) {
+if (((LuceneServiceImpl) 
service).getDefinedIndex(searchContext.getIndexName(),
+region.getFullPath()) != null) {
+  // The node may be in the process of recovering, where we have 
the index defined but yet
+  // to be recovered
+  // If we retry fast enough, we could get a stack overflow based 
on the way function
+  // execution is currently written
+  // Instead we will add an artificial sleep to slow down the 
retry at this point
+  // Hopefully in the future, the function execution would retry 
without adding to the stack
+  // and this can be removed
+  try {
--- End diff --

Can there be a possibility that this node never recovers but another node 
is ready to execute the query and we are stuck here for 10 seconds?


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

[jira] [Commented] (GEODE-2768) Lucene Queries executed before index is fully created should be retried

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/geode/pull/451#discussion_r111272945
  
--- Diff: 
geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/distributed/LuceneQueryFunction.java
 ---
@@ -132,6 +133,25 @@ private LuceneIndexImpl getLuceneIndex(final Region 
region,
 try {
   index =
   (LuceneIndexImpl) service.getIndex(searchContext.getIndexName(), 
region.getFullPath());
+  if (index == null && service instanceof LuceneServiceImpl) {
+if (((LuceneServiceImpl) 
service).getDefinedIndex(searchContext.getIndexName(),
+region.getFullPath()) != null) {
+  // The node may be in the process of recovering, where we have 
the index defined but yet
+  // to be recovered
+  // If we retry fast enough, we could get a stack overflow based 
on the way function
+  // execution is currently written
+  // Instead we will add an artificial sleep to slow down the 
retry at this point
+  // Hopefully in the future, the function execution would retry 
without adding to the stack
+  // and this can be removed
+  try {
--- End diff --

Can there be a possibility that this node never recovers but another node 
is ready to execute the query and we are stuck here for 10 seconds?


> Lucene Queries executed before index is fully created should be retried
> ---
>
> Key: GEODE-2768
> URL: https://issues.apache.org/jira/browse/GEODE-2768
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Jason Huynh
>Assignee: Jason Huynh
>
> With the feature to destroy a Lucene Index, parts of the querying function 
> were changed to handle the event where we execute a query on an index that is 
> no longer present.  However, the scenario where we execute a query on an 
> index that is defined but has not been created can also arise. 
> We want to handle the case where we have defined the index, but have yet to 
> create it due to a brief window in restart.  



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

[jira] [Created] (GEODE-2777) Change version number from 1.1 to 1.2 in docs

[Joey McAllister (JIRA)]

Joey McAllister created GEODE-2777:
--

 Summary: Change version number from 1.1 to 1.2 in docs
 Key: GEODE-2777
 URL: https://issues.apache.org/jira/browse/GEODE-2777
 Project: Geode
  Issue Type: Task
  Components: docs
Reporter: Joey McAllister
 Fix For: 1.2.0


On the `develop` branch, change any reference to v1.1 to be v1.2 in the 
`geode-docs` and `geode-book` directories.

In the `geode-book` directory, make sure to change the hrefs in the subnav from 
`/11/` to `/12/` and make relevant version changes to the `config.yml` file.



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

[jira] [Reopened] (GEODE-2737) PulseAuthTest failures

[Kenneth Howe (JIRA)]

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

Kenneth Howe reopened GEODE-2737:
-

New failure on automated CI run (didn't see this one when I made the change 
noted above.)

org.apache.geode.tools.pulse.tests.ui.PulseAutomatedTest > 
clickHostShowsMemberTest FAILED
org.openqa.selenium.StaleElementReferenceException: 
{"errorMessage":"Element is no longer attached to the 
DOM","request":{"headers":{"Accept-Encoding":"gzip,deflate","Connection":"Keep-Alive","Content-Length":"27","Content-Type":"application/json;
 charset=utf-8","Host":"localhost:26799","User-Agent":"Apache-HttpClient/4.5.2 
(Java/1.8.0_121)"},"httpVersion":"1.1","method":"POST","post":"{\"id\":\":wdc:1492030111207\"}","url":"/click","urlParsed":{"anchor":"","query":"","file":"click","directory":"/","path":"/click","relative":"/click","port":"","host":"","password":"","user":"","userInfo":"","authority":"","protocol":"","source":"/click","queryKey":{},"chunks":["click"]},"urlOriginal":"/session/61a08b30-1fc1-11e7-a081-875185d8fe5e/element/:wdc:1492030111207/click"}}
Command duration or timeout: 206 milliseconds
For documentation on this error, please visit: 
http://seleniumhq.org/exceptions/stale_element_reference.html
Build info: version: '3.0.1', revision: '1969d75', time: '2016-10-18 
09:49:13 -0700'
System info: host: '4e845115-d552-450d-58eb-d6cef82baadc', ip: 
'10.254.0.10', os.name: 'Linux', os.arch: 'amd64', os.version: 
'4.4.0-62-generic', java.version: '1.8.0_121'
Driver info: org.openqa.selenium.phantomjs.PhantomJSDriver
Capabilities [{applicationCacheEnabled=false, rotatable=false, 
handlesAlerts=false, databaseEnabled=false, version=2.1.1, platform=LINUX, 
browserConnectionEnabled=false, proxy={proxyType=direct}, nativeEvents=true, 
acceptSslCerts=false, driverVersion=1.2.0, 
phantomjs.page.settings.userAgent=Mozilla/5.0 (Windows NT 6.1; Win64; x64; 
rv:16.0) Gecko/20121026 Firefox/16.0, locationContextEnabled=false, 
webStorageEnabled=false, browserName=phantomjs, takesScreenshot=true, 
driverName=ghostdriver, javascriptEnabled=true, cssSelectorsEnabled=true}]
Session ID: 61a08b30-1fc1-11e7-a081-875185d8fe5e
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at 
org.openqa.selenium.remote.ErrorHandler.createThrowable(ErrorHandler.java:216)
at 
org.openqa.selenium.remote.ErrorHandler.throwIfResponseFailed(ErrorHandler.java:168)
at 
org.openqa.selenium.remote.RemoteWebDriver.execute(RemoteWebDriver.java:635)
at 
org.openqa.selenium.remote.RemoteWebElement.execute(RemoteWebElement.java:274)
at 
org.openqa.selenium.remote.RemoteWebElement.click(RemoteWebElement.java:84)
at 
org.apache.geode.tools.pulse.tests.ui.PulseAutomatedTest.clickHostShowsMemberTest(PulseAutomatedTest.java:212)

Caused by:
org.openqa.selenium.remote.ScreenshotException: Screen shot has been 
taken
Build info: version: '3.0.1', revision: '1969d75', time: '2016-10-18 
09:49:13 -0700'
System info: host: '4e845115-d552-450d-58eb-d6cef82baadc', ip: 
'10.254.0.10', os.name: 'Linux', os.arch: 'amd64', os.version: 
'4.4.0-62-generic', java.version: '1.8.0_121'
Driver info: driver.version: RemoteWebDriver
at 
org.openqa.selenium.remote.ErrorHandler.throwIfResponseFailed(ErrorHandler.java:142)
... 4 more

Caused by:
org.openqa.selenium.StaleElementReferenceException: 
{"errorMessage":"Element is no longer attached to the 
DOM","request":{"headers":{"Accept-Encoding":"gzip,deflate","Connection":"Keep-Alive","Content-Length":"27","Content-Type":"application/json;
 charset=utf-8","Host":"localhost:26799","User-Agent":"Apache-HttpClient/4.5.2 
(Java/1.8.0_121)"},"httpVersion":"1.1","method":"POST","post":"{\"id\":\":wdc:1492030111207\"}","url":"/click","urlParsed":{"anchor":"","query":"","file":"click","directory":"/","path":"/click","relative":"/click","port":"","host":"","password":"","user":"","userInfo":"","authority":"","protocol":"","source":"/click","queryKey":{},"chunks":["click"]},"urlOriginal":"/session/61a08b30-1fc1-11e7-a081-875185d8fe5e/element/:wdc:1492030111207/click"}}
For documentation on this error, please visit: 
http://seleniumhq.org/exceptions/stale_element_reference.html
Build info: version: '3.0.1', revision: '1969d75', time: 
'2016-10-18 09:49:13 -0700'
System info: host: '4e845115-d552-450d-58eb-d6cef82baadc', ip: 
'10.254.0.10', os.name: 'Linux', os.arch: 'amd64', os.version: 
'4.4.0-62-generic', java.version: 

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

[Bruce Schuchardt (JIRA)]

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

Bruce Schuchardt edited comment on GEODE-2724 at 4/12/17 9:35 PM:
--

[~jstewart] this was from the Geode users mailing list.  I'll forward the 
conversation to you.

Here are the instructions from the person who ran into the problem:

Steps:
1. Start locator
2. Start pulse
3. Do some activity in pulse [some clicks -- opening random tabs] [Don't logout]
3. Stop locator
4. Locator is still running in system even after message saying it was stopped



was (Author: bschuchardt):
[~jstewart] this was from the Geode users mailing list.  I'll forward the 
conversation to you.

> NPE shutting down locator
> -
>
> Key: GEODE-2724
> URL: https://issues.apache.org/jira/browse/GEODE-2724
> Project: Geode
>  Issue Type: Bug
>  Components: pulse
>Reporter: Bruce Schuchardt
>
> Locator shutdown threw an NPE when stopping a Jetty server in Pulse code:
> {code}
> [warning 2017/03/28 08:56:25.493 IST locator1  tid=0x4a] Failed to 
> stop the HTTP service because: null
> java.lang.NullPointerException
> at 
> org.apache.geode.tools.pulse.internal.data.Repository.removeAllClusters(Repository.java:225)
> at 
> org.apache.geode.tools.pulse.internal.PulseAppListener.contextDestroyed(PulseAppListener.java:84)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.callContextDestroyed(ContextHandler.java:843)
> at 
> org.eclipse.jetty.servlet.ServletContextHandler.callContextDestroyed(ServletContextHandler.java:543)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.stopContext(ContextHandler.java:824)
> at 
> org.eclipse.jetty.servlet.ServletContextHandler.stopContext(ServletContextHandler.java:353)
> at 
> org.eclipse.jetty.webapp.WebAppContext.stopWebapp(WebAppContext.java:1385)
> at 
> org.eclipse.jetty.webapp.WebAppContext.stopContext(WebAppContext.java:1349)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doStop(ContextHandler.java:872)
> at 
> org.eclipse.jetty.servlet.ServletContextHandler.doStop(ServletContextHandler.java:269)
> at org.eclipse.jetty.webapp.WebAppContext.doStop(WebAppContext.java:541)
> at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
> at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:143)
> at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:161)
> at 
> org.eclipse.jetty.server.handler.AbstractHandler.doStop(AbstractHandler.java:73)
> at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
> at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:143)
> at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:161)
> at 
> org.eclipse.jetty.server.handler.AbstractHandler.doStop(AbstractHandler.java:73)
> at org.eclipse.jetty.server.Server.doStop(Server.java:476)
> at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
> at 
> org.apache.geode.management.internal.ManagementAgent.stopHttpService(ManagementAgent.java:328)
> at 
> org.apache.geode.management.internal.ManagementAgent.stopAgent(ManagementAgent.java:156)
> at 
> org.apache.geode.management.internal.SystemManagementService.close(SystemManagementService.java:265)
> at 
> org.apache.geode.management.internal.beans.ManagementAdapter.handleCacheRemoval(ManagementAdapter.java:735)
> at 
> org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:117)
> at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2146)
> at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:536)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:2149)
> at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:1314)
> at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:964)
> at 
> org.apache.geode.management.internal.beans.MemberMBeanBridge$1.run(MemberMBeanBridge.java:1000)
> at java.lang.Thread.run(Thread.java:745)
> [error 2017/03/28 08:56:25.494 IST locator1  tid=0x4a] Failed to 
> properly release resources held by the HTTP service: !STOPPED
> java.lang.IllegalStateException: !STOPPED
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.destroy(HandlerWrapper.java:134)
> at 
> 

Re: Review Request 58388: GEODE-2730: refactor rules

[Ken Howe]

> On April 12, 2017, 9:10 p.m., Ken Howe wrote:
> > geode-core/src/test/java/org/apache/geode/test/dunit/rules/MemberStarterRule.java
> > Lines 110 (patched)
> > 
> >
> > I find this method name confusing because the member it just sets a 
> > boolean to start (or not) later in the before() method. My interpretation 
> > is that it's an "auto start" flag for each test.
> 
> Jinmei Liao wrote:
> probably renamed to autoStart()?
> 
> Jared Stewart wrote:
> Maybe startAutomatically()

That makes it more readable to me. I made the comment to see if there's 
consensus or strong feelings either way. If the method name is changed, then 
proably also want to rename the boolean as well.


- Ken


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


On April 12, 2017, 3:08 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58388/
> ---
> 
> (Updated April 12, 2017, 3:08 p.m.)
> 
> 
> Review request for geode, Jared Stewart, Ken Howe, Kirk Lund, and Patrick 
> Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> * consolidated the two sets of rules.
> * do not allow member start up at test initialization time.
> * validate properties in @Before
> * use provider in the chained rules to get the appropriate ports in @Before
> 
> Jared and I tried to use ServerLauncher/LocatorLauncher to start the 
> respective member in the rules, but precheckin yields many failures. Looks 
> like it has two problems:
> 1) by passing in the workingDir in the launcher alone does not make all the 
> logs go there. I still have to set the user.dir env variable to make some 
> tests pass.
> 2) launcher.stop does not stop the cache/locator/server cleanly. Subsequent 
> tests fail due to insufficient cleanup.
> Due to the above two reasons, I reverted back to use the old way to start 
> server/locator. This looks like a lean and mean way to get what we needed.
> 
> We also investigated the use of Builder in the rules. At least for now, it 
> doesn't buy us much since we need to do validation/startup servers in @Before 
> of the rules. And it yeilds some duplication code and make the usage not that 
> intuitive.
> 
> As for using AvailablePort.Keeper, Jared and I found out it doesn't really 
> keep the ports, so revert that back as well.
> 
> 
> Diffs
> -
> 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityIntegrationTest.java
>  cbd83e382116dcfc06b0199b69bf91486be22f06 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityPostProcessorTest.java
>  e93561c0b5fc4fa7f89c03ff4055515d6bbb21be 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityWithSSLTest.java
>  14113c06532d42833ee67f4fbf97ba24d535f2d3 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestServersJUnitTest.java
>  2a3a036782fbde22f8969337973ca5794a7172b0 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/SwaggerVerificationTest.java
>  a8ab19c0ac7f5cb94148fff725093c5f07858e93 
>   
> geode-assembly/src/test/java/org/apache/geode/test/dunit/rules/EmbeddedPulseRule.java
>  PRE-CREATION 
>   
> geode-assembly/src/test/java/org/apache/geode/test/dunit/rules/HttpClientRule.java
>  49351d9bba854eef08c20d47b99eb3ce467cabaa 
>   
> geode-assembly/src/test/java/org/apache/geode/tools/pulse/PulseDataExportTest.java
>  10ca43b8fc171f75887519deb72700f464f24149 
>   
> geode-assembly/src/test/java/org/apache/geode/tools/pulse/PulseVerificationTest.java
>  5a300a15b06b948603b5e82acba1190e1905b41a 
>   
> geode-core/src/test/java/org/apache/geode/cache/ConnectionPoolDUnitTest.java 
> 2ac5120a673ed53f7a8f4b1ed077902566e7865d 
>   geode-core/src/test/java/org/apache/geode/cache/ProxyJUnitTest.java 
> 05228addb74b070a4eac13bd61e84b055916a503 
>   
> geode-core/src/test/java/org/apache/geode/cache/partition/PartitionRegionHelperDUnitTest.java
>  c57ce5beebc7bc4e4d7b826d8795d5a8e367f245 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/BaseLineAndCompareQueryPerfJUnitTest.java
>  de2f8d3e159ed199c1bd4b740ce7dd8ed5b82a5f 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/dunit/QueryIndexDUnitTest.java
>  d121fe9993e13e07dcea4817a173b80a8342e169 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/dunit/RemoteQueryDUnitTest.java
>  5f48dae54cd14beb2affeae8a8f3387f3e7bfae0 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/functional/IndexWithSngleFrmAndMultCondQryJUnitTest.java
>  d5195a6b2c8f1b62955ddd127e28ee74bc63ab21 
>   
> 

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

[Bruce Schuchardt (JIRA)]

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

Bruce Schuchardt commented on GEODE-2724:
-

[~jstewart] this was from the Geode users mailing list.  I'll forward the 
conversation to you.

> NPE shutting down locator
> -
>
> Key: GEODE-2724
> URL: https://issues.apache.org/jira/browse/GEODE-2724
> Project: Geode
>  Issue Type: Bug
>  Components: pulse
>Reporter: Bruce Schuchardt
>
> Locator shutdown threw an NPE when stopping a Jetty server in Pulse code:
> {code}
> [warning 2017/03/28 08:56:25.493 IST locator1  tid=0x4a] Failed to 
> stop the HTTP service because: null
> java.lang.NullPointerException
> at 
> org.apache.geode.tools.pulse.internal.data.Repository.removeAllClusters(Repository.java:225)
> at 
> org.apache.geode.tools.pulse.internal.PulseAppListener.contextDestroyed(PulseAppListener.java:84)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.callContextDestroyed(ContextHandler.java:843)
> at 
> org.eclipse.jetty.servlet.ServletContextHandler.callContextDestroyed(ServletContextHandler.java:543)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.stopContext(ContextHandler.java:824)
> at 
> org.eclipse.jetty.servlet.ServletContextHandler.stopContext(ServletContextHandler.java:353)
> at 
> org.eclipse.jetty.webapp.WebAppContext.stopWebapp(WebAppContext.java:1385)
> at 
> org.eclipse.jetty.webapp.WebAppContext.stopContext(WebAppContext.java:1349)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doStop(ContextHandler.java:872)
> at 
> org.eclipse.jetty.servlet.ServletContextHandler.doStop(ServletContextHandler.java:269)
> at org.eclipse.jetty.webapp.WebAppContext.doStop(WebAppContext.java:541)
> at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
> at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:143)
> at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:161)
> at 
> org.eclipse.jetty.server.handler.AbstractHandler.doStop(AbstractHandler.java:73)
> at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
> at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:143)
> at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:161)
> at 
> org.eclipse.jetty.server.handler.AbstractHandler.doStop(AbstractHandler.java:73)
> at org.eclipse.jetty.server.Server.doStop(Server.java:476)
> at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
> at 
> org.apache.geode.management.internal.ManagementAgent.stopHttpService(ManagementAgent.java:328)
> at 
> org.apache.geode.management.internal.ManagementAgent.stopAgent(ManagementAgent.java:156)
> at 
> org.apache.geode.management.internal.SystemManagementService.close(SystemManagementService.java:265)
> at 
> org.apache.geode.management.internal.beans.ManagementAdapter.handleCacheRemoval(ManagementAdapter.java:735)
> at 
> org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:117)
> at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2146)
> at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:536)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:2149)
> at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:1314)
> at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:964)
> at 
> org.apache.geode.management.internal.beans.MemberMBeanBridge$1.run(MemberMBeanBridge.java:1000)
> at java.lang.Thread.run(Thread.java:745)
> [error 2017/03/28 08:56:25.494 IST locator1  tid=0x4a] Failed to 
> properly release resources held by the HTTP service: !STOPPED
> java.lang.IllegalStateException: !STOPPED
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.destroy(HandlerWrapper.java:134)
> at 
> org.apache.geode.management.internal.ManagementAgent.stopHttpService(ManagementAgent.java:333)
> at 
> org.apache.geode.management.internal.ManagementAgent.stopAgent(ManagementAgent.java:156)
> at 
> org.apache.geode.management.internal.SystemManagementService.close(SystemManagementService.java:265)
> at 
> org.apache.geode.management.internal.beans.ManagementAdapter.handleCacheRemoval(ManagementAdapter.java:735)
> at 
> 

Re: Review Request 58388: GEODE-2730: refactor rules

[Jared Stewart]

> On April 12, 2017, 9:10 p.m., Ken Howe wrote:
> > geode-core/src/test/java/org/apache/geode/test/dunit/rules/MemberStarterRule.java
> > Lines 110 (patched)
> > 
> >
> > I find this method name confusing because the member it just sets a 
> > boolean to start (or not) later in the before() method. My interpretation 
> > is that it's an "auto start" flag for each test.
> 
> Jinmei Liao wrote:
> probably renamed to autoStart()?

Maybe startAutomatically()


- Jared


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


On April 12, 2017, 3:08 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58388/
> ---
> 
> (Updated April 12, 2017, 3:08 p.m.)
> 
> 
> Review request for geode, Jared Stewart, Ken Howe, Kirk Lund, and Patrick 
> Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> * consolidated the two sets of rules.
> * do not allow member start up at test initialization time.
> * validate properties in @Before
> * use provider in the chained rules to get the appropriate ports in @Before
> 
> Jared and I tried to use ServerLauncher/LocatorLauncher to start the 
> respective member in the rules, but precheckin yields many failures. Looks 
> like it has two problems:
> 1) by passing in the workingDir in the launcher alone does not make all the 
> logs go there. I still have to set the user.dir env variable to make some 
> tests pass.
> 2) launcher.stop does not stop the cache/locator/server cleanly. Subsequent 
> tests fail due to insufficient cleanup.
> Due to the above two reasons, I reverted back to use the old way to start 
> server/locator. This looks like a lean and mean way to get what we needed.
> 
> We also investigated the use of Builder in the rules. At least for now, it 
> doesn't buy us much since we need to do validation/startup servers in @Before 
> of the rules. And it yeilds some duplication code and make the usage not that 
> intuitive.
> 
> As for using AvailablePort.Keeper, Jared and I found out it doesn't really 
> keep the ports, so revert that back as well.
> 
> 
> Diffs
> -
> 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityIntegrationTest.java
>  cbd83e382116dcfc06b0199b69bf91486be22f06 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityPostProcessorTest.java
>  e93561c0b5fc4fa7f89c03ff4055515d6bbb21be 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityWithSSLTest.java
>  14113c06532d42833ee67f4fbf97ba24d535f2d3 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestServersJUnitTest.java
>  2a3a036782fbde22f8969337973ca5794a7172b0 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/SwaggerVerificationTest.java
>  a8ab19c0ac7f5cb94148fff725093c5f07858e93 
>   
> geode-assembly/src/test/java/org/apache/geode/test/dunit/rules/EmbeddedPulseRule.java
>  PRE-CREATION 
>   
> geode-assembly/src/test/java/org/apache/geode/test/dunit/rules/HttpClientRule.java
>  49351d9bba854eef08c20d47b99eb3ce467cabaa 
>   
> geode-assembly/src/test/java/org/apache/geode/tools/pulse/PulseDataExportTest.java
>  10ca43b8fc171f75887519deb72700f464f24149 
>   
> geode-assembly/src/test/java/org/apache/geode/tools/pulse/PulseVerificationTest.java
>  5a300a15b06b948603b5e82acba1190e1905b41a 
>   
> geode-core/src/test/java/org/apache/geode/cache/ConnectionPoolDUnitTest.java 
> 2ac5120a673ed53f7a8f4b1ed077902566e7865d 
>   geode-core/src/test/java/org/apache/geode/cache/ProxyJUnitTest.java 
> 05228addb74b070a4eac13bd61e84b055916a503 
>   
> geode-core/src/test/java/org/apache/geode/cache/partition/PartitionRegionHelperDUnitTest.java
>  c57ce5beebc7bc4e4d7b826d8795d5a8e367f245 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/BaseLineAndCompareQueryPerfJUnitTest.java
>  de2f8d3e159ed199c1bd4b740ce7dd8ed5b82a5f 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/dunit/QueryIndexDUnitTest.java
>  d121fe9993e13e07dcea4817a173b80a8342e169 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/dunit/RemoteQueryDUnitTest.java
>  5f48dae54cd14beb2affeae8a8f3387f3e7bfae0 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/functional/IndexWithSngleFrmAndMultCondQryJUnitTest.java
>  d5195a6b2c8f1b62955ddd127e28ee74bc63ab21 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/functional/LimitClauseJUnitTest.java
>  1661cc8d5ba42b782e08251338605c001c526c97 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/internal/QueryUtilsJUnitTest.java
>  

Re: Review Request 58388: GEODE-2730: refactor rules

[Jinmei Liao]

> On April 12, 2017, 9:10 p.m., Ken Howe wrote:
> > geode-core/src/test/java/org/apache/geode/test/dunit/rules/MemberStarterRule.java
> > Lines 110 (patched)
> > 
> >
> > I find this method name confusing because the member it just sets a 
> > boolean to start (or not) later in the before() method. My interpretation 
> > is that it's an "auto start" flag for each test.

probably renamed to autoStart()?


- Jinmei


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


On April 12, 2017, 3:08 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58388/
> ---
> 
> (Updated April 12, 2017, 3:08 p.m.)
> 
> 
> Review request for geode, Jared Stewart, Ken Howe, Kirk Lund, and Patrick 
> Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> * consolidated the two sets of rules.
> * do not allow member start up at test initialization time.
> * validate properties in @Before
> * use provider in the chained rules to get the appropriate ports in @Before
> 
> Jared and I tried to use ServerLauncher/LocatorLauncher to start the 
> respective member in the rules, but precheckin yields many failures. Looks 
> like it has two problems:
> 1) by passing in the workingDir in the launcher alone does not make all the 
> logs go there. I still have to set the user.dir env variable to make some 
> tests pass.
> 2) launcher.stop does not stop the cache/locator/server cleanly. Subsequent 
> tests fail due to insufficient cleanup.
> Due to the above two reasons, I reverted back to use the old way to start 
> server/locator. This looks like a lean and mean way to get what we needed.
> 
> We also investigated the use of Builder in the rules. At least for now, it 
> doesn't buy us much since we need to do validation/startup servers in @Before 
> of the rules. And it yeilds some duplication code and make the usage not that 
> intuitive.
> 
> As for using AvailablePort.Keeper, Jared and I found out it doesn't really 
> keep the ports, so revert that back as well.
> 
> 
> Diffs
> -
> 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityIntegrationTest.java
>  cbd83e382116dcfc06b0199b69bf91486be22f06 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityPostProcessorTest.java
>  e93561c0b5fc4fa7f89c03ff4055515d6bbb21be 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityWithSSLTest.java
>  14113c06532d42833ee67f4fbf97ba24d535f2d3 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestServersJUnitTest.java
>  2a3a036782fbde22f8969337973ca5794a7172b0 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/SwaggerVerificationTest.java
>  a8ab19c0ac7f5cb94148fff725093c5f07858e93 
>   
> geode-assembly/src/test/java/org/apache/geode/test/dunit/rules/EmbeddedPulseRule.java
>  PRE-CREATION 
>   
> geode-assembly/src/test/java/org/apache/geode/test/dunit/rules/HttpClientRule.java
>  49351d9bba854eef08c20d47b99eb3ce467cabaa 
>   
> geode-assembly/src/test/java/org/apache/geode/tools/pulse/PulseDataExportTest.java
>  10ca43b8fc171f75887519deb72700f464f24149 
>   
> geode-assembly/src/test/java/org/apache/geode/tools/pulse/PulseVerificationTest.java
>  5a300a15b06b948603b5e82acba1190e1905b41a 
>   
> geode-core/src/test/java/org/apache/geode/cache/ConnectionPoolDUnitTest.java 
> 2ac5120a673ed53f7a8f4b1ed077902566e7865d 
>   geode-core/src/test/java/org/apache/geode/cache/ProxyJUnitTest.java 
> 05228addb74b070a4eac13bd61e84b055916a503 
>   
> geode-core/src/test/java/org/apache/geode/cache/partition/PartitionRegionHelperDUnitTest.java
>  c57ce5beebc7bc4e4d7b826d8795d5a8e367f245 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/BaseLineAndCompareQueryPerfJUnitTest.java
>  de2f8d3e159ed199c1bd4b740ce7dd8ed5b82a5f 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/dunit/QueryIndexDUnitTest.java
>  d121fe9993e13e07dcea4817a173b80a8342e169 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/dunit/RemoteQueryDUnitTest.java
>  5f48dae54cd14beb2affeae8a8f3387f3e7bfae0 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/functional/IndexWithSngleFrmAndMultCondQryJUnitTest.java
>  d5195a6b2c8f1b62955ddd127e28ee74bc63ab21 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/functional/LimitClauseJUnitTest.java
>  1661cc8d5ba42b782e08251338605c001c526c97 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/internal/QueryUtilsJUnitTest.java
>  85305560669544d5fb3493a88f7bf93d86b8ac91 
>   
> 

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

[Jared Stewart (JIRA)]

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

Jared Stewart commented on GEODE-2724:
--

Can you provide any details about how to reproduce this failure?

> NPE shutting down locator
> -
>
> Key: GEODE-2724
> URL: https://issues.apache.org/jira/browse/GEODE-2724
> Project: Geode
>  Issue Type: Bug
>  Components: pulse
>Reporter: Bruce Schuchardt
>
> Locator shutdown threw an NPE when stopping a Jetty server in Pulse code:
> {code}
> [warning 2017/03/28 08:56:25.493 IST locator1  tid=0x4a] Failed to 
> stop the HTTP service because: null
> java.lang.NullPointerException
> at 
> org.apache.geode.tools.pulse.internal.data.Repository.removeAllClusters(Repository.java:225)
> at 
> org.apache.geode.tools.pulse.internal.PulseAppListener.contextDestroyed(PulseAppListener.java:84)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.callContextDestroyed(ContextHandler.java:843)
> at 
> org.eclipse.jetty.servlet.ServletContextHandler.callContextDestroyed(ServletContextHandler.java:543)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.stopContext(ContextHandler.java:824)
> at 
> org.eclipse.jetty.servlet.ServletContextHandler.stopContext(ServletContextHandler.java:353)
> at 
> org.eclipse.jetty.webapp.WebAppContext.stopWebapp(WebAppContext.java:1385)
> at 
> org.eclipse.jetty.webapp.WebAppContext.stopContext(WebAppContext.java:1349)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doStop(ContextHandler.java:872)
> at 
> org.eclipse.jetty.servlet.ServletContextHandler.doStop(ServletContextHandler.java:269)
> at org.eclipse.jetty.webapp.WebAppContext.doStop(WebAppContext.java:541)
> at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
> at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:143)
> at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:161)
> at 
> org.eclipse.jetty.server.handler.AbstractHandler.doStop(AbstractHandler.java:73)
> at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
> at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:143)
> at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:161)
> at 
> org.eclipse.jetty.server.handler.AbstractHandler.doStop(AbstractHandler.java:73)
> at org.eclipse.jetty.server.Server.doStop(Server.java:476)
> at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
> at 
> org.apache.geode.management.internal.ManagementAgent.stopHttpService(ManagementAgent.java:328)
> at 
> org.apache.geode.management.internal.ManagementAgent.stopAgent(ManagementAgent.java:156)
> at 
> org.apache.geode.management.internal.SystemManagementService.close(SystemManagementService.java:265)
> at 
> org.apache.geode.management.internal.beans.ManagementAdapter.handleCacheRemoval(ManagementAdapter.java:735)
> at 
> org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:117)
> at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2146)
> at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:536)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:2149)
> at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:1314)
> at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:964)
> at 
> org.apache.geode.management.internal.beans.MemberMBeanBridge$1.run(MemberMBeanBridge.java:1000)
> at java.lang.Thread.run(Thread.java:745)
> [error 2017/03/28 08:56:25.494 IST locator1  tid=0x4a] Failed to 
> properly release resources held by the HTTP service: !STOPPED
> java.lang.IllegalStateException: !STOPPED
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.destroy(HandlerWrapper.java:134)
> at 
> org.apache.geode.management.internal.ManagementAgent.stopHttpService(ManagementAgent.java:333)
> at 
> org.apache.geode.management.internal.ManagementAgent.stopAgent(ManagementAgent.java:156)
> at 
> org.apache.geode.management.internal.SystemManagementService.close(SystemManagementService.java:265)
> at 
> org.apache.geode.management.internal.beans.ManagementAdapter.handleCacheRemoval(ManagementAdapter.java:735)
> at 
> org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:117)
> at 
> 

Re: Review Request 58388: GEODE-2730: refactor rules

[Ken Howe]

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



Reviewed the rest of the diffs


geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsIntegrationTest.java
Line 34 (original), 32 (patched)


Your patch does not apply cleanly to this file due to other recent changes 
affecting ExportLogs. You should probably sync up with the current state of the 
develop branch and re-run precheckin.



geode-core/src/test/java/org/apache/geode/test/dunit/rules/MemberStarterRule.java
Lines 110 (patched)


I find this method name confusing because the member it just sets a boolean 
to start (or not) later in the before() method. My interpretation is that it's 
an "auto start" flag for each test.


- Ken Howe


On April 12, 2017, 3:08 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58388/
> ---
> 
> (Updated April 12, 2017, 3:08 p.m.)
> 
> 
> Review request for geode, Jared Stewart, Ken Howe, Kirk Lund, and Patrick 
> Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> * consolidated the two sets of rules.
> * do not allow member start up at test initialization time.
> * validate properties in @Before
> * use provider in the chained rules to get the appropriate ports in @Before
> 
> Jared and I tried to use ServerLauncher/LocatorLauncher to start the 
> respective member in the rules, but precheckin yields many failures. Looks 
> like it has two problems:
> 1) by passing in the workingDir in the launcher alone does not make all the 
> logs go there. I still have to set the user.dir env variable to make some 
> tests pass.
> 2) launcher.stop does not stop the cache/locator/server cleanly. Subsequent 
> tests fail due to insufficient cleanup.
> Due to the above two reasons, I reverted back to use the old way to start 
> server/locator. This looks like a lean and mean way to get what we needed.
> 
> We also investigated the use of Builder in the rules. At least for now, it 
> doesn't buy us much since we need to do validation/startup servers in @Before 
> of the rules. And it yeilds some duplication code and make the usage not that 
> intuitive.
> 
> As for using AvailablePort.Keeper, Jared and I found out it doesn't really 
> keep the ports, so revert that back as well.
> 
> 
> Diffs
> -
> 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityIntegrationTest.java
>  cbd83e382116dcfc06b0199b69bf91486be22f06 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityPostProcessorTest.java
>  e93561c0b5fc4fa7f89c03ff4055515d6bbb21be 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityWithSSLTest.java
>  14113c06532d42833ee67f4fbf97ba24d535f2d3 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestServersJUnitTest.java
>  2a3a036782fbde22f8969337973ca5794a7172b0 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/SwaggerVerificationTest.java
>  a8ab19c0ac7f5cb94148fff725093c5f07858e93 
>   
> geode-assembly/src/test/java/org/apache/geode/test/dunit/rules/EmbeddedPulseRule.java
>  PRE-CREATION 
>   
> geode-assembly/src/test/java/org/apache/geode/test/dunit/rules/HttpClientRule.java
>  49351d9bba854eef08c20d47b99eb3ce467cabaa 
>   
> geode-assembly/src/test/java/org/apache/geode/tools/pulse/PulseDataExportTest.java
>  10ca43b8fc171f75887519deb72700f464f24149 
>   
> geode-assembly/src/test/java/org/apache/geode/tools/pulse/PulseVerificationTest.java
>  5a300a15b06b948603b5e82acba1190e1905b41a 
>   
> geode-core/src/test/java/org/apache/geode/cache/ConnectionPoolDUnitTest.java 
> 2ac5120a673ed53f7a8f4b1ed077902566e7865d 
>   geode-core/src/test/java/org/apache/geode/cache/ProxyJUnitTest.java 
> 05228addb74b070a4eac13bd61e84b055916a503 
>   
> geode-core/src/test/java/org/apache/geode/cache/partition/PartitionRegionHelperDUnitTest.java
>  c57ce5beebc7bc4e4d7b826d8795d5a8e367f245 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/BaseLineAndCompareQueryPerfJUnitTest.java
>  de2f8d3e159ed199c1bd4b740ce7dd8ed5b82a5f 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/dunit/QueryIndexDUnitTest.java
>  d121fe9993e13e07dcea4817a173b80a8342e169 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/dunit/RemoteQueryDUnitTest.java
>  5f48dae54cd14beb2affeae8a8f3387f3e7bfae0 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/functional/IndexWithSngleFrmAndMultCondQryJUnitTest.java
>  d5195a6b2c8f1b62955ddd127e28ee74bc63ab21 
>   
> 

[GitHub] geode pull request #451: GEODE-2768: Lucene Queries executed before index is...

[gesterzhou]

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

https://github.com/apache/geode/pull/451#discussion_r111261018
  
--- Diff: 
geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/distributed/LuceneQueryFunction.java
 ---
@@ -132,6 +133,25 @@ private LuceneIndexImpl getLuceneIndex(final Region 
region,
 try {
   index =
   (LuceneIndexImpl) service.getIndex(searchContext.getIndexName(), 
region.getFullPath());
+  if (index == null && service instanceof LuceneServiceImpl) {
+if (((LuceneServiceImpl) 
service).getDefinedIndex(searchContext.getIndexName(),
+region.getFullPath()) != null) {
+  // The node may be in the process of recovering, where we have 
the index defined but yet
+  // to be recovered
+  // If we retry fast enough, we could get a stack overflow based 
on the way function
+  // execution is currently written
+  // Instead we will add an artificial sleep to slow down the 
retry at this point
+  // Hopefully in the future, the function execution would retry 
without adding to the stack
+  // and this can be removed
+  try {
--- End diff --

Is sleep 100 ms enough? How about using a 10 seconds timeout, but check if 
it's ready every 100ms?


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

[jira] [Commented] (GEODE-2768) Lucene Queries executed before index is fully created should be retried

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/geode/pull/451#discussion_r111261018
  
--- Diff: 
geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/distributed/LuceneQueryFunction.java
 ---
@@ -132,6 +133,25 @@ private LuceneIndexImpl getLuceneIndex(final Region 
region,
 try {
   index =
   (LuceneIndexImpl) service.getIndex(searchContext.getIndexName(), 
region.getFullPath());
+  if (index == null && service instanceof LuceneServiceImpl) {
+if (((LuceneServiceImpl) 
service).getDefinedIndex(searchContext.getIndexName(),
+region.getFullPath()) != null) {
+  // The node may be in the process of recovering, where we have 
the index defined but yet
+  // to be recovered
+  // If we retry fast enough, we could get a stack overflow based 
on the way function
+  // execution is currently written
+  // Instead we will add an artificial sleep to slow down the 
retry at this point
+  // Hopefully in the future, the function execution would retry 
without adding to the stack
+  // and this can be removed
+  try {
--- End diff --

Is sleep 100 ms enough? How about using a 10 seconds timeout, but check if 
it's ready every 100ms?


> Lucene Queries executed before index is fully created should be retried
> ---
>
> Key: GEODE-2768
> URL: https://issues.apache.org/jira/browse/GEODE-2768
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Jason Huynh
>Assignee: Jason Huynh
>
> With the feature to destroy a Lucene Index, parts of the querying function 
> were changed to handle the event where we execute a query on an index that is 
> no longer present.  However, the scenario where we execute a query on an 
> index that is defined but has not been created can also arise. 
> We want to handle the case where we have defined the index, but have yet to 
> create it due to a brief window in restart.  



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

[jira] [Commented] (GEODE-2703) Improve error message that Lucene queries are not supported in the context of a transaction

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2703:


Commit e7b57b679b1be837f943c34e1d7022b5aa8de583 in geode's branch 
refs/heads/feature/GEODE-2703 from [~huynhja]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=e7b57b6 ]

GEODE-2703: Improve exception message when executing lucene within a transaction

  * Throw a LuceneQueryException instead of a TransactionException


> Improve error message that Lucene queries are not supported in the context of 
> a transaction
> ---
>
> Key: GEODE-2703
> URL: https://issues.apache.org/jira/browse/GEODE-2703
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Diane Hardman
>
> We currently do not support Lucene queries in the context of a transaction. 
> The exception thrown, however, may be confusing to the user.
> ERROR org.apache.geode.cache.TransactionException: Function inside a 
> transaction cannot execute on more than one node
> org.apache.geode.cache.TransactionException: Function inside a transaction 
> cannot execute on more than one node
> at 
> org.apache.geode.internal.cache.execute.PartitionedRegionFunctionExecutor.validateExecution(PartitionedRegionFunctionExecutor.java:344)
> at 
> org.apache.geode.internal.cache.PartitionedRegion.executeOnAllBuckets(PartitionedRegion.java:3840)
> at 
> org.apache.geode.internal.cache.PartitionedRegion.executeFunction(PartitionedRegion.java:3353)
> at 
> org.apache.geode.internal.cache.execute.PartitionedRegionFunctionExecutor.executeFunction(PartitionedRegionFunctionExecutor.java:228)
> at 
> org.apache.geode.internal.cache.execute.AbstractExecution.execute(AbstractExecution.java:376)
> at 
> org.apache.geode.cache.lucene.internal.LuceneQueryImpl.findTopEntries(LuceneQueryImpl.java:115)
> at 
> org.apache.geode.cache.lucene.internal.LuceneQueryImpl.findPages(LuceneQueryImpl.java:95)
> at 
> org.apache.geode.cache.lucene.internal.LuceneQueryImpl.findResults(LuceneQueryImpl.java:81)
> at lucene.LuceneTest.executeLuceneQuery(LuceneTest.java:154)
> at parReg.ParRegTest.doEntryOperations(ParRegTest.java:2929)
> at parReg.ParRegTest.doRROpsAndVerify(ParRegTest.java:1709)
> at parReg.ParRegTest.HydraTask_doRROpsAndVerify(ParRegTest.java:958)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at hydra.MethExecutor.execute(MethExecutor.java:182)
> at hydra.MethExecutor.execute(MethExecutor.java:150)
> at hydra.TestTask.execute(TestTask.java:192)
> at hydra.RemoteTestModule$1.run(RemoteTestModule.java:212)
> ```



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

[jira] [Commented] (GEODE-2775) Pulse is not using certificate to connect to JMX when ssl is turned for jmx connection

[Jinmei Liao (JIRA)]

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

Jinmei Liao commented on GEODE-2775:


The problem lies in the fact that when in the embedded mode, the useSSL flag of 
pulse is not correctly set. Here is the workaround with the current release:
In the embedded mode:
* once a locator/server is started with ssl, go to the working directory of the 
member and find the pulse.properties file. Change the property 
"pulse.useSSL.manager" to true. 
* restart the locator/server to pick up the change in the properties file, now 
pulse should be able to connect.

In the standalone mode:
* follow this guide to set up the pulse.properties and pulsesecurity.properties 
with the ssl information: 
http://gemfirexd.docs.pivotal.io/1.3.1/userguide/manage_guide/pulse/quickstart.html
* remember to put "pulse.useSSL.manager=true" in the pulse.properties

> Pulse is not using certificate to connect to JMX when ssl is turned for jmx 
> connection
> --
>
> Key: GEODE-2775
> URL: https://issues.apache.org/jira/browse/GEODE-2775
> Project: Geode
>  Issue Type: Bug
>  Components: pulse
>Affects Versions: 1.1.1
>Reporter: Jinmei Liao
>
> Steps to reproduce:
> 1) start a locator with a SecurityManager and with this property: 
> ssl-enabled-components=jmx
> 2) start a browser and tries to login to pulse.
> Actual result: not able to log in using valid username/password



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

[jira] [Commented] (GEODE-2768) Lucene Queries executed before index is fully created should be retried

[ASF GitHub Bot (JIRA)]

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

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

Github user jhuynh1 commented on the issue:

https://github.com/apache/geode/pull/451
  
Tagging potential reviewers @nabarunnag @boglesby @ladyVader @gesterzhou 


> Lucene Queries executed before index is fully created should be retried
> ---
>
> Key: GEODE-2768
> URL: https://issues.apache.org/jira/browse/GEODE-2768
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Jason Huynh
>Assignee: Jason Huynh
>
> With the feature to destroy a Lucene Index, parts of the querying function 
> were changed to handle the event where we execute a query on an index that is 
> no longer present.  However, the scenario where we execute a query on an 
> index that is defined but has not been created can also arise. 
> We want to handle the case where we have defined the index, but have yet to 
> create it due to a brief window in restart.  



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

[GitHub] geode issue #451: GEODE-2768: Lucene Queries executed before index is fully ...

[jhuynh1]

Github user jhuynh1 commented on the issue:

https://github.com/apache/geode/pull/451
  
Tagging potential reviewers @nabarunnag @boglesby @ladyVader @gesterzhou 


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

[GitHub] geode pull request #451: GEODE-2768: Lucene Queries executed before index is...

[jhuynh1]

GitHub user jhuynh1 opened a pull request:

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

GEODE-2768: Lucene Queries executed before index is fully created sho…

…uld be retried

  * Added a sleep to prevent rapid retries which lead to stack overflow
  * Sleep can be removed when Function Execution retry does not add to stack

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

$ git pull https://github.com/apache/geode feature/GEODE-2768

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

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


commit 60f5f06f18f8ea6c1d176a43a25bfbb4086e2f21
Author: Jason Huynh 
Date:   2017-04-12T18:39:28Z

GEODE-2768: Lucene Queries executed before index is fully created should be 
retried

  * Added a sleep to prevent rapid retries which lead to stack overflow
  * Sleep can be removed when Function Execution retry does not add to stack




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

[jira] [Commented] (GEODE-2745) The AsyncEventQueueImpl waitUntilFlushed method waits longer than it should for events to be flushed

[ASF GitHub Bot (JIRA)]

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

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

Github user ladyVader closed the pull request at:

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


> The AsyncEventQueueImpl waitUntilFlushed method waits longer than it should 
> for events to be flushed
> 
>
> Key: GEODE-2745
> URL: https://issues.apache.org/jira/browse/GEODE-2745
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Reporter: Barry Oglesby
>Assignee: Shelley Lynn Hughes-Godfrey
> Fix For: 1.2.0
>
>
> With the changes to waitUntilFlushed to process 10 buckets at a time, if 
> events are happening while waitUntilFlushed is in progress, then all the 
> buckets after the first 10 will have processed more than it should before 
> returning.
> If the update rate is causing the queue to always contain 113000 events, and 
> the events are spread evenly across the buckets, each bucket will have 1000 
> events to wait for. The first 10 buckets will wait for their 1000 events. 
> When those have been processed, the next 10 buckets will wait for their 1000 
> events starting from that point, but they've already processed 1000 events. 
> So, these buckets will actually wait for 2000 events to be processed before 
> returning. This pattern continues until all the buckets are done.
> The WaitUntilBucketRegionQueueFlushedCallable needs to track not only the 
> BucketRegionQueue but also the latestQueuedKey.



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

[GitHub] geode pull request #448: GEODE-2745: WaitUntilBucketRegionQueueFlushedCallab...

[ladyVader]

Github user ladyVader closed the pull request at:

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


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

[jira] [Resolved] (GEODE-2193) a member is kicked out immediately after joining

[Hitesh Khamesra (JIRA)]

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

Hitesh Khamesra resolved GEODE-2193.

Fix Version/s: (was: 1.1.0)
   1.2.0

> a member is kicked out immediately after joining
> 
>
> Key: GEODE-2193
> URL: https://issues.apache.org/jira/browse/GEODE-2193
> Project: Geode
>  Issue Type: Bug
>  Components: membership
>Reporter: Bruce Schuchardt
>Assignee: Hitesh Khamesra
> Fix For: 1.2.0
>
>
> We have observed a number of cases where a member is kicked out immediately 
> after joining.  The problem seems to be this:
> 1) the member sends a join request to the current coordinator
> 2) the current coordinator is in the process of shutting down
> 3) the current coordinator sends a view preparation message admitting the new 
> member
> 4) another member receives the current coordinator's shutdown message and 
> initiates becoming the coordinator
> 5) the new coordinator sends out a membership view that does not include the 
> new member
> 6) the new member receives the prepared view and continues with startup
> 7) the new member sends startup messages to other members
> 8) the other members have the new coordinator's view and request removal of 
> the new member as being rogue
> 9) the new coordinator sends a Leave message to the new member, causing it to 
> issue a ForcedDisconnect
> The old coordinator should not initiate a new view if it is shutting down.  
> It needs to have cancellation & shutdown checks in its view transmission 
> methods.



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

[jira] [Commented] (GEODE-2193) a member is kicked out immediately after joining

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2193:


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

GEODE-2193 Now we don't send view if shutdown process is started.

Earlier we were checking flag, which was set after sending the shutdown
message. Now we check flag, which was set before sending the shutdown
message.


> a member is kicked out immediately after joining
> 
>
> Key: GEODE-2193
> URL: https://issues.apache.org/jira/browse/GEODE-2193
> Project: Geode
>  Issue Type: Bug
>  Components: membership
>Reporter: Bruce Schuchardt
>Assignee: Hitesh Khamesra
> Fix For: 1.1.0
>
>
> We have observed a number of cases where a member is kicked out immediately 
> after joining.  The problem seems to be this:
> 1) the member sends a join request to the current coordinator
> 2) the current coordinator is in the process of shutting down
> 3) the current coordinator sends a view preparation message admitting the new 
> member
> 4) another member receives the current coordinator's shutdown message and 
> initiates becoming the coordinator
> 5) the new coordinator sends out a membership view that does not include the 
> new member
> 6) the new member receives the prepared view and continues with startup
> 7) the new member sends startup messages to other members
> 8) the other members have the new coordinator's view and request removal of 
> the new member as being rogue
> 9) the new coordinator sends a Leave message to the new member, causing it to 
> issue a ForcedDisconnect
> The old coordinator should not initiate a new view if it is shutting down.  
> It needs to have cancellation & shutdown checks in its view transmission 
> methods.



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

Review Request 58397: check off-heap limit during disk recovery

[Darrel Schneider]

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

Review request for geode, anilkumar gingade, Eric Shu, and Lynn Gallinat.


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


Repository: geode


Description
---

During disk recovery, the code now checks the offheap LRU limit instead of the 
heap LRU limit for offheap regions.
A unit test has been added that without this fix would run out of offheap 
memory during recovery.


Diffs
-

  
geode-core/src/main/java/org/apache/geode/internal/cache/AbstractLRURegionMap.java
 328ff35b940239bfbcf817d144d97f886506b33a 
  
geode-core/src/main/java/org/apache/geode/internal/cache/AbstractRegionMap.java 
eaababaf6be6041c72156a338c69fa81f10db4c5 
  geode-core/src/main/java/org/apache/geode/internal/cache/LocalRegion.java 
d0aacc2d95fa38b1bc9faf68de795af5ef3d9090 
  
geode-core/src/main/java/org/apache/geode/internal/cache/PlaceHolderDiskRegion.java
 db01162aeeba8113c208565d683e71a41d0f6d00 
  geode-core/src/main/java/org/apache/geode/internal/cache/ProxyRegionMap.java 
92c7b6f8e90a3382e7ce00064581d69f9706fcd3 
  geode-core/src/main/java/org/apache/geode/internal/cache/lru/EnableLRU.java 
6aaf8cc914c3b8c2e308446930bbd3215c9f58ca 
  
geode-core/src/main/java/org/apache/geode/internal/cache/lru/HeapLRUCapacityController.java
 5e86ce87b99fc4e8793461e881853c141fdfec1f 
  
geode-core/src/main/java/org/apache/geode/internal/cache/lru/LRUCapacityController.java
 3596a07df407960c3558057ac33e92c89bd5ba22 
  
geode-core/src/main/java/org/apache/geode/internal/cache/lru/LRUMapCallbacks.java
 27a4ec019ae3b5fd29a26ffc451d0d9feb75f903 
  
geode-core/src/main/java/org/apache/geode/internal/cache/lru/MemLRUCapacityController.java
 2c2e8ec1a805b7485e6e59858a12122fa8d88de1 
  
geode-core/src/test/java/org/apache/geode/internal/cache/lru/LRUClockJUnitTest.java
 8095d5ac483be061199623a78b63618697e09d9d 
  
geode-core/src/test/java/org/apache/geode/internal/offheap/OffHeapLRURecoveryRegressionTest.java
 PRE-CREATION 


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


Testing
---

precheckin


Thanks,

Darrel Schneider

Re: One class loader vs multiple class loaders for deployed jars

[John Blum]

+1 to what Mike Stolz said.

On Wed, Apr 12, 2017 at 8:17 PM, Anthony Baker  wrote:

> Agreed.  It’s used by maven but the project itself doesn’t seem very
> active.
>
> Anthony
>
> > On Apr 12, 2017, at 11:15 AM, Jared Stewart  wrote:
> >
> > Anthony - I was never able to find any substantial documentation for
> Plexus Classworlds.  This makes it both hard to evaluate and potentially
> scary to use.
>
>


-- 
-John
john.blum10101 (skype)

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

[Swapnil Bawaskar (JIRA)]

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

Swapnil Bawaskar updated GEODE-2716:

Fix Version/s: 1.2.0

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



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

[jira] [Resolved] (GEODE-2103) start locator command should include --http-service-port and --http-service-bind-address

[Swapnil Bawaskar (JIRA)]

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

Swapnil Bawaskar resolved GEODE-2103.
-
Resolution: Fixed

> start locator command should include --http-service-port and 
> --http-service-bind-address
> 
>
> Key: GEODE-2103
> URL: https://issues.apache.org/jira/browse/GEODE-2103
> Project: Geode
>  Issue Type: Improvement
>  Components: docs, management
>Affects Versions: 1.0.0-incubating
>Reporter: Kirk Lund
>Assignee: Deepak Dixit
>
> To facilitate starting the Admin REST API on a Locator, start locator command 
> should include --http-service-port and --http-service-bind-address.
> Workaround is to specify these configuration properties with --J:
> --J=-Dgemfire.http-service-port=
> --J=-Dgemfire.http-service-bind-address=



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

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

[Swapnil Bawaskar (JIRA)]

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

Swapnil Bawaskar resolved GEODE-2716.
-
Resolution: Fixed

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



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

[jira] [Commented] (GEODE-2768) Lucene Queries executed before index is fully created should be retried

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2768:


Commit 60f5f06f18f8ea6c1d176a43a25bfbb4086e2f21 in geode's branch 
refs/heads/feature/GEODE-2768 from [~huynhja]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=60f5f06 ]

GEODE-2768: Lucene Queries executed before index is fully created should be 
retried

  * Added a sleep to prevent rapid retries which lead to stack overflow
  * Sleep can be removed when Function Execution retry does not add to stack


> Lucene Queries executed before index is fully created should be retried
> ---
>
> Key: GEODE-2768
> URL: https://issues.apache.org/jira/browse/GEODE-2768
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Jason Huynh
>Assignee: Jason Huynh
>
> With the feature to destroy a Lucene Index, parts of the querying function 
> were changed to handle the event where we execute a query on an index that is 
> no longer present.  However, the scenario where we execute a query on an 
> index that is defined but has not been created can also arise. 
> We want to handle the case where we have defined the index, but have yet to 
> create it due to a brief window in restart.  



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

Review Request 58395: GEODE-2773: Checking region version based on WaitCriterion only with async invocation

[Eric Shu]

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

Review request for geode, anilkumar gingade, Darrel Schneider, and Lynn 
Gallinat.


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


Repository: geode


Description
---

The current checking of region version in async call is incorrect as it can 
fail due to newer region versions caused by other operations.


Diffs
-

  
geode-core/src/test/java/org/apache/geode/internal/cache/GIIDeltaDUnitTest.java 
d07227b 


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


Testing
---

precheckin.


Thanks,

Eric Shu

[GitHub] geode issue #447: Feature/geode 2217

[jhuynh1]

Github user jhuynh1 commented on the issue:

https://github.com/apache/geode/pull/447
  
I pulled the changes and it built fine.  I collapsed and edited the commit 
messages to match how geode commits generally look and made a minor tweak to 
the wording on one parameter.  This is now in the develop branch of Geode.  
Thanks (again) for the contribution!


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

[GitHub] geode pull request #447: Feature/geode 2217

[asfgit]

Github user asfgit closed the pull request at:

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


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

[jira] [Commented] (GEODE-2217) Add generic type parameter to FunctionContext interface

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2217:


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

GEODE-2217: Add generic type parameter to FunctionContext interface

 * This closes #447


> Add generic type parameter to FunctionContext interface
> ---
>
> Key: GEODE-2217
> URL: https://issues.apache.org/jira/browse/GEODE-2217
> Project: Geode
>  Issue Type: Bug
>  Components: functions
>Reporter: Jared Stewart
>Assignee: Alyssa Kim
>
> FunctionContext has a method getArguments() that returns Object.  It would be 
> nice to have getArguments return a known type instead.
> ```
> public interface FunctionContext  {
>   public T getArguments();
> }
> ```
> The Function interface would then allow users to bound the expected argument 
> type:
> ```
> public interface Function {
>   public void execute(FunctionContext context);
> }
> ```



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

[jira] [Commented] (GEODE-2217) Add generic type parameter to FunctionContext interface

[ASF GitHub Bot (JIRA)]

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

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

Github user asfgit closed the pull request at:

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


> Add generic type parameter to FunctionContext interface
> ---
>
> Key: GEODE-2217
> URL: https://issues.apache.org/jira/browse/GEODE-2217
> Project: Geode
>  Issue Type: Bug
>  Components: functions
>Reporter: Jared Stewart
>Assignee: Alyssa Kim
>
> FunctionContext has a method getArguments() that returns Object.  It would be 
> nice to have getArguments return a known type instead.
> ```
> public interface FunctionContext  {
>   public T getArguments();
> }
> ```
> The Function interface would then allow users to bound the expected argument 
> type:
> ```
> public interface Function {
>   public void execute(FunctionContext context);
> }
> ```



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

[jira] [Resolved] (GEODE-2745) The AsyncEventQueueImpl waitUntilFlushed method waits longer than it should for events to be flushed

[Shelley Lynn Hughes-Godfrey (JIRA)]

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

Shelley Lynn Hughes-Godfrey resolved GEODE-2745.

   Resolution: Fixed
 Assignee: Shelley Lynn Hughes-Godfrey
Fix Version/s: 1.2.0

Fixed on develop:
{noformat}
commit f13da788c8b2d2315581c451154f8e5410b764bc
Author: Lynn Hughes-Godfrey 
Date:   Fri Apr 7 11:57:16 2017 -0700

GEODE-2745: waitUntilFlushed method waits longer than it should

- Added getter in BucketRegionQueue for latestQueuedKey
- WaitUntilBucketRegionQueueFlushedCallable constructor now gets/maintains 
the BucketRegionQueue.latestQueuedKey
{noformat}

> The AsyncEventQueueImpl waitUntilFlushed method waits longer than it should 
> for events to be flushed
> 
>
> Key: GEODE-2745
> URL: https://issues.apache.org/jira/browse/GEODE-2745
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Reporter: Barry Oglesby
>Assignee: Shelley Lynn Hughes-Godfrey
> Fix For: 1.2.0
>
>
> With the changes to waitUntilFlushed to process 10 buckets at a time, if 
> events are happening while waitUntilFlushed is in progress, then all the 
> buckets after the first 10 will have processed more than it should before 
> returning.
> If the update rate is causing the queue to always contain 113000 events, and 
> the events are spread evenly across the buckets, each bucket will have 1000 
> events to wait for. The first 10 buckets will wait for their 1000 events. 
> When those have been processed, the next 10 buckets will wait for their 1000 
> events starting from that point, but they've already processed 1000 events. 
> So, these buckets will actually wait for 2000 events to be processed before 
> returning. This pattern continues until all the buckets are done.
> The WaitUntilBucketRegionQueueFlushedCallable needs to track not only the 
> BucketRegionQueue but also the latestQueuedKey.



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

[jira] [Commented] (GEODE-2745) The AsyncEventQueueImpl waitUntilFlushed method waits longer than it should for events to be flushed

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2745:


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

GEODE-2745: waitUntilFlushed method waits longer than it should

- Added getter in BucketRegionQueue for latestQueuedKey
- WaitUntilBucketRegionQueueFlushedCallable constructor now gets/maintains the 
BucketRegionQueue.latestQueuedKey


> The AsyncEventQueueImpl waitUntilFlushed method waits longer than it should 
> for events to be flushed
> 
>
> Key: GEODE-2745
> URL: https://issues.apache.org/jira/browse/GEODE-2745
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Reporter: Barry Oglesby
>
> With the changes to waitUntilFlushed to process 10 buckets at a time, if 
> events are happening while waitUntilFlushed is in progress, then all the 
> buckets after the first 10 will have processed more than it should before 
> returning.
> If the update rate is causing the queue to always contain 113000 events, and 
> the events are spread evenly across the buckets, each bucket will have 1000 
> events to wait for. The first 10 buckets will wait for their 1000 events. 
> When those have been processed, the next 10 buckets will wait for their 1000 
> events starting from that point, but they've already processed 1000 events. 
> So, these buckets will actually wait for 2000 events to be processed before 
> returning. This pattern continues until all the buckets are done.
> The WaitUntilBucketRegionQueueFlushedCallable needs to track not only the 
> BucketRegionQueue but also the latestQueuedKey.



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

[jira] [Commented] (GEODE-1577) Unhelpful generic types on Execution.execute

[ASF GitHub Bot (JIRA)]

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

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

Github user jhuynh1 commented on the issue:

https://github.com/apache/geode/pull/321
  
I've pulled these changes in.  Had to resolve some conflicts but these 
changes should be in geode now.


> Unhelpful generic types on Execution.execute
> 
>
> Key: GEODE-1577
> URL: https://issues.apache.org/jira/browse/GEODE-1577
> Project: Geode
>  Issue Type: Bug
>  Components: functions
>Reporter: Dan Smith
>
> The execute methods of the function service Execution class returns a 
> ResultCollector with wildcards for the type.
> {code}  
> public ResultCollector execute(
>   Function function) throws FunctionException;
> {code}
> Wildcards are supposed to be used in APIs where the type doesn't matter, for 
> example counting the elements in a list. By returning a ResultCollector with 
> wildcards, we're essentially forcing the user to cast the result collector.
> At a minimum they should be able to pick the type of result collector
> {code}
>   public  ResultCollector execute(
>   Function function) throws FunctionException;
> {code}
> But maybe it would make more sense to parameterize Execution itself. Then the 
> compiler could ensure that the types used by withCollector and the types used 
> by execute match.



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

[GitHub] geode issue #321: [GEODE-1577] Unhelpful generic types on Execution.execute

[jhuynh1]

Github user jhuynh1 commented on the issue:

https://github.com/apache/geode/pull/321
  
I've pulled these changes in.  Had to resolve some conflicts but these 
changes should be in geode now.


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

[jira] [Commented] (GEODE-1577) Unhelpful generic types on Execution.execute

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-1577:


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

GEODE-1577: modified MultiRegionFunctionExecutor to fix compilation error


> Unhelpful generic types on Execution.execute
> 
>
> Key: GEODE-1577
> URL: https://issues.apache.org/jira/browse/GEODE-1577
> Project: Geode
>  Issue Type: Bug
>  Components: functions
>Reporter: Dan Smith
>
> The execute methods of the function service Execution class returns a 
> ResultCollector with wildcards for the type.
> {code}  
> public ResultCollector execute(
>   Function function) throws FunctionException;
> {code}
> Wildcards are supposed to be used in APIs where the type doesn't matter, for 
> example counting the elements in a list. By returning a ResultCollector with 
> wildcards, we're essentially forcing the user to cast the result collector.
> At a minimum they should be able to pick the type of result collector
> {code}
>   public  ResultCollector execute(
>   Function function) throws FunctionException;
> {code}
> But maybe it would make more sense to parameterize Execution itself. Then the 
> compiler could ensure that the types used by withCollector and the types used 
> by execute match.



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

[jira] [Commented] (GEODE-1577) Unhelpful generic types on Execution.execute

[ASF GitHub Bot (JIRA)]

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

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

Github user asfgit closed the pull request at:

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


> Unhelpful generic types on Execution.execute
> 
>
> Key: GEODE-1577
> URL: https://issues.apache.org/jira/browse/GEODE-1577
> Project: Geode
>  Issue Type: Bug
>  Components: functions
>Reporter: Dan Smith
>
> The execute methods of the function service Execution class returns a 
> ResultCollector with wildcards for the type.
> {code}  
> public ResultCollector execute(
>   Function function) throws FunctionException;
> {code}
> Wildcards are supposed to be used in APIs where the type doesn't matter, for 
> example counting the elements in a list. By returning a ResultCollector with 
> wildcards, we're essentially forcing the user to cast the result collector.
> At a minimum they should be able to pick the type of result collector
> {code}
>   public  ResultCollector execute(
>   Function function) throws FunctionException;
> {code}
> But maybe it would make more sense to parameterize Execution itself. Then the 
> compiler could ensure that the types used by withCollector and the types used 
> by execute match.



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

[jira] [Commented] (GEODE-1577) Unhelpful generic types on Execution.execute

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-1577:


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

 GEODE-1577: Unhelpful generic types on Execution.execute

  * Replaced wildcards with  for non-deprecated Execution.execute methods.
  * descriptions added for params  in javadoc
  * explicit type casting removed
  * This closes #321


> Unhelpful generic types on Execution.execute
> 
>
> Key: GEODE-1577
> URL: https://issues.apache.org/jira/browse/GEODE-1577
> Project: Geode
>  Issue Type: Bug
>  Components: functions
>Reporter: Dan Smith
>
> The execute methods of the function service Execution class returns a 
> ResultCollector with wildcards for the type.
> {code}  
> public ResultCollector execute(
>   Function function) throws FunctionException;
> {code}
> Wildcards are supposed to be used in APIs where the type doesn't matter, for 
> example counting the elements in a list. By returning a ResultCollector with 
> wildcards, we're essentially forcing the user to cast the result collector.
> At a minimum they should be able to pick the type of result collector
> {code}
>   public  ResultCollector execute(
>   Function function) throws FunctionException;
> {code}
> But maybe it would make more sense to parameterize Execution itself. Then the 
> compiler could ensure that the types used by withCollector and the types used 
> by execute match.



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

[GitHub] geode pull request #321: [GEODE-1577] Unhelpful generic types on Execution.e...

[asfgit]

Github user asfgit closed the pull request at:

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


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

Re: One class loader vs multiple class loaders for deployed jars

[Anthony Baker]

Agreed.  It’s used by maven but the project itself doesn’t seem very active.

Anthony

> On Apr 12, 2017, at 11:15 AM, Jared Stewart  wrote:
> 
> Anthony - I was never able to find any substantial documentation for Plexus 
> Classworlds.  This makes it both hard to evaluate and potentially scary to 
> use.

Re: One class loader vs multiple class loaders for deployed jars

[Jared Stewart]

I have submitted a review board request for this change, comments and feedback 
are welcome:  https://reviews.apache.org/r/58393/ 
  

I don’t believe it breaks the current expected behavior, and I don’t think it 
will pose any additional barriers to classloader isolation in the future (the 
fast-classpath-scanner library is agnostic about the class loader 
implementation you give to it).  

Anthony - I was never able to find any substantial documentation for Plexus 
Classworlds.  This makes it both hard to evaluate and potentially scary to use.

- Jared

> On Apr 12, 2017, at 8:55 AM, Michael Stolz  wrote:
> 
> +1 for merging the current fix.
> 
> It at least makes it easier to deploy a jar in the happy day scenario.
> I'm not sure how much we should be trying to emulate an application server
> anyway.
> If people really want to combine the cache with the app server they can
> embed Geode into an app server.
> There may be some API sugar that would make that more useful, but it seems
> it's a lot less work than all this classloader stuff we're discussing, and
> would likely yield much better sandboxing.
> 
> --
> Mike Stolz
> Principal Engineer, GemFire Product Manager
> Mobile: +1-631-835-4771
> 
> On Tue, Apr 11, 2017 at 7:46 PM, Jinmei Liao  wrote:
> 
>> I believe with the current fix, we at least do not have the "eager loading"
>> problem anymore. The classloader isolation was a problem before and would
>> remain as a problem after this for further larger scale changes. +1 for
>> merging the fix.
>> 
>> On Tue, Apr 11, 2017 at 4:04 PM, Swapnil Bawaskar 
>> wrote:
>> 
>>> +1 for merging Jared's fix. it gets us closer to fixing classloading in a
>>> later release.
>>> 
>>> On Tue, Apr 11, 2017 at 1:41 PM Jacob Barrett 
>> wrote:
>>> 
 I can support the idea of taking the small step of fixing the eager
>> class
 loading if it doesn't:
 1) break the current expected behavior.
 2) dig is deeper into a hole with class loading isolation in the
>> future.
 
 If it breaks the current expected behavior, that in itself is ok until
>>> you
 consider that adding class loader isolation later will most definitely
 break the expected behavior, can we afford do break it twice?
 
 -Jake
 
 On Tue, Apr 11, 2017 at 10:06 AM Jared Stewart 
 wrote:
 
> I would like to distinguish between the following two objectives:
> 1) Do not eagerly load every class contained in a deployed jar
> 2) Establish robust classloader isolation for deployed jars
> 
> The aim of my current line of work is to fix 1) (GEODE-2290).  This
>> is
 not
> to say that 2) is not a valuable pursuit, but I think getting 2) done
> correctly is a larger task than fixing 1) in isolation.
> 
> To get into the specifics of the libraries you mentioned,
> 
> JCL:
> - JCL has no support for removing/undeploying jars.  In this
>> respect,
>>> I
> don't see anything that JCL would add over simply using a
>>> URLClassLoader.
> We would have to rebuild the JCL class loader in exactly the same set
>>> of
> circumstances that we would need to rebuild a URLClassLoader.
> - I have seen a fair number of warnings from people that JCL is
>> buggy
 and
> incomplete, e.g. (
> 
 http://stackoverflow.com/questions/60764/how-should-i-
>>> load-jars-dynamically-at-runtime#comment43066872_1450837
 )
> This would seem to be supported by a quick look at the github issues
>>> page
> for JCL, which includes things like a bug report of a deadlock from
>> Jun
> 2016 to which the developers have never responded.
> 
> JBoss Modules:
> - JBoss Modules (or Java 9/Jigsaw Modules) seem like a good
>> strategic
> direction towards which to strive.  Yet the fact that they require an
> external module descriptor (XML) would again seem to make this a much
> larger task than 1) alone.  (If the idea here is to have a user
>> provide
 us
> with a JBoss Module rather than a plain jar file, this would be a
>> large
> breaking change for existing users.  On the other hand, if the idea
>> is
 for
> us to autogenerate the necessary metainformation to transform the
>>> user's
> jar file into a JBoss Module, this would seem to be a large task
>> which
>>> is
> again independent from the goals of 1).
> 
> - Jared
> 
>> On Apr 10, 2017, at 9:41 PM, Jacob Barrett 
 wrote:
>> 
>> There are certainly many projects in the OS community that have
>>> solved
> this
>> same problem. Perhaps we can find a class loader from a project
>> that
> would
>> suite this need.
>> 
>> Quick search of standalone frameworks comes up with a few popular
>>> hits:
>> https://github.com/kamranzafar/JCL
>> 

[jira] [Assigned] (GEODE-2773) AssertionError shown in GIIDeltaDUnitTest.testFullGIITriggeredByHigherRVVGC

[Eric Shu (JIRA)]

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

Eric Shu reassigned GEODE-2773:
---

Assignee: Eric Shu

> AssertionError shown in GIIDeltaDUnitTest.testFullGIITriggeredByHigherRVVGC
> ---
>
> Key: GEODE-2773
> URL: https://issues.apache.org/jira/browse/GEODE-2773
> Project: Geode
>  Issue Type: Bug
>  Components: persistence
>Reporter: Eric Shu
>Assignee: Eric Shu
>
> Though the test is passing, the following Assertion was thrown in one of the 
> VM.invokeAysc call.
> {noformat}
> [vm0] [info 2017/04/11 16:42:03.214 PDT  
> tid=72] Got result: EXCEPTION_OCCURRED
> [vm0] java.lang.AssertionError: expected:<5> but was:<6>
> [vm0] at org.junit.Assert.fail(Assert.java:88)
> [vm0] at org.junit.Assert.failNotEquals(Assert.java:834)
> [vm0] at org.junit.Assert.assertEquals(Assert.java:645)
> [vm0] at org.junit.Assert.assertEquals(Assert.java:631)
> [vm0] at 
> org.apache.geode.internal.cache.GIIDeltaDUnitTest$55.run(GIIDeltaDUnitTest.java:2587)
> [vm0] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [vm0] at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [vm0] at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [vm0] at java.lang.reflect.Method.invoke(Method.java:498)
> [vm0] at hydra.MethExecutor.executeObject(MethExecutor.java:245)
> [vm0] at 
> org.apache.geode.test.dunit.standalone.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:73)
> [vm0] at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
> [vm0] at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [vm0] at java.lang.reflect.Method.invoke(Method.java:498)
> [vm0] at 
> sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:324)
> [vm0] at sun.rmi.transport.Transport$1.run(Transport.java:200)
> [vm0] at sun.rmi.transport.Transport$1.run(Transport.java:197)
> [vm0] at java.security.AccessController.doPrivileged(Native Method)
> [vm0] at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
> [vm0] at 
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:568)
> [vm0] at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:826)
> [vm0] at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:683)
> [vm0] at java.security.AccessController.doPrivileged(Native Method)
> [vm0] at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:682)
> [vm0] at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [vm0] at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [vm0] at java.lang.Thread.run(Thread.java:745)
> [vm0]  from org.apache.geode.internal.cache.GIIDeltaDUnitTest$55.run with 0 
> args on object: "destroy key5" (took 682 ms)
> {noformat}



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

Review Request 58393: GEODE-2686: Remove JarClassLoader

[Jared Stewart]

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

Review request for geode, Jinmei Liao, Ken Howe, Kirk Lund, and Patrick 
Rhomberg.


Repository: geode


Description
---

GEODE-2686: Remove JarClassLoader
- Remove JarClassLoader
- Replace ClassPathLoader's collection of JarClassLoaders with a single 
URLClassLoader
- Change naming scheme for deployed jars from 'vf.gf#myJar.jar#1' to 
'myJar.v1.jar'

GEODE-2705: Jars undeployed from cluster configuration will not be loaded from 
disk on member restart

GEODE-2686: Add more logging to JarDeployer

GEODE-2290: Limit scanning of deployed jars
- Uses fast-classpath-scanner to scan jars for classes containing Functions 
without eagerly loading all classes in the jar.


Diffs
-

  geode-assembly/build.gradle 304a1c4d7ede5b82299c8a0f05038f3d11b2ac82 
  geode-assembly/src/test/resources/expected_jars.txt 
b7d1dc22fd7995e6f7786984994ce62e1064bed3 
  geode-core/build.gradle 757599a9d76844dec17e545d1b4d19b32c22afef 
  geode-core/src/main/java/org/apache/geode/internal/ClassPathLoader.java 
9ab7c308579c9ea5c8fb300ee7550b3153507b1c 
  geode-core/src/main/java/org/apache/geode/internal/DeployedJar.java 
PRE-CREATION 
  
geode-core/src/main/java/org/apache/geode/internal/InternalDataSerializer.java 
f4f40692d1574bb9eca9bf8f7d42ce64fab18f9b 
  geode-core/src/main/java/org/apache/geode/internal/JarClassLoader.java 
9cd05899898fc82eec87a3f0ab5ace31b67ef308 
  geode-core/src/main/java/org/apache/geode/internal/JarDeployer.java 
18d4b42213f29761792d35f12eddfb1cbfbba081 
  
geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java
 f904af188eb295f1cb84e41023de168c160ed07f 
  
geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java 
08f916b117a07ed303638366c64a2c9d5b807b91 
  
geode-core/src/main/java/org/apache/geode/internal/cache/persistence/BackupManager.java
 d052551d85e5b01b16255160f76795e829a14429 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/DeployFunction.java
 5f1f16167e08dd79b299c42541fb01ee2546 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/ListDeployedFunction.java
 8df24dbe35a08173932776226c9f20665db5e9a3 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/UndeployFunction.java
 3f0508270b51b4930c2eafe15547b9b258b96bd9 
  
geode-core/src/test/java/org/apache/geode/internal/ClassPathLoaderIntegrationTest.java
 c52d5754792cfeaed1bb87bdb9380a360308395a 
  geode-core/src/test/java/org/apache/geode/internal/ClassPathLoaderTest.java 
6baddaf4b9d3b58fce10fc224440111c2e88b849 
  geode-core/src/test/java/org/apache/geode/internal/DeployedJarJUnitTest.java 
PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/internal/JarClassLoaderJUnitTest.java 
adc1d2eb2b633d4c81076db2b4685fedb6315913 
  geode-core/src/test/java/org/apache/geode/internal/JarDeployerDUnitTest.java 
a365899c46bb7f28ce75118e45137a243493cbd0 
  
geode-core/src/test/java/org/apache/geode/internal/JarDeployerIntegrationTest.java
 71daeccc42e7944f01ce50d94fc3c4afc5c9b121 
  
geode-core/src/test/java/org/apache/geode/internal/cache/IncrementalBackupDUnitTest.java
 0cc003ebd15628ea62a67a36c1ac595fe0a02693 
  geode-core/src/test/java/org/apache/geode/management/DeployJarTestSuite.java 
PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/DeployCommandRedeployDUnitTest.java
 PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/DeployCommandsDUnitTest.java
 7b0823bea38043967502e0accee90963d5d7b650 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/UserCommandsDUnitTest.java
 24f5cdb549fbc172e12f965044681e83f11b5829 
  
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfig.java
 c3d7f5ec2483b4ae28f73e3b3477180d20b1a53e 
  
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigBaseTest.java
 cecc8cfd683a2fb24d621c9010d5650ef2996966 
  
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigDeployJarDUnitTest.java
 7cc84d6c4417872daf9a13ea5f237e458cafe154 
  
geode-core/src/test/java/org/apache/geode/test/dunit/rules/GfshShellConnectionRule.java
 02bad30e97f0a3550eac0bf00ce0c6833d761dae 
  
geode-web/src/test/java/org/apache/geode/management/internal/cli/commands/CommandOverHttpDUnitTest.java
 5f4cd74b8af81ae3bbeff04d6ce44a5c4ac9ec59 


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


Testing
---

-Precheckin started (still running)
-Manually deployed jars and executed functions via gfsh


Thanks,

Jared Stewart

[jira] [Created] (GEODE-2776) The version tag on client event is not updated when an entry is added to server using load operation.

[Anilkumar Gingade (JIRA)]

Anilkumar Gingade created GEODE-2776:


 Summary: The version tag on client event is not updated when an 
entry is added to server using load operation.
 Key: GEODE-2776
 URL: https://issues.apache.org/jira/browse/GEODE-2776
 Project: Geode
  Issue Type: Bug
  Components: regions
Reporter: Anilkumar Gingade


When client does a get() which results in adding an entry by calling loader on 
server side, the client event returned back is not updated with the version tag 
that is created with the new entry on server. This results in client having a 
different version tag than the server side entry. If client has registered 
event, and is concurrently updating the entry (from get() call and an 
register-event from server), it could result in data consistency between client 
and server.

Scenario 1:
On Server invalidate happens, and the event is added to client queue.
Client does get()
On Server, the get() triggers load + put on server. And the response is sent 
back.
Client gets the result from get() (which is newer) and applies to its cache.
Client gets invalid event (older than get), and it applies the event to the 
cache (this is supposed to be conflated, but due to this bug its not conflated).
At the end server has valid entry in the cache but client has invalid entry.

On Server: INVALID (First), Get(From Client, LOAD+PUT) (later)
On Client: GET(), PUT using Get Response(), INVALID (old)

Scenario 2:
Client does get()
On Server, the get() triggers load + put on server. And the response is sent 
back.
On Server invalidate happens, and the event is added to client queue.
Client gets invalid event, and it applies the event to the cache.
Client gets the result from get() (which is older than invalidate) and applies 
to its cache (this is supposed to be conflated, but due to this bug its not 
conflated).
At the end server has invalid entry in the cache but client has valid entry 
(old value).
On Server: Get(From Client, LOAD+PUT), INVALID (later)
On Client: GET() (new), INVALID (old), PUT using Get Response().



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

Re: Review Request 58391: GEODE-2193 Now we don't send view if shutdown process is started.

[Bruce Schuchardt]

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


Ship it!




Ship It!

- Bruce Schuchardt


On April 12, 2017, 5:34 p.m., Hitesh Khamesra wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58391/
> ---
> 
> (Updated April 12, 2017, 5:34 p.m.)
> 
> 
> Review request for geode and Bruce Schuchardt.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Earlier we were checking flag, which was set after sending the shutdown
> message. Now we check flag, which was set before sending the shutdown
> message.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionManager.java
>  3efbafc 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/interfaces/Manager.java
>  3fe8cc1 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/membership/GMSJoinLeave.java
>  e4066ef 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/mgr/GMSMembershipManager.java
>  0180ddb 
> 
> 
> Diff: https://reviews.apache.org/r/58391/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Hitesh Khamesra
> 
>

Review Request 58391: GEODE-2193 Now we don't send view if shutdown process is started.

[Hitesh Khamesra]

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

Review request for geode and Bruce Schuchardt.


Repository: geode


Description
---

Earlier we were checking flag, which was set after sending the shutdown
message. Now we check flag, which was set before sending the shutdown
message.


Diffs
-

  
geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionManager.java
 3efbafc 
  
geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/interfaces/Manager.java
 3fe8cc1 
  
geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/membership/GMSJoinLeave.java
 e4066ef 
  
geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/mgr/GMSMembershipManager.java
 0180ddb 


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


Testing
---


Thanks,

Hitesh Khamesra

Re: Build failed in Jenkins: Geode-nightly #805

[Kenneth Howe]

See discussion in https://issues.apache.org/jira/browse/GEODE-2647 


> On Apr 12, 2017, at 9:31 AM, Apache Jenkins Server 
>  wrote:
> 
> See 
> 
> 
> Changes:
> 
> [gosullivan] Fix a repetition in the README.
> 
> [jiliao] GEODE-1274: Migration from PulseLogWriter to Log4j standard and 
> removal
> 
> [jiliao] GEODE-2767: Added DUnitTests to validate export log options --group 
> and
> 
> [dschneider] Revert "GEODE-2485: fix leak in tx suspend/resume"
> 
> [klund] GEODE-2765: change gfsh help to consistently use log4j levels
> 
> [dschneider] GEODE-2485: fix leak in tx suspend/resume
> 
> --
> [...truncated 101.04 KB...]
>at org.apache.geode.test.dunit.VM.invoke(VM.java:292)
>at 
> org.apache.geode.management.ClientHealthStatsDUnitTest.testClientHealthStats_SubscriptionEnabled(ClientHealthStatsDUnitTest.java:128)
> 
>Caused by:
>java.lang.NullPointerException
>at 
> org.apache.geode.management.ClientHealthStatsDUnitTest.put(ClientHealthStatsDUnitTest.java:377)
>at 
> org.apache.geode.management.ClientHealthStatsDUnitTest.lambda$testClientHealthStats_SubscriptionEnabled$bb17a952$2(ClientHealthStatsDUnitTest.java:128)
> 
> 6854 tests completed, 2 failed, 603 skipped
> :geode-core:distributedTest FAILED
> :geode-core:flakyTest
> :geode-core:integrationTest
> :geode-cq:assemble
> :geode-cq:compileTestJavaNote: Some input files use or override a deprecated 
> API.
> Note: Recompile with -Xlint:deprecation for details.
> Note: Some input files use unchecked or unsafe operations.
> Note: Recompile with -Xlint:unchecked for details.
> 
> :geode-cq:processTestResources
> :geode-cq:testClasses
> :geode-cq:checkMissedTests
> :geode-cq:spotlessJavaCheck
> :geode-cq:spotlessCheck
> :geode-cq:test
> :geode-cq:check
> :geode-cq:build
> :geode-cq:distributedTest
> :geode-cq:flakyTest
> :geode-cq:integrationTest
> :geode-json:assemble
> :geode-json:compileTestJava UP-TO-DATE
> :geode-json:processTestResources
> :geode-json:testClasses
> :geode-json:checkMissedTests UP-TO-DATE
> :geode-json:spotlessJavaCheck
> :geode-json:spotlessCheck
> :geode-json:test UP-TO-DATE
> :geode-json:check
> :geode-json:build
> :geode-json:distributedTest UP-TO-DATE
> :geode-json:flakyTest UP-TO-DATE
> :geode-json:integrationTest UP-TO-DATE
> :geode-junit:javadoc
> :geode-junit:javadocJar
> :geode-junit:sourcesJar
> :geode-junit:signArchives SKIPPED
> :geode-junit:assemble
> :geode-junit:compileTestJava
> :geode-junit:processTestResources UP-TO-DATE
> :geode-junit:testClasses
> :geode-junit:checkMissedTests
> :geode-junit:spotlessJavaCheck
> :geode-junit:spotlessCheck
> :geode-junit:test
> :geode-junit:check
> :geode-junit:build
> :geode-junit:distributedTest
> :geode-junit:flakyTest
> :geode-junit:integrationTest
> :geode-lucene:assemble
> :geode-lucene:compileTestJavaNote: Some input files use or override a 
> deprecated API.
> Note: Recompile with -Xlint:deprecation for details.
> Note: Some input files use unchecked or unsafe operations.
> Note: Recompile with -Xlint:unchecked for details.
> 
> :geode-lucene:processTestResources
> :geode-lucene:testClasses
> :geode-lucene:checkMissedTests
> :geode-lucene:spotlessJavaCheck
> :geode-lucene:spotlessCheck
> :geode-lucene:test
> :geode-lucene:check
> :geode-lucene:build
> :geode-lucene:distributedTest
> :geode-lucene:flakyTest
> :geode-lucene:integrationTest
> :geode-old-client-support:assemble
> :geode-old-client-support:compileTestJava
> :geode-old-client-support:processTestResources UP-TO-DATE
> :geode-old-client-support:testClasses
> :geode-old-client-support:checkMissedTests
> :geode-old-client-support:spotlessJavaCheck
> :geode-old-client-support:spotlessCheck
> :geode-old-client-support:test
> :geode-old-client-support:check
> :geode-old-client-support:build
> :geode-old-client-support:distributedTest
> :geode-old-client-support:flakyTest
> :geode-old-client-support:integrationTest
> :geode-old-versions:javadoc UP-TO-DATE
> :geode-old-versions:javadocJar
> :geode-old-versions:sourcesJar
> :geode-old-versions:signArchives SKIPPED
> :geode-old-versions:assemble
> :geode-old-versions:compileTestJava UP-TO-DATE
> :geode-old-versions:processTestResources UP-TO-DATE
> :geode-old-versions:testClasses UP-TO-DATE
> :geode-old-versions:checkMissedTests UP-TO-DATE
> :geode-old-versions:spotlessJavaCheck
> :geode-old-versions:spotlessCheck
> :geode-old-versions:test UP-TO-DATE
> :geode-old-versions:check
> :geode-old-versions:build
> :geode-old-versions:distributedTest UP-TO-DATE
> :geode-old-versions:flakyTest UP-TO-DATE
> :geode-old-versions:integrationTest UP-TO-DATE
> :geode-pulse:assemble
> :geode-pulse:compileTestJavaNote: 
> 

[jira] [Resolved] (GEODE-2737) PulseAuthTest failures

[Kenneth Howe (JIRA)]

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

Kenneth Howe resolved GEODE-2737.
-
   Resolution: Fixed
Fix Version/s: 1.2.0

commit 3a64b57ce433c7ed7ed0923af0d3c5811d0d4169

> PulseAuthTest failures
> --
>
> Key: GEODE-2737
> URL: https://issues.apache.org/jira/browse/GEODE-2737
> Project: Geode
>  Issue Type: Bug
>  Components: pulse
>Affects Versions: 1.1.0
>Reporter: Kenneth Howe
>Assignee: Kenneth Howe
> Fix For: 1.2.0
>
>
> Tests are failing in the PulseAuthTest (UITest category) with the error:
> {code}
> org.apache.geode.tools.pulse.tests.ui.PulseAuthTest > testTopologyPopUpData 
> FAILED
> org.openqa.selenium.TimeoutException: Expected condition failed: waiting 
> for org.apache.geode.tools.pulse.tests.rules.WebDriverRule$1@4d7af88e (tried 
> for 30 second(s) with 500 MILLISECONDS interval)
> Build info: version: '3.0.1', revision: '1969d75', time: '2016-10-18 
> 09:49:13 -0700'
> System info: host: 'Kens-MacBook-Pro-2.local', ip: '127.0.0.1', os.name: 
> 'Mac OS X', os.arch: 'x86_64', os.version: '10.12.3', java.version: 
> '1.8.0_111'
> Driver info: org.openqa.selenium.phantomjs.PhantomJSDriver
> Capabilities [{applicationCacheEnabled=false, rotatable=false, 
> handlesAlerts=false, databaseEnabled=false, version=2.1.1, platform=MAC, 
> browserConnectionEnabled=false, proxy={proxyType=direct}, nativeEvents=true, 
> acceptSslCerts=false, driverVersion=1.2.0, 
> phantomjs.page.settings.userAgent=Mozilla/5.0 (Windows NT 6.1; Win64; x64; 
> rv:16.0) Gecko/20121026 Firefox/16.0, locationContextEnabled=false, 
> webStorageEnabled=false, browserName=phantomjs, takesScreenshot=true, 
> driverName=ghostdriver, javascriptEnabled=true, cssSelectorsEnabled=true}]
> Session ID: abd2bc60-1593-11e7-922e-d790ba7a8581
> Caused by:
> org.openqa.selenium.NoSuchElementException: {"errorMessage":"Unable 
> to find element with id 
> 'userName'","request":{"headers":{"Accept-Encoding":"gzip,deflate","Connection":"Keep-Alive","Content-Length":"33","Content-Type":"application/json;
>  
> charset=utf-8","Host":"localhost:43794","User-Agent":"Apache-HttpClient/4.5.2 
> (Java/1.8.0_111)"},"httpVersion":"1.1","method":"POST","post":"{\"using\":\"id\",\"value\":\"userName\"}","url":"/element","urlParsed":{"anchor":"","query":"","file":"element","directory":"/","path":"/element","relative":"/element","port":"","host":"","password":"","user":"","userInfo":"","authority":"","protocol":"","source":"/element","queryKey":{},"chunks":["element"]},"urlOriginal":"/session/abd2bc60-1593-11e7-922e-d790ba7a8581/element"}}
> Command duration or timeout: 10.13 seconds
> For documentation on this error, please visit: 
> http://seleniumhq.org/exceptions/no_such_element.html
> Build info: version: '3.0.1', revision: '1969d75', time: '2016-10-18 
> 09:49:13 -0700'
> System info: host: 'Kens-MacBook-Pro-2.local', ip: '127.0.0.1', 
> os.name: 'Mac OS X', os.arch: 'x86_64', os.version: '10.12.3', java.version: 
> '1.8.0_111'
> Driver info: org.openqa.selenium.phantomjs.PhantomJSDriver
> Capabilities [{applicationCacheEnabled=false, rotatable=false, 
> handlesAlerts=false, databaseEnabled=false, version=2.1.1, platform=MAC, 
> browserConnectionEnabled=false, proxy={proxyType=direct}, nativeEvents=true, 
> acceptSslCerts=false, driverVersion=1.2.0, 
> phantomjs.page.settings.userAgent=Mozilla/5.0 (Windows NT 6.1; Win64; x64; 
> rv:16.0) Gecko/20121026 Firefox/16.0, locationContextEnabled=false, 
> webStorageEnabled=false, browserName=phantomjs, takesScreenshot=true, 
> driverName=ghostdriver, javascriptEnabled=true, cssSelectorsEnabled=true}]
> Session ID: abd2bc60-1593-11e7-922e-d790ba7a8581
> *** Element info: {Using=id, value=userName}
> Caused by:
> org.openqa.selenium.remote.ScreenshotException: Screen shot has 
> been taken
> Build info: version: '3.0.1', revision: '1969d75', time: 
> '2016-10-18 09:49:13 -0700'
> System info: host: 'Kens-MacBook-Pro-2.local', ip: '127.0.0.1', 
> os.name: 'Mac OS X', os.arch: 'x86_64', os.version: '10.12.3', java.version: 
> '1.8.0_111'
> Driver info: driver.version: RemoteWebDriver
> Caused by:
> org.openqa.selenium.NoSuchElementException: 
> {"errorMessage":"Unable to find element with id 
> 'userName'","request":{"headers":{"Accept-Encoding":"gzip,deflate","Connection":"Keep-Alive","Content-Length":"33","Content-Type":"application/json;
>  
> charset=utf-8","Host":"localhost:43794","User-Agent":"Apache-HttpClient/4.5.2 
> 

[jira] [Assigned] (GEODE-2737) PulseAuthTest failures

[Kenneth Howe (JIRA)]

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

Kenneth Howe reassigned GEODE-2737:
---

Assignee: Kenneth Howe

> PulseAuthTest failures
> --
>
> Key: GEODE-2737
> URL: https://issues.apache.org/jira/browse/GEODE-2737
> Project: Geode
>  Issue Type: Bug
>  Components: pulse
>Affects Versions: 1.1.0
>Reporter: Kenneth Howe
>Assignee: Kenneth Howe
>
> Tests are failing in the PulseAuthTest (UITest category) with the error:
> {code}
> org.apache.geode.tools.pulse.tests.ui.PulseAuthTest > testTopologyPopUpData 
> FAILED
> org.openqa.selenium.TimeoutException: Expected condition failed: waiting 
> for org.apache.geode.tools.pulse.tests.rules.WebDriverRule$1@4d7af88e (tried 
> for 30 second(s) with 500 MILLISECONDS interval)
> Build info: version: '3.0.1', revision: '1969d75', time: '2016-10-18 
> 09:49:13 -0700'
> System info: host: 'Kens-MacBook-Pro-2.local', ip: '127.0.0.1', os.name: 
> 'Mac OS X', os.arch: 'x86_64', os.version: '10.12.3', java.version: 
> '1.8.0_111'
> Driver info: org.openqa.selenium.phantomjs.PhantomJSDriver
> Capabilities [{applicationCacheEnabled=false, rotatable=false, 
> handlesAlerts=false, databaseEnabled=false, version=2.1.1, platform=MAC, 
> browserConnectionEnabled=false, proxy={proxyType=direct}, nativeEvents=true, 
> acceptSslCerts=false, driverVersion=1.2.0, 
> phantomjs.page.settings.userAgent=Mozilla/5.0 (Windows NT 6.1; Win64; x64; 
> rv:16.0) Gecko/20121026 Firefox/16.0, locationContextEnabled=false, 
> webStorageEnabled=false, browserName=phantomjs, takesScreenshot=true, 
> driverName=ghostdriver, javascriptEnabled=true, cssSelectorsEnabled=true}]
> Session ID: abd2bc60-1593-11e7-922e-d790ba7a8581
> Caused by:
> org.openqa.selenium.NoSuchElementException: {"errorMessage":"Unable 
> to find element with id 
> 'userName'","request":{"headers":{"Accept-Encoding":"gzip,deflate","Connection":"Keep-Alive","Content-Length":"33","Content-Type":"application/json;
>  
> charset=utf-8","Host":"localhost:43794","User-Agent":"Apache-HttpClient/4.5.2 
> (Java/1.8.0_111)"},"httpVersion":"1.1","method":"POST","post":"{\"using\":\"id\",\"value\":\"userName\"}","url":"/element","urlParsed":{"anchor":"","query":"","file":"element","directory":"/","path":"/element","relative":"/element","port":"","host":"","password":"","user":"","userInfo":"","authority":"","protocol":"","source":"/element","queryKey":{},"chunks":["element"]},"urlOriginal":"/session/abd2bc60-1593-11e7-922e-d790ba7a8581/element"}}
> Command duration or timeout: 10.13 seconds
> For documentation on this error, please visit: 
> http://seleniumhq.org/exceptions/no_such_element.html
> Build info: version: '3.0.1', revision: '1969d75', time: '2016-10-18 
> 09:49:13 -0700'
> System info: host: 'Kens-MacBook-Pro-2.local', ip: '127.0.0.1', 
> os.name: 'Mac OS X', os.arch: 'x86_64', os.version: '10.12.3', java.version: 
> '1.8.0_111'
> Driver info: org.openqa.selenium.phantomjs.PhantomJSDriver
> Capabilities [{applicationCacheEnabled=false, rotatable=false, 
> handlesAlerts=false, databaseEnabled=false, version=2.1.1, platform=MAC, 
> browserConnectionEnabled=false, proxy={proxyType=direct}, nativeEvents=true, 
> acceptSslCerts=false, driverVersion=1.2.0, 
> phantomjs.page.settings.userAgent=Mozilla/5.0 (Windows NT 6.1; Win64; x64; 
> rv:16.0) Gecko/20121026 Firefox/16.0, locationContextEnabled=false, 
> webStorageEnabled=false, browserName=phantomjs, takesScreenshot=true, 
> driverName=ghostdriver, javascriptEnabled=true, cssSelectorsEnabled=true}]
> Session ID: abd2bc60-1593-11e7-922e-d790ba7a8581
> *** Element info: {Using=id, value=userName}
> Caused by:
> org.openqa.selenium.remote.ScreenshotException: Screen shot has 
> been taken
> Build info: version: '3.0.1', revision: '1969d75', time: 
> '2016-10-18 09:49:13 -0700'
> System info: host: 'Kens-MacBook-Pro-2.local', ip: '127.0.0.1', 
> os.name: 'Mac OS X', os.arch: 'x86_64', os.version: '10.12.3', java.version: 
> '1.8.0_111'
> Driver info: driver.version: RemoteWebDriver
> Caused by:
> org.openqa.selenium.NoSuchElementException: 
> {"errorMessage":"Unable to find element with id 
> 'userName'","request":{"headers":{"Accept-Encoding":"gzip,deflate","Connection":"Keep-Alive","Content-Length":"33","Content-Type":"application/json;
>  
> charset=utf-8","Host":"localhost:43794","User-Agent":"Apache-HttpClient/4.5.2 
> 

[jira] [Resolved] (GEODE-2694) RECOVERED_FROM_DISK bit is cleared during gii, but should be restored if the recovered entry and gii entry has the same version tag

[Eric Shu (JIRA)]

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

Eric Shu resolved GEODE-2694.
-
Resolution: Not A Bug

> RECOVERED_FROM_DISK bit is cleared during gii, but should be restored if the 
> recovered entry and gii entry has the same version tag
> ---
>
> Key: GEODE-2694
> URL: https://issues.apache.org/jira/browse/GEODE-2694
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Eric Shu
>Assignee: Eric Shu
>
> Currently for all gii entries, product clears the RECOVERED_FROM_DISK bit for 
> DiskEntry. However, if entry comes from gii has the same version as recovered 
> entry, the RECOVERED_FROM_DISK bit should be restored but does not.
> {noformat}
> synchronized (re) { // fixes bug 41409
>   if (dr.testIsRecoveredAndClear(re)) {
> wasRecovered = true;
> if (tmpValue == null) {
>   tmpValue = entry.isLocalInvalid() ? Token.LOCAL_INVALID : 
> Token.INVALID;
> }
> // Compare the version stamps, and if they are equal
> // we can skip adding the entry we receive as part of GII.
> VersionStamp stamp = re.getVersionStamp();
> boolean entriesEqual = stamp != null && 
> stamp.asVersionTag().equals(tag);
> // If the received entry and what we have in the cache
> // actually are equal, keep don't put the received
> // entry into the cache (this avoids writing a record to disk)
> if (entriesEqual) {
>   continue;
> }
> {noformat}



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

[jira] [Commented] (GEODE-2737) PulseAuthTest failures

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2737:


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

GEODE-2737: Change Pulse UI tests to use random port for JMX connections

Renamed parameter port to jmxPort in Server.java to clarify usage.


> PulseAuthTest failures
> --
>
> Key: GEODE-2737
> URL: https://issues.apache.org/jira/browse/GEODE-2737
> Project: Geode
>  Issue Type: Bug
>  Components: pulse
>Affects Versions: 1.1.0
>Reporter: Kenneth Howe
>
> Tests are failing in the PulseAuthTest (UITest category) with the error:
> {code}
> org.apache.geode.tools.pulse.tests.ui.PulseAuthTest > testTopologyPopUpData 
> FAILED
> org.openqa.selenium.TimeoutException: Expected condition failed: waiting 
> for org.apache.geode.tools.pulse.tests.rules.WebDriverRule$1@4d7af88e (tried 
> for 30 second(s) with 500 MILLISECONDS interval)
> Build info: version: '3.0.1', revision: '1969d75', time: '2016-10-18 
> 09:49:13 -0700'
> System info: host: 'Kens-MacBook-Pro-2.local', ip: '127.0.0.1', os.name: 
> 'Mac OS X', os.arch: 'x86_64', os.version: '10.12.3', java.version: 
> '1.8.0_111'
> Driver info: org.openqa.selenium.phantomjs.PhantomJSDriver
> Capabilities [{applicationCacheEnabled=false, rotatable=false, 
> handlesAlerts=false, databaseEnabled=false, version=2.1.1, platform=MAC, 
> browserConnectionEnabled=false, proxy={proxyType=direct}, nativeEvents=true, 
> acceptSslCerts=false, driverVersion=1.2.0, 
> phantomjs.page.settings.userAgent=Mozilla/5.0 (Windows NT 6.1; Win64; x64; 
> rv:16.0) Gecko/20121026 Firefox/16.0, locationContextEnabled=false, 
> webStorageEnabled=false, browserName=phantomjs, takesScreenshot=true, 
> driverName=ghostdriver, javascriptEnabled=true, cssSelectorsEnabled=true}]
> Session ID: abd2bc60-1593-11e7-922e-d790ba7a8581
> Caused by:
> org.openqa.selenium.NoSuchElementException: {"errorMessage":"Unable 
> to find element with id 
> 'userName'","request":{"headers":{"Accept-Encoding":"gzip,deflate","Connection":"Keep-Alive","Content-Length":"33","Content-Type":"application/json;
>  
> charset=utf-8","Host":"localhost:43794","User-Agent":"Apache-HttpClient/4.5.2 
> (Java/1.8.0_111)"},"httpVersion":"1.1","method":"POST","post":"{\"using\":\"id\",\"value\":\"userName\"}","url":"/element","urlParsed":{"anchor":"","query":"","file":"element","directory":"/","path":"/element","relative":"/element","port":"","host":"","password":"","user":"","userInfo":"","authority":"","protocol":"","source":"/element","queryKey":{},"chunks":["element"]},"urlOriginal":"/session/abd2bc60-1593-11e7-922e-d790ba7a8581/element"}}
> Command duration or timeout: 10.13 seconds
> For documentation on this error, please visit: 
> http://seleniumhq.org/exceptions/no_such_element.html
> Build info: version: '3.0.1', revision: '1969d75', time: '2016-10-18 
> 09:49:13 -0700'
> System info: host: 'Kens-MacBook-Pro-2.local', ip: '127.0.0.1', 
> os.name: 'Mac OS X', os.arch: 'x86_64', os.version: '10.12.3', java.version: 
> '1.8.0_111'
> Driver info: org.openqa.selenium.phantomjs.PhantomJSDriver
> Capabilities [{applicationCacheEnabled=false, rotatable=false, 
> handlesAlerts=false, databaseEnabled=false, version=2.1.1, platform=MAC, 
> browserConnectionEnabled=false, proxy={proxyType=direct}, nativeEvents=true, 
> acceptSslCerts=false, driverVersion=1.2.0, 
> phantomjs.page.settings.userAgent=Mozilla/5.0 (Windows NT 6.1; Win64; x64; 
> rv:16.0) Gecko/20121026 Firefox/16.0, locationContextEnabled=false, 
> webStorageEnabled=false, browserName=phantomjs, takesScreenshot=true, 
> driverName=ghostdriver, javascriptEnabled=true, cssSelectorsEnabled=true}]
> Session ID: abd2bc60-1593-11e7-922e-d790ba7a8581
> *** Element info: {Using=id, value=userName}
> Caused by:
> org.openqa.selenium.remote.ScreenshotException: Screen shot has 
> been taken
> Build info: version: '3.0.1', revision: '1969d75', time: 
> '2016-10-18 09:49:13 -0700'
> System info: host: 'Kens-MacBook-Pro-2.local', ip: '127.0.0.1', 
> os.name: 'Mac OS X', os.arch: 'x86_64', os.version: '10.12.3', java.version: 
> '1.8.0_111'
> Driver info: driver.version: RemoteWebDriver
> Caused by:
> org.openqa.selenium.NoSuchElementException: 
> {"errorMessage":"Unable to find element with id 
> 'userName'","request":{"headers":{"Accept-Encoding":"gzip,deflate","Connection":"Keep-Alive","Content-Length":"33","Content-Type":"application/json;
>  
> 

[jira] [Commented] (GEODE-2694) RECOVERED_FROM_DISK bit is cleared during gii, but should be restored if the recovered entry and gii entry has the same version tag

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2694:


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

GEODE-2694: Add test coverage on RECOVERED_FROM_DISK bit after gii.


> RECOVERED_FROM_DISK bit is cleared during gii, but should be restored if the 
> recovered entry and gii entry has the same version tag
> ---
>
> Key: GEODE-2694
> URL: https://issues.apache.org/jira/browse/GEODE-2694
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Eric Shu
>Assignee: Eric Shu
>
> Currently for all gii entries, product clears the RECOVERED_FROM_DISK bit for 
> DiskEntry. However, if entry comes from gii has the same version as recovered 
> entry, the RECOVERED_FROM_DISK bit should be restored but does not.
> {noformat}
> synchronized (re) { // fixes bug 41409
>   if (dr.testIsRecoveredAndClear(re)) {
> wasRecovered = true;
> if (tmpValue == null) {
>   tmpValue = entry.isLocalInvalid() ? Token.LOCAL_INVALID : 
> Token.INVALID;
> }
> // Compare the version stamps, and if they are equal
> // we can skip adding the entry we receive as part of GII.
> VersionStamp stamp = re.getVersionStamp();
> boolean entriesEqual = stamp != null && 
> stamp.asVersionTag().equals(tag);
> // If the received entry and what we have in the cache
> // actually are equal, keep don't put the received
> // entry into the cache (this avoids writing a record to disk)
> if (entriesEqual) {
>   continue;
> }
> {noformat}



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

Re: Review Request 58388: GEODE-2730: refactor rules

[Ken Howe]

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



Reviewed the first page of diffs


geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestServersJUnitTest.java
Lines 41 (patched)


A symbolic constant would be better than a hardcoded "magic number" (i.e. a 
constant without explanation.) DEFAULT_HTTP_SERVICE_PORT is defined in 
geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionConfig.java.
 RestInterfaceJUnitTest defines its own DEFAULT_HTTP_SERVICE_PORT. Consistency 
would be good.



geode-assembly/src/test/java/org/apache/geode/test/dunit/rules/EmbeddedPulseRule.java
Lines 21 (patched)


Basic "how to use" javadocs on the Rule classes would be a big help for 
developing new tests. I think one problem with consistent use of our rules is a 
lack of understanding how they are intended to be used. Adoption of rules seems 
to have been somewhat haphazard up to now.

This commnent applies to all our rules, not just this one.


- Ken Howe


On April 12, 2017, 3:08 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58388/
> ---
> 
> (Updated April 12, 2017, 3:08 p.m.)
> 
> 
> Review request for geode, Jared Stewart, Ken Howe, Kirk Lund, and Patrick 
> Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> * consolidated the two sets of rules.
> * do not allow member start up at test initialization time.
> * validate properties in @Before
> * use provider in the chained rules to get the appropriate ports in @Before
> 
> Jared and I tried to use ServerLauncher/LocatorLauncher to start the 
> respective member in the rules, but precheckin yields many failures. Looks 
> like it has two problems:
> 1) by passing in the workingDir in the launcher alone does not make all the 
> logs go there. I still have to set the user.dir env variable to make some 
> tests pass.
> 2) launcher.stop does not stop the cache/locator/server cleanly. Subsequent 
> tests fail due to insufficient cleanup.
> Due to the above two reasons, I reverted back to use the old way to start 
> server/locator. This looks like a lean and mean way to get what we needed.
> 
> We also investigated the use of Builder in the rules. At least for now, it 
> doesn't buy us much since we need to do validation/startup servers in @Before 
> of the rules. And it yeilds some duplication code and make the usage not that 
> intuitive.
> 
> As for using AvailablePort.Keeper, Jared and I found out it doesn't really 
> keep the ports, so revert that back as well.
> 
> 
> Diffs
> -
> 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityIntegrationTest.java
>  cbd83e382116dcfc06b0199b69bf91486be22f06 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityPostProcessorTest.java
>  e93561c0b5fc4fa7f89c03ff4055515d6bbb21be 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityWithSSLTest.java
>  14113c06532d42833ee67f4fbf97ba24d535f2d3 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestServersJUnitTest.java
>  2a3a036782fbde22f8969337973ca5794a7172b0 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/SwaggerVerificationTest.java
>  a8ab19c0ac7f5cb94148fff725093c5f07858e93 
>   
> geode-assembly/src/test/java/org/apache/geode/test/dunit/rules/EmbeddedPulseRule.java
>  PRE-CREATION 
>   
> geode-assembly/src/test/java/org/apache/geode/test/dunit/rules/HttpClientRule.java
>  49351d9bba854eef08c20d47b99eb3ce467cabaa 
>   
> geode-assembly/src/test/java/org/apache/geode/tools/pulse/PulseDataExportTest.java
>  10ca43b8fc171f75887519deb72700f464f24149 
>   
> geode-assembly/src/test/java/org/apache/geode/tools/pulse/PulseVerificationTest.java
>  5a300a15b06b948603b5e82acba1190e1905b41a 
>   
> geode-core/src/test/java/org/apache/geode/cache/ConnectionPoolDUnitTest.java 
> 2ac5120a673ed53f7a8f4b1ed077902566e7865d 
>   geode-core/src/test/java/org/apache/geode/cache/ProxyJUnitTest.java 
> 05228addb74b070a4eac13bd61e84b055916a503 
>   
> geode-core/src/test/java/org/apache/geode/cache/partition/PartitionRegionHelperDUnitTest.java
>  c57ce5beebc7bc4e4d7b826d8795d5a8e367f245 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/BaseLineAndCompareQueryPerfJUnitTest.java
>  de2f8d3e159ed199c1bd4b740ce7dd8ed5b82a5f 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/dunit/QueryIndexDUnitTest.java
>  d121fe9993e13e07dcea4817a173b80a8342e169 
>   
> 

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

[ASF GitHub Bot (JIRA)]

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

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

Github user asfgit closed the pull request at:

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


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



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

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

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2725:


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

GEODE-2725: export logs now honors --dir when connected via JMX, with
respect to the manager filesystem.

* Absolute Paths are better.  Test class inheritance is cumbersome.

* Removed --dir usage from ExportLogsDUnitTests:
startAndEndDateCanIncludeLogs and
testExportWithStartAndEndDateTimeFiltering; these tests expected logs
to appear in the locator working directory and the --dir option was
not actually being used.

* Usage of LocalLocatorStarterRules reverted in
ExportLogsIntegrationTest as locator working directory access is
required.

* this closes #438

Corrected mismatched merging of strings against offline help golden file.


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



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

[GitHub] geode pull request #438: GEODE-2725: export logs now honors --dir when conne...

[asfgit]

Github user asfgit closed the pull request at:

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


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

Build failed in Jenkins: Geode-nightly #805

[Apache Jenkins Server]

See 


Changes:

[gosullivan] Fix a repetition in the README.

[jiliao] GEODE-1274: Migration from PulseLogWriter to Log4j standard and removal

[jiliao] GEODE-2767: Added DUnitTests to validate export log options --group and

[dschneider] Revert "GEODE-2485: fix leak in tx suspend/resume"

[klund] GEODE-2765: change gfsh help to consistently use log4j levels

[dschneider] GEODE-2485: fix leak in tx suspend/resume

--
[...truncated 101.04 KB...]
at org.apache.geode.test.dunit.VM.invoke(VM.java:292)
at 
org.apache.geode.management.ClientHealthStatsDUnitTest.testClientHealthStats_SubscriptionEnabled(ClientHealthStatsDUnitTest.java:128)

Caused by:
java.lang.NullPointerException
at 
org.apache.geode.management.ClientHealthStatsDUnitTest.put(ClientHealthStatsDUnitTest.java:377)
at 
org.apache.geode.management.ClientHealthStatsDUnitTest.lambda$testClientHealthStats_SubscriptionEnabled$bb17a952$2(ClientHealthStatsDUnitTest.java:128)

6854 tests completed, 2 failed, 603 skipped
:geode-core:distributedTest FAILED
:geode-core:flakyTest
:geode-core:integrationTest
:geode-cq:assemble
:geode-cq:compileTestJavaNote: Some input files use or override a deprecated 
API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

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

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

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

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

:geode-pulse:processTestResources
:geode-pulse:testClasses
:geode-pulse:checkMissedTests
:geode-pulse:spotlessJavaCheck

Re: Review Request 58325: GEODE-2737: Change Pulse UI tests to use random port for JMX connections

[Jinmei Liao]

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


Ship it!




Ship It!

- Jinmei Liao


On April 12, 2017, 4:02 p.m., Ken Howe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58325/
> ---
> 
> (Updated April 12, 2017, 4:02 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Kirk Lund, and Patrick 
> Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2737: Change Pulse UI tests to use random port for JMX connections
> 
> 
> Diffs
> -
> 
>   geode-pulse/src/test/java/org/apache/geode/tools/pulse/tests/Server.java 
> ebf291b481c78533adab9006e32a9dcb5d1d8d39 
>   
> geode-pulse/src/test/java/org/apache/geode/tools/pulse/tests/rules/ServerRule.java
>  af3d64bd5118ff870fadc16dcdeb3cde858611ce 
> 
> 
> Diff: https://reviews.apache.org/r/58325/diff/3/
> 
> 
> Testing
> ---
> 
> ==> Latest precheckin was clean.
> 
> All Pulse UI tests run locally pass.
> 
> Precheckin is running
> 
> 
> Thanks,
> 
> Ken Howe
> 
>

Re: Review Request 58325: GEODE-2737: Change Pulse UI tests to use random port for JMX connections

[Ken Howe]

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

(Updated April 12, 2017, 4:02 p.m.)


Review request for geode, Jinmei Liao, Jared Stewart, Kirk Lund, and Patrick 
Rhomberg.


Repository: geode


Description
---

GEODE-2737: Change Pulse UI tests to use random port for JMX connections


Diffs
-

  geode-pulse/src/test/java/org/apache/geode/tools/pulse/tests/Server.java 
ebf291b481c78533adab9006e32a9dcb5d1d8d39 
  
geode-pulse/src/test/java/org/apache/geode/tools/pulse/tests/rules/ServerRule.java
 af3d64bd5118ff870fadc16dcdeb3cde858611ce 


Diff: https://reviews.apache.org/r/58325/diff/3/


Testing (updated)
---

==> Latest precheckin was clean.

All Pulse UI tests run locally pass.

Precheckin is running


Thanks,

Ken Howe

Re: One class loader vs multiple class loaders for deployed jars

[Michael Stolz]

+1 for merging the current fix.

It at least makes it easier to deploy a jar in the happy day scenario.
I'm not sure how much we should be trying to emulate an application server
anyway.
If people really want to combine the cache with the app server they can
embed Geode into an app server.
There may be some API sugar that would make that more useful, but it seems
it's a lot less work than all this classloader stuff we're discussing, and
would likely yield much better sandboxing.

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

On Tue, Apr 11, 2017 at 7:46 PM, Jinmei Liao  wrote:

> I believe with the current fix, we at least do not have the "eager loading"
> problem anymore. The classloader isolation was a problem before and would
> remain as a problem after this for further larger scale changes. +1 for
> merging the fix.
>
> On Tue, Apr 11, 2017 at 4:04 PM, Swapnil Bawaskar 
> wrote:
>
> > +1 for merging Jared's fix. it gets us closer to fixing classloading in a
> > later release.
> >
> > On Tue, Apr 11, 2017 at 1:41 PM Jacob Barrett 
> wrote:
> >
> > > I can support the idea of taking the small step of fixing the eager
> class
> > > loading if it doesn't:
> > > 1) break the current expected behavior.
> > > 2) dig is deeper into a hole with class loading isolation in the
> future.
> > >
> > > If it breaks the current expected behavior, that in itself is ok until
> > you
> > > consider that adding class loader isolation later will most definitely
> > > break the expected behavior, can we afford do break it twice?
> > >
> > > -Jake
> > >
> > > On Tue, Apr 11, 2017 at 10:06 AM Jared Stewart 
> > > wrote:
> > >
> > > > I would like to distinguish between the following two objectives:
> > > >  1) Do not eagerly load every class contained in a deployed jar
> > > >  2) Establish robust classloader isolation for deployed jars
> > > >
> > > > The aim of my current line of work is to fix 1) (GEODE-2290).  This
> is
> > > not
> > > > to say that 2) is not a valuable pursuit, but I think getting 2) done
> > > > correctly is a larger task than fixing 1) in isolation.
> > > >
> > > > To get into the specifics of the libraries you mentioned,
> > > >
> > > > JCL:
> > > >  - JCL has no support for removing/undeploying jars.  In this
> respect,
> > I
> > > > don't see anything that JCL would add over simply using a
> > URLClassLoader.
> > > > We would have to rebuild the JCL class loader in exactly the same set
> > of
> > > > circumstances that we would need to rebuild a URLClassLoader.
> > > >  - I have seen a fair number of warnings from people that JCL is
> buggy
> > > and
> > > > incomplete, e.g. (
> > > >
> > > http://stackoverflow.com/questions/60764/how-should-i-
> > load-jars-dynamically-at-runtime#comment43066872_1450837
> > > )
> > > > This would seem to be supported by a quick look at the github issues
> > page
> > > > for JCL, which includes things like a bug report of a deadlock from
> Jun
> > > > 2016 to which the developers have never responded.
> > > >
> > > > JBoss Modules:
> > > >  - JBoss Modules (or Java 9/Jigsaw Modules) seem like a good
> strategic
> > > > direction towards which to strive.  Yet the fact that they require an
> > > > external module descriptor (XML) would again seem to make this a much
> > > > larger task than 1) alone.  (If the idea here is to have a user
> provide
> > > us
> > > > with a JBoss Module rather than a plain jar file, this would be a
> large
> > > > breaking change for existing users.  On the other hand, if the idea
> is
> > > for
> > > > us to autogenerate the necessary metainformation to transform the
> > user's
> > > > jar file into a JBoss Module, this would seem to be a large task
> which
> > is
> > > > again independent from the goals of 1).
> > > >
> > > > - Jared
> > > >
> > > > > On Apr 10, 2017, at 9:41 PM, Jacob Barrett 
> > > wrote:
> > > > >
> > > > > There are certainly many projects in the OS community that have
> > solved
> > > > this
> > > > > same problem. Perhaps we can find a class loader from a project
> that
> > > > would
> > > > > suite this need.
> > > > >
> > > > > Quick search of standalone frameworks comes up with a few popular
> > hits:
> > > > > https://github.com/kamranzafar/JCL
> > > > > https://github.com/jboss-modules/jboss-modules
> > > > >
> > > > > -Jake
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Mon, Apr 10, 2017 at 1:40 PM Kirk Lund 
> wrote:
> > > > >
> > > > >> I think Jared started down this path because we had a custom
> > > classloader
> > > > >> implementation that he was trying to get rid of -- that impl was
> > > pretty
> > > > >> limited and forced loading of all classes up-front.
> > > > >>
> > > > >> Now the code uses fast classpath scanner and that old custom
> > > classloader
> > > > >> can't be used. The old classloader is so simplistic and limited
> that

Re: Review Request 58388: GEODE-2730: refactor rules

[Jinmei Liao]

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

(Updated April 12, 2017, 3:08 p.m.)


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


Repository: geode


Description (updated)
---

* consolidated the two sets of rules.
* do not allow member start up at test initialization time.
* validate properties in @Before
* use provider in the chained rules to get the appropriate ports in @Before

Jared and I tried to use ServerLauncher/LocatorLauncher to start the respective 
member in the rules, but precheckin yields many failures. Looks like it has two 
problems:
1) by passing in the workingDir in the launcher alone does not make all the 
logs go there. I still have to set the user.dir env variable to make some tests 
pass.
2) launcher.stop does not stop the cache/locator/server cleanly. Subsequent 
tests fail due to insufficient cleanup.
Due to the above two reasons, I reverted back to use the old way to start 
server/locator. This looks like a lean and mean way to get what we needed.

We also investigated the use of Builder in the rules. At least for now, it 
doesn't buy us much since we need to do validation/startup servers in @Before 
of the rules. And it yeilds some duplication code and make the usage not that 
intuitive.

As for using AvailablePort.Keeper, Jared and I found out it doesn't really keep 
the ports, so revert that back as well.


Diffs (updated)
-

  
geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityIntegrationTest.java
 cbd83e382116dcfc06b0199b69bf91486be22f06 
  
geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityPostProcessorTest.java
 e93561c0b5fc4fa7f89c03ff4055515d6bbb21be 
  
geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityWithSSLTest.java
 14113c06532d42833ee67f4fbf97ba24d535f2d3 
  
geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestServersJUnitTest.java
 2a3a036782fbde22f8969337973ca5794a7172b0 
  
geode-assembly/src/test/java/org/apache/geode/rest/internal/web/SwaggerVerificationTest.java
 a8ab19c0ac7f5cb94148fff725093c5f07858e93 
  
geode-assembly/src/test/java/org/apache/geode/test/dunit/rules/EmbeddedPulseRule.java
 PRE-CREATION 
  
geode-assembly/src/test/java/org/apache/geode/test/dunit/rules/HttpClientRule.java
 49351d9bba854eef08c20d47b99eb3ce467cabaa 
  
geode-assembly/src/test/java/org/apache/geode/tools/pulse/PulseDataExportTest.java
 10ca43b8fc171f75887519deb72700f464f24149 
  
geode-assembly/src/test/java/org/apache/geode/tools/pulse/PulseVerificationTest.java
 5a300a15b06b948603b5e82acba1190e1905b41a 
  geode-core/src/test/java/org/apache/geode/cache/ConnectionPoolDUnitTest.java 
2ac5120a673ed53f7a8f4b1ed077902566e7865d 
  geode-core/src/test/java/org/apache/geode/cache/ProxyJUnitTest.java 
05228addb74b070a4eac13bd61e84b055916a503 
  
geode-core/src/test/java/org/apache/geode/cache/partition/PartitionRegionHelperDUnitTest.java
 c57ce5beebc7bc4e4d7b826d8795d5a8e367f245 
  
geode-core/src/test/java/org/apache/geode/cache/query/BaseLineAndCompareQueryPerfJUnitTest.java
 de2f8d3e159ed199c1bd4b740ce7dd8ed5b82a5f 
  
geode-core/src/test/java/org/apache/geode/cache/query/dunit/QueryIndexDUnitTest.java
 d121fe9993e13e07dcea4817a173b80a8342e169 
  
geode-core/src/test/java/org/apache/geode/cache/query/dunit/RemoteQueryDUnitTest.java
 5f48dae54cd14beb2affeae8a8f3387f3e7bfae0 
  
geode-core/src/test/java/org/apache/geode/cache/query/functional/IndexWithSngleFrmAndMultCondQryJUnitTest.java
 d5195a6b2c8f1b62955ddd127e28ee74bc63ab21 
  
geode-core/src/test/java/org/apache/geode/cache/query/functional/LimitClauseJUnitTest.java
 1661cc8d5ba42b782e08251338605c001c526c97 
  
geode-core/src/test/java/org/apache/geode/cache/query/internal/QueryUtilsJUnitTest.java
 85305560669544d5fb3493a88f7bf93d86b8ac91 
  
geode-core/src/test/java/org/apache/geode/cache/query/internal/index/IndexMaintenanceJUnitTest.java
 b7b590ac2918e3176f2aa9625f4bbe7d06113c87 
  
geode-core/src/test/java/org/apache/geode/cache/query/partitioned/PRQueryDUnitHelper.java
 e07990d88061d174f2a7a69e4158abb1ed3ac679 
  geode-core/src/test/java/org/apache/geode/cache30/CacheLoaderTestCase.java 
164221776bcb187fc5d2d1fe199d40cfd37a0c63 
  geode-core/src/test/java/org/apache/geode/cache30/CacheXml66DUnitTest.java 
738ef3f778da58375d495bb1ad294f07161133db 
  geode-core/src/test/java/org/apache/geode/cache30/DiskRegionDUnitTest.java 
c3553b7ece3b91ce142ad5e0acd4ecc1845e9869 
  geode-core/src/test/java/org/apache/geode/cache30/DiskRegionTestImpl.java 
301c23267995dd0201566bac9472d4b7db3c60fd 
  
geode-core/src/test/java/org/apache/geode/cache30/DistributedAckRegionCCEDUnitTest.java
 dcb6cf37a5458e40d4638b944c1394fb63a52da2 
  
geode-core/src/test/java/org/apache/geode/cache30/DistributedMulticastRegionDUnitTest.java
 

Review Request 58388: GEODE-2730: refactor rules

[Jinmei Liao]

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

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


Repository: geode


Description
---

* do not allow member start up at test initialization time.
* validate properties in @Before
* use provider in the chained rules to get the appropriate ports in @Before

Jared and I tried to use ServerLauncher/LocatorLauncher to start the respective 
member in the rules, but precheckin yields many failures. Looks like it has two 
problems:
1) by passing in the workingDir in the launcher alone does not make all the 
logs go there. I still have to set the user.dir env variable to make some tests 
pass.
2) launcher.stop does not stop the cache/locator/server cleanly. Subsequent 
tests fail due to insufficient cleanup.
Due to the above two reasons, I reverted back to use the old way to start 
server/locator. This looks like a lean and mean way to get what we needed.

We also investigated the use of Builder in the rules. At least for now, it 
doesn't buy us much since we need to do validation/startup servers in @Before 
of the rules. And it yeilds some duplication code and make the usage not that 
intuitive.

As for using AvailablePort.Keeper, Jared and I found out it doesn't really keep 
the ports, so revert that back as well.


Diffs
-

  
geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityIntegrationTest.java
 cbd83e382116dcfc06b0199b69bf91486be22f06 
  
geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityPostProcessorTest.java
 e93561c0b5fc4fa7f89c03ff4055515d6bbb21be 
  
geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityWithSSLTest.java
 14113c06532d42833ee67f4fbf97ba24d535f2d3 
  
geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestServersJUnitTest.java
 2a3a036782fbde22f8969337973ca5794a7172b0 
  
geode-assembly/src/test/java/org/apache/geode/rest/internal/web/SwaggerVerificationTest.java
 a8ab19c0ac7f5cb94148fff725093c5f07858e93 
  
geode-assembly/src/test/java/org/apache/geode/test/dunit/rules/EmbeddedPulseRule.java
 PRE-CREATION 
  
geode-assembly/src/test/java/org/apache/geode/test/dunit/rules/HttpClientRule.java
 49351d9bba854eef08c20d47b99eb3ce467cabaa 
  
geode-assembly/src/test/java/org/apache/geode/tools/pulse/PulseDataExportTest.java
 10ca43b8fc171f75887519deb72700f464f24149 
  
geode-assembly/src/test/java/org/apache/geode/tools/pulse/PulseVerificationTest.java
 5a300a15b06b948603b5e82acba1190e1905b41a 
  geode-core/src/main/java/org/apache/geode/distributed/LocatorLauncher.java 
856a2cda2f1c36f6940f3900f8b316568815afdc 
  geode-core/src/main/java/org/apache/geode/distributed/ServerLauncher.java 
c96732ca2752c4f0f259333b8672ab258831405e 
  geode-core/src/test/java/org/apache/geode/cache/ConnectionPoolDUnitTest.java 
2ac5120a673ed53f7a8f4b1ed077902566e7865d 
  geode-core/src/test/java/org/apache/geode/cache/ProxyJUnitTest.java 
05228addb74b070a4eac13bd61e84b055916a503 
  
geode-core/src/test/java/org/apache/geode/cache/partition/PartitionRegionHelperDUnitTest.java
 c57ce5beebc7bc4e4d7b826d8795d5a8e367f245 
  
geode-core/src/test/java/org/apache/geode/cache/query/BaseLineAndCompareQueryPerfJUnitTest.java
 de2f8d3e159ed199c1bd4b740ce7dd8ed5b82a5f 
  
geode-core/src/test/java/org/apache/geode/cache/query/dunit/QueryIndexDUnitTest.java
 d121fe9993e13e07dcea4817a173b80a8342e169 
  
geode-core/src/test/java/org/apache/geode/cache/query/dunit/RemoteQueryDUnitTest.java
 5f48dae54cd14beb2affeae8a8f3387f3e7bfae0 
  
geode-core/src/test/java/org/apache/geode/cache/query/functional/IndexWithSngleFrmAndMultCondQryJUnitTest.java
 d5195a6b2c8f1b62955ddd127e28ee74bc63ab21 
  
geode-core/src/test/java/org/apache/geode/cache/query/functional/LimitClauseJUnitTest.java
 1661cc8d5ba42b782e08251338605c001c526c97 
  
geode-core/src/test/java/org/apache/geode/cache/query/internal/QueryUtilsJUnitTest.java
 85305560669544d5fb3493a88f7bf93d86b8ac91 
  
geode-core/src/test/java/org/apache/geode/cache/query/internal/index/IndexMaintenanceJUnitTest.java
 b7b590ac2918e3176f2aa9625f4bbe7d06113c87 
  
geode-core/src/test/java/org/apache/geode/cache/query/partitioned/PRQueryDUnitHelper.java
 e07990d88061d174f2a7a69e4158abb1ed3ac679 
  geode-core/src/test/java/org/apache/geode/cache30/CacheLoaderTestCase.java 
164221776bcb187fc5d2d1fe199d40cfd37a0c63 
  geode-core/src/test/java/org/apache/geode/cache30/CacheXml66DUnitTest.java 
738ef3f778da58375d495bb1ad294f07161133db 
  geode-core/src/test/java/org/apache/geode/cache30/DiskRegionDUnitTest.java 
c3553b7ece3b91ce142ad5e0acd4ecc1845e9869 
  geode-core/src/test/java/org/apache/geode/cache30/DiskRegionTestImpl.java 
301c23267995dd0201566bac9472d4b7db3c60fd 
  
geode-core/src/test/java/org/apache/geode/cache30/DistributedAckRegionCCEDUnitTest.java
 

[jira] [Assigned] (GEODE-1975) CI Failure: SecurityClusterConfigDUnitTest.serverWithDifferentSecurityManagerShouldThrowException

[Jinmei Liao (JIRA)]

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

Jinmei Liao reassigned GEODE-1975:
--

Assignee: Jinmei Liao

> CI Failure: 
> SecurityClusterConfigDUnitTest.serverWithDifferentSecurityManagerShouldThrowException
> -
>
> Key: GEODE-1975
> URL: https://issues.apache.org/jira/browse/GEODE-1975
> Project: Geode
>  Issue Type: Bug
>  Components: configuration, gfsh, security
>Reporter: Barry Oglesby
>Assignee: Jinmei Liao
>  Labels: CI, Flaky
>
> Geode_develop_DistributedTests
> Private Build #4129
> Revision: 0a6e1a5339243b069a04d8010a869bfd1f4172c1
> java.lang.AssertionError: 
> Expecting message:
>  <"A server cannot specify its own security-manager or 
> security-post-processor when using cluster configuration">
> but was:
>  <"cluster configuration service not available">
>   at 
> org.apache.geode.security.SecurityClusterConfigDUnitTest.serverWithDifferentSecurityManagerShouldThrowException(SecurityClusterConfigDUnitTest.java:156)
>   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.ExternalResource$1.evaluate(ExternalResource.java:48)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
>   at sun.reflect.GeneratedMethodAccessor560.invoke(Unknown Source)
>   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.GeneratedMethodAccessor559.invoke(Unknown Source)
>   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 
> 

[jira] [Closed] (GEODE-2771) Geode locators do not see each other after network connection interruption

[Vadim Lotarev (JIRA)]

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

Vadim Lotarev closed GEODE-2771.


> Geode locators do not see each other after network connection interruption
> --
>
> Key: GEODE-2771
> URL: https://issues.apache.org/jira/browse/GEODE-2771
> Project: Geode
>  Issue Type: Bug
>  Components: locator
>Affects Versions: 1.1.1
>Reporter: Vadim Lotarev
> Attachments: LocatorsWorkingDirs.zip, screenshot.66.jpg
>
>
> How to reproduce:
> 1. Run two locators on different ports on the same machine
> 2. Execute gfsh, connect to each locator subsequently and execute {{list 
> members}}. You'll see both locators in spite of the fact that gfsh is connect 
> to one of them.
> 3. Disable/enable network adapter emulating network connection interruption.
> 4. Repeat step 2. You'll see only one locator in response to {{list members}} 
> (actually that one gfsh is connected to).
> Also there are some strange messages in the logs:
> {code}
> [info 2017/04/11 12:19:33.627 MSK locator_4  receiver,VLOTAREV-17591> tid=0x24] Ignoring the view 
> View[192.168.63.58(locator_41112:16908:locator):1025|12] members: 
> [192.168.63.58(locator_41112:16908:locator):1025]  crashed: 
> [192.168.63.58(locator_4:18396:locator):1024] from member 
> 192.168.63.58(:):1025, which is not in my current view 
> View[192.168.63.58(locator_4:18396:locator):1024|2] members: 
> [192.168.63.58(locator_4:18396:locator):1024]  crashed: 
> [192.168.63.58(locator_41112:16908:locator):1025] 
> {code}
> Please see attached the full content of locator's working directories and 
> screenshot of gfsh commands.



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

[jira] [Resolved] (GEODE-2771) Geode locators do not see each other after network connection interruption

[Vadim Lotarev (JIRA)]

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

Vadim Lotarev resolved GEODE-2771.
--
Resolution: Won't Fix

This is an expected behavior related to network partition detection 
implementation.

> Geode locators do not see each other after network connection interruption
> --
>
> Key: GEODE-2771
> URL: https://issues.apache.org/jira/browse/GEODE-2771
> Project: Geode
>  Issue Type: Bug
>  Components: locator
>Affects Versions: 1.1.1
>Reporter: Vadim Lotarev
> Attachments: LocatorsWorkingDirs.zip, screenshot.66.jpg
>
>
> How to reproduce:
> 1. Run two locators on different ports on the same machine
> 2. Execute gfsh, connect to each locator subsequently and execute {{list 
> members}}. You'll see both locators in spite of the fact that gfsh is connect 
> to one of them.
> 3. Disable/enable network adapter emulating network connection interruption.
> 4. Repeat step 2. You'll see only one locator in response to {{list members}} 
> (actually that one gfsh is connected to).
> Also there are some strange messages in the logs:
> {code}
> [info 2017/04/11 12:19:33.627 MSK locator_4  receiver,VLOTAREV-17591> tid=0x24] Ignoring the view 
> View[192.168.63.58(locator_41112:16908:locator):1025|12] members: 
> [192.168.63.58(locator_41112:16908:locator):1025]  crashed: 
> [192.168.63.58(locator_4:18396:locator):1024] from member 
> 192.168.63.58(:):1025, which is not in my current view 
> View[192.168.63.58(locator_4:18396:locator):1024|2] members: 
> [192.168.63.58(locator_4:18396:locator):1024]  crashed: 
> [192.168.63.58(locator_41112:16908:locator):1025] 
> {code}
> Please see attached the full content of locator's working directories and 
> screenshot of gfsh commands.



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

[jira] [Commented] (GEODE-2632) Integrated Security performance improvements

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/geode/pull/450#discussion_r111093862
  
--- Diff: 
geode-core/src/jmh/java/org/apache/geode/internal/cache/tier/sockets/command/ClientCachePutBench.java
 ---
@@ -0,0 +1,199 @@
+/*
+ * 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.tier.sockets.command;
+
+import static java.lang.System.*;
+import static java.util.concurrent.TimeUnit.*;
+import static org.apache.commons.io.FileUtils.*;
+import static org.apache.commons.lang.StringUtils.*;
+import static org.apache.geode.cache.client.ClientRegionShortcut.*;
+import static org.apache.geode.distributed.AbstractLauncher.Status.*;
+import static org.apache.geode.distributed.ConfigurationProperties.*;
+import static org.apache.geode.distributed.internal.DistributionConfig.*;
+import static org.apache.geode.internal.AvailablePort.*;
+import static org.apache.geode.test.dunit.NetworkUtils.*;
+import static org.assertj.core.api.Assertions.*;
+import static org.awaitility.Awaitility.*;
+
+import org.apache.geode.cache.Region;
+import org.apache.geode.cache.client.ClientCache;
+import org.apache.geode.cache.client.ClientCacheFactory;
+import org.apache.geode.distributed.ServerLauncher;
+import org.apache.geode.internal.process.ProcessStreamReader;
+import org.junit.rules.TemporaryFolder;
+import org.openjdk.jmh.annotations.Benchmark;
+import org.openjdk.jmh.annotations.BenchmarkMode;
+import org.openjdk.jmh.annotations.Fork;
+import org.openjdk.jmh.annotations.Level;
+import org.openjdk.jmh.annotations.Measurement;
+import org.openjdk.jmh.annotations.Mode;
+import org.openjdk.jmh.annotations.OutputTimeUnit;
+import org.openjdk.jmh.annotations.Scope;
+import org.openjdk.jmh.annotations.Setup;
+import org.openjdk.jmh.annotations.State;
+import org.openjdk.jmh.annotations.TearDown;
+import org.openjdk.jmh.annotations.Warmup;
+
+import java.io.File;
+import java.io.IOException;
+import java.net.URL;
+import java.util.ArrayList;
+import java.util.List;
+import java.util.Random;
+import java.util.concurrent.TimeUnit;
+
+/**
+ * Benchmark that measures throughput of client performing puts to a loner 
server.
+ */
+@Measurement(iterations = 3, time = 3, timeUnit = MINUTES)
+@Warmup(iterations = 3, time = 1, timeUnit = MINUTES)
+@Fork(3)
+@BenchmarkMode(Mode.Throughput)
+@OutputTimeUnit(TimeUnit.SECONDS)
+@State(Scope.Thread)
+@SuppressWarnings("unused")
+public class ClientCachePutBench {
+
+  static final long PROCESS_READER_TIMEOUT = 60 * 1000;
+  static final String CLASS_NAME = 
ClientCachePutBench.class.getSimpleName();
+  static final String PACKAGE_NAME =
+  replace(ClientCachePutBench.class.getPackage().getName(), ".", "/");
+  static final String REGION_NAME = CLASS_NAME + "-region";
+  static final String SERVER_XML_NAME = "/" + PACKAGE_NAME + "/" + 
CLASS_NAME + "-server.xml";
+
+  @State(Scope.Benchmark)
+  public static class ClientState {
+
+Random random;
+Region region;
+
+private Process process;
+private volatile ProcessStreamReader processOutReader;
+private volatile ProcessStreamReader processErrReader;
+
+private int serverPort;
+private ServerLauncher launcher;
+private File serverDirectory;
+private ClientCache clientCache;
+
+private TemporaryFolder temporaryFolder = new TemporaryFolder();
+
+@Setup(Level.Trial)
+public void startServer() throws Exception {
+  System.out.println("\n" + "[ClientCachePutBench] startServer");
+
+  this.random = new Random(nanoTime());
+

[GitHub] geode pull request #450: GEODE-2632: create ClientCachePutBench

[kohlmu-pivotal]

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

https://github.com/apache/geode/pull/450#discussion_r111093862
  
--- Diff: 
geode-core/src/jmh/java/org/apache/geode/internal/cache/tier/sockets/command/ClientCachePutBench.java
 ---
@@ -0,0 +1,199 @@
+/*
+ * 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.tier.sockets.command;
+
+import static java.lang.System.*;
+import static java.util.concurrent.TimeUnit.*;
+import static org.apache.commons.io.FileUtils.*;
+import static org.apache.commons.lang.StringUtils.*;
+import static org.apache.geode.cache.client.ClientRegionShortcut.*;
+import static org.apache.geode.distributed.AbstractLauncher.Status.*;
+import static org.apache.geode.distributed.ConfigurationProperties.*;
+import static org.apache.geode.distributed.internal.DistributionConfig.*;
+import static org.apache.geode.internal.AvailablePort.*;
+import static org.apache.geode.test.dunit.NetworkUtils.*;
+import static org.assertj.core.api.Assertions.*;
+import static org.awaitility.Awaitility.*;
+
+import org.apache.geode.cache.Region;
+import org.apache.geode.cache.client.ClientCache;
+import org.apache.geode.cache.client.ClientCacheFactory;
+import org.apache.geode.distributed.ServerLauncher;
+import org.apache.geode.internal.process.ProcessStreamReader;
+import org.junit.rules.TemporaryFolder;
+import org.openjdk.jmh.annotations.Benchmark;
+import org.openjdk.jmh.annotations.BenchmarkMode;
+import org.openjdk.jmh.annotations.Fork;
+import org.openjdk.jmh.annotations.Level;
+import org.openjdk.jmh.annotations.Measurement;
+import org.openjdk.jmh.annotations.Mode;
+import org.openjdk.jmh.annotations.OutputTimeUnit;
+import org.openjdk.jmh.annotations.Scope;
+import org.openjdk.jmh.annotations.Setup;
+import org.openjdk.jmh.annotations.State;
+import org.openjdk.jmh.annotations.TearDown;
+import org.openjdk.jmh.annotations.Warmup;
+
+import java.io.File;
+import java.io.IOException;
+import java.net.URL;
+import java.util.ArrayList;
+import java.util.List;
+import java.util.Random;
+import java.util.concurrent.TimeUnit;
+
+/**
+ * Benchmark that measures throughput of client performing puts to a loner 
server.
+ */
+@Measurement(iterations = 3, time = 3, timeUnit = MINUTES)
+@Warmup(iterations = 3, time = 1, timeUnit = MINUTES)
+@Fork(3)
+@BenchmarkMode(Mode.Throughput)
+@OutputTimeUnit(TimeUnit.SECONDS)
+@State(Scope.Thread)
+@SuppressWarnings("unused")
+public class ClientCachePutBench {
+
+  static final long PROCESS_READER_TIMEOUT = 60 * 1000;
+  static final String CLASS_NAME = 
ClientCachePutBench.class.getSimpleName();
+  static final String PACKAGE_NAME =
+  replace(ClientCachePutBench.class.getPackage().getName(), ".", "/");
+  static final String REGION_NAME = CLASS_NAME + "-region";
+  static final String SERVER_XML_NAME = "/" + PACKAGE_NAME + "/" + 
CLASS_NAME + "-server.xml";
+
+  @State(Scope.Benchmark)
+  public static class ClientState {
+
+Random random;
+Region region;
+
+private Process process;
+private volatile ProcessStreamReader processOutReader;
+private volatile ProcessStreamReader processErrReader;
+
+private int serverPort;
+private ServerLauncher launcher;
+private File serverDirectory;
+private ClientCache clientCache;
+
+private TemporaryFolder temporaryFolder = new TemporaryFolder();
+
+@Setup(Level.Trial)
+public void startServer() throws Exception {
+  System.out.println("\n" + "[ClientCachePutBench] startServer");
+
+  this.random = new Random(nanoTime());
+
+  this.temporaryFolder.create();
+  this.serverDirectory = this.temporaryFolder.getRoot();
+
+  startServerProcess();
+
+  try {
+startProcessReaders();
+
+ServerLauncher