date:20170907

GEODE 1.2 and java 8

2017-09-07 Thread Roi Apelker

Hi,

As we have moved to Java 8, and compiled GEODE 1.2 with it,

Are there any recommendations regarding java parameters (JVM or any other) that 
can be suggested?

Thanks

Roi
This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,

you may review at https://www.amdocs.com/about/email-disclaimer

Build failed in Jenkins: Geode-nightly #947

2017-09-07 Thread Apache Jenkins Server

See 


Changes:

[jdeppe] GEODE-3556: Update gradle docker plugin to 0.5.4

[jdeppe] GEODE-3556: Add support for setting the user inside docker containers

[boglesby] GEODE-3316: Modified tests to roll locator and server

[eshu] GEODE-3516: Avoid tryResume call to add the thread again into the

[gzhou] GEODE-3568: User can set a LuceneSerializer through the Java API

--
[...truncated 167.90 KB...]
---
* What went wrong:
Execution failed for task ':geode-assembly:integrationTest'.
> There were failing tests. See the report at: 
> file://

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug 
option to get more log output.
==

2: Task failed with an exception.
---
* What went wrong:
Execution failed for task ':geode-web:distributedTest'.
> There were failing tests. See the report at: 
> file://

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug 
option to get more log output.
==

3: Task failed with an exception.
---
* Where:
Script ' 
line: 116

* What went wrong:
Execution failed for task ':extensions/geode-modules-assembly:uploadArchives'.
> Could not find which method repositories() to invoke from this list:
public org.gradle.api.artifacts.dsl.RepositoryHandler 
org.gradle.api.tasks.Upload#repositories(groovy.lang.Closure)
public org.gradle.api.artifacts.dsl.RepositoryHandler 
org.gradle.api.tasks.Upload#repositories(org.gradle.api.Action)

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug 
option to get more log output.
==

4: Task failed with an exception.
---
* Where:
Script ' 
line: 116

* What went wrong:
Execution failed for task ':geode-common:uploadArchives'.
> Could not find which method repositories() to invoke from this list:
public org.gradle.api.artifacts.dsl.RepositoryHandler 
org.gradle.api.tasks.Upload#repositories(groovy.lang.Closure)
public org.gradle.api.artifacts.dsl.RepositoryHandler 
org.gradle.api.tasks.Upload#repositories(org.gradle.api.Action)

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug 
option to get more log output.
==

5: Task failed with an exception.
---
* Where:
Script ' 
line: 116

* What went wrong:
Execution failed for task ':geode-core:uploadArchives'.
> Could not find which method repositories() to invoke from this list:
public org.gradle.api.artifacts.dsl.RepositoryHandler 
org.gradle.api.tasks.Upload#repositories(groovy.lang.Closure)
public org.gradle.api.artifacts.dsl.RepositoryHandler 
org.gradle.api.tasks.Upload#repositories(org.gradle.api.Action)

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug 
option to get more log output.
==

6: Task failed with an exception.
---
* Where:
Script ' 
line: 116

* What went wrong:
Execution failed for task ':geode-cq:uploadArchives'.
> Could not find which method repositories() to invoke from this list:
public org.gradle.api.artifacts.dsl.RepositoryHandler 
org.gradle.api.tasks.Upload#repositories(groovy.lang.Closure)
public org.gradle.api.artifacts.dsl.RepositoryHandler 
org.gradle.api.tasks.Upload#repositories(org.gradle.api.Action)

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug 
option to get more log output.
==

7: Task failed with an exception.
---
* Where:
Script ' 
line: 116

* What went wrong:
Execution failed for task ':geode-json:uploadArchives'.
> Could not find which method repositories() to invoke from this list:
public org.gradle.api.artifacts.dsl.RepositoryHandler 
org.gradle.api.tasks.Upload#repositories(groovy.lang.Closure)
public org.gradle.api.artifacts.dsl.RepositoryHandler 
org.gradle.api.tasks.Upload#repositories(org.gradle.api.Action)

* Try:
Run with --stacktrace option to

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

2017-09-07 Thread Apache Jenkins Server

See 

--
Started by upstream project "Geode-nightly" build number 947
originally caused by:
 Started by timer
[EnvInject] - Loading node environment variables.
Building remotely on H26 (couchdbtest ubuntu xenial) in workspace 

 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url 
 > https://git-wip-us.apache.org/repos/asf/geode.git # timeout=10
