date:20170512

2017-05-12 Thread ASF subversion and git services (JIRA)


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

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

Github user jhuynh1 closed the pull request at:

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


> Lucene javadoc cleanup
> --
>
> Key: GEODE-2914
> URL: https://issues.apache.org/jira/browse/GEODE-2914
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Jason Huynh
>Assignee: Jason Huynh
>
> There are a few javadoc errors in LuceneService.  The  inside the 
>  tags appears to convert the remaining javadoc into "code".
> Typo with non, should be none.



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

[GitHub] geode pull request #513: GEODE-2914: Tidy up LuceneService javadoc

2017-05-12 Thread jhuynh1

Github user jhuynh1 closed the pull request at:

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


---
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-254) Remove deprecated Region.keys and Region.entries


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

ASF subversion and git services commented on GEODE-254:
---

Commit dc198bd3d35b0a3f5339683ce7a25add6584a147 in geode's branch 
refs/heads/feature/GEODE-2632-15 from [~adongre]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=dc198bd ]

GEODE-254: Addressing review comments from PR #488 Replacing all inststance of 
entries with entrySet

GEODE-254: Fixing the Test Failures
 - Removed test testIndexMaintenanceWithIndexOnMethodEntries since this is no 
more applicable.

GEODE-254: Spotless fixing.
This closes #504

Signed-off-by: adongre 


> Remove deprecated Region.keys and Region.entries
> 
>
> Key: GEODE-254
> URL: https://issues.apache.org/jira/browse/GEODE-254
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Darrel Schneider
>Assignee: Avinash Dongre
> Fix For: 1.2.0
>
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> Remove the deprecated Region.keys and Region.entries. Any calls can be simply 
> changed to Region.keySet and Region.entrySet so this should be an easy change.
> A large number of tests call the deprecated methods.



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

[jira] [Commented] (GEODE-2637) LuceneQueryFactory.setResultLimit() method should match LuceneQuery.getLimit()

2017-05-12 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on GEODE-2637:


Commit efbe53cbafe30c5fb17681e22a3c83f3042e08ae in geode's branch 
refs/heads/feature/GEODE-2632-15 from nabarunnag
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=efbe53c ]

GEODE-2637: Refactored LuceneQueryFactory.setResultLimit()

* Renamed LuceneQueryFactory.getResult to setLimit()
* This is done to match the cwiki documents


> LuceneQueryFactory.setResultLimit() method should match LuceneQuery.getLimit()
> --
>
> Key: GEODE-2637
> URL: https://issues.apache.org/jira/browse/GEODE-2637
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Affects Versions: 1.2.0
>Reporter: Shelley Lynn Hughes-Godfrey
>Assignee: Shelley Lynn Hughes-Godfrey
>
> In the Lucene docs located here:
>  https://cwiki.apache.org/confluence/display/GEODE/Text+Search+With+Lucene
> we see that we control the number of results from the lucene query via 
> LuceneQueryFactory.setLimit() which corresponds directly with the 
> LuceneQuery.getLimit() method.
> However, this has been implemented as LuceneQueryFactory.setResultLimit().
> This needs to be changed to setLimit().



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

[jira] [Commented] (GEODE-2876) CI Failure: org.apache.geode.management.internal.cli.commands.ConcurrentDeployDUnitTest#testMultipleGfshClientToOneServer

2017-05-12 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on GEODE-2876:


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

GEODE-2876: add logging and testing to diagnose test failure


> CI Failure: 
> org.apache.geode.management.internal.cli.commands.ConcurrentDeployDUnitTest#testMultipleGfshClientToOneServer
> -
>
> Key: GEODE-2876
> URL: https://issues.apache.org/jira/browse/GEODE-2876
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh, management
>Reporter: Jared Stewart
>
> ConcurrentDeployDUnitTest is failing due to a parsing error.
> {noformat}
> Error
> java.lang.AssertionError: An exception occurred during asynchronous 
> invocation.
> Stacktrace
> java.lang.AssertionError: An exception occurred during asynchronous 
> invocation.
>   at 
> org.apache.geode.test.dunit.AsyncInvocation.checkException(AsyncInvocation.java:148)
>   at 
> org.apache.geode.test.dunit.AsyncInvocation.await(AsyncInvocation.java:341)
>   at 
> org.apache.geode.test.dunit.AsyncInvocation.await(AsyncInvocation.java:364)
>   at 
> org.apache.geode.management.internal.cli.commands.ConcurrentDeployDUnitTest.testMultipleGfshClientToOneServer(ConcurrentDeployDUnitTest.java:67)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
>   at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
>   at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
>   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.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
>   at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
>   at 
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109

[jira] [Commented] (GEODE-254) Remove deprecated Region.keys and Region.entries

2017-05-12 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on GEODE-254:
---

Commit dc198bd3d35b0a3f5339683ce7a25add6584a147 in geode's branch 
refs/heads/feature/GEODE-2632-15 from [~adongre]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=dc198bd ]

GEODE-254: Addressing review comments from PR #488 Replacing all inststance of 
entries with entrySet

GEODE-254: Fixing the Test Failures
 - Removed test testIndexMaintenanceWithIndexOnMethodEntries since this is no 
more applicable.

GEODE-254: Spotless fixing.
This closes #504

Signed-off-by: adongre 


> Remove deprecated Region.keys and Region.entries
> 
>
> Key: GEODE-254
> URL: https://issues.apache.org/jira/browse/GEODE-254
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Darrel Schneider
>Assignee: Avinash Dongre
> Fix For: 1.2.0
>
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> Remove the deprecated Region.keys and Region.entries. Any calls can be simply 
> changed to Region.keySet and Region.entrySet so this should be an easy change.
> A large number of tests call the deprecated methods.



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

[jira] [Commented] (GEODE-2875) shutdown is taking as long as 20 seconds

2017-05-12 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on GEODE-2875:


Commit 48f6e11adb84145187f9b1f715b6b368d94cee68 in geode's branch 
refs/heads/feature/GEODE-2632-15 from [~bschuchardt]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=48f6e11 ]

GEODE-2875 shutdown is taking as long as 20 seconds

The fix for this issue causes one of the test cases in LocatorDUnitTest
to fail consistently. With the fix we don't create any TCP/IP connections
in this test during startup but the test expects one to have been created
and it expects the connection's reader-thread to have initiated suspect
processing.

The test needs to be altered to ensure that this thread has been created
by sending message that requires a reply. The reply will be sent over the
expected connection, ensuring that there is a reader-thread.


> shutdown is taking as long as 20 seconds
> 
>
> Key: GEODE-2875
> URL: https://issues.apache.org/jira/browse/GEODE-2875
> Project: Geode
>  Issue Type: Bug
>  Components: membership
>Reporter: Bruce Schuchardt
>Assignee: Bruce Schuchardt
> Fix For: 1.2.0
>
>
> Recent changes have introduced a bug where sometimes, particularly during 
> shutdown of a lot of servers, the shutdown process will stall for as long as 
> 20 seconds.  This appears to be due to changes that keep a membership 
> coordinator from sending out a new view during shutdown.



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

[jira] [Commented] (GEODE-1130) Session state modules DeltaEvent logs extraneous 'attribute is already a byte[]' message

2017-05-12 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on GEODE-1130:


Commit 5b122c795ef9156ab4b003e5a04c348baf9ffcf6 in geode's branch 
refs/heads/feature/GEODE-2632-15 from [~barry.oglesby]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=5b122c7 ]

GEODE-1130: Removed log message


> Session state modules DeltaEvent logs extraneous 'attribute is already a 
> byte[]' message
> 
>
> Key: GEODE-1130
> URL: https://issues.apache.org/jira/browse/GEODE-1130
> Project: Geode
>  Issue Type: Bug
>  Components: http session
>Reporter: Barry Oglesby
>Assignee: Barry Oglesby
>
> The following message is logged by {{DeltaEvent.blobifyValue}}:
> {noformat}
> [warning 2016/03/22 15:00:06.867 GMT+09:00   tid=0x60] Session 
> attribute is already a byte[] - problems may occur transmitting this delta.
> {noformat}
> Here:
> {noformat}if (value instanceof byte[]) {
>   LOG.warn("Session attribute is already a byte[] - problems may "
> + "occur transmitting this delta.");
> }
> {noformat}
> It can safely be removed.



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

[jira] [Commented] (GEODE-237) Remove EntryEvent deprecated methods

2017-05-12 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on GEODE-237:
---

Commit 0c5011ec7f6adb7ecbf0f6aac5f01d52c810f3a6 in geode's branch 
refs/heads/feature/GEODE-2632-15 from [~adongre]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=0c5011e ]

GEODE-237: Removed deprecated API from EntryEvent
This closes #496

Signed-off-by: adongre 


> Remove EntryEvent deprecated methods
> 
>
> Key: GEODE-237
> URL: https://issues.apache.org/jira/browse/GEODE-237
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Darrel Schneider
>Assignee: Avinash Dongre
> Fix For: 1.2.0
>
>   Original Estimate: 4h
>  Remaining Estimate: 4h
>
> The following EntryEvent methods need to be removed:
> - isLocalLoad: change to getOperation().isLocalLoad
> - isNetLoad: change to getOperation().isNetLoad
> - isLoad: change to getOperation().isLoad
> - isNetSearch: change to getOperation().isNetSearch
> - isBridgeEvent: change to hasClientOrigin
> these should be pretty easy to change



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

[jira] [Commented] (GEODE-254) Remove deprecated Region.keys and Region.entries

2017-05-12 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on GEODE-254:
---

Commit dc198bd3d35b0a3f5339683ce7a25add6584a147 in geode's branch 
refs/heads/feature/GEODE-2632-15 from [~adongre]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=dc198bd ]

GEODE-254: Addressing review comments from PR #488 Replacing all inststance of 
entries with entrySet

GEODE-254: Fixing the Test Failures
 - Removed test testIndexMaintenanceWithIndexOnMethodEntries since this is no 
more applicable.

GEODE-254: Spotless fixing.
This closes #504