Fetching upstream changes from https://git-wip-us.apache.org/repos/asf/geode.git
 > git --version # timeout=10
 > git fetch --tags --progress 
 > https://git-wip-us.apache.org/repos/asf/geode.git 
 > +refs/heads/*:refs/remotes/origin/*
ERROR: Error fetching remote repo 'origin'
hudson.plugins.git.GitException: Failed to fetch from 
https://git-wip-us.apache.org/repos/asf/geode.git
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:817)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1084)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1115)
at hudson.scm.SCM.checkout(SCM.java:495)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1276)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:560)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:485)
at hudson.model.Run.execute(Run.java:1735)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:97)
at hudson.model.Executor.run(Executor.java:405)
Caused by: hudson.plugins.git.GitException: Command "git fetch --tags 
--progress https://git-wip-us.apache.org/repos/asf/geode.git 
+refs/heads/*:refs/remotes/origin/*" returned status code 128:
stdout: 
stderr: fatal: repository 'https://git-wip-us.apache.org/repos/asf/geode.git/' 
not found

at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1924)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1643)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$300(CliGitAPIImpl.java:71)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:352)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:153)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:146)
at hudson.remoting.UserRequest.perform(UserRequest.java:153)
at hudson.remoting.UserRequest.perform(UserRequest.java:50)
at hudson.remoting.Request$2.run(Request.java:336)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:748)
at ..remote call to H26(Native Method)
at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1545)
at hudson.remoting.UserResponse.retrieve(UserRequest.java:253)
at hudson.remoting.Channel.call(Channel.java:830)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:146)
at sun.reflect.GeneratedMethodAccessor866.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.invoke(RemoteGitImpl.java:132)
at com.sun.proxy.$Proxy106.execute(Unknown Source)
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:815)
... 11 more
ERROR: Error fetching remote repo 'origin'
Retrying after 10 seconds
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url 
 > https://git-wip-us.apache.org/repos/asf/geode.git # timeout=10
Fetching upstream changes from https://git-wip-us.apache.org/repos/asf/geode.git
 > git --version # timeout=10
 > git fetch --tags --progress 
 > https://git-wip-us.apache.org/repos/asf/geode.git 
 > +refs/heads/*:refs/remotes/origin/*
ERROR: Error fetching remote repo 'origin'
hudson.plugins.git.GitException: Failed to fetch from 
https://git-wip-us.apache.org/repos/asf/geode.git
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:817)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1084)

Query mechanism

2017-09-07 Thread Roi Apelker

Hi,

Is there a design document which explains the query mechanism? Main classes, 
modules, main algorithm?

I have been looking into this area (since I have a performance issue, where it 
seems that data is loaded from disk prematurely in eviction state, which causes 
the system to become really slow),

I have found a few scenarios where things do not work as it seems they should, 
for example using 2 hints doesn't work, using 1 hint may give slower results, 
indexes that are not used (at least according to the trace) - it's something 
larger than a specific issue, and while going through the code I sometimes fail 
to understand what was meant to be and why in several locations.

Any help here would be gladly appreciated,

Thank you,

Roi


This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,

you may review at https://www.amdocs.com/about/email-disclaimer

Review Request 62163: GEODE-3096: pulling in refactoring work on HttpOperationInvoker

2017-09-07 Thread Jinmei Liao


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

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


Repository: geode


Description
---

* Use HttpOperationInvoker to replace RestHttpOperationInvoker and 
SimpleHttpOperationInvoker
* Use one single ShellCommandController to replace all command controllers
* do not allow execution of commands that require client side file data 
gathering to be executed only on the locator/server
* deprecate CommandService and CommandStatement
* simplify CommandRequest, delete geode's ClientHttpRequest
* fix tests


Diffs
-

  
geode-assembly/src/test/java/org/apache/geode/management/internal/cli/commands/GfshStartLocatorLogTest.java
 eadbea8a2ddde34aed7e1a39e4826be4c70fd65f 
  
geode-assembly/src/test/java/org/apache/geode/test/dunit/rules/gfsh/GfshExecution.java
 23f2a73acf2cf92a8b1c0c2ea2afd10392265628 
  geode-core/build.gradle 8145a634ae706d90026ee0154bdb2eab39e956d0 
  geode-core/src/main/java/org/apache/geode/internal/lang/Initializer.java 
20373710390f7496831507684504804c81cff4ee 
  geode-core/src/main/java/org/apache/geode/internal/util/ArgumentRedactor.java 
df82dffb8e6655785e5347d99032a64cc4d3b40e 
  geode-core/src/main/java/org/apache/geode/management/MemberMXBean.java 
ca7c2a24f1e78ab2cb3047f06f553b117fc8ba8e 
  geode-core/src/main/java/org/apache/geode/management/cli/CliMetaData.java 
226086f7c601292bef307313775ae26b97ce65a5 
  geode-core/src/main/java/org/apache/geode/management/cli/CommandService.java 
20f1c75e06dd7e9fa533182274c45db230170da9 
  
geode-core/src/main/java/org/apache/geode/management/cli/CommandStatement.java 
a01f08c2f09b9c762bbd4ef561ce0ba26d22dd73 
  
geode-core/src/main/java/org/apache/geode/management/internal/beans/MemberMBean.java
 271dce150fb3a93803806700cee7053f9422a8f2 
  
geode-core/src/main/java/org/apache/geode/management/internal/beans/MemberMBeanBridge.java
 5105c3d4bd8b2cfd3a2daf0e0f8208115591c8f1 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/CommandManager.java
 3c8f6cf235d0f1b34d948d23e39fddfbe306be2c 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/CommandRequest.java
 00a05872a512f294f914dbc8ac1c12b799a9145d 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/CommandResponse.java
 81c49583b759ea815f6f20fb1c6da7edb7f99b2f 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/CommandResponseBuilder.java
 790e54be47673f67060d41b323f4b6d22800a852 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/GfshParseResult.java
 b228b281fb471f699c642045d9603ea9d8f9bfcc 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ConnectCommand.java
 a75eeb0ce591a9e3e1c4f56626a1cae8fe722806 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DeployCommand.java
 4f465399abcbcf1d508e05c7fbd73bdd3c68cf1d 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportConfigCommand.java
 672ec881d04d7aa47e01d58268d3df90a285d95a 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportImportClusterConfigurationCommands.java
 83eddeebb472758944863cde098746c7ff8da5a4 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportLogsCommand.java
 70e1e60ff6ed137900eae5d19d67497a5fa718e2 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/GfshCommand.java
 c7f53b1552b45f340b244828cb76d09c8aaa83da 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/QueryCommand.java
 3c039b3a70cf7b38b4f4af77079f0b5d6a39caf5 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/remote/CommandExecutor.java
 PRE-CREATION 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/remote/CommandProcessor.java
 2464b0065d61b1aafc3b933f5f1a04e90e95c689 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/remote/CommandStatementImpl.java
 ac510d1755c7dba1c2c7a772887a5c1b64cdcf57 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/remote/MemberCommandService.java
 25ff549be2bf706c3e3a312fa1b6ce6b423996e7 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/remote/OnlineCommandProcessor.java
 PRE-CREATION 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/remote/RemoteExecutionStrategy.java
 75dce477ba6ce0352ff2575daa7b16f66f1acf18 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/result/AbstractResultData.java
 0bb96cf7058ad73775ce85008492024987bae346 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/result/CommandResult.java
 bbb59d0755ffd2cf405f78c89b420a5279844e29 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/result/DownloadFileResult.java

Re: Missing Gitbox activation email

2017-09-07 Thread Udo Kohlmeyer

It was as Dan indicated you need to make sure your github username 
is registered with id.apache.org. I then later received an email that 
requested I join the apache org. And now my gitbox works.


Thank you for the help.

--Udo


On 9/6/17 21:41, Jacob Barrett wrote:

I think the key is exactly what Dan pointed out about accepting the Apache org 
invite on GitHub. If you hadn’t done that previously you must do it now. You 
must have any and all GitHub IDs you plan to use as committer registered with 
Apache. You should also have any and all email addresses you plan to use as 
committer registered as well.

-Jake



On Sep 6, 2017, at 8:07 PM, Ernest Burghardt  wrote:

When geode-native moved I don't think we received an activation email...
just had to follow the instructions Jake sent out: (obviously drop the
"-native")

For committers the origin is now github.com/apache/geode-native. Before you
can get write access to the new repo you need to "link" your accounts via
https://gitbox.apache.org/setup/. You should also change the URL of your
origin from Apache to GitHub. You will also notice we have full control
over pull requests, including assignments and labeling. Good times ahead.


On Wed, Sep 6, 2017 at 5:53 PM, Xiaojian Zhou  wrote:

I did not get any email. But it seems all set for me.




On Wed, Sep 6, 2017 at 4:33 PM, Nabarun Nag  wrote:

*I think the email takes some time to arrive."An organisational invite
will
be sent to you via email shortly thereafter (within 30 minutes)."*


On Wed, Sep 6, 2017 at 4:21 PM Dan Smith  wrote:

If you are stuck on 3rd step (MFA Status) make you have added your

github

username on id.apache.org *and* that you have accepted the invitation

to

join the apache group on github.

You should see an apache feather listed underneath your organizations on
github.

-Dan

On Wed, Sep 6, 2017 at 4:08 PM, Jacob Barrett 

wrote:

I’d hit up Infra tomorrow if it isn’t working by then.


On Sep 6, 2017, at 4:06 PM, Jared Stewart 

wrote:

I’m stuck on the same step.  I tried clearing out my GitHub

username at

id.apache.org  and then re-adding it in the

hopes

of re-triggering the email, but it still hasn’t arrived.

- Jared

On Sep 6, 2017, at 4:04 PM, Udo Kohlmeyer  wrote:

Hey there,

I've gone through all the steps to activate my github user with

gitbox.

Looking at gitbox.apache.org, I was completed step 2 of 3. I'm

currently waiting for the email that I'm supposed to receive, BUT it

has

never arrived. I have checked my Spam folder and it was not in there

either.

Does anyone know how to have to email sent *again*?

--Udo

Re: Missing Gitbox activation email

2017-09-07 Thread Jared Stewart

I never received an Apache org invite on GitHub or via email after adding my 
GitHub username to id.apache.org.  I filed an infra ticket to request help.  
(https://issues.apache.org/jira/browse/INFRA-15042 
)

- Jared
> On Sep 7, 2017, at 9:36 AM, Udo Kohlmeyer  wrote:
> 
> It was as Dan indicated you need to make sure your github username is 
> registered with id.apache.org. I then later received an email that requested 
> I join the apache org. And now my gitbox works.
> 
> Thank you for the help.
> 
> --Udo
> 
> 
> On 9/6/17 21:41, Jacob Barrett wrote:
>> I think the key is exactly what Dan pointed out about accepting the Apache 
>> org invite on GitHub. If you hadn’t done that previously you must do it now. 
>> You must have any and all GitHub IDs you plan to use as committer registered 
>> with Apache. You should also have any and all email addresses you plan to 
>> use as committer registered as well.
>> 
>> -Jake
>> 
>> 
>>> On Sep 6, 2017, at 8:07 PM, Ernest Burghardt  wrote:
>>> 
>>> When geode-native moved I don't think we received an activation email...
>>> just had to follow the instructions Jake sent out: (obviously drop the
>>> "-native")
>>> 
>>> For committers the origin is now github.com/apache/geode-native. Before you
>>> can get write access to the new repo you need to "link" your accounts via
>>> https://gitbox.apache.org/setup/. You should also change the URL of your
>>> origin from Apache to GitHub. You will also notice we have full control
>>> over pull requests, including assignments and labeling. Good times ahead.
>>> 
 On Wed, Sep 6, 2017 at 5:53 PM, Xiaojian Zhou  wrote:
 
 I did not get any email. But it seems all set for me.
 
 
 
> On Wed, Sep 6, 2017 at 4:33 PM, Nabarun Nag  wrote:
> 
> *I think the email takes some time to arrive."An organisational invite
> will
> be sent to you via email shortly thereafter (within 30 minutes)."*
> 
>> On Wed, Sep 6, 2017 at 4:21 PM Dan Smith  wrote:
>> 
>> If you are stuck on 3rd step (MFA Status) make you have added your
> github
>> username on id.apache.org *and* that you have accepted the invitation
> to
>> join the apache group on github.
>> 
>> You should see an apache feather listed underneath your organizations on
>> github.
>> 
>> -Dan
>> 
>> On Wed, Sep 6, 2017 at 4:08 PM, Jacob Barrett 
> wrote:
>>> I’d hit up Infra tomorrow if it isn’t working by then.
>>> 
 On Sep 6, 2017, at 4:06 PM, Jared Stewart 
> wrote:
 I’m stuck on the same step.  I tried clearing out my GitHub
> username at
>>> id.apache.org  and then re-adding it in the
> hopes
>>> of re-triggering the email, but it still hasn’t arrived.
 - Jared
> On Sep 6, 2017, at 4:04 PM, Udo Kohlmeyer  wrote:
> 
> Hey there,
> 
> I've gone through all the steps to activate my github user with
>> gitbox.
> Looking at gitbox.apache.org, I was completed step 2 of 3. I'm
>>> currently waiting for the email that I'm supposed to receive, BUT it
> has
>>> never arrived. I have checked my Spam folder and it was not in there
>> either.
> Does anyone know how to have to email sent *again*?
> 
> --Udo
 
>

Review Request 62164: GEODE-3566 Moving a bucket during rebalancing does not update overflow stats

2017-09-07 Thread Lynn Gallinat


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

Review request for geode, anilkumar gingade, Darrel Schneider, Eric Shu, and 
Nick Reich.


Repository: geode


Description
---

We now update the stats in a member that lost a bucket due to rebalancing


Diffs
-

  geode-core/src/main/java/org/apache/geode/internal/cache/BucketRegion.java 
465a3dd 
  
geode-core/src/test/java/org/apache/geode/internal/cache/partitioned/BucketRebalanceStatRegressionTest.java
 PRE-CREATION 


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


Testing
---

Precheckin


Thanks,

Lynn Gallinat

Re: Monitor the neighbour JVM using neihbour's member-timeout

2017-09-07 Thread Bruce Schuchardt

I think this might be an acceptable change though I doubt many people 
would find it useful.


It's already possible to set different member-timeouts on each node of 
the distributed system but the meaning of the setting is the inverse of 
what's proposed here, so having the current setting be different in each 
node is pretty useless.


I think the initiation of suspect processing ought to be addressed if we 
make this change.  The ack-wait-threshold and ack-severe-alert-threshold 
aren't based on the member-timeout but ought to be.  This would make it 
possible to initiate suspect processing with different timing for 
different nodes.  It would still leave the question of slow backup 
operations hanging:  If you're waiting for one node that's blocked 
waiting for a response from another node (say a node holding a backup 
bucket) you are going to initiate suspect processing on the node you're 
waiting on & not those other (backup) nodes.


Rolling upgrade will also be a problem since old members aren't going to 
cough up their member-timeout settings.  What should be used as a 
membership timeout for the old members during an upgrade?


If we proceed with this idea I'd prefer that we deprecate 
member-timeout, ack-wait-threshold and ack-severe-alert-threshold and 
have new settings with the "ack" settings being multiples of the new 
membership timeout setting.


Concerning the PR, it isn't acceptable in its current form. 
InternalDistributedMember identifiers are often transmitted in messages 
and increasing their size affects performance.  Any new member 
attributes need to be added to NetView instead of InternalDistributedMember.



On 8/22/17 12:35 AM, Aravind Musigumpula wrote:

Hi Team,

We have a requirement to configure  different member timeout for different 
members as we need some members to survive in the view for longer time than the 
other the members before being kicked out of the view in case they aren't 
responding.


1.   Now with the current monitoring system it is not possible to determine 
when the member will be kicked out of the view if we configure different 
member-timeout's for some required members.

2.   Because if a member is not responding to any heartbeat requests, the 
member who is monitoring the non-responding member will initiate check member 
request.

3.   In this check member request monitoring member pings the 
non-responding member and waits for member-timeout of monitoring member for a 
response.

4.   If still there is no response, it will initiate a final suspect 
request to coordinator where the coordinator does the final check waiting for 
coordinators member-timeout.

5.   If coordinator did not get any response, it will remove the 
non-responding member from the view and publishes it.

6.   So, Here the time period for removing a member depends on its 
monitoring member's and coordinator's timeout. But the monitoring member 
depends on the view but it may change from time to time.

So, now when a monitoring-member doing the check on a member, if we wait for 
the non-responding member's timeout instead of the monitoring member-timeout, 
then the time when the non-responding member will be removed from the view 
depends on its own member-timeout and the coordinators member-timeout.
Hence we can configure different member-timeout for the required members.

I created a pull request based on the above scenario: 
https://github.com/apache/geode/pull/717

Is the above approach correct? Do we have any concerns around this area?
Please give your insights on this issue.

Thanks,
Aravind Musigumpula

This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,

you may review at https://www.amdocs.com/about/email-disclaimer

Re: Missing Gitbox activation email

2017-09-07 Thread Jared Stewart

To anyone else having the same problem, I was able to accept the invite by 
navigating to https://github.com/apache .  

 - Jared
> On Sep 7, 2017, at 9:36 AM, Udo Kohlmeyer  wrote:
> 
> It was as Dan indicated you need to make sure your github username is 
> registered with id.apache.org. I then later received an email that requested 
> I join the apache org. And now my gitbox works.
> 
> Thank you for the help.
> 
> --Udo
> 
> 
> On 9/6/17 21:41, Jacob Barrett wrote:
>> I think the key is exactly what Dan pointed out about accepting the Apache 
>> org invite on GitHub. If you hadn’t done that previously you must do it now. 
>> You must have any and all GitHub IDs you plan to use as committer registered 
>> with Apache. You should also have any and all email addresses you plan to 
>> use as committer registered as well.
>> 
>> -Jake
>> 
>> 
>>> On Sep 6, 2017, at 8:07 PM, Ernest Burghardt  wrote:
>>> 
>>> When geode-native moved I don't think we received an activation email...
>>> just had to follow the instructions Jake sent out: (obviously drop the
>>> "-native")
>>> 
>>> For committers the origin is now github.com/apache/geode-native. Before you
>>> can get write access to the new repo you need to "link" your accounts via
>>> https://gitbox.apache.org/setup/. You should also change the URL of your
>>> origin from Apache to GitHub. You will also notice we have full control
>>> over pull requests, including assignments and labeling. Good times ahead.
>>> 
 On Wed, Sep 6, 2017 at 5:53 PM, Xiaojian Zhou  wrote:
 
 I did not get any email. But it seems all set for me.
 
 
 
> On Wed, Sep 6, 2017 at 4:33 PM, Nabarun Nag  wrote:
> 
> *I think the email takes some time to arrive."An organisational invite
> will
> be sent to you via email shortly thereafter (within 30 minutes)."*
> 
>> On Wed, Sep 6, 2017 at 4:21 PM Dan Smith  wrote:
>> 
>> If you are stuck on 3rd step (MFA Status) make you have added your
> github
>> username on id.apache.org *and* that you have accepted the invitation
> to
>> join the apache group on github.
>> 
>> You should see an apache feather listed underneath your organizations on
>> github.
>> 
>> -Dan
>> 
>> On Wed, Sep 6, 2017 at 4:08 PM, Jacob Barrett 
> wrote:
>>> I’d hit up Infra tomorrow if it isn’t working by then.
>>> 
 On Sep 6, 2017, at 4:06 PM, Jared Stewart 
> wrote:
 I’m stuck on the same step.  I tried clearing out my GitHub
> username at
>>> id.apache.org  and then re-adding it in the
> hopes
>>> of re-triggering the email, but it still hasn’t arrived.
 - Jared
> On Sep 6, 2017, at 4:04 PM, Udo Kohlmeyer  wrote:
> 
> Hey there,
> 
> I've gone through all the steps to activate my github user with
>> gitbox.
> Looking at gitbox.apache.org, I was completed step 2 of 3. I'm
>>> currently waiting for the email that I'm supposed to receive, BUT it
> has
>>> never arrived. I have checked my Spam folder and it was not in there
>> either.
> Does anyone know how to have to email sent *again*?
> 
> --Udo
 
>

Geode sessions at SpringOne Platform conference

2017-09-07 Thread Jagdish Mirani

Hello Geode contributors:
As you most likely already know, we're folding the next Geode Summit into
the upcoming SpringOne Platform conference. We're working through some
great session proposals, and we'll keep adding the accepted sessions to the
Geode page on the SpringOne Platform site.

https://springoneplatform.io/geode

I would like to promote the Geode coverage at this event on the Apache
Geode site; the most appropriate placement is probably on the community
page:
http://geode.apache.org/community/

It would also be great to get a banner
on the home page, if this is appropriate.

Who can help with editing the Apache Geode site to include this?

-- 
Regards
Jag

Re: Review Request 62088: GEODE-3249 Validate internal client/server messages

2017-09-07 Thread Bruce Schuchardt


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

(Updated Sept. 7, 2017, 10:32 a.m.)


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


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


Repository: geode


Description (updated)
---

This change leaves the security hole in place but allows you to plug it by 
setting the system property

geode.disallow-internal-messages-without-credentials=true

Clients must be upgraded to the release containing this change if you set this 
system property to true and client/server authentication is enabled.  Otherwise 
client messages to register PDX types or Instantiators will be rejected by the 
servers.

New tests have been added to perform backward-compatibility testing with the 
old security implementation and the internal message command classes have been 
modified to perform validation of credentials if the system property is set to 
true.


Diffs (updated)
-

  
geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/ServerConnection.java
 b243d8ebb8f7fb698a4637c7a787ee2d7216f1f7 
  
geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/command/AddPdxEnum.java
 5a4a07b81b18d33e465bd3aa46ad4232b976b608 
  
geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/command/AddPdxType.java
 041e12fbd04e81f1f69520c53ef9c2f7481132fd 
  
geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/command/GetFunctionAttribute.java
 76cc4a59bff691c4760083861362825d70ba326e 
  
geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/command/GetPDXEnumById.java
 5e59640e5067ec8ac5fc50807ec276e1bdc025dd 
  
geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/command/GetPDXIdForEnum.java
 b0ebaf23f27e91278c7afe3648954ad6113206a8 
  
geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/command/GetPDXIdForType.java
 f2172ef4d8fa9f83929d8f5b2aa0c5377d7cf57e 
  
geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/command/GetPDXTypeById.java
 e46445bc96d735a66aa09330a1790b951591251e 
  
geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/command/GetPdxEnums70.java
 3fe9750f8577a70e4cda9e76da83070f6e6606b1 
  
geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/command/GetPdxTypes70.java
 e64683fb620985d698357912bb1d1b52e8b24681 
  
geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/command/RegisterDataSerializers.java
 eef5195eae3bedb414aa2e2fca748b31e0b27908 
  
geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/command/RegisterInstantiators.java
 a402cb360f05f99442833e6098c736d2ac18d69a 
  
geode-core/src/test/java/org/apache/geode/security/ClientAuthenticationDUnitTest.java
 ca7b2b6b7a2c8d8215eda828901a05dcabdf3625 
  
geode-core/src/test/java/org/apache/geode/security/ClientAuthenticationPart2DUnitTest.java
 f8ebe056e21228f1d9e32e1dd271f6a4bfb4af71 
  
geode-core/src/test/java/org/apache/geode/security/ClientAuthenticationTestCase.java
 0ecd72f4ee321f7f8aa5e998fa176551e45f025c 
  
geode-core/src/test/java/org/apache/geode/security/ClientAuthorizationDUnitTest.java
 09aedbec86f95ab9affa1f76b387a5a03c0098ec 
  
geode-core/src/test/java/org/apache/geode/security/ClientAuthorizationTestCase.java
 a4fd365ffaa51447d56c2bcb481311082ddcbc31 
  geode-core/src/test/java/org/apache/geode/security/SecurityTestUtils.java 
e69f36de1efbd0061ad8621db45fe3a64686968e 
  
geode-cq/src/main/java/org/apache/geode/internal/cache/tier/sockets/command/MonitorCQ.java
 f5e31df988f5955d2fbeef5269a7729ec97c9d03 
  
geode-cq/src/test/java/org/apache/geode/security/ClientAuthorizationTwoDUnitTest.java
 f5f686c0595c7500c4275292edb2e8f87593c67e 


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

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


Testing
---


Thanks,

Bruce Schuchardt

Re: Review Request 62088: GEODE-3249 Validate internal client/server messages

2017-09-07 Thread Bruce Schuchardt



> On Sept. 5, 2017, 11 a.m., Hitesh Khamesra wrote:
> > Ship It!

I've had to do more work on this & would appreciate another review.


- Bruce


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


On Sept. 7, 2017, 10:32 a.m., Bruce Schuchardt wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/62088/
> ---
> 
> (Updated Sept. 7, 2017, 10:32 a.m.)
> 
> 
> Review request for geode, Alexander Murmann, Galen O'Sullivan, Hitesh 
> Khamesra, and Udo Kohlmeyer.
> 
> 
> Bugs: GEODE-3249
> https://issues.apache.org/jira/browse/GEODE-3249
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> This change leaves the security hole in place but allows you to plug it by 
> setting the system property
> 
> geode.disallow-internal-messages-without-credentials=true
> 
> Clients must be upgraded to the release containing this change if you set 
> this system property to true and client/server authentication is enabled.  
> Otherwise client messages to register PDX types or Instantiators will be 
> rejected by the servers.
> 
> New tests have been added to perform backward-compatibility testing with the 
> old security implementation and the internal message command classes have 
> been modified to perform validation of credentials if the system property is 
> set to true.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/ServerConnection.java
>  b243d8ebb8f7fb698a4637c7a787ee2d7216f1f7 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/command/AddPdxEnum.java
>  5a4a07b81b18d33e465bd3aa46ad4232b976b608 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/command/AddPdxType.java
>  041e12fbd04e81f1f69520c53ef9c2f7481132fd 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/command/GetFunctionAttribute.java
>  76cc4a59bff691c4760083861362825d70ba326e 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/command/GetPDXEnumById.java
>  5e59640e5067ec8ac5fc50807ec276e1bdc025dd 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/command/GetPDXIdForEnum.java
>  b0ebaf23f27e91278c7afe3648954ad6113206a8 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/command/GetPDXIdForType.java
>  f2172ef4d8fa9f83929d8f5b2aa0c5377d7cf57e 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/command/GetPDXTypeById.java
>  e46445bc96d735a66aa09330a1790b951591251e 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/command/GetPdxEnums70.java
>  3fe9750f8577a70e4cda9e76da83070f6e6606b1 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/command/GetPdxTypes70.java
>  e64683fb620985d698357912bb1d1b52e8b24681 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/command/RegisterDataSerializers.java
>  eef5195eae3bedb414aa2e2fca748b31e0b27908 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/command/RegisterInstantiators.java
>  a402cb360f05f99442833e6098c736d2ac18d69a 
>   
> geode-core/src/test/java/org/apache/geode/security/ClientAuthenticationDUnitTest.java
>  ca7b2b6b7a2c8d8215eda828901a05dcabdf3625 
>   
> geode-core/src/test/java/org/apache/geode/security/ClientAuthenticationPart2DUnitTest.java
>  f8ebe056e21228f1d9e32e1dd271f6a4bfb4af71 
>   
> geode-core/src/test/java/org/apache/geode/security/ClientAuthenticationTestCase.java
>  0ecd72f4ee321f7f8aa5e998fa176551e45f025c 
>   
> geode-core/src/test/java/org/apache/geode/security/ClientAuthorizationDUnitTest.java
>  09aedbec86f95ab9affa1f76b387a5a03c0098ec 
>   
> geode-core/src/test/java/org/apache/geode/security/ClientAuthorizationTestCase.java
>  a4fd365ffaa51447d56c2bcb481311082ddcbc31 
>   geode-core/src/test/java/org/apache/geode/security/SecurityTestUtils.java 
> e69f36de1efbd0061ad8621db45fe3a64686968e 
>   
> geode-cq/src/main/java/org/apache/geode/internal/cache/tier/sockets/command/MonitorCQ.java
>  f5e31df988f5955d2fbeef5269a7729ec97c9d03 
>   
> geode-cq/src/test/java/org/apache/geode/security/ClientAuthorizationTwoDUnitTest.java
>  f5f686c0595c7500c4275292edb2e8f87593c67e 
> 
> 
> Diff: https://reviews.apache.org/r/62088/diff/2/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Bruce Schuchardt
> 
>

Re: Review Request 62088: GEODE-3249 Validate internal client/server messages

2017-09-07 Thread Bruce Schuchardt


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

(Updated Sept. 7, 2017, 10:43 a.m.)


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


Changes
---

modified tests to also run with the current version in clients


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


Repository: geode


Description
---

This change leaves the security hole in place but allows you to plug it by 
setting the system property

geode.disallow-internal-messages-without-credentials=true

Clients must be upgraded to the release containing this change if you set this 
system property to true and client/server authentication is enabled.  Otherwise 
client messages to register PDX types or Instantiators will be rejected by the 
servers.

New tests have been added to perform backward-compatibility testing with the 
old security implementation and the internal message command classes have been 
modified to perform validation of credentials if the system property is set to 
true.


Diffs (updated)
-

  
geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/ServerConnection.java
 b243d8ebb8f7fb698a4637c7a787ee2d7216f1f7 
  
geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/command/AddPdxEnum.java
 5a4a07b81b18d33e465bd3aa46ad4232b976b608 
  
geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/command/AddPdxType.java
 041e12fbd04e81f1f69520c53ef9c2f7481132fd 
  
geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/command/GetFunctionAttribute.java
 76cc4a59bff691c4760083861362825d70ba326e 
  
geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/command/GetPDXEnumById.java
 5e59640e5067ec8ac5fc50807ec276e1bdc025dd 
  
geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/command/GetPDXIdForEnum.java
 b0ebaf23f27e91278c7afe3648954ad6113206a8 
  
geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/command/GetPDXIdForType.java
 f2172ef4d8fa9f83929d8f5b2aa0c5377d7cf57e 
  
geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/command/GetPDXTypeById.java
 e46445bc96d735a66aa09330a1790b951591251e 
  
geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/command/GetPdxEnums70.java
 3fe9750f8577a70e4cda9e76da83070f6e6606b1 
  
geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/command/GetPdxTypes70.java
 e64683fb620985d698357912bb1d1b52e8b24681 
  
geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/command/RegisterDataSerializers.java
 eef5195eae3bedb414aa2e2fca748b31e0b27908 
  
geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/command/RegisterInstantiators.java
 a402cb360f05f99442833e6098c736d2ac18d69a 
  
geode-core/src/test/java/org/apache/geode/security/ClientAuthenticationDUnitTest.java
 ca7b2b6b7a2c8d8215eda828901a05dcabdf3625 
  
geode-core/src/test/java/org/apache/geode/security/ClientAuthenticationPart2DUnitTest.java
 f8ebe056e21228f1d9e32e1dd271f6a4bfb4af71 
  
geode-core/src/test/java/org/apache/geode/security/ClientAuthenticationTestCase.java
 0ecd72f4ee321f7f8aa5e998fa176551e45f025c 
  
geode-core/src/test/java/org/apache/geode/security/ClientAuthorizationDUnitTest.java
 09aedbec86f95ab9affa1f76b387a5a03c0098ec 
  
geode-core/src/test/java/org/apache/geode/security/ClientAuthorizationTestCase.java
 a4fd365ffaa51447d56c2bcb481311082ddcbc31 
  geode-core/src/test/java/org/apache/geode/security/SecurityTestUtils.java 
e69f36de1efbd0061ad8621db45fe3a64686968e 
  
geode-cq/src/main/java/org/apache/geode/internal/cache/tier/sockets/command/MonitorCQ.java
 f5e31df988f5955d2fbeef5269a7729ec97c9d03 
  
geode-cq/src/test/java/org/apache/geode/security/ClientAuthorizationTwoDUnitTest.java
 f5f686c0595c7500c4275292edb2e8f87593c67e 


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

Changes: https://reviews.apache.org/r/62088/diff/2-3/


Testing
---


Thanks,

Bruce Schuchardt

Re: Review Request 62163: GEODE-3096: pulling in refactoring work on HttpOperationInvoker

2017-09-07 Thread Patrick Rhomberg

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

Overall: I love how much is getting pruned!

I like to run inspections with the `Changed Files` scope to clean up some of 
the low-hanging fruit.  In particular, I get rankled by
* Missorted modifiers (`ExportLogsCommand`)
* Unnecessary fully qualified names (a few that could be replace by imports)
* Unnecessary interface modifies (`CliMetaData` and `CommandStatement`)
* Collapsable catch blocks
* Explicit type can be reoplace with `<>`
* Unnecessary semicolons

It's the sort of stuff that really doesn't matter, but is easy to touch up when 
you're in the file anyway.

geode-core/src/main/java/org/apache/geode/internal/util/ArgumentRedactor.java
Lines 110 (patched)

Does Java respect the standard macro classes?  `[^\s]` can be the more 
succinct `\S`.

geode-core/src/main/java/org/apache/geode/management/cli/CommandStatement.java
Lines 44-51 (original)

This is a non-internal interface.  Would it not be better to leave it as-is 
until we can remove the interface altogether in Geode 1.4+?

geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ConnectCommand.java
Lines 254-259 (original), 250-255 (patched)

Not entirely clear what's going on here, but `String query` is dead now and 
can be removed.

geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportConfigCommand.java
Line 132 (original), 119-124 (patched)

Since part of this rework is allowing commands to throw and be caught by 
the executor, is that something we'd like / would be able to do here as well?  
I feel like it makes more sence to throw these errors rather than return an 
`ErrorResult`, if that's possible.

geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportImportClusterConfigurationCommands.java
Line 110 (original), 116 (patched)

Should we just rethrow the exception, now that we can handle them on the 
executor?

geode-core/src/main/java/org/apache/geode/management/internal/cli/remote/CommandStatementImpl.java
Lines 44-48 (original), 42-46 (patched)

Kill the dead code.

geode-core/src/main/java/org/apache/geode/management/internal/cli/result/DownloadFileResult.java
Lines 74-82 (patched)

Remove dead code.

geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/ShellCommandsController.java
Line 289 (original), 180 (patched)

Spelling.

geode-core/src/main/java/org/apache/geode/management/internal/web/util/ConvertUtils.java
Line 55 (original), 56-59 (patched)

Early exits are so much better than extra nesting.  Hurrah!

geode-core/src/test/java/org/apache/geode/internal/util/ArgumentRedactorJUnitTest.java
Lines 129 (patched)

Spelling.

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

Remove dead code.

geode-core/src/test/java/org/apache/geode/management/internal/web/http/ClientHttpRequestTest.java
Line 25 (original), 21 (patched)

This class was introduced but is unused?

geode-junit/build.gradle
Lines 26 (patched)

Do we need to start a thread on geode-dev about adding dependencies?  Or is 
the JUnit module somewhat outside that?

- Patrick Rhomberg

On Sept. 7, 2017, 3:33 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/62163/
> ---
> 
> (Updated Sept. 7, 2017, 3:33 p.m.)
> 
> 
> Review request for geode, Jared Stewart, Ken Howe, Kirk Lund, and Patrick 
> Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> * Use HttpOperationInvoker to replace RestHttpOperationInvoker and 
> SimpleHttpOperationInvoker
> * Use one single ShellCommandController to replace all command controllers
> * do not allow execution of commands that require client side file data 
> gathering to be executed only on the locator/server
> * deprecate CommandService and CommandStatement
> * simplify CommandRequest, delete g

Re: Review Request 62163: GEODE-3096: pulling in refactoring work on HttpOperationInvoker

2017-09-07 Thread Patrick Rhomberg



> On Sept. 7, 2017, 6:03 p.m., Patrick Rhomberg wrote:
> > Overall: I love how much is getting pruned!
> > 
> > I like to run inspections with the `Changed Files` scope to clean up some 
> > of the low-hanging fruit.  In particular, I get rankled by
> > * Missorted modifiers (`ExportLogsCommand`)
> > * Unnecessary fully qualified names (a few that could be replace by imports)
> > * Unnecessary interface modifies (`CliMetaData` and `CommandStatement`)
> > * Collapsable catch blocks
> > * Explicit type can be reoplace with `<>`
> > * Unnecessary semicolons
> > 
> > It's the sort of stuff that really doesn't matter, but is easy to touch up 
> > when you're in the file anyway.

That middle paragraph didn't parse the markdown how I had thought it would.  
Probably needed an extra carriage return in there.  Let's try again.

I like to run inspections with the Changed Files scope to clean up some of the 
low-hanging fruit.  In particular, I get rankled by:

* Missorted modifiers (`ExportLogsCommand`)  
* Unnecessary fully qualified names (a few that could be replace by imports)
* Unnecessary interface modifies (`CliMetaData` and `CommandStatement`)
* Collapsable catch blocks
* Explicit type can be reoplace with `<>`
* Unnecessary semicolons


- Patrick


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


On Sept. 7, 2017, 3:33 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/62163/
> ---
> 
> (Updated Sept. 7, 2017, 3:33 p.m.)
> 
> 
> Review request for geode, Jared Stewart, Ken Howe, Kirk Lund, and Patrick 
> Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> * Use HttpOperationInvoker to replace RestHttpOperationInvoker and 
> SimpleHttpOperationInvoker
> * Use one single ShellCommandController to replace all command controllers
> * do not allow execution of commands that require client side file data 
> gathering to be executed only on the locator/server
> * deprecate CommandService and CommandStatement
> * simplify CommandRequest, delete geode's ClientHttpRequest
> * fix tests
> 
> 
> Diffs
> -
> 
>   
> geode-assembly/src/test/java/org/apache/geode/management/internal/cli/commands/GfshStartLocatorLogTest.java
>  eadbea8a2ddde34aed7e1a39e4826be4c70fd65f 
>   
> geode-assembly/src/test/java/org/apache/geode/test/dunit/rules/gfsh/GfshExecution.java
>  23f2a73acf2cf92a8b1c0c2ea2afd10392265628 
>   geode-core/build.gradle 8145a634ae706d90026ee0154bdb2eab39e956d0 
>   geode-core/src/main/java/org/apache/geode/internal/lang/Initializer.java 
> 20373710390f7496831507684504804c81cff4ee 
>   
> geode-core/src/main/java/org/apache/geode/internal/util/ArgumentRedactor.java 
> df82dffb8e6655785e5347d99032a64cc4d3b40e 
>   geode-core/src/main/java/org/apache/geode/management/MemberMXBean.java 
> ca7c2a24f1e78ab2cb3047f06f553b117fc8ba8e 
>   geode-core/src/main/java/org/apache/geode/management/cli/CliMetaData.java 
> 226086f7c601292bef307313775ae26b97ce65a5 
>   
> geode-core/src/main/java/org/apache/geode/management/cli/CommandService.java 
> 20f1c75e06dd7e9fa533182274c45db230170da9 
>   
> geode-core/src/main/java/org/apache/geode/management/cli/CommandStatement.java
>  a01f08c2f09b9c762bbd4ef561ce0ba26d22dd73 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/beans/MemberMBean.java
>  271dce150fb3a93803806700cee7053f9422a8f2 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/beans/MemberMBeanBridge.java
>  5105c3d4bd8b2cfd3a2daf0e0f8208115591c8f1 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/CommandManager.java
>  3c8f6cf235d0f1b34d948d23e39fddfbe306be2c 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/CommandRequest.java
>  00a05872a512f294f914dbc8ac1c12b799a9145d 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/CommandResponse.java
>  81c49583b759ea815f6f20fb1c6da7edb7f99b2f 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/CommandResponseBuilder.java
>  790e54be47673f67060d41b323f4b6d22800a852 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/GfshParseResult.java
>  b228b281fb471f699c642045d9603ea9d8f9bfcc 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ConnectCommand.java
>  a75eeb0ce591a9e3e1c4f56626a1cae8fe722806 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DeployCommand.java
>  4f465399abcbcf1d508e05c7fbd73bdd3c68cf1d 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportConfigCommand.java
>  672ec881d04d7aa47e01d58268d3df90a285d95a 
>   
> geode-core/src/ma

Re: Review Request 62132: GEODE-3277: Fix error path constructors of Launcher inner State classess

2017-09-07 Thread Jared Stewart


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




geode-core/src/main/java/org/apache/geode/distributed/LocatorLauncher.java
Line 1099 (original), 1092 (patched)


Do you think there is any value in logging the full stacktrace of the 
exception?  It looks like that never gets logged anywhere.


- Jared Stewart


On Sept. 6, 2017, 8:10 p.m., Ken Howe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/62132/
> ---
> 
> (Updated Sept. 6, 2017, 8:10 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Kirk Lund, and Patrick 
> Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Updated tests for changes in the error constructors for ServerState and
> LocatorState.
> 
> Minor spelling corrections.
> 
> This reintroduces changes that were reverted due to merge conflicts with
> the previous state of the develop branch
> 
> 
> Diffs
> -
> 
>   geode-core/src/main/java/org/apache/geode/distributed/LocatorLauncher.java 
> 83c1ab533e3dea323a8a99f7002b9464a54dfc25 
>   geode-core/src/main/java/org/apache/geode/distributed/ServerLauncher.java 
> ae64691605130c9b212a3a33bb65ae37b28af02b 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/StartLocatorCommand.java
>  72ccfbbc83b18e8bc32759dbeabaf2f9ef4c2f45 
>   
> geode-core/src/test/java/org/apache/geode/distributed/LauncherIntegrationTestCase.java
>  409a96dbe416a6f96c2389356b9d823d1adb793f 
>   
> geode-core/src/test/java/org/apache/geode/distributed/LocatorLauncherLocalIntegrationTest.java
>  9fce94e89a369094a2383eb9103f2f43a8ff3013 
>   
> geode-core/src/test/java/org/apache/geode/distributed/LocatorLauncherRemoteIntegrationTest.java
>  cc42a53772f3064b800ca1ac1ae894be6c715399 
>   
> geode-core/src/test/java/org/apache/geode/distributed/ServerLauncherLocalIntegrationTest.java
>  29ddaaf6692565a9afb8c528790b35798d118a31 
>   
> geode-core/src/test/java/org/apache/geode/distributed/ServerLauncherRemoteIntegrationTest.java
>  733a1082ae9993fbdb646712380af7dcc1cca560 
>   
> geode-core/src/test/java/org/apache/geode/distributed/ServerLauncherTest.java 
> 2bcd994d4d14888adfdf68abef5acbc068b6fea8 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/rules/GfshShellConnectionRule.java
>  a9ce889006800523505dace6e0b4696c9911d205 
> 
> 
> Diff: https://reviews.apache.org/r/62132/diff/1/
> 
> 
> Testing
> ---
> 
> Precheckin is green
> 
> 
> Thanks,
> 
> Ken Howe
> 
>

Re: Review Request 62132: GEODE-3277: Fix error path constructors of Launcher inner State classess

2017-09-07 Thread Ken Howe



> On Sept. 7, 2017, 6:16 p.m., Jared Stewart wrote:
> > geode-core/src/main/java/org/apache/geode/distributed/LocatorLauncher.java
> > Line 1099 (original), 1092 (patched)
> > 
> >
> > Do you think there is any value in logging the full stacktrace of the 
> > exception?  It looks like that never gets logged anywhere.

I can take that out - I added quite a bit of extra logging while debugging that 
isn't normally necessary.


- Ken


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


On Sept. 6, 2017, 8:10 p.m., Ken Howe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/62132/
> ---
> 
> (Updated Sept. 6, 2017, 8:10 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Kirk Lund, and Patrick 
> Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Updated tests for changes in the error constructors for ServerState and
> LocatorState.
> 
> Minor spelling corrections.
> 
> This reintroduces changes that were reverted due to merge conflicts with
> the previous state of the develop branch
> 
> 
> Diffs
> -
> 
>   geode-core/src/main/java/org/apache/geode/distributed/LocatorLauncher.java 
> 83c1ab533e3dea323a8a99f7002b9464a54dfc25 
>   geode-core/src/main/java/org/apache/geode/distributed/ServerLauncher.java 
> ae64691605130c9b212a3a33bb65ae37b28af02b 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/StartLocatorCommand.java
>  72ccfbbc83b18e8bc32759dbeabaf2f9ef4c2f45 
>   
> geode-core/src/test/java/org/apache/geode/distributed/LauncherIntegrationTestCase.java
>  409a96dbe416a6f96c2389356b9d823d1adb793f 
>   
> geode-core/src/test/java/org/apache/geode/distributed/LocatorLauncherLocalIntegrationTest.java
>  9fce94e89a369094a2383eb9103f2f43a8ff3013 
>   
> geode-core/src/test/java/org/apache/geode/distributed/LocatorLauncherRemoteIntegrationTest.java
>  cc42a53772f3064b800ca1ac1ae894be6c715399 
>   
> geode-core/src/test/java/org/apache/geode/distributed/ServerLauncherLocalIntegrationTest.java
>  29ddaaf6692565a9afb8c528790b35798d118a31 
>   
> geode-core/src/test/java/org/apache/geode/distributed/ServerLauncherRemoteIntegrationTest.java
>  733a1082ae9993fbdb646712380af7dcc1cca560 
>   
> geode-core/src/test/java/org/apache/geode/distributed/ServerLauncherTest.java 
> 2bcd994d4d14888adfdf68abef5acbc068b6fea8 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/rules/GfshShellConnectionRule.java
>  a9ce889006800523505dace6e0b4696c9911d205 
> 
> 
> Diff: https://reviews.apache.org/r/62132/diff/1/
> 
> 
> Testing
> ---
> 
> Precheckin is green
> 
> 
> Thanks,
> 
> Ken Howe
> 
>

Re: Review Request 62164: GEODE-3566 Moving a bucket during rebalancing does not update overflow stats

2017-09-07 Thread anilkumar gingade


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


Ship it!




Ship It!

- anilkumar gingade


On Sept. 7, 2017, 4:56 p.m., Lynn Gallinat wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/62164/
> ---
> 
> (Updated Sept. 7, 2017, 4:56 p.m.)
> 
> 
> Review request for geode, anilkumar gingade, Darrel Schneider, Eric Shu, and 
> Nick Reich.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> We now update the stats in a member that lost a bucket due to rebalancing
> 
> 
> Diffs
> -
> 
>   geode-core/src/main/java/org/apache/geode/internal/cache/BucketRegion.java 
> 465a3dd 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/partitioned/BucketRebalanceStatRegressionTest.java
>  PRE-CREATION 
> 
> 
> Diff: https://reviews.apache.org/r/62164/diff/1/
> 
> 
> Testing
> ---
> 
> Precheckin
> 
> 
> Thanks,
> 
> Lynn Gallinat
> 
>

Re: Query mechanism

2017-09-07 Thread Anilkumar Gingade

Roi,

There is no documentation on the internals of Query engine...I believe
there are tools which can generate package/class diagrams and their
relationship...Based on the problem/issue, we could point to the source
file, where you can find more info.

To know how query is picking the best index; you can look at:
IndexManager.getBestMatchIndex()

-Anil.







On Thu, Sep 7, 2017 at 8:14 AM, Roi Apelker  wrote:

> Hi,
>
> Is there a design document which explains the query mechanism? Main
> classes, modules, main algorithm?
>
> I have been looking into this area (since I have a performance issue,
> where it seems that data is loaded from disk prematurely in eviction state,
> which causes the system to become really slow),
>
> I have found a few scenarios where things do not work as it seems they
> should, for example using 2 hints doesn't work, using 1 hint may give
> slower results, indexes that are not used (at least according to the trace)
> - it's something larger than a specific issue, and while going through the
> code I sometimes fail to understand what was meant to be and why in several
> locations.
>
> Any help here would be gladly appreciated,
>
> Thank you,
>
> Roi
>
>
> This message and the information contained herein is proprietary and
> confidential and subject to the Amdocs policy statement,
>
> you may review at https://www.amdocs.com/about/email-disclaimer <
> https://www.amdocs.com/about/email-disclaimer>
>

Re: Review Request 62164: GEODE-3566 Moving a bucket during rebalancing does not update overflow stats

2017-09-07 Thread Nick Reich


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




geode-core/src/main/java/org/apache/geode/internal/cache/BucketRegion.java
Lines 2460 (patched)


Can remove nesting by checking dr != null && destroyDiskRegion



geode-core/src/test/java/org/apache/geode/internal/cache/partitioned/BucketRebalanceStatRegressionTest.java
Lines 91 (patched)


It does not look like the second part of this method uses the shortcut or 
overflow parameters, so it could be a seperate method. Since this method does 
two different things, that would probably be optimal.


- Nick Reich


On Sept. 7, 2017, 4:56 p.m., Lynn Gallinat wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/62164/
> ---
> 
> (Updated Sept. 7, 2017, 4:56 p.m.)
> 
> 
> Review request for geode, anilkumar gingade, Darrel Schneider, Eric Shu, and 
> Nick Reich.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> We now update the stats in a member that lost a bucket due to rebalancing
> 
> 
> Diffs
> -
> 
>   geode-core/src/main/java/org/apache/geode/internal/cache/BucketRegion.java 
> 465a3dd 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/partitioned/BucketRebalanceStatRegressionTest.java
>  PRE-CREATION 
> 
> 
> Diff: https://reviews.apache.org/r/62164/diff/1/
> 
> 
> Testing
> ---
> 
> Precheckin
> 
> 
> Thanks,
> 
> Lynn Gallinat
> 
>

Re: Missing Gitbox activation email

2017-09-07 Thread Nabarun Nag

Thanks Jared, that worked for me.

On Thu, Sep 7, 2017 at 10:28 AM Jared Stewart  wrote:

> To anyone else having the same problem, I was able to accept the invite by
> navigating to https://github.com/apache .
>
>  - Jared
> > On Sep 7, 2017, at 9:36 AM, Udo Kohlmeyer  wrote:
> >
> > It was as Dan indicated you need to make sure your github username
> is registered with id.apache.org. I then later received an email that
> requested I join the apache org. And now my gitbox works.
> >
> > Thank you for the help.
> >
> > --Udo
> >
> >
> > On 9/6/17 21:41, Jacob Barrett wrote:
> >> I think the key is exactly what Dan pointed out about accepting the
> Apache org invite on GitHub. If you hadn’t done that previously you must do
> it now. You must have any and all GitHub IDs you plan to use as committer
> registered with Apache. You should also have any and all email addresses
> you plan to use as committer registered as well.
> >>
> >> -Jake
> >>
> >>
> >>> On Sep 6, 2017, at 8:07 PM, Ernest Burghardt 
> wrote:
> >>>
> >>> When geode-native moved I don't think we received an activation
> email...
> >>> just had to follow the instructions Jake sent out: (obviously drop the
> >>> "-native")
> >>>
> >>> For committers the origin is now github.com/apache/geode-native.
> Before you
> >>> can get write access to the new repo you need to "link" your accounts
> via
> >>> https://gitbox.apache.org/setup/. You should also change the URL of
> your
> >>> origin from Apache to GitHub. You will also notice we have full control
> >>> over pull requests, including assignments and labeling. Good times
> ahead.
> >>>
>  On Wed, Sep 6, 2017 at 5:53 PM, Xiaojian Zhou 
> wrote:
> 
>  I did not get any email. But it seems all set for me.
> 
>  
> 
> > On Wed, Sep 6, 2017 at 4:33 PM, Nabarun Nag  wrote:
> >
> > *I think the email takes some time to arrive."An organisational
> invite
> > will
> > be sent to you via email shortly thereafter (within 30 minutes)."*
> >
> >> On Wed, Sep 6, 2017 at 4:21 PM Dan Smith  wrote:
> >>
> >> If you are stuck on 3rd step (MFA Status) make you have added your
> > github
> >> username on id.apache.org *and* that you have accepted the
> invitation
> > to
> >> join the apache group on github.
> >>
> >> You should see an apache feather listed underneath your
> organizations on
> >> github.
> >>
> >> -Dan
> >>
> >> On Wed, Sep 6, 2017 at 4:08 PM, Jacob Barrett 
> > wrote:
> >>> I’d hit up Infra tomorrow if it isn’t working by then.
> >>>
>  On Sep 6, 2017, at 4:06 PM, Jared Stewart 
> > wrote:
>  I’m stuck on the same step.  I tried clearing out my GitHub
> > username at
> >>> id.apache.org  and then re-adding it in the
> > hopes
> >>> of re-triggering the email, but it still hasn’t arrived.
>  - Jared
> > On Sep 6, 2017, at 4:04 PM, Udo Kohlmeyer 
> wrote:
> >
> > Hey there,
> >
> > I've gone through all the steps to activate my github user with
> >> gitbox.
> > Looking at gitbox.apache.org, I was completed step 2 of 3. I'm
> >>> currently waiting for the email that I'm supposed to receive, BUT
> it
> > has
> >>> never arrived. I have checked my Spam folder and it was not in
> there
> >> either.
> > Does anyone know how to have to email sent *again*?
> >
> > --Udo
> 
> >
>
>

Re: Review Request 62164: GEODE-3566 Moving a bucket during rebalancing does not update overflow stats

2017-09-07 Thread Nick Reich


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




geode-core/src/test/java/org/apache/geode/internal/cache/partitioned/BucketRebalanceStatRegressionTest.java
Lines 17 (patched)


I think this is the wrong library, or are you using assertj on purpose 
instead of junit?



geode-core/src/test/java/org/apache/geode/internal/cache/partitioned/BucketRebalanceStatRegressionTest.java
Lines 128 (patched)


This could be cleaned up by getting the region once at the top of the 
method and using that variable throughout.



geode-core/src/test/java/org/apache/geode/internal/cache/partitioned/BucketRebalanceStatRegressionTest.java
Lines 129 (patched)


This method seems to be doing two distinct things: the first is a vm 
specific check of region entry and bucket count sizes (which could be its own 
method that takes only a single vm) and the second is checking overflow, which 
could also be its own method (especially since only one region is checked).



geode-core/src/test/java/org/apache/geode/internal/cache/partitioned/BucketRebalanceStatRegressionTest.java
Lines 156 (patched)


Normalize variable names to camel case?



geode-core/src/test/java/org/apache/geode/internal/cache/partitioned/BucketRebalanceStatRegressionTest.java
Lines 249 (patched)


use TEST_REGION constant


- Nick Reich


On Sept. 7, 2017, 4:56 p.m., Lynn Gallinat wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/62164/
> ---
> 
> (Updated Sept. 7, 2017, 4:56 p.m.)
> 
> 
> Review request for geode, anilkumar gingade, Darrel Schneider, Eric Shu, and 
> Nick Reich.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> We now update the stats in a member that lost a bucket due to rebalancing
> 
> 
> Diffs
> -
> 
>   geode-core/src/main/java/org/apache/geode/internal/cache/BucketRegion.java 
> 465a3dd 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/partitioned/BucketRebalanceStatRegressionTest.java
>  PRE-CREATION 
> 
> 
> Diff: https://reviews.apache.org/r/62164/diff/1/
> 
> 
> Testing
> ---
> 
> Precheckin
> 
> 
> Thanks,
> 
> Lynn Gallinat
> 
>

Re: Review Request 62164: GEODE-3566 Moving a bucket during rebalancing does not update overflow stats

2017-09-07 Thread Darrel Schneider


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


Ship it!




Ship It!

- Darrel Schneider


On Sept. 7, 2017, 9:56 a.m., Lynn Gallinat wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/62164/
> ---
> 
> (Updated Sept. 7, 2017, 9:56 a.m.)
> 
> 
> Review request for geode, anilkumar gingade, Darrel Schneider, Eric Shu, and 
> Nick Reich.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> We now update the stats in a member that lost a bucket due to rebalancing
> 
> 
> Diffs
> -
> 
>   geode-core/src/main/java/org/apache/geode/internal/cache/BucketRegion.java 
> 465a3dd 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/partitioned/BucketRebalanceStatRegressionTest.java
>  PRE-CREATION 
> 
> 
> Diff: https://reviews.apache.org/r/62164/diff/1/
> 
> 
> Testing
> ---
> 
> Precheckin
> 
> 
> Thanks,
> 
> Lynn Gallinat
> 
>

Re: [Discuss] Enable region set operations to start JTA transactions

2017-09-07 Thread Swapnil Bawaskar

How is this going to work for a PartitionedRegion?

Are we going to throw TransactionDataNotColocatedException when iterating
over non-colocated data in the PR?
If so, how useful is this work going to be if the set ops always throw
exceptions?
If not, then that will mean we have to maintain a txState on all the
members of the system. This effectively means supporting distributed
transactions.

At this point, I would like to question the ability to perform set ops from
within a transaction. We already do not allow region operations (clear,
destroy etc) from within a transaction, should we disable set ops
(entries(), keys()) etc as well?




On Mon, Aug 28, 2017 at 9:27 AM Michael Stolz  wrote:

> +1 for revising set ops to bootstrap by default. Document the behavior
> change in release notes along with property to revert to old behavior.
>
> --
> Mike Stolz
> Principal Engineer, GemFire Product Manager
> Mobile: +1-631-835-4771 <(631)%20835-4771>
>
> On Fri, Aug 25, 2017 at 6:41 PM, Anilkumar Gingade 
> wrote:
>
> > +1 Having a consistent behavior for set operation within the transaction
> > (wherever its invoked). And having a gemfire property to allow old way.
> >
> > On Fri, Aug 25, 2017 at 2:49 PM, Eric Shu  wrote:
> >
> > > Hi Team,
> > >
> > > Currently in GEODE JTA implementation, if GEODE transaction is not yet
> > > bootstrapped (there is no TXState created yet for the transaction),
> > region
> > > set operations will not bootstrap the JTA transaction. In other word,
> if
> > > the first operation of the JTA transaction is region set operation, the
> > set
> > > is not in a transactional view (TXState). However, if the JTA
> > > UserTransaction has been bootstrapped (first operation is a get or put
> > > operation, etc), the following region set operation is transactional
> (in
> > > TXState). To some users, this seems to be a bug. Please see the GEODE
> > > ticket (https://issues.apache.org/jira/browse/GEODE-3521).
> > >
> > > Although we intentionally implemented this way to alleviate the memory
> > > requirements for users (each transaction will have a new copy of region
> > > data put into TXState but not if the set op is the first op), we think
> > the
> > > new user has a valid point as well. We propose to allow region set op
> to
> > > bootstrap the transaction. To allow backward compatibility, we will
> > > introduce a new GemFire property to allow the old behavior.
> > >
> > > The question is what should be a default behavior. Do we allow region
> set
> > > op to bootstrap transaction as default? If so, existing customers need
> to
> > > set the new property to get the old behavior. Or we maintain the old
> > > behavior, and require the new users to set the property.
> > >
> > > Please comment if you have any suggestions.
> > >
> > > Thanks,
> > > Eric
> > >
> >
>

Review Request 62178: GEODE-3449: Fix flakiness in ConnectCommandWithSSLTest

2017-09-07 Thread Jared Stewart


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

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


Repository: geode


Description
---

GEODE-3449: Fix flakiness in ConnectCommandWithSSLTest


Diffs
-

  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/IndexCommandsDUnitTest.java
 794c58846ffe9c1b2b5143c95b9dc5aea388afbc 


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


Testing
---

Precheckin running


Thanks,

Jared Stewart

Re: Review Request 62132: GEODE-3277: Fix error path constructors of Launcher inner State classess

2017-09-07 Thread Ken Howe


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

(Updated Sept. 7, 2017, 10:29 p.m.)


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


Changes
---

Updated debug messages for both ```ServerLauncher``` and ```LocatorLanucher```


Repository: geode


Description
---

Updated tests for changes in the error constructors for ServerState and
LocatorState.

Minor spelling corrections.

This reintroduces changes that were reverted due to merge conflicts with
the previous state of the develop branch


Diffs (updated)
-

  geode-core/src/main/java/org/apache/geode/distributed/LocatorLauncher.java 
83c1ab533e3dea323a8a99f7002b9464a54dfc25 
  geode-core/src/main/java/org/apache/geode/distributed/ServerLauncher.java 
ae64691605130c9b212a3a33bb65ae37b28af02b 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/StartLocatorCommand.java
 72ccfbbc83b18e8bc32759dbeabaf2f9ef4c2f45 
  
geode-core/src/test/java/org/apache/geode/distributed/LauncherIntegrationTestCase.java
 409a96dbe416a6f96c2389356b9d823d1adb793f 
  
geode-core/src/test/java/org/apache/geode/distributed/LocatorLauncherLocalIntegrationTest.java
 9fce94e89a369094a2383eb9103f2f43a8ff3013 
  
geode-core/src/test/java/org/apache/geode/distributed/LocatorLauncherRemoteIntegrationTest.java
 cc42a53772f3064b800ca1ac1ae894be6c715399 
  
geode-core/src/test/java/org/apache/geode/distributed/ServerLauncherLocalIntegrationTest.java
 29ddaaf6692565a9afb8c528790b35798d118a31 
  
geode-core/src/test/java/org/apache/geode/distributed/ServerLauncherRemoteIntegrationTest.java
 733a1082ae9993fbdb646712380af7dcc1cca560 
  geode-core/src/test/java/org/apache/geode/distributed/ServerLauncherTest.java 
2bcd994d4d14888adfdf68abef5acbc068b6fea8 
  
geode-core/src/test/java/org/apache/geode/test/dunit/rules/GfshShellConnectionRule.java
 a9ce889006800523505dace6e0b4696c9911d205 


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

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


Testing
---

Precheckin is green


Thanks,

Ken Howe

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

2017-09-07 Thread Spring CI


---
Spring Data GemFire > Nightly-ApacheGeode > #671 was successful.
---
Scheduled
2029 tests in total.

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





--
This message is automatically generated by Atlassian Bamboo

Re: Review Request 62179: Test Rule Fix: clean up client DS when using LocatorServerStartupRule

2017-09-07 Thread Jinmei Liao


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

(Updated Sept. 7, 2017, 11:12 p.m.)


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


Repository: geode


Description
---

Test Rule Fix: clean up clientVM if using LocatorServerStartUpRule to get the 
ClientVM


Diffs
-

  
geode-core/src/test/java/org/apache/geode/test/dunit/rules/LocatorServerStartupRule.java
 f0385e21f708d9a085e7129d82fb3101e2fb8322 
  
geode-core/src/test/java/org/apache/geode/test/dunit/rules/MemberStarterRule.java
 a832a2590527100afc05fb9de2e332a263d52c19 


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


Testing (updated)
---

precheckin running


Thanks,

Jinmei Liao

Review Request 62179: Test Rule Fix: clean up client DS when using LocatorServerStartupRule

2017-09-07 Thread Jinmei Liao


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

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


Repository: geode


Description
---

Test Rule Fix: clean up clientVM if using LocatorServerStartUpRule to get the 
ClientVM


Diffs
-

  
geode-core/src/test/java/org/apache/geode/test/dunit/rules/LocatorServerStartupRule.java
 f0385e21f708d9a085e7129d82fb3101e2fb8322 
  
geode-core/src/test/java/org/apache/geode/test/dunit/rules/MemberStarterRule.java
 a832a2590527100afc05fb9de2e332a263d52c19 


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


Testing
---


Thanks,

Jinmei Liao

Re: Review Request 62163: GEODE-3096: pulling in refactoring work on HttpOperationInvoker

2017-09-07 Thread Jared Stewart


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




geode-assembly/src/test/java/org/apache/geode/test/dunit/rules/gfsh/GfshExecution.java
Lines 37 (patched)


I don't think this method is used.



geode-core/src/main/java/org/apache/geode/management/cli/CommandService.java
Line 109 (original)


I wonder if these methods are OK to delete, since they're public methods in 
what looks to be a public (non-internal) class.



geode-core/src/main/java/org/apache/geode/management/internal/cli/GfshParseResult.java
Line 86 (original)


Why is it safe to remove this escaping now?



geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ConnectCommand.java
Line 256 (original), 252 (patched)


It might be good to add a comment here explaining that our intent is to 
trigger authorization.


- Jared Stewart


On Sept. 7, 2017, 3:33 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/62163/
> ---
> 
> (Updated Sept. 7, 2017, 3:33 p.m.)
> 
> 
> Review request for geode, Jared Stewart, Ken Howe, Kirk Lund, and Patrick 
> Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> * Use HttpOperationInvoker to replace RestHttpOperationInvoker and 
> SimpleHttpOperationInvoker
> * Use one single ShellCommandController to replace all command controllers
> * do not allow execution of commands that require client side file data 
> gathering to be executed only on the locator/server
> * deprecate CommandService and CommandStatement
> * simplify CommandRequest, delete geode's ClientHttpRequest
> * fix tests
> 
> 
> Diffs
> -
> 
>   
> geode-assembly/src/test/java/org/apache/geode/management/internal/cli/commands/GfshStartLocatorLogTest.java
>  eadbea8a2ddde34aed7e1a39e4826be4c70fd65f 
>   
> geode-assembly/src/test/java/org/apache/geode/test/dunit/rules/gfsh/GfshExecution.java
>  23f2a73acf2cf92a8b1c0c2ea2afd10392265628 
>   geode-core/build.gradle 8145a634ae706d90026ee0154bdb2eab39e956d0 
>   geode-core/src/main/java/org/apache/geode/internal/lang/Initializer.java 
> 20373710390f7496831507684504804c81cff4ee 
>   
> geode-core/src/main/java/org/apache/geode/internal/util/ArgumentRedactor.java 
> df82dffb8e6655785e5347d99032a64cc4d3b40e 
>   geode-core/src/main/java/org/apache/geode/management/MemberMXBean.java 
> ca7c2a24f1e78ab2cb3047f06f553b117fc8ba8e 
>   geode-core/src/main/java/org/apache/geode/management/cli/CliMetaData.java 
> 226086f7c601292bef307313775ae26b97ce65a5 
>   
> geode-core/src/main/java/org/apache/geode/management/cli/CommandService.java 
> 20f1c75e06dd7e9fa533182274c45db230170da9 
>   
> geode-core/src/main/java/org/apache/geode/management/cli/CommandStatement.java
>  a01f08c2f09b9c762bbd4ef561ce0ba26d22dd73 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/beans/MemberMBean.java
>  271dce150fb3a93803806700cee7053f9422a8f2 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/beans/MemberMBeanBridge.java
>  5105c3d4bd8b2cfd3a2daf0e0f8208115591c8f1 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/CommandManager.java
>  3c8f6cf235d0f1b34d948d23e39fddfbe306be2c 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/CommandRequest.java
>  00a05872a512f294f914dbc8ac1c12b799a9145d 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/CommandResponse.java
>  81c49583b759ea815f6f20fb1c6da7edb7f99b2f 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/CommandResponseBuilder.java
>  790e54be47673f67060d41b323f4b6d22800a852 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/GfshParseResult.java
>  b228b281fb471f699c642045d9603ea9d8f9bfcc 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ConnectCommand.java
>  a75eeb0ce591a9e3e1c4f56626a1cae8fe722806 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DeployCommand.java
>  4f465399abcbcf1d508e05c7fbd73bdd3c68cf1d 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportConfigCommand.java
>  672ec881d04d7aa47e01d58268d3df90a285d95a 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportImportClusterConfigurationCommands.java
>  83eddeebb472758944863cde098746c7ff8da5a4 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportLogsCommand.java
>  70e1e60ff6ed13

Re: Review Request 62179: Test Rule Fix: clean up client DS when using LocatorServerStartupRule

2017-09-07 Thread Jared Stewart


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




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


How do you think this reads this instead of the `for` loop? 
```
Consumer stopMemberAndDisconnectDS = (MemberVM memberVM) -> {
  memberVM.stopMember();
  memberVM.getVM().invoke((SerializableRunnableIF) 
MemberStarterRule::disconnectDSIfAny);
};


Arrays.stream(members).filter(Objects::nonNull).forEach(stopMemberAndDisconnectDS);
```


- Jared Stewart


On Sept. 7, 2017, 11:12 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/62179/
> ---
> 
> (Updated Sept. 7, 2017, 11:12 p.m.)
> 
> 
> Review request for geode, Jared Stewart, Ken Howe, Kirk Lund, and Patrick 
> Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Test Rule Fix: clean up clientVM if using LocatorServerStartUpRule to get the 
> ClientVM
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/rules/LocatorServerStartupRule.java
>  f0385e21f708d9a085e7129d82fb3101e2fb8322 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/rules/MemberStarterRule.java
>  a832a2590527100afc05fb9de2e332a263d52c19 
> 
> 
> Diff: https://reviews.apache.org/r/62179/diff/1/
> 
> 
> Testing
> ---
> 
> precheckin running
> 
> 
> Thanks,
> 
> Jinmei Liao
> 
>

Review Request 62180: refactor away GemfireCacheImpl.getInstance from lucene function

2017-09-07 Thread xiaojian zhou


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

Review request for geode, Barry Oglesby and Dan Smith.


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


Repository: geode


Description
---

use dm.getCache() instead


Diffs
-

  
geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/DestroyLuceneIndexMessage.java
 9eada5b20 


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


Testing
---


Thanks,

xiaojian zhou

Re: Review Request 62180: refactor away GemfireCacheImpl.getInstance from lucene function

2017-09-07 Thread Darrel Schneider

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

This review is confusing. It requires the fix for GEODE-3557 which currently 
has its own PR (see https://github.com/apache/geode/pull/763).
So why did you submit this review? It looks like you just grabbed one line from 
that PR since it has also has the change.
I just wanted to make clear you should not checkin this code review because in 
your code base DM.getCache() does not exist.

- Darrel Schneider

On Sept. 7, 2017, 5:43 p.m., xiaojian zhou wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/62180/
> ---
> 
> (Updated Sept. 7, 2017, 5:43 p.m.)
> 
> 
> Review request for geode, Barry Oglesby and Dan Smith.
> 
> 
> Bugs: GEODE-3557
> https://issues.apache.org/jira/browse/GEODE-3557
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> use dm.getCache() instead
> 
> 
> Diffs
> -
> 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/DestroyLuceneIndexMessage.java
>  9eada5b20 
> 
> 
> Diff: https://reviews.apache.org/r/62180/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> xiaojian zhou
> 
>

Re: Geode sessions at SpringOne Platform conference

2017-09-07 Thread Joey McAllister

Hi Jag,

Thanks for the pointer to the Geode page for SpringOne. I'd be happy to add
that info to the Events section of the Geode Community page.

Do you have an existing banner image—preferably one comparable in
dimensions to the ApacheCon banner currently on that page, which the
SpringOne banner will replace? If not, do you have the details you'd like
to include?

Best,
Joey

On Thu, Sep 7, 2017 at 10:22 AM Jagdish Mirani  wrote:

> Hello Geode contributors:
> As you most likely already know, we're folding the next Geode Summit into
> the upcoming SpringOne Platform conference. We're working through some
> great session proposals, and we'll keep adding the accepted sessions to the
> Geode page on the SpringOne Platform site.
>
> https://springoneplatform.io/geode
>
> I would like to promote the Geode coverage at this event on the Apache
> Geode site; the most appropriate placement is probably on the community
> page:
> http://geode.apache.org/community/
>
> It would also be great to get a banner
> on the home page, if this is appropriate.
>
> Who can help with editing the Apache Geode site to include this?
>
> --
> Regards
> Jag
>

[DISCUSS] Addition of isValid API to Index interface

2017-09-07 Thread Nabarun Nag

*Proposal:*
* Index interface will include an API - isValid() which will return true if
the index is still valid / uncorrupted, else will return false if it
corrupted / invalid.
* gfsh command "list index" will have one more column "Is Valid" which will
state the status as "true" or "false".
* Invalid indexes will not be used during query executions.
* In case the index is found to be invalid, the user will be able to
remove/destroy the index.
* When a put operation corrupts an index, it will be logged.

*Reasoning:*
* Currently if a put operation raises an exception while updating the
index, the put operation fails with an exception to the putter.
* For example, if an index is created on an object method, and that method
causes an exception while updating the index as a part of a put operation,
then the put operation fails for that particular entry and the index is
left in a bad state.
* This may occur also due to lack of permission to update index but have
permission to do puts.
* We are proposing that in the above mentioned scenarios, the put succeeds
in putting the entry in the region but the index which it was trying to
update will be marked invalid and will not be used for query executions.
* This can be justified because the corrupted index will not correctly
represent the region entries.

*Status Quo:*
* Index creation will still fail if we are trying to create an index over a
region containing an entry/entries  which will cause an exception while
loading the entry into the index.

Regards
Nabarun Nag

Re: Review Request 62178: GEODE-3449: Fix flakiness in ConnectCommandWithSSLTest

2017-09-07 Thread Jinmei Liao


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


Ship it!




Ship It!

- Jinmei Liao


On Sept. 7, 2017, 10:21 p.m., Jared Stewart wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/62178/
> ---
> 
> (Updated Sept. 7, 2017, 10:21 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Ken Howe, Kirk Lund, 
> and Patrick Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-3449: Fix flakiness in ConnectCommandWithSSLTest
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/IndexCommandsDUnitTest.java
>  794c58846ffe9c1b2b5143c95b9dc5aea388afbc 
> 
> 
> Diff: https://reviews.apache.org/r/62178/diff/1/
> 
> 
> Testing
> ---
> 
> Precheckin running
> 
> 
> Thanks,
> 
> Jared Stewart
> 
>

Re: Review Request 62178: GEODE-3449: Fix flakiness in ConnectCommandWithSSLTest

2017-09-07 Thread Jinmei Liao


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


Ship it!




Ship It!

- Jinmei Liao


On Sept. 7, 2017, 10:21 p.m., Jared Stewart wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/62178/
> ---
> 
> (Updated Sept. 7, 2017, 10:21 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Ken Howe, Kirk Lund, 
> and Patrick Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-3449: Fix flakiness in ConnectCommandWithSSLTest
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/IndexCommandsDUnitTest.java
>  794c58846ffe9c1b2b5143c95b9dc5aea388afbc 
> 
> 
> Diff: https://reviews.apache.org/r/62178/diff/1/
> 
> 
> Testing
> ---
> 
> Precheckin running
> 
> 
> Thanks,
> 
> Jared Stewart
> 
>

Re: Review Request 62132: GEODE-3277: Fix error path constructors of Launcher inner State classess

2017-09-07 Thread Jinmei Liao


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




geode-core/src/main/java/org/apache/geode/distributed/LocatorLauncher.java
Line 2026 (original), 2019 (patched)


just noticed the discrepencies between the parameters passed to this 
constructor and the one above. 

The one above calls launcher.getBindAddressAsString while this one ues 
getBindAddressAsSTring(launcher) which is private, probably we can do some code 
cleanup here?



geode-core/src/main/java/org/apache/geode/distributed/ServerLauncher.java
Lines 2607 (patched)


Is it possible to consolidate this method with the one in the LocatorState, 
seems very similar.


- Jinmei Liao


On Sept. 7, 2017, 10:29 p.m., Ken Howe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/62132/
> ---
> 
> (Updated Sept. 7, 2017, 10:29 p.m.)
> 
> 
> Review request for geode, Emily Yeh, Jinmei Liao, Jared Stewart, Kirk Lund, 
> and Patrick Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Updated tests for changes in the error constructors for ServerState and
> LocatorState.
> 
> Minor spelling corrections.
> 
> This reintroduces changes that were reverted due to merge conflicts with
> the previous state of the develop branch
> 
> 
> Diffs
> -
> 
>   geode-core/src/main/java/org/apache/geode/distributed/LocatorLauncher.java 
> 83c1ab533e3dea323a8a99f7002b9464a54dfc25 
>   geode-core/src/main/java/org/apache/geode/distributed/ServerLauncher.java 
> ae64691605130c9b212a3a33bb65ae37b28af02b 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/StartLocatorCommand.java
>  72ccfbbc83b18e8bc32759dbeabaf2f9ef4c2f45 
>   
> geode-core/src/test/java/org/apache/geode/distributed/LauncherIntegrationTestCase.java
>  409a96dbe416a6f96c2389356b9d823d1adb793f 
>   
> geode-core/src/test/java/org/apache/geode/distributed/LocatorLauncherLocalIntegrationTest.java
>  9fce94e89a369094a2383eb9103f2f43a8ff3013 
>   
> geode-core/src/test/java/org/apache/geode/distributed/LocatorLauncherRemoteIntegrationTest.java
>  cc42a53772f3064b800ca1ac1ae894be6c715399 
>   
> geode-core/src/test/java/org/apache/geode/distributed/ServerLauncherLocalIntegrationTest.java
>  29ddaaf6692565a9afb8c528790b35798d118a31 
>   
> geode-core/src/test/java/org/apache/geode/distributed/ServerLauncherRemoteIntegrationTest.java
>  733a1082ae9993fbdb646712380af7dcc1cca560 
>   
> geode-core/src/test/java/org/apache/geode/distributed/ServerLauncherTest.java 
> 2bcd994d4d14888adfdf68abef5acbc068b6fea8 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/rules/GfshShellConnectionRule.java
>  a9ce889006800523505dace6e0b4696c9911d205 
> 
> 
> Diff: https://reviews.apache.org/r/62132/diff/2/
> 
> 
> Testing
> ---
> 
> Precheckin is green
> 
> 
> Thanks,
> 
> Ken Howe
> 
>

Re: Review Request 62179: Test Rule Fix: clean up client DS when using LocatorServerStartupRule

2017-09-07 Thread Jinmei Liao



> On Sept. 7, 2017, 11:34 p.m., Jared Stewart wrote:
> > geode-core/src/test/java/org/apache/geode/test/dunit/rules/LocatorServerStartupRule.java
> > Lines 107 (patched)
> > 
> >
> > How do you think this reads this instead of the `for` loop? 
> > ```
> > Consumer stopMemberAndDisconnectDS = (MemberVM memberVM) 
> > -> {
> >   memberVM.stopMember();
> >   memberVM.getVM().invoke((SerializableRunnableIF) 
> > MemberStarterRule::disconnectDSIfAny);
> > };
> > 
> > 
> > Arrays.stream(members).filter(Objects::nonNull).forEach(stopMemberAndDisconnectDS);
> > ```

this way, we are still only calling disconnectDSIfAny() when the members 
element is not null. When a VM is used only as a client, the members[] won't 
contain that VM at all, because it only contains the ServerVM and LocatorVM.


- Jinmei


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


On Sept. 7, 2017, 11:12 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/62179/
> ---
> 
> (Updated Sept. 7, 2017, 11:12 p.m.)
> 
> 
> Review request for geode, Jared Stewart, Ken Howe, Kirk Lund, and Patrick 
> Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Test Rule Fix: clean up clientVM if using LocatorServerStartUpRule to get the 
> ClientVM
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/rules/LocatorServerStartupRule.java
>  f0385e21f708d9a085e7129d82fb3101e2fb8322 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/rules/MemberStarterRule.java
>  a832a2590527100afc05fb9de2e332a263d52c19 
> 
> 
> Diff: https://reviews.apache.org/r/62179/diff/1/
> 
> 
> Testing
> ---
> 
> precheckin running
> 
> 
> Thanks,
> 
> Jinmei Liao
> 
>

40 matches

Mail list logo