Signed-off-by: adongre 


> Remove deprecated Region.keys and Region.entries
> 
>
> Key: GEODE-254
> URL: https://issues.apache.org/jira/browse/GEODE-254
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Darrel Schneider
>Assignee: Avinash Dongre
> Fix For: 1.2.0
>
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> Remove the deprecated Region.keys and Region.entries. Any calls can be simply 
> changed to Region.keySet and Region.entrySet so this should be an easy change.
> A large number of tests call the deprecated methods.



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

[jira] [Commented] (GEODE-2914) Lucene javadoc cleanup

2017-05-12 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on GEODE-2914:


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

GEODE-2914: Tidy up LuceneService javadoc


> Lucene javadoc cleanup
> --
>
> Key: GEODE-2914
> URL: https://issues.apache.org/jira/browse/GEODE-2914
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Jason Huynh
>Assignee: Jason Huynh
>
> There are a few javadoc errors in LuceneService.  The  inside the 
>  tags appears to convert the remaining javadoc into "code".
> Typo with non, should be none.



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

Re: Review Request 59234: GEODE:2859: Fix ShowDeadlockDUnitTest jenkins failure


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


Ship it!




Ship It!

- Jinmei Liao


On May 12, 2017, 9:18 p.m., Jared Stewart wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59234/
> ---
> 
> (Updated May 12, 2017, 9:18 p.m.)
> 
> 
> Review request for geode.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> - Use a TemporaryFolder to avoid failures due to file system state
> - Refactor test
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ShowDeadlockDUnitTest.java
>  a5293eb0fa0a2599b837abc76903704a45428111 
> 
> 
> Diff: https://reviews.apache.org/r/59234/diff/1/
> 
> 
> Testing
> ---
> 
> Precheckin passed
> 
> 
> Thanks,
> 
> Jared Stewart
> 
>

Review Request 59246: GEODE-2876: reset isGfshVM flag to false when tearing down tests using CliCommandTestBase.


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

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


Repository: geode


Description
---

* tests using CliCommandTestBase will set this flag to true which messes up 
following test vms.


Diffs
-

  
geode-core/src/main/java/org/apache/geode/management/internal/cli/GfshParser.java
 bc4db1660054ba837a4907d1173a254931fef230 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/CliCommandTestBase.java
 afdb706c285578f63fdaf459ac4ae59d83ab27e3 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/MemberCommandsDUnitTest.java
 e41164495e2330ffdbf70bd52dc91bc0ae333830 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ShowDeadlockDUnitTest.java
 a5293eb0fa0a2599b837abc76903704a45428111 


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


Testing
---

precheckin running


Thanks,

Jinmei Liao

[jira] [Closed] (GEODE-2875) shutdown is taking as long as 20 seconds


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

Bruce Schuchardt closed GEODE-2875.
---

> shutdown is taking as long as 20 seconds
> 
>
> Key: GEODE-2875
> URL: https://issues.apache.org/jira/browse/GEODE-2875
> Project: Geode
>  Issue Type: Bug
>  Components: membership
>Reporter: Bruce Schuchardt
>Assignee: Bruce Schuchardt
> Fix For: 1.2.0
>
>
> Recent changes have introduced a bug where sometimes, particularly during 
> shutdown of a lot of servers, the shutdown process will stall for as long as 
> 20 seconds.  This appears to be due to changes that keep a membership 
> coordinator from sending out a new view during shutdown.



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

[jira] [Resolved] (GEODE-2875) shutdown is taking as long as 20 seconds

2017-05-12 Thread ASF subversion and git services (JIRA)


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

Bruce Schuchardt resolved GEODE-2875.
-
   Resolution: Fixed
Fix Version/s: 1.2.0

> shutdown is taking as long as 20 seconds
> 
>
> Key: GEODE-2875
> URL: https://issues.apache.org/jira/browse/GEODE-2875
> Project: Geode
>  Issue Type: Bug
>  Components: membership
>Reporter: Bruce Schuchardt
>Assignee: Bruce Schuchardt
> Fix For: 1.2.0
>
>
> Recent changes have introduced a bug where sometimes, particularly during 
> shutdown of a lot of servers, the shutdown process will stall for as long as 
> 20 seconds.  This appears to be due to changes that keep a membership 
> coordinator from sending out a new view during shutdown.



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

Re: Review Request 59239: Allow a locator host to be taken off line and replaced with a different machine having the same host name

2017-05-12 Thread Bruce Schuchardt


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


Ship it!




It would be nice to have a javadoc on the two tests.  Other than that the 
changes look good to me Hitesh.

- Bruce Schuchardt


On May 12, 2017, 7:01 p.m., Hitesh Khamesra wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59239/
> ---
> 
> (Updated May 12, 2017, 7:01 p.m.)
> 
> 
> Review request for geode, Bruce Schuchardt, Galen O'Sullivan, and Udo 
> Kohlmeyer.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2804 Update InetSocketAddress, when there is IOException.
> 
> Geode keeps InetSocketAddress for locators. So, if locators ip
> changes in cloud/VM enviroment then Geode process unable to
> connect to locator. Thus we have fixed this problem in two way.
> 
> a. If Geode client sees IOException while connectin to locator then
> we change cached InetAddress to use locator hostname. In this way,
> client does DNS query again for locator host.
> b. For other Geode process, now we connect to locator using hostname.
> 
> Added couple of junit tests for it.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/cache/client/internal/AutoConnectionSourceImpl.java
>  1e807ee 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/membership/GMSJoinLeave.java
>  4bf010b 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/tcpserver/TcpClient.java
>  6b54170 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/JmxManagerLocatorRequest.java
>  0efba01 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/LauncherLifecycleCommands.java
>  b3de975 
>   
> geode-core/src/test/java/org/apache/geode/cache/client/internal/AutoConnectionSourceImplJUnitTest.java
>  385569c 
> 
> 
> Diff: https://reviews.apache.org/r/59239/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Hitesh Khamesra
> 
>

[jira] [Commented] (GEODE-2911) LocatorDUnitTest.testLeadAndCoordFailure

2017-05-12 Thread Kirk Lund (JIRA)


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

Kirk Lund commented on GEODE-2911:
--

I seem to be hitting this failure very consistently.

> LocatorDUnitTest.testLeadAndCoordFailure
> 
>
> Key: GEODE-2911
> URL: https://issues.apache.org/jira/browse/GEODE-2911
> Project: Geode
>  Issue Type: Bug
>  Components: locator
>Reporter: Udo Kohlmeyer
>
> java.lang.AssertionError: expected suspect processing initiated by TCPConduit
>   at org.junit.Assert.fail(Assert.java:88)
>   at org.junit.Assert.assertTrue(Assert.java:41)
>   at 
> org.apache.geode.distributed.LocatorDUnitTest.testLeadAndCoordFailure(LocatorDUnitTest.java:856)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
>   at 
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
>   at 
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:51)
>   at 
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
>   at 
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)



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

[jira] [Commented] (GEODE-2875) shutdown is taking as long as 20 seconds


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

ASF subversion and git services commented on GEODE-2875:


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

GEODE-2875 shutdown is taking as long as 20 seconds

The fix for this issue causes one of the test cases in LocatorDUnitTest
to fail consistently. With the fix we don't create any TCP/IP connections
in this test during startup but the test expects one to have been created
and it expects the connection's reader-thread to have initiated suspect
processing.

The test needs to be altered to ensure that this thread has been created
by sending message that requires a reply. The reply will be sent over the
expected connection, ensuring that there is a reader-thread.


> shutdown is taking as long as 20 seconds
> 
>
> Key: GEODE-2875
> URL: https://issues.apache.org/jira/browse/GEODE-2875
> Project: Geode
>  Issue Type: Bug
>  Components: membership
>Reporter: Bruce Schuchardt
>Assignee: Bruce Schuchardt
>
> Recent changes have introduced a bug where sometimes, particularly during 
> shutdown of a lot of servers, the shutdown process will stall for as long as 
> 20 seconds.  This appears to be due to changes that keep a membership 
> coordinator from sending out a new view during shutdown.



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

Re: Review Request 59234: GEODE:2859: Fix ShowDeadlockDUnitTest jenkins failure

2017-05-12 Thread Jared Stewart


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

(Updated May 12, 2017, 9:18 p.m.)


Review request for geode.


Repository: geode


Description
---

- Use a TemporaryFolder to avoid failures due to file system state
- Refactor test


Diffs
-

  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ShowDeadlockDUnitTest.java
 a5293eb0fa0a2599b837abc76903704a45428111 


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


Testing (updated)
---

Precheckin passed


Thanks,

Jared Stewart

[jira] [Created] (GEODE-2916) CI failure: CacheAdvisorDUnitTest.testNetLoadAdviceWithAttributesMutator

2017-05-12 Thread Lynn Gallinat (JIRA)

Lynn Gallinat created GEODE-2916:


 Summary: CI failure: 
CacheAdvisorDUnitTest.testNetLoadAdviceWithAttributesMutator
 Key: GEODE-2916
 URL: https://issues.apache.org/jira/browse/GEODE-2916
 Project: Geode
  Issue Type: Bug
  Components: configuration
Reporter: Lynn Gallinat


org.apache.geode.internal.cache.CacheAdvisorDUnitTest > 
testNetLoadAdviceWithAttributesMutator FAILED
org.apache.geode.test.dunit.RMIException: While invoking 
org.apache.geode.internal.cache.CacheAdvisorDUnitTest$5.run in VM 1 running on 
Host 625a8f112303 with 4 VMs
at org.apache.geode.test.dunit.VM.invoke(VM.java:377)
at org.apache.geode.test.dunit.VM.invoke(VM.java:347)
at org.apache.geode.test.dunit.VM.invoke(VM.java:292)
at 
org.apache.geode.internal.cache.CacheAdvisorDUnitTest.testNetLoadAdviceWithAttributesMutator(CacheAdvisorDUnitTest.java:207)

Caused by:
java.lang.AssertionError: expected:<4> but was:<3>




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

[GitHub] geode-native pull request #98: Test commit for Vince & Scott

2017-05-12 Thread echobravopapa

GitHub user echobravopapa opened a pull request:

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

Test commit for Vince & Scott

DO NOT MERGE THIS!

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

$ git pull https://github.com/echobravopapa/geode-native feature/GEODE-4242

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

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


commit 8daa626d82ed0fb029c5ee747f606be3b25a941c
Author: Ernest Burghardt 
Date:   2017-05-12T21:07:06Z

Test commit for Vince & Scott




---
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 59237: GEODE-2875 shutdown is taking as long as 20 seconds

2017-05-12 Thread Udo Kohlmeyer


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


Ship it!




Ship It!

- Udo Kohlmeyer


On May 12, 2017, 6:29 p.m., Bruce Schuchardt wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59237/
> ---
> 
> (Updated May 12, 2017, 6:29 p.m.)
> 
> 
> Review request for geode, Galen O'Sullivan, Hitesh Khamesra, and Udo 
> Kohlmeyer.
> 
> 
> Bugs: GEODE-2875
> https://issues.apache.org/jira/browse/GEODE-2875
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> The fix for this issue causes one of the test cases in LocatorDUnitTest to 
> fail consistently. With the fix we don't create any TCP/IP connections in 
> this test during startup but the test expects one to have been created and it 
> expects the connection's reader-thread to have initiated suspect processing.
> 
> The test needs to be altered to ensure that this thread has been created by 
> sending message that requires a reply. The reply will be sent over the 
> expected connection, ensuring that there is a reader-thread.
> 
> 
> Diffs
> -
> 
>   geode-core/src/test/java/org/apache/geode/distributed/LocatorDUnitTest.java 
> 6f01f9094bb9cfb35031c51472b2fd9a532e3ee3 
> 
> 
> Diff: https://reviews.apache.org/r/59237/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Bruce Schuchardt
> 
>

Review Request 59242: GEODE-2915 Messages rejected due to unknown "vmkind"

2017-05-12 Thread Bruce Schuchardt

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

Review request for geode, Galen O'Sullivan, Hitesh Khamesra, and Udo Kohlmeyer.

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

Repository: geode

Description
---

The fix for GEODE_2875 has exacerbated this problem, which we used to only see
in cases where disable-tcp=true or when multicast was enabled.

The problem is that JGroupsMessenger is not sending the "vmkind" of the sender
in message headers. This part of the header comes from
GMSMember.writeEssentialData(). I've changed it here to include the vmKind if
the recipient isn't using geode 1.0, which doesn't expect the version byte.

Diffs
-

geode-core/src/main/java/org/apache/geode/distributed/internal/membership/InternalDistributedMember.java
41c85d6421c8283163b70f2a560c8e4cbb02f2cc

geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/GMSMember.java
b7079f8bc20a0e58949b69b9f0174a26af1a9b86

geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/mgr/GMSMembershipManager.java
0476bbbfa4a1480d3b31a052e98dc62d9f0e3867
geode-core/src/main/java/org/apache/geode/internal/i18n/LocalizedStrings.java
85042da54f5a2a772d39ba450110073e14a30196

geode-core/src/test/java/org/apache/geode/distributed/internal/membership/gms/GMSMemberJUnitTest.java
f471ad99b56615a1935ccf52127960f4af763d7d

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

Testing
---

new unit test. Precheckin is underway. I expect AnalyzeSerializables to fail
& will need to update its sanctionedDataSerializables.txt record for GMSMember.

Thanks,

Bruce Schuchardt

[jira] [Created] (GEODE-2915) Messages rejected due to unknown "vmkind"

2017-05-12 Thread ASF subversion and git services (JIRA)

Bruce Schuchardt created GEODE-2915:
---

 Summary: Messages rejected due to unknown "vmkind"
 Key: GEODE-2915
 URL: https://issues.apache.org/jira/browse/GEODE-2915
 Project: Geode
  Issue Type: Bug
  Components: messaging
Reporter: Bruce Schuchardt


Periodically we are seeing messages being rejected with the following error:


{noformat}
[warning 2017/02/25 10:28:49.539 PST 
gemfire2_rs-FullRegression-2017-02-25-03-00-45-client-30_6335 
 
tid=0x14] Membership: Error handling startup event
org.apache.geode.InternalGemFireError: Unknown  member type:  0
at 
org.apache.geode.distributed.internal.DistributionManager.addNewMember(DistributionManager.java:1787)
at 
org.apache.geode.distributed.internal.DistributionManager$MyListener.newMemberConnected(DistributionManager.java:4319)
at 
org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.addSurpriseMember(GMSMembershipManager.java:972)
at 
org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.dispatchMessage(GMSMembershipManager.java:1094)
at 
org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.processStartupEvent(GMSMembershipManager.java:1204)
at 
org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.startEventProcessing(GMSMembershipManager.java:1254)
at 
org.apache.geode.distributed.internal.DistributionManager.(DistributionManager.java:1185)
at 
org.apache.geode.distributed.internal.DistributionManager.create(DistributionManager.java:531)
at 
org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:687)
at 
org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:299)
at 
org.apache.geode.distributed.DistributedSystem.connect(DistributedSystem.java:202)
at 
hydra.DistributedSystemHelper._connect(DistributedSystemHelper.java:110)
at 
hydra.DistributedSystemHelper.connect(DistributedSystemHelper.java:73)
at perffmwk.PerformanceStatistics.factory(PerformanceStatistics.java:93)
at 
cacheperf.CachePerfStats.getStatisticDescriptors(CachePerfStats.java:96)
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 
perffmwk.PerformanceStatistics.getStatisticsType(PerformanceStatistics.java:139)
at 
perffmwk.PerformanceStatistics.getInstance(PerformanceStatistics.java:125)
at 
perffmwk.PerformanceStatistics.getInstance(PerformanceStatistics.java:105)
at cacheperf.CachePerfStats.getInstance(CachePerfStats.java:216)
at cacheperf.CachePerfClient.openStatistics(CachePerfClient.java:965)
at 
cacheperf.CachePerfClient.openStatisticsTask(CachePerfClient.java:959)
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)
{noformat}



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

Review Request 59239: Allow a locator host to be taken off line and replaced with a different machine having the same host name

2017-05-12 Thread Hitesh Khamesra

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

Review request for geode, Bruce Schuchardt, Galen O'Sullivan, and Udo Kohlmeyer.

Repository: geode

Description
---

GEODE-2804 Update InetSocketAddress, when there is IOException.

Geode keeps InetSocketAddress for locators. So, if locators ip
changes in cloud/VM enviroment then Geode process unable to
connect to locator. Thus we have fixed this problem in two way.

a. If Geode client sees IOException while connectin to locator then
we change cached InetAddress to use locator hostname. In this way,
client does DNS query again for locator host.
b. For other Geode process, now we connect to locator using hostname.

Added couple of junit tests for it.

Diffs
-

geode-core/src/main/java/org/apache/geode/cache/client/internal/AutoConnectionSourceImpl.java
1e807ee

geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/membership/GMSJoinLeave.java
4bf010b

geode-core/src/main/java/org/apache/geode/distributed/internal/tcpserver/TcpClient.java
6b54170

geode-core/src/main/java/org/apache/geode/management/internal/JmxManagerLocatorRequest.java
0efba01

geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/LauncherLifecycleCommands.java
b3de975

geode-core/src/test/java/org/apache/geode/cache/client/internal/AutoConnectionSourceImplJUnitTest.java
385569c

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

Testing
---

Thanks,

Hitesh Khamesra

[GitHub] geode pull request #512: GEODE-2637: Refactored LuceneQueryFactory.setResult...

2017-05-12 Thread asfgit

Github user asfgit closed the pull request at:

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


---
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-2637) LuceneQueryFactory.setResultLimit() method should match LuceneQuery.getLimit()


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

ASF subversion and git services commented on GEODE-2637:


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

GEODE-2637: Refactored LuceneQueryFactory.setResultLimit()

* Renamed LuceneQueryFactory.getResult to setLimit()
* This is done to match the cwiki documents


> LuceneQueryFactory.setResultLimit() method should match LuceneQuery.getLimit()
> --
>
> Key: GEODE-2637
> URL: https://issues.apache.org/jira/browse/GEODE-2637
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Affects Versions: 1.2.0
>Reporter: Shelley Lynn Hughes-Godfrey
>Assignee: Shelley Lynn Hughes-Godfrey
>
> In the Lucene docs located here:
>  https://cwiki.apache.org/confluence/display/GEODE/Text+Search+With+Lucene
> we see that we control the number of results from the lucene query via 
> LuceneQueryFactory.setLimit() which corresponds directly with the 
> LuceneQuery.getLimit() method.
> However, this has been implemented as LuceneQueryFactory.setResultLimit().
> This needs to be changed to setLimit().



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

[jira] [Commented] (GEODE-2637) LuceneQueryFactory.setResultLimit() method should match LuceneQuery.getLimit()


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

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

Github user asfgit closed the pull request at:

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


> LuceneQueryFactory.setResultLimit() method should match LuceneQuery.getLimit()
> --
>
> Key: GEODE-2637
> URL: https://issues.apache.org/jira/browse/GEODE-2637
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Affects Versions: 1.2.0
>Reporter: Shelley Lynn Hughes-Godfrey
>Assignee: Shelley Lynn Hughes-Godfrey
>
> In the Lucene docs located here:
>  https://cwiki.apache.org/confluence/display/GEODE/Text+Search+With+Lucene
> we see that we control the number of results from the lucene query via 
> LuceneQueryFactory.setLimit() which corresponds directly with the 
> LuceneQuery.getLimit() method.
> However, this has been implemented as LuceneQueryFactory.setResultLimit().
> This needs to be changed to setLimit().



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

[jira] [Assigned] (GEODE-2874) StringIndexOutOfBoundsException while initializing logger

2017-05-12 Thread Jared Stewart (JIRA)


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

Jared Stewart reassigned GEODE-2874:


Assignee: Jared Stewart

> StringIndexOutOfBoundsException while initializing logger
> -
>
> Key: GEODE-2874
> URL: https://issues.apache.org/jira/browse/GEODE-2874
> Project: Geode
>  Issue Type: Bug
>  Components: management
>Reporter: Hitesh Khamesra
>Assignee: Jared Stewart
>
> Exception in thread "main" java.lang.StringIndexOutOfBoundsException: String 
> index out of range: -1
>   at java.lang.String.substring(String.java:1967)
>   at 
> org.apache.geode.internal.io.MainWithChildrenRollingFileHandler.calcNextChildId(MainWithChildrenRollingFileHandler.java:47)
>   at 
> org.apache.geode.internal.logging.ManagerLogWriter.getLogNameForOldMainLog(ManagerLogWriter.java:330)
>   at 
> org.apache.geode.internal.logging.log4j.LogWriterAppenders.createLogWriterAppender(LogWriterAppenders.java:144)
>   at 
> org.apache.geode.internal.logging.log4j.LogWriterAppenders.getOrCreateAppender(LogWriterAppenders.java:72)
>   at 
> org.apache.geode.internal.logging.log4j.LogWriterAppenders.getOrCreateAppender(LogWriterAppenders.java:88)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:591)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:304)
>   at 
> org.apache.geode.distributed.DistributedSystem.connect(DistributedSystem.java:206)
>   at 
> org.apache.geode.cache.client.ClientCacheFactory.basicCreate(ClientCacheFactory.java:235)
>   at 
> org.apache.geode.cache.client.ClientCacheFactory.create(ClientCacheFactory.java:207)
>   at GeodeClient.GeodeClient(GeodeClient.java:22)
>   at GeodeClient.main(GeodeClient.java:10)



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

Re: Review Request 59237: GEODE-2875 shutdown is taking as long as 20 seconds

2017-05-12 Thread Hitesh Khamesra


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


Ship it!




Ship It!

- Hitesh Khamesra


On May 12, 2017, 6:29 p.m., Bruce Schuchardt wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59237/
> ---
> 
> (Updated May 12, 2017, 6:29 p.m.)
> 
> 
> Review request for geode, Galen O'Sullivan, Hitesh Khamesra, and Udo 
> Kohlmeyer.
> 
> 
> Bugs: GEODE-2875
> https://issues.apache.org/jira/browse/GEODE-2875
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> The fix for this issue causes one of the test cases in LocatorDUnitTest to 
> fail consistently. With the fix we don't create any TCP/IP connections in 
> this test during startup but the test expects one to have been created and it 
> expects the connection's reader-thread to have initiated suspect processing.
> 
> The test needs to be altered to ensure that this thread has been created by 
> sending message that requires a reply. The reply will be sent over the 
> expected connection, ensuring that there is a reader-thread.
> 
> 
> Diffs
> -
> 
>   geode-core/src/test/java/org/apache/geode/distributed/LocatorDUnitTest.java 
> 6f01f9094bb9cfb35031c51472b2fd9a532e3ee3 
> 
> 
> Diff: https://reviews.apache.org/r/59237/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Bruce Schuchardt
> 
>

Review Request 59237: GEODE-2875 shutdown is taking as long as 20 seconds

2017-05-12 Thread Bruce Schuchardt


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

Review request for geode, Galen O'Sullivan, Hitesh Khamesra, and Udo Kohlmeyer.


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


Repository: geode


Description
---

The fix for this issue causes one of the test cases in LocatorDUnitTest to fail 
consistently. With the fix we don't create any TCP/IP connections in this test 
during startup but the test expects one to have been created and it expects the 
connection's reader-thread to have initiated suspect processing.

The test needs to be altered to ensure that this thread has been created by 
sending message that requires a reply. The reply will be sent over the expected 
connection, ensuring that there is a reader-thread.


Diffs
-

  geode-core/src/test/java/org/apache/geode/distributed/LocatorDUnitTest.java 
6f01f9094bb9cfb35031c51472b2fd9a532e3ee3 


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


Testing
---


Thanks,

Bruce Schuchardt

[jira] [Reopened] (GEODE-2875) shutdown is taking as long as 20 seconds


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

Bruce Schuchardt reopened GEODE-2875:
-
  Assignee: Bruce Schuchardt

The fix for this issue causes one of the test cases in LocatorDUnitTest to fail 
consistently.  With the fix we don't create any TCP/IP connections in this test 
during startup but the test expects one to have been created and it expects the 
connection's reader-thread to have initiated suspect processing.

The test needs to be altered to ensure that this thread has been created by 
sending message that requires a reply.  The reply will be sent over the 
expected connection, ensuring that there is a reader-thread.

> shutdown is taking as long as 20 seconds
> 
>
> Key: GEODE-2875
> URL: https://issues.apache.org/jira/browse/GEODE-2875
> Project: Geode
>  Issue Type: Bug
>  Components: membership
>Reporter: Bruce Schuchardt
>Assignee: Bruce Schuchardt
>
> Recent changes have introduced a bug where sometimes, particularly during 
> shutdown of a lot of servers, the shutdown process will stall for as long as 
> 20 seconds.  This appears to be due to changes that keep a membership 
> coordinator from sending out a new view during shutdown.



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

Re: Review Request 59210: GEODE-2912: Hot deploy for functions in deployed Jars


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


Ship it!




Ship It!

- Jinmei Liao


On May 12, 2017, 6:06 p.m., Jared Stewart wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59210/
> ---
> 
> (Updated May 12, 2017, 6:06 p.m.)
> 
> 
> Review request for geode.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2912: Hot deploy for functions in deployed Jars
> 
> - New versions of a function now deploy over top the old versions without an 
> intermediate undeploy
> 
> 
> Diffs
> -
> 
>   geode-core/src/main/java/org/apache/geode/internal/DeployedJar.java acb7d22 
>   geode-core/src/main/java/org/apache/geode/internal/JarDeployer.java df3f10b 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/DeployCommandRedeployDUnitTest.java
>  6972477 
> 
> 
> Diff: https://reviews.apache.org/r/59210/diff/2/
> 
> 
> Testing
> ---
> 
> Precheckin running
> 
> 
> Thanks,
> 
> Jared Stewart
> 
>

Re: Review Request 59210: GEODE-2912: Hot deploy for functions in deployed Jars

2017-05-12 Thread Ken Howe


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


Ship it!




Ship It!

- Ken Howe


On May 12, 2017, 6:06 p.m., Jared Stewart wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59210/
> ---
> 
> (Updated May 12, 2017, 6:06 p.m.)
> 
> 
> Review request for geode.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2912: Hot deploy for functions in deployed Jars
> 
> - New versions of a function now deploy over top the old versions without an 
> intermediate undeploy
> 
> 
> Diffs
> -
> 
>   geode-core/src/main/java/org/apache/geode/internal/DeployedJar.java acb7d22 
>   geode-core/src/main/java/org/apache/geode/internal/JarDeployer.java df3f10b 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/DeployCommandRedeployDUnitTest.java
>  6972477 
> 
> 
> Diff: https://reviews.apache.org/r/59210/diff/2/
> 
> 
> Testing
> ---
> 
> Precheckin running
> 
> 
> Thanks,
> 
> Jared Stewart
> 
>

[jira] [Commented] (GEODE-2890) Incorrect debug log location in AbstractGatewaySenderEventProcessor.processQueue()


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

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

Github user jhuynh1 commented on the issue:

https://github.com/apache/geode/pull/505
  
Yeah I think so.  Thanks!


> Incorrect debug log location in 
> AbstractGatewaySenderEventProcessor.processQueue() 
> ---
>
> Key: GEODE-2890
> URL: https://issues.apache.org/jira/browse/GEODE-2890
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Reporter: Jason Huynh
>Assignee: Amey Barve
>
> The following code snippet in processQueue() for AEQ's appears to be outside 
> of an if condition where we check to see if the node is primary still or not. 
>  This line prints for every event and I believe it should be inside the 
> previous if condition. 
> {noformat}
> if (qpr != null) {
>BucketRegion bucket = qpr.getDataStore().getLocalBucketById(bucketId);
>if (bucket == null || !bucket.getBucketAdvisor().isPrimary()) {
>  event.setPossibleDuplicate(true);
> //I think the debug log should be placed here?
>}
> }
> if (isDebugEnabled) {
>   logger.debug( "Bucket id: {} is no longer primary on this node. The event 
> {} will be dispatched from this node with possibleDuplicate set to true.", 
> bucketId, event);
> }
> {noformat}



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

[GitHub] geode issue #505: [GEODE-2890]: Corrected debug log location in AbstractGate...

2017-05-12 Thread jhuynh1

Github user jhuynh1 commented on the issue:

https://github.com/apache/geode/pull/505
  
Yeah I think so.  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.
---

Re: Review Request 59210: GEODE-2912: Hot deploy for functions in deployed Jars

2017-05-12 Thread Jared Stewart


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

(Updated May 12, 2017, 6:06 p.m.)


Review request for geode.


Repository: geode


Description
---

GEODE-2912: Hot deploy for functions in deployed Jars

- New versions of a function now deploy over top the old versions without an 
intermediate undeploy


Diffs (updated)
-

  geode-core/src/main/java/org/apache/geode/internal/DeployedJar.java acb7d22 
  geode-core/src/main/java/org/apache/geode/internal/JarDeployer.java df3f10b 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/DeployCommandRedeployDUnitTest.java
 6972477 


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

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


Testing
---

Precheckin running


Thanks,

Jared Stewart

[jira] [Updated] (GEODE-2906) Users need easy co-location of entries on partitioned regions

2017-05-12 Thread Fred Krone (JIRA)


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

Fred Krone updated GEODE-2906:
--
Description: 
Implement a dynamic PartitionResolver that takes a String key and uses a '.' as 
the separator between the actual key and the partitioning key, returning the 
partitioning key when called. 

The actual key would be the entire string, the partitioning key would be 
everything after the last '.' unless there are no dots in which case it is the 
whole String (which is the default without a PartitionResolver).

Requirements:
Make configurable via GFSH, cache.xml, or programmatically
-- Allow them to define their own resolver token
Make it work from the client
-- Putting a key that doesn't match configuration -- should throw exception
-- Not serializable
-- Will need to update the client to know the token (?)

  was:
Implement a dynamic PartitionResolver that takes a String key and uses a '.' as 
the separator between the actual key and the partitioning key, returning the 
partitioning key when called. 

The actual key would be the entire string, the partitioning key would be 
everything after the last '.' unless there are no dots in which case it is the 
whole String (which is the default without a PartitionResolver).

Requirements:
Make configurable via GFSH, cache.xml, or programmatically
-- Allow them to define their own resolver token
Make it work from the client
-- Putting a key that doesn't match configuration -- should throw exception



> Users need easy co-location of entries on partitioned regions
> -
>
> Key: GEODE-2906
> URL: https://issues.apache.org/jira/browse/GEODE-2906
> Project: Geode
>  Issue Type: Improvement
>  Components: docs, regions
>Reporter: Fred Krone
>
> Implement a dynamic PartitionResolver that takes a String key and uses a '.' 
> as the separator between the actual key and the partitioning key, returning 
> the partitioning key when called. 
> The actual key would be the entire string, the partitioning key would be 
> everything after the last '.' unless there are no dots in which case it is 
> the whole String (which is the default without a PartitionResolver).
> Requirements:
> Make configurable via GFSH, cache.xml, or programmatically
> -- Allow them to define their own resolver token
> Make it work from the client
> -- Putting a key that doesn't match configuration -- should throw exception
> -- Not serializable
> -- Will need to update the client to know the token (?)



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

Build failed in Jenkins: Geode-nightly #833

2017-05-12 Thread Apache Jenkins Server

See 


Changes:

[gzhou] GEODE-1775: Run a few hundreds times and not reproducable any more. No

[abaker] GEODE-2897 Add PR template for github

[bschuchardt] GEODE-2812: Add API to get list of live locators

[bschuchardt] GEODE-2812: Add API to get list of live locators

[bschuchardt] Change "LiveLocator", "ActiveLocator" to "OnlineLocator".

[jstewart] GEODE-2883: Fix GFSH gc heap size output

[kmiller] GEODE-2909  CTR fix of 2 typos in Lucene documentation

[nnag] GEODE-2907: Removed @Experimental tag from the Lucene module

[jstewart] GEODE-2859: Fix race in ShowDeadlockDUnitTest

[gzhou] GEODE-11: add unit test for soundex analyzer

[boglesby] GEODE-1130: Removed log message

[jiliao] GEODE-2876: add logging and testing to diagnose test failure

[adongre] GEODE-254: Addressing review comments from PR #488 Replacing all

[adongre] GEODE-237: Removed deprecated API from EntryEvent This closes #496

--
[...truncated 104.52 KB...]
: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:compileTestJava
Download 
https://repo1.maven.org/maven2/org/apache/lucene/lucene-analyzers-phonetic/6.4.1/lucene-analyzers-phonetic-6.4.1.pom
Download 
https://repo1.maven.org/maven2/org/apache/lucene/lucene-analyzers-phonetic/6.4.1/lucene-analyzers-phonetic-6.4.1.jar
Note: 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
:geode-pulse:spotlessCheck
:geode-pulse:test
:geode-pulse:check
:geode-pulse:build
:geode-pulse:distributedTest
:geode-pulse:flakyTest
:geode-pulse:integrationTest
:geode-rebalancer:assemble
:geode-rebalancer:compileTestJava
:geode-rebalancer:processTestResources UP-TO-DATE
:geode-rebalancer:testClasses
:geode-rebalancer:

[jira] [Updated] (GEODE-2906) Users need easy co-location of entries on partitioned regions

2017-05-12 Thread Fred Krone (JIRA)


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

Fred Krone updated GEODE-2906:
--
Description: 
Implement a dynamic PartitionResolver that takes a String key and uses a '.' as 
the separator between the actual key and the partitioning key, returning the 
partitioning key when called. 

The actual key would be the entire string, the partitioning key would be 
everything after the last '.' unless there are no dots in which case it is the 
whole String (which is the default without a PartitionResolver).

Requirements:
Make configurable via GFSH, cache.xml, or programmatically
-- Allow them to define their own resolver token
Make it work from the client
-- Putting a key that doesn't match configuration -- should throw exception


  was:
Implement a dynamic PartitionResolver that takes a String key and uses a '.' as 
the separator between the actual key and the partitioning key, returning the 
partitioning key when called. 

The actual key would be the entire string, the partitioning key would be 
everything after the last '.' unless there are no dots in which case it is the 
whole String (which is the default without a PartitionResolver).

Requirements:
Make configurable via GFSH, cache.xml, or programmatically
-- Allow them to define their own resolver token
Make it work from the client



> Users need easy co-location of entries on partitioned regions
> -
>
> Key: GEODE-2906
> URL: https://issues.apache.org/jira/browse/GEODE-2906
> Project: Geode
>  Issue Type: Improvement
>  Components: docs, regions
>Reporter: Fred Krone
>
> Implement a dynamic PartitionResolver that takes a String key and uses a '.' 
> as the separator between the actual key and the partitioning key, returning 
> the partitioning key when called. 
> The actual key would be the entire string, the partitioning key would be 
> everything after the last '.' unless there are no dots in which case it is 
> the whole String (which is the default without a PartitionResolver).
> Requirements:
> Make configurable via GFSH, cache.xml, or programmatically
> -- Allow them to define their own resolver token
> Make it work from the client
> -- Putting a key that doesn't match configuration -- should throw exception



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

[jira] [Commented] (GEODE-2914) Lucene javadoc cleanup

2017-05-12 Thread ASF subversion and git services (JIRA)


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

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

GitHub user jhuynh1 opened a pull request:

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

GEODE-2914: Tidy up LuceneService javadoc

Potential reviewers:
@karensmolermiller @nabarunnag @ladyVader

Fixing typos and javadoc issues


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

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

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

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


commit 433e84e7a364228a1adbee1fdd7c0f7a7975ea8b
Author: Jason Huynh 
Date:   2017-05-12T17:42:01Z

GEODE-2914: Tidy up LuceneService javadoc




> Lucene javadoc cleanup
> --
>
> Key: GEODE-2914
> URL: https://issues.apache.org/jira/browse/GEODE-2914
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Jason Huynh
>Assignee: Jason Huynh
>
> There are a few javadoc errors in LuceneService.  The  inside the 
>  tags appears to convert the remaining javadoc into "code".
> Typo with non, should be none.



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

[GitHub] geode pull request #513: GEODE-2914: Tidy up LuceneService javadoc

2017-05-12 Thread jhuynh1

GitHub user jhuynh1 opened a pull request:

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

GEODE-2914: Tidy up LuceneService javadoc

Potential reviewers:
@karensmolermiller @nabarunnag @ladyVader

Fixing typos and javadoc issues


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

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

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

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


commit 433e84e7a364228a1adbee1fdd7c0f7a7975ea8b
Author: Jason Huynh 
Date:   2017-05-12T17:42:01Z

GEODE-2914: Tidy up LuceneService javadoc




---
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-2914) Lucene javadoc cleanup


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

ASF subversion and git services commented on GEODE-2914:


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

GEODE-2914: Tidy up LuceneService javadoc


> Lucene javadoc cleanup
> --
>
> Key: GEODE-2914
> URL: https://issues.apache.org/jira/browse/GEODE-2914
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Jason Huynh
>Assignee: Jason Huynh
>
> There are a few javadoc errors in LuceneService.  The  inside the 
>  tags appears to convert the remaining javadoc into "code".
> Typo with non, should be none.



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

[jira] [Assigned] (GEODE-2914) Lucene javadoc cleanup

2017-05-12 Thread Jason Huynh (JIRA)


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

Jason Huynh reassigned GEODE-2914:
--

Assignee: Jason Huynh

> Lucene javadoc cleanup
> --
>
> Key: GEODE-2914
> URL: https://issues.apache.org/jira/browse/GEODE-2914
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Jason Huynh
>Assignee: Jason Huynh
>
> There are a few javadoc errors in LuceneService.  The  inside the 
>  tags appears to convert the remaining javadoc into "code".
> Typo with non, should be none.



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

[jira] [Created] (GEODE-2914) Lucene javadoc cleanup

2017-05-12 Thread Jason Huynh (JIRA)

Jason Huynh created GEODE-2914:
--

 Summary: Lucene javadoc cleanup
 Key: GEODE-2914
 URL: https://issues.apache.org/jira/browse/GEODE-2914
 Project: Geode
  Issue Type: Bug
  Components: lucene
Reporter: Jason Huynh


There are a few javadoc errors in LuceneService.  The  inside the  
tags appears to convert the remaining javadoc into "code".

Typo with non, should be none.




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

[jira] [Updated] (GEODE-2913) Update Lucene documentation

2017-05-12 Thread Karen Smoler Miller (JIRA)


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

Karen Smoler Miller updated GEODE-2913:
---
Description: 
Improvements to the code base that need to be reflected in the docs:
* Change LuceneService.createIndex to use a factory pattern
{code:java}
luceneService.createIndex(region, index, ...)
{code}
changes to
{code:java}
luceneService.createIndexFactory()
.addField("field1name")
.addField("field2name")
.create()
{code}
*  Lucene indexes will *NOT* be stored in off-heap memory.
* Document how to configure an index on accessors - you still need to create 
the Lucene index before creating the region, even though this member does not 
hold any region data.
If the index is not defined on the accessor, an exception like this will be 
thrown while attempting to create the region:
{quote}
[error 2017/05/02 15:19:26.018 PDT  tid=0x1] 
java.lang.IllegalStateException: Must create Lucene index full_index on region 
/data because it is defined in another member.
Exception in thread "main" java.lang.IllegalStateException: Must create Lucene 
index full_index on region /data because it is defined in another member.
at 
org.apache.geode.internal.cache.CreateRegionProcessor$CreateRegionMessage.handleCacheDistributionAdvisee(CreateRegionProcessor.java:478)
at 
org.apache.geode.internal.cache.CreateRegionProcessor$CreateRegionMessage.process(CreateRegionProcessor.java:379)
{quote}
* Do not need to create a Lucene index on a client with a Proxy cache. The 
Lucene search will always be done on the server.  Besides, _you can't create an 
index on a client._
* If you configure Invalidates for region entries (alone or as part of 
expiration), these will *NOT* invalidate the Lucene indexes.
The problem with this is the index contains the keys, but the region doesn't, 
so the query produces results that don't exist.
In this test, the first time the query is run, it produces N valid results. The 
second time it is run it produces N empty results:
** load entries
** run query
** invalidate entries
** run query again
*  Destroying a region will *NOT* automatically destroy any Lucene index 
associated with that region. Instead, attempting to destroy a region with a 
Lucene index will throw a colocated region exception. 
An IllegalStateException is thrown:
{quote}
java.lang.IllegalStateException: The parent region [/data] in colocation chain 
cannot be destroyed, unless all its children [[/cusip_index#_data.files]] are 
destroyed
at 
org.apache.geode.internal.cache.PartitionedRegion.checkForColocatedChildren(PartitionedRegion.java:7231)
at 
org.apache.geode.internal.cache.PartitionedRegion.destroyRegion(PartitionedRegion.java:7243)
at 
org.apache.geode.internal.cache.AbstractRegion.destroyRegion(AbstractRegion.java:308)
at 
DestroyLuceneIndexesAndRegionFunction.destroyRegion(DestroyLuceneIndexesAndRegionFunction.java:46)
{quote}
* The process to change a Lucene index using gfsh: 
  1. export region data
  2. destroy Lucene index, destroy region 
  3. create new index, create new region without user-defined business 
logic callbacks
  4. import data with option to turn on callbacks (to invoke Lucene Async 
Event Listener to index the data)
  5. alter region to add user-defined business logic callbacks
* Make sure there are no references to replicated regions as they are not 
supported.
* Document security implementation and defaults.  If a user has security 
configured for their cluster, creating a Lucene index requires DATA:MANAGE 
privilege (similar to OQL), but doing Lucene queries requires DATA:WRITE 
privilege because a function is called (different from OQL which requires only 
DATA:READ privilege). Here are all the required privileges for the gfsh 
commands:
** create index requires DATA:MANAGE:region
** describe index requires CLUSTER:READ
** list indexes requires CLUSTER:READ
** search index requires DATA:WRITE
** destroy index requires DATA:MANAGE:region
* A user cannot create a Lucene index on a region that has eviction configured 
with local destroy. If using Lucene indexing, eviction can only be configured 
with overflow to disk. In this case, only the region data is overflowed to 
disk, *NOT* the Lucene index. An UnsupportedOperationException is thrown:
{quote}
[error 2017/05/02 16:12:32.461 PDT  tid=0x1] 
java.lang.UnsupportedOperationException: Lucene indexes on regions with 
eviction and action local destroy are not supported
Exception in thread "main" java.lang.UnsupportedOperationException: Lucene 
indexes on regions with eviction and action local destroy are not supported
at 
org.apache.geode.cache.lucene.internal.LuceneRegionListener.beforeCreate(LuceneRegionListener.java:85)
at 
org.apache.geode.internal.cache.GemFireCacheImpl.invokeRegionBefore(GemFireCacheImpl.java:3154)
at 
org.apache.geode.internal.cache.GemFireCacheImpl.createVMRegion(GemFireCacheImpl.java:3013)
at 
org.ap

Review Request 59234: GEODE:2859: Fix ShowDeadlockDUnitTest jenkins failure

2017-05-12 Thread Jared Stewart


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

Review request for geode.


Repository: geode


Description
---

- Use a TemporaryFolder to avoid failures due to file system state
- Refactor test


Diffs
-

  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ShowDeadlockDUnitTest.java
 a5293eb0fa0a2599b837abc76903704a45428111 


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


Testing
---

Precheckin running


Thanks,

Jared Stewart

[jira] [Commented] (GEODE-2853) Change of locator list request interval


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

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

Github user bschuchardt commented on the issue:

https://github.com/apache/geode/pull/483
  
I will merge this pull request to develop.  I may not get it done until 
early next week.


> Change of locator list request interval
> ---
>
> Key: GEODE-2853
> URL: https://issues.apache.org/jira/browse/GEODE-2853
> Project: Geode
>  Issue Type: Improvement
>  Components: client/server
>Reporter: Masaki Yamakawa
>Priority: Minor
>
> If you connect to a Geode cluster using a locator from the client, the 
> locator list request will be executed at regular intervals in the background 
> thread. I want to tune this interval. I understand that this interval can be 
> changed by the ping-interval of the Pool attribute. However, I think that 
> ping-interval originally sets the ping interval for health check to the cache 
> server. Therefore, it is not possible to change the locator list request 
> interval without changing the health check interval to the cache server. So,I 
> want to add a java system property that can change the locator list request 
> interval.
> The locator list request interval is determined by the following priority 
> order.
>   1. java system property "gemfire.LOCATOR_UPDATE_INTERVAL"
>   2. ping-interval of the Pool attribute
> In addition, when changing this time, the background thread is activated only 
> when this value is a positive value.



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

[GitHub] geode issue #483: GEODE-2853: Change of locator list request interval

2017-05-12 Thread bschuchardt

Github user bschuchardt commented on the issue:

https://github.com/apache/geode/pull/483
  
I will merge this pull request to develop.  I may not get it done until 
early next week.


---
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-2913) Update Lucene documentation

2017-05-12 Thread Karen Smoler Miller (JIRA)


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

Karen Smoler Miller commented on GEODE-2913:


Both gfsh commands ({{destroy lucene index}} and {{describe lucene index}} have 
already been documented.  However, review of these pages leads to another task 
for this ticket:
* The Example Commands subsection of the {{destroy lucene index}} gfsh command 
reference page needs to be revised.  It specifies a --member option which 
probably ought to be a region option.


> Update Lucene documentation
> ---
>
> Key: GEODE-2913
> URL: https://issues.apache.org/jira/browse/GEODE-2913
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Karen Smoler Miller
>Assignee: Karen Smoler Miller
>
> Improvements to the code base that need to be reflected in the docs:
> * Change LuceneService.createIndex to use a factory pattern
> {code:java}
> luceneService.createIndex(region, index, ...)
> {code}
> changes to
> {code:java}
> luceneService.createIndexFactory()
> .setXXX()
> .setYYY()
> .create()
> {code}
> *  Lucene indexes will *NOT* be stored in off-heap memory.
> * Document how to configure an index on accessors - you still need to create 
> the Lucene index before creating the region, even though this member does not 
> hold any region data.
> If the index is not defined on the accessor, an exception like this will be 
> thrown while attempting to create the region:
> {quote}
> [error 2017/05/02 15:19:26.018 PDT  tid=0x1] 
> java.lang.IllegalStateException: Must create Lucene index full_index on 
> region /data because it is defined in another member.
> Exception in thread "main" java.lang.IllegalStateException: Must create 
> Lucene index full_index on region /data because it is defined in another 
> member.
> at 
> org.apache.geode.internal.cache.CreateRegionProcessor$CreateRegionMessage.handleCacheDistributionAdvisee(CreateRegionProcessor.java:478)
> at 
> org.apache.geode.internal.cache.CreateRegionProcessor$CreateRegionMessage.process(CreateRegionProcessor.java:379)
> {quote}
> * Do not need to create a Lucene index on a client with a Proxy cache. The 
> Lucene search will always be done on the server.  Besides, _you can't create 
> an index on a client._
> * If you configure Invalidates for region entries (alone or as part of 
> expiration), these will *NOT* invalidate the Lucene indexes.
> The problem with this is the index contains the keys, but the region doesn't, 
> so the query produces results that don't exist.
> In this test, the first time the query is run, it produces N valid results. 
> The second time it is run it produces N empty results:
> ** load entries
> ** run query
> ** invalidate entries
> ** run query again
> *  Destroying a region will *NOT* automatically destroy any Lucene index 
> associated with that region. Instead, attempting to destroy a region with a 
> Lucene index will throw a colocated region exception. 
> An IllegalStateException is thrown:
> {quote}
> java.lang.IllegalStateException: The parent region [/data] in colocation 
> chain cannot be destroyed, unless all its children 
> [[/cusip_index#_data.files]] are destroyed
> at 
> org.apache.geode.internal.cache.PartitionedRegion.checkForColocatedChildren(PartitionedRegion.java:7231)
> at 
> org.apache.geode.internal.cache.PartitionedRegion.destroyRegion(PartitionedRegion.java:7243)
> at 
> org.apache.geode.internal.cache.AbstractRegion.destroyRegion(AbstractRegion.java:308)
> at 
> DestroyLuceneIndexesAndRegionFunction.destroyRegion(DestroyLuceneIndexesAndRegionFunction.java:46)
> {quote}
> * The process to change a Lucene index using gfsh: 
>   1. export region data
>   2. destroy Lucene index, destroy region 
>   3. create new index, create new region without user-defined business 
> logic callbacks
>   4. import data with option to turn on callbacks (to invoke Lucene Async 
> Event Listener to index the data)
>   5. alter region to add user-defined business logic callbacks
> * Make sure there are no references to replicated regions as they are not 
> supported.
> * Document security implementation and defaults.  If a user has security 
> configured for their cluster, creating a Lucene index requires DATA:MANAGE 
> privilege (similar to OQL), but doing Lucene queries requires DATA:WRITE 
> privilege because a function is called (different from OQL which requires 
> only DATA:READ privilege). Here are all the required privileges for the gfsh 
> commands:
> ** create index requires DATA:MANAGE:region
> ** describe index requires CLUSTER:READ
> ** list indexes requires CLUSTER:READ
> ** search index requires DATA:WRITE
> ** destroy index requires DATA:MANAGE:region
> * A user cannot create a Lucene index on a region that has evic

[jira] [Updated] (GEODE-2906) Users need easy co-location of entries on partitioned regions

2017-05-12 Thread Karen Smoler Miller (JIRA)


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

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

> Users need easy co-location of entries on partitioned regions
> -
>
> Key: GEODE-2906
> URL: https://issues.apache.org/jira/browse/GEODE-2906
> Project: Geode
>  Issue Type: Improvement
>  Components: docs, regions
>Reporter: Fred Krone
>
> Implement a dynamic PartitionResolver that takes a String key and uses a '.' 
> as the separator between the actual key and the partitioning key, returning 
> the partitioning key when called. 
> The actual key would be the entire string, the partitioning key would be 
> everything after the last '.' unless there are no dots in which case it is 
> the whole String (which is the default without a PartitionResolver).
> Requirements:
> Make configurable via GFSH, cache.xml, or programmatically
> -- Allow them to define their own resolver token
> Make it work from the client



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

[jira] [Commented] (GEODE-2853) Change of locator list request interval


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

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

Github user masaki-yamakawa commented on the issue:

https://github.com/apache/geode/pull/483
  
@kohlmu-pivotal Thank you for review.


> Change of locator list request interval
> ---
>
> Key: GEODE-2853
> URL: https://issues.apache.org/jira/browse/GEODE-2853
> Project: Geode
>  Issue Type: Improvement
>  Components: client/server
>Reporter: Masaki Yamakawa
>Priority: Minor
>
> If you connect to a Geode cluster using a locator from the client, the 
> locator list request will be executed at regular intervals in the background 
> thread. I want to tune this interval. I understand that this interval can be 
> changed by the ping-interval of the Pool attribute. However, I think that 
> ping-interval originally sets the ping interval for health check to the cache 
> server. Therefore, it is not possible to change the locator list request 
> interval without changing the health check interval to the cache server. So,I 
> want to add a java system property that can change the locator list request 
> interval.
> The locator list request interval is determined by the following priority 
> order.
>   1. java system property "gemfire.LOCATOR_UPDATE_INTERVAL"
>   2. ping-interval of the Pool attribute
> In addition, when changing this time, the background thread is activated only 
> when this value is a positive value.



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

[GitHub] geode issue #483: GEODE-2853: Change of locator list request interval

2017-05-12 Thread masaki-yamakawa

Github user masaki-yamakawa commented on the issue:

https://github.com/apache/geode/pull/483
  
@kohlmu-pivotal Thank you for review.


---
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 59210: GEODE-2912: Hot deploy for functions in deployed Jars


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




geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/DeployCommandRedeployDUnitTest.java
Lines 129 (patched)


the rule will automatically disconnect and exit. No need to call this.


- Jinmei Liao


On May 11, 2017, 9:47 p.m., Jared Stewart wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59210/
> ---
> 
> (Updated May 11, 2017, 9:47 p.m.)
> 
> 
> Review request for geode.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2912: Hot deploy for functions in deployed Jars
> 
> - New versions of a function now deploy over top the old versions without an 
> intermediate undeploy
> 
> 
> Diffs
> -
> 
>   geode-core/src/main/java/org/apache/geode/internal/DeployedJar.java 
> acb7d227a4f67c749cbc11ee2fdae8651d3bc5d6 
>   geode-core/src/main/java/org/apache/geode/internal/JarDeployer.java 
> df3f10b8cba9bdca8429bdcf8567b654d36ea475 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/DeployCommandRedeployDUnitTest.java
>  697247701f883a5532ac0118ff116ac6562776d4 
> 
> 
> Diff: https://reviews.apache.org/r/59210/diff/1/
> 
> 
> Testing
> ---
> 
> Precheckin running
> 
> 
> Thanks,
> 
> Jared Stewart
> 
>

Re: Review Request 59210: GEODE-2912: Hot deploy for functions in deployed Jars

2017-05-12 Thread Ken Howe


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




geode-core/src/main/java/org/apache/geode/internal/DeployedJar.java
Lines 219-220 (patched)


minor: extraneous blank lines



geode-core/src/main/java/org/apache/geode/internal/DeployedJar.java
Lines 233 (patched)


Can't the newVesrion == null test be pulled outside the for loop?


if (newVersion != null) {
  for ...
}




geode-core/src/main/java/org/apache/geode/internal/DeployedJar.java
Lines 409 (patched)


CollectionUtils.isEmpty(this.registeredFunctions) will handle the null 
case, and it's more concise.



geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/DeployCommandRedeployDUnitTest.java
Lines 129 (patched)


Put this in an @After block


- Ken Howe


On May 11, 2017, 9:47 p.m., Jared Stewart wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59210/
> ---
> 
> (Updated May 11, 2017, 9:47 p.m.)
> 
> 
> Review request for geode.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2912: Hot deploy for functions in deployed Jars
> 
> - New versions of a function now deploy over top the old versions without an 
> intermediate undeploy
> 
> 
> Diffs
> -
> 
>   geode-core/src/main/java/org/apache/geode/internal/DeployedJar.java 
> acb7d227a4f67c749cbc11ee2fdae8651d3bc5d6 
>   geode-core/src/main/java/org/apache/geode/internal/JarDeployer.java 
> df3f10b8cba9bdca8429bdcf8567b654d36ea475 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/DeployCommandRedeployDUnitTest.java
>  697247701f883a5532ac0118ff116ac6562776d4 
> 
> 
> Diff: https://reviews.apache.org/r/59210/diff/1/
> 
> 
> Testing
> ---
> 
> Precheckin running
> 
> 
> Thanks,
> 
> Jared Stewart
> 
>

[jira] [Commented] (GEODE-2853) Change of locator list request interval


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

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

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

https://github.com/apache/geode/pull/483#discussion_r116248082
  
--- Diff: 
geode-core/src/test/java/org/apache/geode/cache/client/internal/AutoConnectionSourceImplJUnitTest.java
 ---
@@ -109,6 +110,7 @@ public void setUp() throws Exception {
 
   @After
   public void tearDown() {
+System.clearProperty(DistributionConfig.GEMFIRE_PREFIX + 
"LOCATOR_UPDATE_INTERVAL");
--- End diff --

This can be replaced with 
`@Rule
  public final RestoreSystemProperties restoreSystemProperties = new 
RestoreSystemProperties();`


> Change of locator list request interval
> ---
>
> Key: GEODE-2853
> URL: https://issues.apache.org/jira/browse/GEODE-2853
> Project: Geode
>  Issue Type: Improvement
>  Components: client/server
>Reporter: Masaki Yamakawa
>Priority: Minor
>
> If you connect to a Geode cluster using a locator from the client, the 
> locator list request will be executed at regular intervals in the background 
> thread. I want to tune this interval. I understand that this interval can be 
> changed by the ping-interval of the Pool attribute. However, I think that 
> ping-interval originally sets the ping interval for health check to the cache 
> server. Therefore, it is not possible to change the locator list request 
> interval without changing the health check interval to the cache server. So,I 
> want to add a java system property that can change the locator list request 
> interval.
> The locator list request interval is determined by the following priority 
> order.
>   1. java system property "gemfire.LOCATOR_UPDATE_INTERVAL"
>   2. ping-interval of the Pool attribute
> In addition, when changing this time, the background thread is activated only 
> when this value is a positive value.



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

[GitHub] geode pull request #483: GEODE-2853: Change of locator list request interval

2017-05-12 Thread kohlmu-pivotal

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

https://github.com/apache/geode/pull/483#discussion_r116248082
  
--- Diff: 
geode-core/src/test/java/org/apache/geode/cache/client/internal/AutoConnectionSourceImplJUnitTest.java
 ---
@@ -109,6 +110,7 @@ public void setUp() throws Exception {
 
   @After
   public void tearDown() {
+System.clearProperty(DistributionConfig.GEMFIRE_PREFIX + 
"LOCATOR_UPDATE_INTERVAL");
--- End diff --

This can be replaced with 
`@Rule
  public final RestoreSystemProperties restoreSystemProperties = new 
RestoreSystemProperties();`


---
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] [Updated] (GEODE-2910) Declaring Object Types in Geode Without Using Client Unclear

2017-05-12 Thread Michael Martell (JIRA)


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

Michael Martell updated GEODE-2910:
---
Description: 
We had trouble passing objects to functions via the REST API because we had no 
objects registered. The only documentation we found for passing objects was 
[here|http://geode.apache.org/docs/guide/11/rest_apps/develop_rest_apps.html#topic_rbc_h25_m4]
 where it says:

"... the Item domain object must be in the CLASSPATH of all members receiving 
the function."

As a C# programmer, this is very confusing. Helpful to spell out that your C# 
class needs to have a Java equivalent loaded in the server. Also that the 
object type name includes the Java package name.

Adding the following simple example to the documentation would have been a 
great demonstration of how objects are registered.

This Java class is required to register the Item object (referred to in the 
link above) on the server:
{code}
package cheezypizza;

public class Item {
public int itemNo;
public String description;
public int quantity;
public float unitprice;
public double totalprice;
}
{code}

A script to register the objects:
{code}
# Build the jar
javac -classpath /mnt/c/gemfire/lib/\* -d ./out src/cheezypizza/*.java
cd out
jar cvMf functions.jar cheezypizza/*.class

# Copy jar to server
scp functions.jar $HOSTNAME:/home/user

# In gfsh, starting the server, specify --classpath=
start server --name=rest-server --start-rest-api=true --http-service-port=8080 
--classpath=/home/user/functions.jar
{code}

  was:
We had trouble passing objects to functions via the REST API because we had no 
objects registered. The only documentation we found for passing objects was 
[here|http://geode.apache.org/docs/guide/11/rest_apps/develop_rest_apps.html#topic_rbc_h25_m4]
 where it says:

"... the Item domain object must be in the CLASSPATH of all members receiving 
the function."

As a C# programmer, this is very confusing. Helpful to spell out that your C# 
class needs to have a Java equivalent loaded in the server. Also that the 
object type name includes the Java package name.

Adding the following simple example to the documentation would have been a 
great demonstration of how objects are registered.

This Java class is required to register the above Item object on the server:
{code}
package cheezypizza;

public class Item {
public int itemNo;
public String description;
public int quantity;
public float unitprice;
public double totalprice;
}
{code}

A script to register the objects:
{code}
# Build the jar
javac -classpath /mnt/c/gemfire/lib/\* -d ./out src/cheezypizza/*.java
cd out
jar cvMf functions.jar cheezypizza/*.class

# Copy jar to server
scp functions.jar $HOSTNAME:/home/user

# In gfsh, starting the server, specify --classpath=
start server --name=rest-server --start-rest-api=true --http-service-port=8080 
--classpath=/home/user/functions.jar
{code}


> Declaring Object Types in Geode Without Using Client Unclear
> 
>
> Key: GEODE-2910
> URL: https://issues.apache.org/jira/browse/GEODE-2910
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Michael Martell
>
> We had trouble passing objects to functions via the REST API because we had 
> no objects registered. The only documentation we found for passing objects 
> was 
> [here|http://geode.apache.org/docs/guide/11/rest_apps/develop_rest_apps.html#topic_rbc_h25_m4]
>  where it says:
> "... the Item domain object must be in the CLASSPATH of all members receiving 
> the function."
> As a C# programmer, this is very confusing. Helpful to spell out that your C# 
> class needs to have a Java equivalent loaded in the server. Also that the 
> object type name includes the Java package name.
> Adding the following simple example to the documentation would have been a 
> great demonstration of how objects are registered.
> This Java class is required to register the Item object (referred to in the 
> link above) on the server:
> {code}
> package cheezypizza;
> public class Item {
> public int itemNo;
> public String description;
> public int quantity;
> public float unitprice;
> public double totalprice;
> }
> {code}
> A script to register the objects:
> {code}
> # Build the jar
> javac -classpath /mnt/c/gemfire/lib/\* -d ./out src/cheezypizza/*.java
> cd out
> jar cvMf functions.jar cheezypizza/*.class
> # Copy jar to server
> scp functions.jar $HOSTNAME:/home/user
> # In gfsh, starting the server, specify --classpath=
> start server --name=rest-server --start-rest-api=true 
> --http-service-port=8080 --classpath=/home/user/functions.jar
> {code}



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

[jira] [Commented] (GEODE-2853) Change of locator list request interval


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

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

Github user masaki-yamakawa commented on the issue:

https://github.com/apache/geode/pull/483
  
I moved the test added to AutoConnectionSourceDUnitTest to 
AutoConnectionSourceImplJUnitTest, and revert AutoConnectionSourceDUnitTest.
I tested by gradle precheckin.


> Change of locator list request interval
> ---
>
> Key: GEODE-2853
> URL: https://issues.apache.org/jira/browse/GEODE-2853
> Project: Geode
>  Issue Type: Improvement
>  Components: client/server
>Reporter: Masaki Yamakawa
>Priority: Minor
>
> If you connect to a Geode cluster using a locator from the client, the 
> locator list request will be executed at regular intervals in the background 
> thread. I want to tune this interval. I understand that this interval can be 
> changed by the ping-interval of the Pool attribute. However, I think that 
> ping-interval originally sets the ping interval for health check to the cache 
> server. Therefore, it is not possible to change the locator list request 
> interval without changing the health check interval to the cache server. So,I 
> want to add a java system property that can change the locator list request 
> interval.
> The locator list request interval is determined by the following priority 
> order.
>   1. java system property "gemfire.LOCATOR_UPDATE_INTERVAL"
>   2. ping-interval of the Pool attribute
> In addition, when changing this time, the background thread is activated only 
> when this value is a positive value.



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

[GitHub] geode issue #483: GEODE-2853: Change of locator list request interval

2017-05-12 Thread masaki-yamakawa

Github user masaki-yamakawa commented on the issue:

https://github.com/apache/geode/pull/483
  
I moved the test added to AutoConnectionSourceDUnitTest to 
AutoConnectionSourceImplJUnitTest, and revert AutoConnectionSourceDUnitTest.
I tested by gradle precheckin.


---
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] [Assigned] (GEODE-2905) CI failure: org.apache.geode.cache.lucene.internal.cli.LuceneIndexCommandsDUnitTest > searchWithoutIndexShouldReturnError

2017-05-12 Thread nabarun (JIRA)


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

nabarun reassigned GEODE-2905:
--

Assignee: nabarun

> CI failure: 
> org.apache.geode.cache.lucene.internal.cli.LuceneIndexCommandsDUnitTest > 
> searchWithoutIndexShouldReturnError 
> --
>
> Key: GEODE-2905
> URL: https://issues.apache.org/jira/browse/GEODE-2905
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Shelley Lynn Hughes-Godfrey
>Assignee: nabarun
>
> This test failed in Apache Jenkins build #830.
> {noformat}
> org.apache.geode.cache.lucene.internal.cli.LuceneIndexCommandsDUnitTest > 
> searchWithoutIndexShouldReturnError FAILED
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertTrue(Assert.java:52)
> at 
> org.apache.geode.cache.lucene.internal.cli.LuceneIndexCommandsDUnitTest.searchWithoutIndexShouldReturnError(LuceneIndexCommandsDUnitTest.java:462)
> {noformat}



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

[jira] [Commented] (GEODE-2637) LuceneQueryFactory.setResultLimit() method should match LuceneQuery.getLimit()


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

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

Github user nabarunnag commented on the issue:

https://github.com/apache/geode/pull/512
  
Potential reviewers
@ladyVader @upthewaterspout @jhuynh1 @boglesby @gesterzhou 


> LuceneQueryFactory.setResultLimit() method should match LuceneQuery.getLimit()
> --
>
> Key: GEODE-2637
> URL: https://issues.apache.org/jira/browse/GEODE-2637
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Affects Versions: 1.2.0
>Reporter: Shelley Lynn Hughes-Godfrey
>Assignee: Shelley Lynn Hughes-Godfrey
>
> In the Lucene docs located here:
>  https://cwiki.apache.org/confluence/display/GEODE/Text+Search+With+Lucene
> we see that we control the number of results from the lucene query via 
> LuceneQueryFactory.setLimit() which corresponds directly with the 
> LuceneQuery.getLimit() method.
> However, this has been implemented as LuceneQueryFactory.setResultLimit().
> This needs to be changed to setLimit().



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

[GitHub] geode issue #512: GEODE-2637: Refactored LuceneQueryFactory.setResultLimit()

2017-05-12 Thread nabarunnag

Github user nabarunnag commented on the issue:

https://github.com/apache/geode/pull/512
  
Potential reviewers
@ladyVader @upthewaterspout @jhuynh1 @boglesby @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.
---

[jira] [Commented] (GEODE-2637) LuceneQueryFactory.setResultLimit() method should match LuceneQuery.getLimit()


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

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

GitHub user nabarunnag opened a pull request:

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

GEODE-2637: Refactored LuceneQueryFactory.setResultLimit()

* Renamed LuceneQueryFactory.getResult to setLimit()
* This is done to match the cwiki documents

Thank you for submitting a contribution to Apache Geode.

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

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

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

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

- [ ] Does `gradlew build` run cleanly?

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

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

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


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

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

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

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


commit efbe53cbafe30c5fb17681e22a3c83f3042e08ae
Author: nabarunnag 
Date:   2017-05-12T13:01:01Z

GEODE-2637: Refactored LuceneQueryFactory.setResultLimit()

* Renamed LuceneQueryFactory.getResult to setLimit()
* This is done to match the cwiki documents




> LuceneQueryFactory.setResultLimit() method should match LuceneQuery.getLimit()
> --
>
> Key: GEODE-2637
> URL: https://issues.apache.org/jira/browse/GEODE-2637
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Affects Versions: 1.2.0
>Reporter: Shelley Lynn Hughes-Godfrey
>Assignee: Shelley Lynn Hughes-Godfrey
>
> In the Lucene docs located here:
>  https://cwiki.apache.org/confluence/display/GEODE/Text+Search+With+Lucene
> we see that we control the number of results from the lucene query via 
> LuceneQueryFactory.setLimit() which corresponds directly with the 
> LuceneQuery.getLimit() method.
> However, this has been implemented as LuceneQueryFactory.setResultLimit().
> This needs to be changed to setLimit().



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

[GitHub] geode pull request #512: GEODE-2637: Refactored LuceneQueryFactory.setResult...

2017-05-12 Thread nabarunnag

GitHub user nabarunnag opened a pull request:

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

GEODE-2637: Refactored LuceneQueryFactory.setResultLimit()

* Renamed LuceneQueryFactory.getResult to setLimit()
* This is done to match the cwiki documents

Thank you for submitting a contribution to Apache Geode.

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

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

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

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

- [ ] Does `gradlew build` run cleanly?

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

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

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


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

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

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

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


commit efbe53cbafe30c5fb17681e22a3c83f3042e08ae
Author: nabarunnag 
Date:   2017-05-12T13:01:01Z

GEODE-2637: Refactored LuceneQueryFactory.setResultLimit()

* Renamed LuceneQueryFactory.getResult to setLimit()
* This is done to match the cwiki documents




---
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-2907) Remove @Experimental tag from the Lucene module

2017-05-12 Thread nabarun (JIRA)


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

nabarun resolved GEODE-2907.

   Resolution: Fixed
Fix Version/s: 1.2.0

> Remove @Experimental tag from the Lucene module
> ---
>
> Key: GEODE-2907
> URL: https://issues.apache.org/jira/browse/GEODE-2907
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: nabarun
>Assignee: nabarun
> Fix For: 1.2.0
>
>
> Issue:
> Remove the @Experimental tag from the files in the Lucene module to prepare 
> Apache Geode for the next release.
> Also improve on the javadocs for the interfaces present in the Lucene module.



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

[jira] [Commented] (GEODE-269) Remove deprecated methods on FunctionService