Re: Review Request 59905: add GfshParserRule to fascilidate command unit test

[Jinmei Liao]

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


Ship it!




Ship It!

- Jinmei Liao


On June 8, 2017, 1:48 a.m., Jared Stewart wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59905/
> ---
> 
> (Updated June 8, 2017, 1:48 a.m.)
> 
> 
> Review request for geode, Emily Yeh, Jared Stewart, Ken Howe, Kirk Lund, and 
> Patrick Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2933: Add jmx-manager-hostname-for-clients for startLocator and 
> startServer
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/GfshParser.java
>  df16e9b9e9f71f21ef7c8ac84267a9858ee4298c 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/LauncherLifecycleCommands.java
>  4c668b6813de71aae9e3e46c82a5c231a41c1f6a 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/i18n/CliStrings.java
>  9f68d3a5eaadbe8f1bd95ec8df85ed1f65aa67ce 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/remote/CommandProcessor.java
>  c2c6e1425d71af9d2ea59046b17afd70ad30dd68 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/shell/Gfsh.java
>  c5ff6b6a51a0bd866d62e15dfce13938c87ecf6b 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/GfshParserAutoCompletionTest.java
>  a122de048eb75ca448155541e2266c872c98904d 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/GfshParserConverterTest.java
>  1ff60d67a7dbfe582e632c116ba83d471211de45 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/GfshParserParsingTest.java
>  ab6dc3d10a6235af0ca6fc5164cac5d3c2419cdd 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/LauncherLifecycleCommandsTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/rules/GfshParserRule.java
>  PRE-CREATION 
> 
> 
> Diff: https://reviews.apache.org/r/59905/diff/1/
> 
> 
> Testing
> ---
> 
> Precheckin passed (other than 1 known flaky)
> 
> 
> Thanks,
> 
> Jared Stewart
> 
>

Build failed in Jenkins: Geode-nightly #860

[Apache Jenkins Server]

See 


Changes:

[bschuchardt] GEODE-3024 race condition between server locator preparing 
membership

[boglesby] GEODE-3040: Compare gateway profile order policy against 9.0 instead 
of

[dbarnes] GEODE-3044: User Manual: Update Swagger example and screen shots -

[dbarnes] GEODE-2555: Region Management docs page refers to the wrong field (id=

[dschneider] GEODE-3027: add a simple PartitionResolver

[abaker] GEODE-194: Remove spark connector

[dbarnes] GEODE-3044: User Manual: Update Swagger example and screen shots -

--
Started by timer
[EnvInject] - Loading node environment variables.
Building remotely on mesos2 (mesos s390x) 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/*
 > git rev-parse refs/remotes/origin/develop^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/develop^{commit} # timeout=10
Checking out Revision d73fa3ce289b2108ba352755a68aa8baf9e9b4ca 
(refs/remotes/origin/develop)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f d73fa3ce289b2108ba352755a68aa8baf9e9b4ca
 > git branch -a -v --no-abbrev # timeout=10
 > git branch -D develop # timeout=10
 > git checkout -b develop d73fa3ce289b2108ba352755a68aa8baf9e9b4ca
 > git rev-list 7bad40f368e14182b3cbc88d56505858af3a0ddd # timeout=10
[Geode-nightly] $ /bin/bash -xe /tmp/hudson7488740573973842216.sh
+ git clean -d -f gemfire-pulse/src/main/resources/
[Gradle] - Launching build.
[Geode-nightly] $  
--no-daemon clean precheckin distTar distZip uploadArchives -xflakyTest

ERROR: JAVA_HOME is set to an invalid directory: 
/home/jenkins/tools/java/latest1.8

Please set the JAVA_HOME variable in your environment to match the
location of your Java installation.

Build step 'Invoke Gradle script' changed build result to FAILURE
Build step 'Invoke Gradle script' marked build as failure
Archiving artifacts
Recording test results
ERROR: Step ?Publish JUnit test result report? failed: No test report files 
were found. Configuration error?
Not sending mail to unregistered user e...@pivotal.io
Not sending mail to unregistered user jil...@pivotal.io

Review Request 59905: add GfshParserRule to fascilidate command unit test

[Jared Stewart]

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

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


Repository: geode


Description
---

GEODE-2933: Add jmx-manager-hostname-for-clients for startLocator and 
startServer


Diffs
-

  
geode-core/src/main/java/org/apache/geode/management/internal/cli/GfshParser.java
 df16e9b9e9f71f21ef7c8ac84267a9858ee4298c 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/LauncherLifecycleCommands.java
 4c668b6813de71aae9e3e46c82a5c231a41c1f6a 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/i18n/CliStrings.java
 9f68d3a5eaadbe8f1bd95ec8df85ed1f65aa67ce 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/remote/CommandProcessor.java
 c2c6e1425d71af9d2ea59046b17afd70ad30dd68 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/shell/Gfsh.java
 c5ff6b6a51a0bd866d62e15dfce13938c87ecf6b 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/GfshParserAutoCompletionTest.java
 a122de048eb75ca448155541e2266c872c98904d 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/GfshParserConverterTest.java
 1ff60d67a7dbfe582e632c116ba83d471211de45 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/GfshParserParsingTest.java
 ab6dc3d10a6235af0ca6fc5164cac5d3c2419cdd 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/LauncherLifecycleCommandsTest.java
 PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/test/dunit/rules/GfshParserRule.java 
PRE-CREATION 


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


Testing
---

Precheckin passed (other than 1 known flaky)


Thanks,

Jared Stewart

[DISCUSS] Using Pull Requests over Review Board

[Jacob Barrett]

All,

I would like to discuss transitioning all code reviews to pull requests
over using review board. For non-committer community members we ask them to
make pull requests against the mirrored GitHub repo. Some committers use
pull requests for their own work reviews while others use review board. I
propose that we just use on and that the one we use be pull requests. It
would give us a single source of history for reviews, a single model to
understand for reviewers and committers and keep workflow consistent with
all contributors, committers or not.

-Jake

Re: [DISCUSS] easy string based partitioning

[Michael Stolz]

Actually it appears that parameterizing the delimeter would be quite
problematic for client side single hop.

--
Mike Stolz
Principal Engineer - Gemfire Product Manager
Mobile: 631-835-4771

On Jun 7, 2017 1:56 PM, "Galen M O'Sullivan"  wrote:

> I don't think it would be that much harder to add an option for a
> user-specified delimiter than it would to hardcode ':' or '|'. I think the
> utility of that would be much higher, and that it would be a much better
> candidate for inclusion in geode-core. Otherwise, I think it should live in
> an "examples" or "utilities" package or repo.
>
> Galen
>
> On Wed, Jun 7, 2017 at 12:47 PM, Jacob Barrett 
> wrote:
>
> > In regard to sending the configuration state to the clients for the
> > partition resolver maybe the config should be a domain object independent
> > of the business object rather than the serialized form of the partition
> > resolver itself. The rational for this would be that non-Java clients
> could
> > get the config as PDX (or some other language neutral scheme) and
> > initialize their native language version of the partition resolver with
> > this config.
> >
> > -Jake
> >
> >
> > Sent from my iPhone
> >
> > > On Jun 7, 2017, at 11:42 AM, Darrel Schneider 
> > wrote:
> > >
> > > Thanks for all the feedback. Since this is such a simple resolver with
> a
> > > fixed delimiter the following changes were made to the original
> proposal:
> > > 1. The StringPrefixPartitionResolver will be in the
> > > "org.apache.geode.cache.util" package.
> > >This was done to keep it from being viewed as part of the core API.
> It
> > > is just a simple implementation
> > >of one of the core API interfaces that user can use if they find it
> > > helpful.
> > > 2. The fixed delimiter was changed from ":" to "|". The character still
> > has
> > > the visual appearance of
> > >delimiting two fields with the benefit of being used less often than
> > > ":". Since the delimiter can not
> > >be configured that makes it more likely someone can use this
> resolver.
> > >
> > > I think the ideas about more complex resolvers are interesting and the
> > > existence of this simple resolver does not prevent other resolver
> > > implementations from also being added to the util package. For example
> > one
> > > that is regex based or spring expression based.
> > >
> > > One of the things discovered was that if a PartitionResolver has state
> > (for
> > > example a configured delimiter, or regex, or spring expression) then
> that
> > > java clients will not be able to single hop to the server region with
> > that
> > > resolver. Our servers send the single hop java clients just the class
> > name
> > > of the PartitionResolver. The instance of the actual resolver is not
> > > serialized to the client. The java client single hop code attempts to
> > > create an instance of it by invoking a no-arg constructor. So any state
> > > stored in the server's resolver instance will be lost. If the resolver
> > > class does not have a no-arg constructor then the java client will be
> > > unable to load an instance and just disable single hop. But if it had
> two
> > > constructors, say one that has no-arg and configures a default
> delimiter
> > > and another that take a delimiter as an arg, then in that case the
> single
> > > hop client would lose the delimiter configured on the server and revert
> > to
> > > the default one from the no-arg constructor. It seems like this could
> > cause
> > > all kinds of bad things to happen. For example in the case of a
> > > StringPrefixPartitionResolver that allows the delimiter to be
> configured
> > > that one used on this client to route keys to the server would have the
> > > wrong delimiter and complain that the key does not contain the
> > delimiter. I
> > > will file a geode ticket about this issue but wanted to have it on this
> > > thread to help explain why this initial resolver is not configurable.
> > >
> > >
> > >> On Tue, Jun 6, 2017 at 1:20 PM, Jacob Barrett 
> > wrote:
> > >>
> > >> I have to agree. Something this trivial an limiting is better suited
> > for a
> > >> blog post or examples somewhere and not a part of the core codebase.
> > >>
> > >> -Jake
> > >>
> > >> On Mon, Jun 5, 2017 at 1:27 PM Udo Kohlmeyer 
> > >> wrote:
> > >>
> > >>> My concern with this approach is that we provide an implementation
> that
> > >>> might be a white elephant and only used by a 1% user base. In
> addition
> > >>> to that, it does really restrict the user on his keys.
> > >>>
> > >>> Whereas something a little more configurable, like a SPEL
> > >>> implementation, would provide a lot more flexibility. Which means
> that
> > >>> one could easily change the partition resolver expression upon region
> > >>> creation/configuration.
> > >>>
> > >>> --Udo
> > >>>
> > >>>
> >  On 6/5/17 08:46, Jens Deppe wrote:
> >  I 

Re: Review Request 59863: Removing obsolete SSL handling in `AcceptorImpl.accept` catch block

[Brian Rowe]

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

(Updated June 8, 2017, 12:40 a.m.)


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


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


Repository: geode


Description
---

SSL handshake is now done in a separate thread and will never reach the handler 
code which is being removed.


Diffs (updated)
-

  
geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/AcceptorImpl.java
 9658f98da 


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

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


Testing
---

Precheckin started


Thanks,

Brian Rowe

Re: Review Request 59850: GEODE-3023: TcpServer thread can be blocked in processRequest

[Udo Kohlmeyer]

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

(Updated June 8, 2017, 12:20 a.m.)


Review request for geode, Alexander Murmann, Bruce Schuchardt, Galen 
O'Sullivan, Hitesh Khamesra, and Brian Rowe.


Repository: geode


Description
---

Moved the socket.setSoTimeout setting to be before the SSL handshake. This is 
to avoid the timeout to never be set in the case of a SSLException. Added a 
test to test that the socket timeout is correctly set upon failure within the 
SSL configuration and handshake.


Diffs
-

  
geode-core/src/main/java/org/apache/geode/distributed/internal/tcpserver/TcpServer.java
 86fe53261 
  
geode-core/src/test/java/org/apache/geode/distributed/internal/tcpserver/TCPServerSSLJUnitTest.java
 PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/distributed/internal/tcpserver/TcpServerJUnitTest.java
 7c7a2b376 
  
geode-core/src/test/java/org/apache/geode/internal/net/DelaySocketCreator.java 
PRE-CREATION 


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


Testing (updated)
---

Junit test - done
precheckin - done


Thanks,

Udo Kohlmeyer

[GitHub] geode pull request #567: GEODE-3051: Removing obsolete SSL handling in `Acce...

[WireBaron]

GitHub user WireBaron opened a pull request:

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

GEODE-3051: Removing obsolete SSL handling in `AcceptorImpl.accept` c…

…atch block

Thank you for submitting a contribution to Apache Geode.

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

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

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

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

- [ ] Does `gradlew build` run cleanly?

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

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

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


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

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

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

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

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

This closes #567


commit 9354cacfc6a8fa79746e8240730f6a209199bb89
Author: Galen O'Sullivan 
Date:   2017-06-08T00:04:17Z

GEODE-3051: Removing obsolete SSL handling in `AcceptorImpl.accept` catch 
block




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

Review Request 59904: GEODE-3050: prevent empty dat files

[Kirk Lund]

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

Review request for geode and Bruce Schuchardt.


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


Repository: geode


Description
---

GEODE-3050: prevent empty dat files

Move creation of dat files to test methods to avoid overwriting
full dat file from other test.


Diffs
-

  
geode-core/src/test/java/org/apache/geode/codeAnalysis/AnalyzeSerializablesJUnitTest.java
 dc73f04309d36fec79558914a81f5eddcbbbe5a9 


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


Testing
---

1) AnalyzeSerializablesJUnitTest, AnalyzeCQSerializablesJUnitTest, 
AnalyzeWANSerializablesJUnitTest
2) precheckin in progress


Thanks,

Kirk Lund

Re: Review Request 59850: GEODE-3023: TcpServer thread can be blocked in processRequest

[Hitesh Khamesra]

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


Fix it, then Ship it!




Ship It!


geode-core/src/main/java/org/apache/geode/distributed/internal/tcpserver/TcpServer.java
Line 171 (original)


Is that code moved inside/will never happen?


- Hitesh Khamesra


On June 7, 2017, 11:32 p.m., Udo Kohlmeyer wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59850/
> ---
> 
> (Updated June 7, 2017, 11:32 p.m.)
> 
> 
> Review request for geode, Alexander Murmann, Bruce Schuchardt, Galen 
> O'Sullivan, Hitesh Khamesra, and Brian Rowe.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Moved the socket.setSoTimeout setting to be before the SSL handshake. This is 
> to avoid the timeout to never be set in the case of a SSLException. Added a 
> test to test that the socket timeout is correctly set upon failure within the 
> SSL configuration and handshake.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/tcpserver/TcpServer.java
>  86fe53261 
>   
> geode-core/src/test/java/org/apache/geode/distributed/internal/tcpserver/TCPServerSSLJUnitTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/distributed/internal/tcpserver/TcpServerJUnitTest.java
>  7c7a2b376 
>   
> geode-core/src/test/java/org/apache/geode/internal/net/DelaySocketCreator.java
>  PRE-CREATION 
> 
> 
> Diff: https://reviews.apache.org/r/59850/diff/2/
> 
> 
> Testing
> ---
> 
> Junit test - done
> precheckin - in progress
> 
> 
> Thanks,
> 
> Udo Kohlmeyer
> 
>

Re: Review Request 59863: Removing obsolete SSL handling in `AcceptorImpl.accept` catch block

[Hitesh Khamesra]

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




geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/AcceptorImpl.java
Line 1252 (original)


Do we need to move this code in another thread?


- Hitesh Khamesra


On June 6, 2017, 10:19 p.m., Brian Rowe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59863/
> ---
> 
> (Updated June 6, 2017, 10:19 p.m.)
> 
> 
> Review request for geode, Bruce Schuchardt, Galen O'Sullivan, Hitesh 
> Khamesra, and Udo Kohlmeyer.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> SSL handshake is now done in a separate thread and will never reach the 
> handler code which is being removed.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/AcceptorImpl.java
>  9658f98da 
> 
> 
> Diff: https://reviews.apache.org/r/59863/diff/1/
> 
> 
> Testing
> ---
> 
> Precheckin started
> 
> 
> Thanks,
> 
> Brian Rowe
> 
>

[GitHub] geode issue #325: merge new version

[kohlmu-pivotal]

Github user kohlmu-pivotal commented on the issue:

https://github.com/apache/geode/pull/325
  
Is this PR still open or relevant? If not, could we please close this


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

[GitHub] geode issue #474: GEODE-2788: Add official Socket timeout parameter when con...

[kohlmu-pivotal]

Github user kohlmu-pivotal commented on the issue:

https://github.com/apache/geode/pull/474
  
@masaki-yamakawa I'm running precheckin. If it passes I'll merge this PR.


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

Re: Review Request 59893: GEODE-3032: Fix CI failure of CommandOverHttpDUnitTest

[Jinmei Liao]

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


Ship it!




Ship It!

- Jinmei Liao


On June 7, 2017, 11:13 p.m., Jared Stewart wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59893/
> ---
> 
> (Updated June 7, 2017, 11:13 p.m.)
> 
> 
> Review request for geode, Emily Yeh, Jared Stewart, Ken Howe, Kirk Lund, and 
> Patrick Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-3032: Fix CI failure of CommandOverHttpDUnitTest
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/MemberCommandsDUnitTest.java
>  5bbfc5b 
>   
> geode-web/src/test/java/org/apache/geode/management/internal/cli/commands/CommandOverHttpDUnitTest.java
>  2a6a03b 
> 
> 
> Diff: https://reviews.apache.org/r/59893/diff/2/
> 
> 
> Testing
> ---
> 
> Precheckin is green except for unrelated flaky DUnits.
> 
> 
> Thanks,
> 
> Jared Stewart
> 
>

Re: Review Request 59863: Removing obsolete SSL handling in `AcceptorImpl.accept` catch block

[Udo Kohlmeyer]

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


Ship it!




Please attach the correct GEODE JIRA number to this.

- Udo Kohlmeyer


On June 6, 2017, 10:19 p.m., Brian Rowe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59863/
> ---
> 
> (Updated June 6, 2017, 10:19 p.m.)
> 
> 
> Review request for geode, Bruce Schuchardt, Galen O'Sullivan, Hitesh 
> Khamesra, and Udo Kohlmeyer.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> SSL handshake is now done in a separate thread and will never reach the 
> handler code which is being removed.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/AcceptorImpl.java
>  9658f98da 
> 
> 
> Diff: https://reviews.apache.org/r/59863/diff/1/
> 
> 
> Testing
> ---
> 
> Precheckin started
> 
> 
> Thanks,
> 
> Brian Rowe
> 
>

Re: Review Request 59893: GEODE-3032: Fix CI failure of CommandOverHttpDUnitTest

[Jared Stewart]

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

(Updated June 7, 2017, 11:13 p.m.)


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


Changes
---

Upon further exception, MemberCommandsDUnitTest doesn't even read the "useHTTP" 
system property being set by the CommandOverHttpDUnitTest Suite.  As such, we 
can simply remove it from the suite.


Repository: geode


Description
---

GEODE-3032: Fix CI failure of CommandOverHttpDUnitTest


Diffs (updated)
-

  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/MemberCommandsDUnitTest.java
 5bbfc5b 
  
geode-web/src/test/java/org/apache/geode/management/internal/cli/commands/CommandOverHttpDUnitTest.java
 2a6a03b 


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

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


Testing
---

Precheckin is green except for unrelated flaky DUnits.


Thanks,

Jared Stewart

Re: Review Request 59896: GEODE-3043 surprise member added when the member is already in the cluster

[Udo Kohlmeyer]

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


Ship it!




Ship It!


geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/mgr/GMSMembershipManager.java
Lines 1137 (patched)


Can this feasibly return a partial? Looking at the code it might be able 
to. Is this correct behaviour?


- Udo Kohlmeyer


On June 7, 2017, 10:02 p.m., Bruce Schuchardt wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59896/
> ---
> 
> (Updated June 7, 2017, 10:02 p.m.)
> 
> 
> Review request for geode, Alexander Murmann, Galen O'Sullivan, Hitesh 
> Khamesra, Udo Kohlmeyer, and Brian Rowe.
> 
> 
> Bugs: GEODE-3043
> https://issues.apache.org/jira/browse/GEODE-3043
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Modified InternalDistributedMember to disregard the "name" field in compareTo 
> if partial IDs are being used in the comparison.
> 
> Modified GMSMembershipManager to attempt to replace partial IDs with the full 
> IDs from the membership view.  Typically these IDs will cause no problems and 
> methods in GMSMembershipManager that send messages to a recipient will also 
> attempt to replace the ID with a full ID from the membership view, but it's 
> good to try to keep IDs canonical.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/InternalDistributedMember.java
>  6982d31f13ad5f5f004f0e7c9a0f4e1aa26a151a 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/GMSMember.java
>  c82d97e9facca19bfb08b20407abf21dd274684e 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/mgr/GMSMembershipManager.java
>  fe560d9eb71131cf1ca5e5ca124e877769e9d518 
>   
> geode-core/src/test/java/org/apache/geode/distributed/DistributedMemberDUnitTest.java
>  0153ca6506af574798ad01b98d9a395fad7be5d5 
> 
> 
> Diff: https://reviews.apache.org/r/59896/diff/1/
> 
> 
> Testing
> ---
> 
> New tests, precheckin
> 
> 
> Thanks,
> 
> Bruce Schuchardt
> 
>

Re: Review Request 59893: GEODE-3032: Fix CI failure of CommandOverHttpDUnitTest

[Jinmei Liao]

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


Ship it!




Ship It!

- Jinmei Liao


On June 7, 2017, 9:08 p.m., Jared Stewart wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59893/
> ---
> 
> (Updated June 7, 2017, 9:08 p.m.)
> 
> 
> Review request for geode, Emily Yeh, Jared Stewart, Ken Howe, Kirk Lund, and 
> Patrick Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-3032: Fix CI failure of CommandOverHttpDUnitTest
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/MemberCommandsDUnitTest.java
>  5bbfc5b3d4ba1a37f8c1e700a36bd96b4ea40667 
> 
> 
> Diff: https://reviews.apache.org/r/59893/diff/1/
> 
> 
> Testing
> ---
> 
> Precheckin is green except for unrelated flaky DUnits.
> 
> 
> Thanks,
> 
> Jared Stewart
> 
>

[GitHub] geode issue #508: GEODE-2908: Adding the new tag as per swagger notification...

[davebarnes97]

Github user davebarnes97 commented on the issue:

https://github.com/apache/geode/pull/508
  
Will add my comment to GEODE-3035 Rest: Swagger UI has lot of references to 
GemFire, instead they should be changed to geode


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

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

[Spring CI]

---
Spring Data GemFire > Nightly-ApacheGeode > #578 was successful.
---
Scheduled
1870 tests in total.

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





--
This message is automatically generated by Atlassian Bamboo

[GitHub] geode issue #508: GEODE-2908: Adding the new tag as per swagger notification...

[jaredjstewart]

Github user jaredjstewart commented on the issue:

https://github.com/apache/geode/pull/508
  
This PR has already been merged in, but feel free to open a new ticket for 
that.  We unfortunately still have a lot of other "gemfire" references 
scattered around.


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

Re: Review Request 59811: GEODE-2420: add file-size-limit param to the ExportLogsController

[Ken Howe]

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

(Updated June 7, 2017, 10:34 p.m.)


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


Changes
---

Updated per review


Repository: geode


Description
---

GEODE-2420: add file-size-limit param to the ExportLogsController


Diffs (updated)
-

  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportLogsCommand.java
 0ff780cbf66937d8ececfb3a2d0789ee485b9b62 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/SizeExportLogsFunction.java
 57355c0efae4c6da9470267f95e27e59aa4d8b2c 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/i18n/CliStrings.java
 9f68d3a5eaadbe8f1bd95ec8df85ed1f65aa67ce 
  
geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/ExportLogController.java
 a369c6e1ffb330715fbde2cd69d023ed36f133ad 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsCommandTest.java
 16549e70bbebf4390bb73a481274e92ca6cad035 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsDUnitTest.java
 8609b3aaf0a0eb1ba903bd39c64103f9510a6a78 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsFileSizeLimitTest.java
 09ee08dd6af29b9a418ef7499defc4980da787ed 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsStatsDUnitTest.java
 44a036298e0991c880fc552596d296e104b97ca1 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsTestSuite.java
 4e1dac013d239437829bc52dc70689c4ba15dc58 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/SizeExportLogsFunctionTest.java
 cc5e7d5256741ad0a48ff87c7f989a18b90f7f03 


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

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


Testing (updated)
---

6/7/17: re-started precheckin
precheckin is green with the exception of unrelated DUnit tests

* re-starting precheckin once more

Precheckin started


Thanks,

Ken Howe

Re: Review Request 59811: GEODE-2420: add file-size-limit param to the ExportLogsController

[Ken Howe]

> On June 7, 2017, 9:40 p.m., Jared Stewart wrote:
> > geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportLogsCommand.java
> > Line 122 (original), 123 (patched)
> > 
> >
> > I really like the "fail fast" idea!  Can I suggest a minor reordering 
> > of a few lines that might be more readable?  (The basic idea is just to 
> > move the lines into a narrower scope when possible).
> > 
> > ```
> >  List results = (List) estimateLogSize(args, 
> > server).getResult();
> >   if (!results.isEmpty()) {
> > if (results.get(0) instanceof Long) {
> >   long estimatedSize = (Long) results.get(0);
> >   logger.info("Received estimated export size from member 
> > {}: {}", server.getId(),
> >   estimatedSize);
> >   totalEstimatedExportSize += estimatedSize;
> > } else if (results.get(0) instanceof ManagementException) {
> >   ManagementException exception = (ManagementException) 
> > results.get(0);
> >   return 
> > ResultBuilder.createUserErrorResult(exception.getMessage());
> > }
> >   }
> > ```

Good suggestion, I do think it helps readability.


- Ken


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


On June 7, 2017, 10:23 p.m., Ken Howe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59811/
> ---
> 
> (Updated June 7, 2017, 10:23 p.m.)
> 
> 
> Review request for geode, Emily Yeh, Jinmei Liao, Jared Stewart, Kirk Lund, 
> and Patrick Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2420: add file-size-limit param to the ExportLogsController
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportLogsCommand.java
>  0ff780cbf66937d8ececfb3a2d0789ee485b9b62 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/SizeExportLogsFunction.java
>  57355c0efae4c6da9470267f95e27e59aa4d8b2c 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/i18n/CliStrings.java
>  9f68d3a5eaadbe8f1bd95ec8df85ed1f65aa67ce 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/ExportLogController.java
>  a369c6e1ffb330715fbde2cd69d023ed36f133ad 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsCommandTest.java
>  16549e70bbebf4390bb73a481274e92ca6cad035 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsDUnitTest.java
>  8609b3aaf0a0eb1ba903bd39c64103f9510a6a78 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsFileSizeLimitTest.java
>  09ee08dd6af29b9a418ef7499defc4980da787ed 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsStatsDUnitTest.java
>  44a036298e0991c880fc552596d296e104b97ca1 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsTestSuite.java
>  4e1dac013d239437829bc52dc70689c4ba15dc58 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/SizeExportLogsFunctionTest.java
>  cc5e7d5256741ad0a48ff87c7f989a18b90f7f03 
> 
> 
> Diff: https://reviews.apache.org/r/59811/diff/2/
> 
> 
> Testing
> ---
> 
> 6/7/17: re-started precheckin
> precheckin is green with the exception of unrelated DUnit tests
> 
> Precheckin started
> 
> 
> Thanks,
> 
> Ken Howe
> 
>

Re: Review Request 59893: GEODE-3032: Fix CI failure of CommandOverHttpDUnitTest

[Emily Yeh]

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


Ship it!




Ship It!

- Emily Yeh


On June 7, 2017, 9:08 p.m., Jared Stewart wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59893/
> ---
> 
> (Updated June 7, 2017, 9:08 p.m.)
> 
> 
> Review request for geode, Emily Yeh, Jared Stewart, Ken Howe, Kirk Lund, and 
> Patrick Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-3032: Fix CI failure of CommandOverHttpDUnitTest
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/MemberCommandsDUnitTest.java
>  5bbfc5b3d4ba1a37f8c1e700a36bd96b4ea40667 
> 
> 
> Diff: https://reviews.apache.org/r/59893/diff/1/
> 
> 
> Testing
> ---
> 
> Precheckin is green except for unrelated flaky DUnits.
> 
> 
> Thanks,
> 
> Jared Stewart
> 
>

Review Request 59896: GEODE-3043 surprise member added when the member is already in the cluster

[Bruce Schuchardt]

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

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


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


Repository: geode


Description
---

Modified InternalDistributedMember to disregard the "name" field in compareTo 
if partial IDs are being used in the comparison.

Modified GMSMembershipManager to attempt to replace partial IDs with the full 
IDs from the membership view.  Typically these IDs will cause no problems and 
methods in GMSMembershipManager that send messages to a recipient will also 
attempt to replace the ID with a full ID from the membership view, but it's 
good to try to keep IDs canonical.


Diffs
-

  
geode-core/src/main/java/org/apache/geode/distributed/internal/membership/InternalDistributedMember.java
 6982d31f13ad5f5f004f0e7c9a0f4e1aa26a151a 
  
geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/GMSMember.java
 c82d97e9facca19bfb08b20407abf21dd274684e 
  
geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/mgr/GMSMembershipManager.java
 fe560d9eb71131cf1ca5e5ca124e877769e9d518 
  
geode-core/src/test/java/org/apache/geode/distributed/DistributedMemberDUnitTest.java
 0153ca6506af574798ad01b98d9a395fad7be5d5 


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


Testing
---

New tests, precheckin


Thanks,

Bruce Schuchardt

Review Request 59894: GEODE-3041 CI failure: DistributedMemberDUnitTest.testGroupsInAllVMs fails intermittently

[Bruce Schuchardt]

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

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


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


Repository: geode


Description
---

When shutting down the MembershipManager after it has joined we should not use 
uncleanShutdown because the member will appear to have crashed.  Instead we 
should do a normal shutdown.


Diffs
-

  
geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionChannel.java
 ef4056ca56c1b102e507f96bbfe41396d0139aa5 
  
geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionManager.java
 029e6377f56d80dd81e4cec430f106ac743e5178 


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


Testing
---

The test was failing every time I ran it.  It no longer fails.


Thanks,

Bruce Schuchardt

Re: Review Request 59811: GEODE-2420: add file-size-limit param to the ExportLogsController

[Jared Stewart]

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




geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportLogsCommand.java
Line 122 (original), 123 (patched)


I really like the "fail fast" idea!  Can I suggest a minor reordering of a 
few lines that might be more readable?  (The basic idea is just to move the 
lines into a narrower scope when possible).

```
 List results = (List) estimateLogSize(args, 
server).getResult();
  if (!results.isEmpty()) {
if (results.get(0) instanceof Long) {
  long estimatedSize = (Long) results.get(0);
  logger.info("Received estimated export size from member {}: 
{}", server.getId(),
  estimatedSize);
  totalEstimatedExportSize += estimatedSize;
} else if (results.get(0) instanceof ManagementException) {
  ManagementException exception = (ManagementException) 
results.get(0);
  return 
ResultBuilder.createUserErrorResult(exception.getMessage());
}
  }
```


- Jared Stewart


On June 7, 2017, 6:35 p.m., Ken Howe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59811/
> ---
> 
> (Updated June 7, 2017, 6:35 p.m.)
> 
> 
> Review request for geode, Emily Yeh, Jinmei Liao, Jared Stewart, Kirk Lund, 
> and Patrick Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2420: add file-size-limit param to the ExportLogsController
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportLogsCommand.java
>  0ff780cbf66937d8ececfb3a2d0789ee485b9b62 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/SizeExportLogsFunction.java
>  57355c0efae4c6da9470267f95e27e59aa4d8b2c 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/i18n/CliStrings.java
>  9f68d3a5eaadbe8f1bd95ec8df85ed1f65aa67ce 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/ExportLogController.java
>  a369c6e1ffb330715fbde2cd69d023ed36f133ad 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsCommandTest.java
>  16549e70bbebf4390bb73a481274e92ca6cad035 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsDUnitTest.java
>  8609b3aaf0a0eb1ba903bd39c64103f9510a6a78 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsFileSizeLimitTest.java
>  09ee08dd6af29b9a418ef7499defc4980da787ed 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsStatsDUnitTest.java
>  44a036298e0991c880fc552596d296e104b97ca1 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsTestSuite.java
>  4e1dac013d239437829bc52dc70689c4ba15dc58 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/SizeExportLogsFunctionTest.java
>  cc5e7d5256741ad0a48ff87c7f989a18b90f7f03 
> 
> 
> Diff: https://reviews.apache.org/r/59811/diff/2/
> 
> 
> Testing
> ---
> 
> 6/7/17: re-started precheckin
> 
> Precheckin started
> 
> 
> Thanks,
> 
> Ken Howe
> 
>

Re: Review Request 59811: GEODE-2420: add file-size-limit param to the ExportLogsController

[Jared Stewart]

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


Ship it!




Ship It!

- Jared Stewart


On June 7, 2017, 6:35 p.m., Ken Howe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59811/
> ---
> 
> (Updated June 7, 2017, 6:35 p.m.)
> 
> 
> Review request for geode, Emily Yeh, Jinmei Liao, Jared Stewart, Kirk Lund, 
> and Patrick Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2420: add file-size-limit param to the ExportLogsController
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportLogsCommand.java
>  0ff780cbf66937d8ececfb3a2d0789ee485b9b62 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/SizeExportLogsFunction.java
>  57355c0efae4c6da9470267f95e27e59aa4d8b2c 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/i18n/CliStrings.java
>  9f68d3a5eaadbe8f1bd95ec8df85ed1f65aa67ce 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/ExportLogController.java
>  a369c6e1ffb330715fbde2cd69d023ed36f133ad 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsCommandTest.java
>  16549e70bbebf4390bb73a481274e92ca6cad035 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsDUnitTest.java
>  8609b3aaf0a0eb1ba903bd39c64103f9510a6a78 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsFileSizeLimitTest.java
>  09ee08dd6af29b9a418ef7499defc4980da787ed 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsStatsDUnitTest.java
>  44a036298e0991c880fc552596d296e104b97ca1 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsTestSuite.java
>  4e1dac013d239437829bc52dc70689c4ba15dc58 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/SizeExportLogsFunctionTest.java
>  cc5e7d5256741ad0a48ff87c7f989a18b90f7f03 
> 
> 
> Diff: https://reviews.apache.org/r/59811/diff/2/
> 
> 
> Testing
> ---
> 
> 6/7/17: re-started precheckin
> 
> Precheckin started
> 
> 
> Thanks,
> 
> Ken Howe
> 
>

[GitHub] geode pull request #558: GEODE-194: Remove spark connector

[asfgit]

Github user asfgit closed the pull request at:

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


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

Re: Need authorization to tweet for Apache Geode

[Greg Chase]

Never too many.  I've added you to the TweetDeck team.



On Wed, Jun 7, 2017 at 2:08 PM, Kirk Lund  wrote:

> I'll volunteer to help too unless that's too many folks. My twitter is
> @kirk_lund
>
> On Wed, Jun 7, 2017 at 1:51 PM, Greg Chase  wrote:
>
> > Added you Mike.
> >
> > On Wed, Jun 7, 2017 at 1:41 PM, Michael Stolz  wrote:
> >
> > > Hi Greg,
> > >
> > > I didn't give you my Twitter handle: @MikeStolz1
> > >
> > >
> > > --
> > > Mike Stolz
> > > Principal Engineer, GemFire Product Manager
> > > Mobile: +1-631-835-4771
> > >
> > > On Wed, Jun 7, 2017 at 1:23 PM, Gregory Chase 
> wrote:
> > >
> > > > Hi Jag,
> > > > Thanks for volunteering to help communicate the goodness of
> > @ApacheGeode!
> > > >
> > > > I'll add you to the authorized Twitter team in TweetDeck!
> > > >
> > > > -Greg
> > > >
> > > > On Wed, Jun 7, 2017 at 1:19 PM, Jagdish Mirani 
> > > wrote:
> > > >
> > > > > Hello:
> > > > > I would like to be authorized to tweet for Apache Geode - I would
> > like
> > > to
> > > > > Tweet from the project handle on behalf of the project.
> > > > >
> > > > > About me.
> > > > >
> > > > > *Twitter handle: *@jagmirani
> > > > > *Role: *I am the Product Marketing Manager for Pivotal GemFire
> (which
> > > is
> > > > > based on Apache Geode). Also, I work closely with our engineering
> and
> > > > > Product Management teams on our contributions to the Geode project.
> > > > >
> > > > > Please authorize tweeting privileges for me.
> > > > >
> > > > > Regards
> > > > > Jagdish Mirani
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Greg Chase
> > > >
> > > > Product team
> > > > http://www.pivotal.io/big-data
> > > >
> > > > Pivotal Software
> > > > http://www.pivotal.io/
> > > >
> > > > 650-215-0477
> > > > @GregChase
> > > > Blog: http://geekmarketing.biz/
> > > >
> > >
> >
>

Re: Need authorization to tweet for Apache Geode

[Kirk Lund]

I'll volunteer to help too unless that's too many folks. My twitter is
@kirk_lund

On Wed, Jun 7, 2017 at 1:51 PM, Greg Chase  wrote:

> Added you Mike.
>
> On Wed, Jun 7, 2017 at 1:41 PM, Michael Stolz  wrote:
>
> > Hi Greg,
> >
> > I didn't give you my Twitter handle: @MikeStolz1
> >
> >
> > --
> > Mike Stolz
> > Principal Engineer, GemFire Product Manager
> > Mobile: +1-631-835-4771
> >
> > On Wed, Jun 7, 2017 at 1:23 PM, Gregory Chase  wrote:
> >
> > > Hi Jag,
> > > Thanks for volunteering to help communicate the goodness of
> @ApacheGeode!
> > >
> > > I'll add you to the authorized Twitter team in TweetDeck!
> > >
> > > -Greg
> > >
> > > On Wed, Jun 7, 2017 at 1:19 PM, Jagdish Mirani 
> > wrote:
> > >
> > > > Hello:
> > > > I would like to be authorized to tweet for Apache Geode - I would
> like
> > to
> > > > Tweet from the project handle on behalf of the project.
> > > >
> > > > About me.
> > > >
> > > > *Twitter handle: *@jagmirani
> > > > *Role: *I am the Product Marketing Manager for Pivotal GemFire (which
> > is
> > > > based on Apache Geode). Also, I work closely with our engineering and
> > > > Product Management teams on our contributions to the Geode project.
> > > >
> > > > Please authorize tweeting privileges for me.
> > > >
> > > > Regards
> > > > Jagdish Mirani
> > > >
> > >
> > >
> > >
> > > --
> > > Greg Chase
> > >
> > > Product team
> > > http://www.pivotal.io/big-data
> > >
> > > Pivotal Software
> > > http://www.pivotal.io/
> > >
> > > 650-215-0477
> > > @GregChase
> > > Blog: http://geekmarketing.biz/
> > >
> >
>

Review Request 59893: GEODE-3032: Fix CI failure of CommandOverHttpDUnitTest

[Jared Stewart]

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

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


Repository: geode


Description
---

GEODE-3032: Fix CI failure of CommandOverHttpDUnitTest


Diffs
-

  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/MemberCommandsDUnitTest.java
 5bbfc5b3d4ba1a37f8c1e700a36bd96b4ea40667 


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


Testing
---

Precheckin is green except for unrelated flaky DUnits.


Thanks,

Jared Stewart

Re: Review Request 59850: GEODE-3023: TcpServer thread can be blocked in processRequest

[Galen O'Sullivan]

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



Code looks good. I haven't taken a particularly thorough look through the tests.

- Galen O'Sullivan


On June 6, 2017, 11:21 p.m., Udo Kohlmeyer wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59850/
> ---
> 
> (Updated June 6, 2017, 11:21 p.m.)
> 
> 
> Review request for geode, Bruce Schuchardt, Galen O'Sullivan, and Hitesh 
> Khamesra.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Moved the socket.setSoTimeout setting to be before the SSL handshake. This is 
> to avoid the timeout to never be set in the case of a SSLException. Added a 
> test to test that the socket timeout is correctly set upon failure within the 
> SSL configuration and handshake.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/tcpserver/TcpServer.java
>  86fe53261 
>   
> geode-core/src/test/java/org/apache/geode/distributed/internal/tcpserver/TCPServerSSLJUnitTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/distributed/internal/tcpserver/TcpServerJUnitTest.java
>  7c7a2b376 
>   
> geode-core/src/test/java/org/apache/geode/internal/net/DelaySocketCreator.java
>  PRE-CREATION 
> 
> 
> Diff: https://reviews.apache.org/r/59850/diff/2/
> 
> 
> Testing
> ---
> 
> Junit test - done
> precheckin - in progress
> 
> 
> Thanks,
> 
> Udo Kohlmeyer
> 
>

Re: [DISCUSS] easy string based partitioning

[Galen M O'Sullivan]

I don't think it would be that much harder to add an option for a
user-specified delimiter than it would to hardcode ':' or '|'. I think the
utility of that would be much higher, and that it would be a much better
candidate for inclusion in geode-core. Otherwise, I think it should live in
an "examples" or "utilities" package or repo.

Galen

On Wed, Jun 7, 2017 at 12:47 PM, Jacob Barrett  wrote:

> In regard to sending the configuration state to the clients for the
> partition resolver maybe the config should be a domain object independent
> of the business object rather than the serialized form of the partition
> resolver itself. The rational for this would be that non-Java clients could
> get the config as PDX (or some other language neutral scheme) and
> initialize their native language version of the partition resolver with
> this config.
>
> -Jake
>
>
> Sent from my iPhone
>
> > On Jun 7, 2017, at 11:42 AM, Darrel Schneider 
> wrote:
> >
> > Thanks for all the feedback. Since this is such a simple resolver with a
> > fixed delimiter the following changes were made to the original proposal:
> > 1. The StringPrefixPartitionResolver will be in the
> > "org.apache.geode.cache.util" package.
> >This was done to keep it from being viewed as part of the core API. It
> > is just a simple implementation
> >of one of the core API interfaces that user can use if they find it
> > helpful.
> > 2. The fixed delimiter was changed from ":" to "|". The character still
> has
> > the visual appearance of
> >delimiting two fields with the benefit of being used less often than
> > ":". Since the delimiter can not
> >be configured that makes it more likely someone can use this resolver.
> >
> > I think the ideas about more complex resolvers are interesting and the
> > existence of this simple resolver does not prevent other resolver
> > implementations from also being added to the util package. For example
> one
> > that is regex based or spring expression based.
> >
> > One of the things discovered was that if a PartitionResolver has state
> (for
> > example a configured delimiter, or regex, or spring expression) then that
> > java clients will not be able to single hop to the server region with
> that
> > resolver. Our servers send the single hop java clients just the class
> name
> > of the PartitionResolver. The instance of the actual resolver is not
> > serialized to the client. The java client single hop code attempts to
> > create an instance of it by invoking a no-arg constructor. So any state
> > stored in the server's resolver instance will be lost. If the resolver
> > class does not have a no-arg constructor then the java client will be
> > unable to load an instance and just disable single hop. But if it had two
> > constructors, say one that has no-arg and configures a default delimiter
> > and another that take a delimiter as an arg, then in that case the single
> > hop client would lose the delimiter configured on the server and revert
> to
> > the default one from the no-arg constructor. It seems like this could
> cause
> > all kinds of bad things to happen. For example in the case of a
> > StringPrefixPartitionResolver that allows the delimiter to be configured
> > that one used on this client to route keys to the server would have the
> > wrong delimiter and complain that the key does not contain the
> delimiter. I
> > will file a geode ticket about this issue but wanted to have it on this
> > thread to help explain why this initial resolver is not configurable.
> >
> >
> >> On Tue, Jun 6, 2017 at 1:20 PM, Jacob Barrett 
> wrote:
> >>
> >> I have to agree. Something this trivial an limiting is better suited
> for a
> >> blog post or examples somewhere and not a part of the core codebase.
> >>
> >> -Jake
> >>
> >> On Mon, Jun 5, 2017 at 1:27 PM Udo Kohlmeyer 
> >> wrote:
> >>
> >>> My concern with this approach is that we provide an implementation that
> >>> might be a white elephant and only used by a 1% user base. In addition
> >>> to that, it does really restrict the user on his keys.
> >>>
> >>> Whereas something a little more configurable, like a SPEL
> >>> implementation, would provide a lot more flexibility. Which means that
> >>> one could easily change the partition resolver expression upon region
> >>> creation/configuration.
> >>>
> >>> --Udo
> >>>
> >>>
>  On 6/5/17 08:46, Jens Deppe wrote:
>  I like the idea of keeping the configuration 'conventional' and thus
> >> not
>  requiring any server configuration. As soon as you need to define a
> >> regex
>  on the server you might as well be writing PartitionResolver code.
> 
>  As an aside I also think that using regexes to parse keys would also
>  introduce a measurable performance hit.
> 
>  --Jens
> 
>  On Mon, Jun 5, 2017 at 8:21 AM, Udo Kohlmeyer 
> >>> wrote:
> 
> 

[GitHub] geode pull request #563: Add a bunch of .proto definitions to the new protoc...

[asfgit]

Github user asfgit closed the pull request at:

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


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

Re: Need authorization to tweet for Apache Geode

[Greg Chase]

Added you Mike.

On Wed, Jun 7, 2017 at 1:41 PM, Michael Stolz  wrote:

> Hi Greg,
>
> I didn't give you my Twitter handle: @MikeStolz1
>
>
> --
> Mike Stolz
> Principal Engineer, GemFire Product Manager
> Mobile: +1-631-835-4771
>
> On Wed, Jun 7, 2017 at 1:23 PM, Gregory Chase  wrote:
>
> > Hi Jag,
> > Thanks for volunteering to help communicate the goodness of @ApacheGeode!
> >
> > I'll add you to the authorized Twitter team in TweetDeck!
> >
> > -Greg
> >
> > On Wed, Jun 7, 2017 at 1:19 PM, Jagdish Mirani 
> wrote:
> >
> > > Hello:
> > > I would like to be authorized to tweet for Apache Geode - I would like
> to
> > > Tweet from the project handle on behalf of the project.
> > >
> > > About me.
> > >
> > > *Twitter handle: *@jagmirani
> > > *Role: *I am the Product Marketing Manager for Pivotal GemFire (which
> is
> > > based on Apache Geode). Also, I work closely with our engineering and
> > > Product Management teams on our contributions to the Geode project.
> > >
> > > Please authorize tweeting privileges for me.
> > >
> > > Regards
> > > Jagdish Mirani
> > >
> >
> >
> >
> > --
> > Greg Chase
> >
> > Product team
> > http://www.pivotal.io/big-data
> >
> > Pivotal Software
> > http://www.pivotal.io/
> >
> > 650-215-0477
> > @GregChase
> > Blog: http://geekmarketing.biz/
> >
>

Re: Need authorization to tweet for Apache Geode

[Michael Stolz]

Hi Greg,

I didn't give you my Twitter handle: @MikeStolz1


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

On Wed, Jun 7, 2017 at 1:23 PM, Gregory Chase  wrote:

> Hi Jag,
> Thanks for volunteering to help communicate the goodness of @ApacheGeode!
>
> I'll add you to the authorized Twitter team in TweetDeck!
>
> -Greg
>
> On Wed, Jun 7, 2017 at 1:19 PM, Jagdish Mirani  wrote:
>
> > Hello:
> > I would like to be authorized to tweet for Apache Geode - I would like to
> > Tweet from the project handle on behalf of the project.
> >
> > About me.
> >
> > *Twitter handle: *@jagmirani
> > *Role: *I am the Product Marketing Manager for Pivotal GemFire (which is
> > based on Apache Geode). Also, I work closely with our engineering and
> > Product Management teams on our contributions to the Geode project.
> >
> > Please authorize tweeting privileges for me.
> >
> > Regards
> > Jagdish Mirani
> >
>
>
>
> --
> Greg Chase
>
> Product team
> http://www.pivotal.io/big-data
>
> Pivotal Software
> http://www.pivotal.io/
>
> 650-215-0477
> @GregChase
> Blog: http://geekmarketing.biz/
>

Re: Need authorization to tweet for Apache Geode

[Gregory Chase]

Hi Jag,
Thanks for volunteering to help communicate the goodness of @ApacheGeode!

I'll add you to the authorized Twitter team in TweetDeck!

-Greg

On Wed, Jun 7, 2017 at 1:19 PM, Jagdish Mirani  wrote:

> Hello:
> I would like to be authorized to tweet for Apache Geode - I would like to
> Tweet from the project handle on behalf of the project.
>
> About me.
>
> *Twitter handle: *@jagmirani
> *Role: *I am the Product Marketing Manager for Pivotal GemFire (which is
> based on Apache Geode). Also, I work closely with our engineering and
> Product Management teams on our contributions to the Geode project.
>
> Please authorize tweeting privileges for me.
>
> Regards
> Jagdish Mirani
>



-- 
Greg Chase

Product team
http://www.pivotal.io/big-data

Pivotal Software
http://www.pivotal.io/

650-215-0477
@GregChase
Blog: http://geekmarketing.biz/

[GitHub] geode-native pull request #101: GEODE-2740: Modified CMAKELists.txt to suppo...

[asfgit]

Github user asfgit closed the pull request at:

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


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

Need authorization to tweet for Apache Geode

[Jagdish Mirani]

Hello:
I would like to be authorized to tweet for Apache Geode - I would like to
Tweet from the project handle on behalf of the project.

About me.

*Twitter handle: *@jagmirani
*Role: *I am the Product Marketing Manager for Pivotal GemFire (which is
based on Apache Geode). Also, I work closely with our engineering and
Product Management teams on our contributions to the Geode project.

Please authorize tweeting privileges for me.

Regards
Jagdish Mirani

[GitHub] geode-native pull request #101: GEODE-2740: Modified CMAKELists.txt to suppo...

[mhansonp]

GitHub user mhansonp opened a pull request:

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

GEODE-2740: Modified CMAKELists.txt to support 64bit linking



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

$ git pull https://github.com/mhansonp/geode-native feature/GEODE-2740

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

https://github.com/apache/geode-native/pull/101.patch

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

This closes #101


commit 24783d4df6630536aacc51074efd2d1d033f9b0e
Author: Mark Hanson 
Date:   2017-06-07T19:47:17Z

GEODE-2740: Modified CMAKELists.txt to support 64bit linking




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

Re: [DISCUSS] easy string based partitioning

[Jacob Barrett]

In regard to sending the configuration state to the clients for the partition 
resolver maybe the config should be a domain object independent of the business 
object rather than the serialized form of the partition resolver itself. The 
rational for this would be that non-Java clients could get the config as PDX 
(or some other language neutral scheme) and initialize their native language 
version of the partition resolver with this config.

-Jake


Sent from my iPhone

> On Jun 7, 2017, at 11:42 AM, Darrel Schneider  wrote:
> 
> Thanks for all the feedback. Since this is such a simple resolver with a
> fixed delimiter the following changes were made to the original proposal:
> 1. The StringPrefixPartitionResolver will be in the
> "org.apache.geode.cache.util" package.
>This was done to keep it from being viewed as part of the core API. It
> is just a simple implementation
>of one of the core API interfaces that user can use if they find it
> helpful.
> 2. The fixed delimiter was changed from ":" to "|". The character still has
> the visual appearance of
>delimiting two fields with the benefit of being used less often than
> ":". Since the delimiter can not
>be configured that makes it more likely someone can use this resolver.
> 
> I think the ideas about more complex resolvers are interesting and the
> existence of this simple resolver does not prevent other resolver
> implementations from also being added to the util package. For example one
> that is regex based or spring expression based.
> 
> One of the things discovered was that if a PartitionResolver has state (for
> example a configured delimiter, or regex, or spring expression) then that
> java clients will not be able to single hop to the server region with that
> resolver. Our servers send the single hop java clients just the class name
> of the PartitionResolver. The instance of the actual resolver is not
> serialized to the client. The java client single hop code attempts to
> create an instance of it by invoking a no-arg constructor. So any state
> stored in the server's resolver instance will be lost. If the resolver
> class does not have a no-arg constructor then the java client will be
> unable to load an instance and just disable single hop. But if it had two
> constructors, say one that has no-arg and configures a default delimiter
> and another that take a delimiter as an arg, then in that case the single
> hop client would lose the delimiter configured on the server and revert to
> the default one from the no-arg constructor. It seems like this could cause
> all kinds of bad things to happen. For example in the case of a
> StringPrefixPartitionResolver that allows the delimiter to be configured
> that one used on this client to route keys to the server would have the
> wrong delimiter and complain that the key does not contain the delimiter. I
> will file a geode ticket about this issue but wanted to have it on this
> thread to help explain why this initial resolver is not configurable.
> 
> 
>> On Tue, Jun 6, 2017 at 1:20 PM, Jacob Barrett  wrote:
>> 
>> I have to agree. Something this trivial an limiting is better suited for a
>> blog post or examples somewhere and not a part of the core codebase.
>> 
>> -Jake
>> 
>> On Mon, Jun 5, 2017 at 1:27 PM Udo Kohlmeyer 
>> wrote:
>> 
>>> My concern with this approach is that we provide an implementation that
>>> might be a white elephant and only used by a 1% user base. In addition
>>> to that, it does really restrict the user on his keys.
>>> 
>>> Whereas something a little more configurable, like a SPEL
>>> implementation, would provide a lot more flexibility. Which means that
>>> one could easily change the partition resolver expression upon region
>>> creation/configuration.
>>> 
>>> --Udo
>>> 
>>> 
 On 6/5/17 08:46, Jens Deppe wrote:
 I like the idea of keeping the configuration 'conventional' and thus
>> not
 requiring any server configuration. As soon as you need to define a
>> regex
 on the server you might as well be writing PartitionResolver code.
 
 As an aside I also think that using regexes to parse keys would also
 introduce a measurable performance hit.
 
 --Jens
 
 On Mon, Jun 5, 2017 at 8:21 AM, Udo Kohlmeyer 
>>> wrote:
 
> Whilst I like the idea to make something (and yes,
> DelimitedStringPartitionResolver is the simplest), I feel that we
>> might
> be able to do one better.
> 
> */Could/* one possibly have an /*SPEL*/ <
>> https://docs.spring.io/spring
> 
>>> -framework/docs/current/spring-framework-reference/
>> html/expressions.html>-based
> PartitionResolver for this? At least this way, we don't have to rely
>> on
> delimiters or a strong knowledge of REGEX.
> 
> IMO, this would provide the greatest bang for buck implementation.
> 
> --Udo
> 
> 
> 
> 

Re: Review Request 59852: GEODE-2632: make SecurityService immutable to improve client/server performance

[Patrick Rhomberg]

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




geode-assembly/src/test/java/org/apache/geode/rest/internal/web/controllers/RestAPIsAndInterOpsDUnitTest.java
Lines 474-492 (original), 452-470 (patched)


Remove dead code?



geode-assembly/src/test/java/org/apache/geode/rest/internal/web/controllers/RestAPIsAndInterOpsDUnitTest.java
Line 557 (original), 516 (patched)


This and the below assignments appear to be unused and seem only to 
duplicate the comment immediately above each assignment.

Remove this unused variable.



geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/Services.java
Lines 189-244 (original), 198-253 (patched)


I don't think the `this`s are necessary here, but if you're making changes 
anyway, these nested `try / finally` make me cringe and should be flattened.



geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/command/UpdateClientNotification.java
Lines 46-72 (original), 47-73 (patched)


May as well rip out the dead code / pointless `try / finally` while we're 
here.



geode-core/src/test/java/org/apache/geode/internal/security/IntegratedSecurityServiceTest.java
Lines 199-202 (original), 183-207 (patched)


Remove or restore dead test.


- Patrick Rhomberg


On June 6, 2017, 11:57 p.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59852/
> ---
> 
> (Updated June 6, 2017, 11:57 p.m.)
> 
> 
> Review request for geode, Emily Yeh, Jinmei Liao, Jared Stewart, Ken Howe, 
> and Patrick Rhomberg.
> 
> 
> Bugs: GEODE-2632
> https://issues.apache.org/jira/browse/GEODE-2632
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> See https://github.com/apache/geode/pull/450 for JMH benchmark 
> ClientCachePutBench. I increased the runtime of ClientCachePutBench from 30 
> minutes to 2 hours to get more accurate measurement. I'll update the "Testing 
> Done" section with performance numbers when that finishes running. My 
> measurements include current develop branch and feature/GEODE-2632-21.
> 
> The changes in this change-set involve making the SecurityService 
> implementation(s) immutable to improve performance of client/server as 
> measured by the JMH benchmark ClientCachePutBench.
> 
> Sorry it's such a long diff again -- I tried to shrink this one down. I could 
> leave out the bulk of client Command classes and tests -- let me know if this 
> review is too big and unwieldy.
> 
> 
> Diffs
> -
> 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/controllers/RestAPIsAndInterOpsDUnitTest.java
>  45e7a6139b30c800e6096d61d1f23db36c017f99 
>   geode-core/src/main/java/org/apache/geode/cache/CacheFactory.java 
> 38fdac692315153cda9b4956d0fbbf66fa8f6399 
>   
> geode-core/src/main/java/org/apache/geode/cache/client/ClientCacheFactory.java
>  0d678ca4d08d100ac99266c5d550d9cee7a13ea3 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionManager.java
>  029e6377f56d80dd81e4cec430f106ac743e5178 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/InternalDistributedSystem.java
>  7caad3f33ee55f72dc61c4adc2ab3de5429a1607 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/SecurityConfig.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/MemberFactory.java
>  f324e3355e77cc64a8e1cce878b3c03ad4180106 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/MemberServices.java
>  60249663aad0a59f1d292d0c5336cac33e503204 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/GMSMemberFactory.java
>  bc94ab5afd3e6c9bb5deb9e0beed5f1f84d924fa 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/Services.java
>  1404b3b6f2a44aeaf3c76b99dad8a428b1b5d1f7 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/auth/GMSAuthenticator.java
>  ab0ca6b4533a52528818ab3b8059576c0bd1518f 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/CacheServerImpl.java 
> 670c697c7f6c3d22a3c79d10be4e9c9929cd612b 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java
>  5e352241ac114b891adb178e1820e8c74017fa64 
>   geode-core/src/main/java/org/apache/geode/internal/cache/InternalCache.java 
> 

Re: [DISCUSS] easy string based partitioning

[Darrel Schneider]

Thanks for all the feedback. Since this is such a simple resolver with a
fixed delimiter the following changes were made to the original proposal:
1. The StringPrefixPartitionResolver will be in the
"org.apache.geode.cache.util" package.
This was done to keep it from being viewed as part of the core API. It
is just a simple implementation
of one of the core API interfaces that user can use if they find it
helpful.
2. The fixed delimiter was changed from ":" to "|". The character still has
the visual appearance of
delimiting two fields with the benefit of being used less often than
":". Since the delimiter can not
be configured that makes it more likely someone can use this resolver.

I think the ideas about more complex resolvers are interesting and the
existence of this simple resolver does not prevent other resolver
implementations from also being added to the util package. For example one
that is regex based or spring expression based.

One of the things discovered was that if a PartitionResolver has state (for
example a configured delimiter, or regex, or spring expression) then that
java clients will not be able to single hop to the server region with that
resolver. Our servers send the single hop java clients just the class name
of the PartitionResolver. The instance of the actual resolver is not
serialized to the client. The java client single hop code attempts to
create an instance of it by invoking a no-arg constructor. So any state
stored in the server's resolver instance will be lost. If the resolver
class does not have a no-arg constructor then the java client will be
unable to load an instance and just disable single hop. But if it had two
constructors, say one that has no-arg and configures a default delimiter
and another that take a delimiter as an arg, then in that case the single
hop client would lose the delimiter configured on the server and revert to
the default one from the no-arg constructor. It seems like this could cause
all kinds of bad things to happen. For example in the case of a
StringPrefixPartitionResolver that allows the delimiter to be configured
that one used on this client to route keys to the server would have the
wrong delimiter and complain that the key does not contain the delimiter. I
will file a geode ticket about this issue but wanted to have it on this
thread to help explain why this initial resolver is not configurable.


On Tue, Jun 6, 2017 at 1:20 PM, Jacob Barrett  wrote:

> I have to agree. Something this trivial an limiting is better suited for a
> blog post or examples somewhere and not a part of the core codebase.
>
> -Jake
>
> On Mon, Jun 5, 2017 at 1:27 PM Udo Kohlmeyer 
> wrote:
>
> > My concern with this approach is that we provide an implementation that
> > might be a white elephant and only used by a 1% user base. In addition
> > to that, it does really restrict the user on his keys.
> >
> > Whereas something a little more configurable, like a SPEL
> > implementation, would provide a lot more flexibility. Which means that
> > one could easily change the partition resolver expression upon region
> > creation/configuration.
> >
> > --Udo
> >
> >
> > On 6/5/17 08:46, Jens Deppe wrote:
> > > I like the idea of keeping the configuration 'conventional' and thus
> not
> > > requiring any server configuration. As soon as you need to define a
> regex
> > > on the server you might as well be writing PartitionResolver code.
> > >
> > > As an aside I also think that using regexes to parse keys would also
> > > introduce a measurable performance hit.
> > >
> > > --Jens
> > >
> > > On Mon, Jun 5, 2017 at 8:21 AM, Udo Kohlmeyer 
> > wrote:
> > >
> > >> Whilst I like the idea to make something (and yes,
> > >> DelimitedStringPartitionResolver is the simplest), I feel that we
> might
> > >> be able to do one better.
> > >>
> > >> */Could/* one possibly have an /*SPEL*/ <
> https://docs.spring.io/spring
> > >>
> > -framework/docs/current/spring-framework-reference/
> html/expressions.html>-based
> > >> PartitionResolver for this? At least this way, we don't have to rely
> on
> > >> delimiters or a strong knowledge of REGEX.
> > >>
> > >> IMO, this would provide the greatest bang for buck implementation.
> > >>
> > >> --Udo
> > >>
> > >>
> > >>
> > >>
> > >> On 6/2/17 19:15, Jacob Barrett wrote:
> > >>
> > >>> If you implement as regular expression the user doesn't have to
> > reformat
> > >>> their key to a specific format (akin to making them implement a
> > class). I
> > >>> would concat the matching groups for generate the routing key.
> > >>>
> > >>> Consider RegEx: .*\bcorrelation=(\d+).*\bmaybe-something-else=(\w)
> > >>> With Keys:
> > >>> A: my,key;with:any-chars;unique=12345;correlation=678/and,maybe
> > >>> -something-else=a
> > >>> B: my,key;unique=876324;correlation=678;and,maybe-
> something-else=a,foo
> > >>> C:
> > 

Re: Review Request 59811: GEODE-2420: add file-size-limit param to the ExportLogsController

[Ken Howe]

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

(Updated June 7, 2017, 6:35 p.m.)


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


Changes
---

Revised the semantics of the export logs size warning:

Previous: 
- file-size-limit option was for the size of the zip file that is exported to 
the locator. To make this check, all the work of exporting the logs was 
completed even thought the exported zipfile is eventually deleted if it was too 
big.
- file-size-limit > 0 also enabled checking for potential disk overflow on each 
member as well as on the locator. This check use the estimated disk space 
required to filter and consolidate the fully expanded individual log files.
- file-size-limit = 0 disables all checking of exported logs size and potential 
disk overflows

Revised:
- file-size-limit option will check that the estimated size of all of the fully 
expanded log files as exported to the locator is less than the specified limit 
(or the default of 100m if not specified). The work (and temporary disk space) 
of preparing and exporting the logs from all the members is not performed if 
the check fails (expnaded size on the locator is too big).
- file-size-limit = 0 - no changes


Refactored SizeExportLogsFunction.
- Simplified the Result returned by the function. The result will always be a 
single Long (the estimated expnaded size of the filtered logs for the member) 
or an error result. 

Fixed the issue with file-size-limit not being recognized when connected to the 
locator via http


Repository: geode


Description
---

GEODE-2420: add file-size-limit param to the ExportLogsController


Diffs (updated)
-

  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportLogsCommand.java
 0ff780cbf66937d8ececfb3a2d0789ee485b9b62 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/SizeExportLogsFunction.java
 57355c0efae4c6da9470267f95e27e59aa4d8b2c 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/i18n/CliStrings.java
 9f68d3a5eaadbe8f1bd95ec8df85ed1f65aa67ce 
  
geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/ExportLogController.java
 a369c6e1ffb330715fbde2cd69d023ed36f133ad 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsCommandTest.java
 16549e70bbebf4390bb73a481274e92ca6cad035 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsDUnitTest.java
 8609b3aaf0a0eb1ba903bd39c64103f9510a6a78 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsFileSizeLimitTest.java
 09ee08dd6af29b9a418ef7499defc4980da787ed 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsStatsDUnitTest.java
 44a036298e0991c880fc552596d296e104b97ca1 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsTestSuite.java
 4e1dac013d239437829bc52dc70689c4ba15dc58 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/SizeExportLogsFunctionTest.java
 cc5e7d5256741ad0a48ff87c7f989a18b90f7f03 


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

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


Testing (updated)
---

6/7/17: re-started precheckin

Precheckin started


Thanks,

Ken Howe

Re: Review Request 59852: GEODE-2632: make SecurityService immutable to improve client/server performance

[Patrick Rhomberg]

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




geode-assembly/src/test/java/org/apache/geode/rest/internal/web/controllers/RestAPIsAndInterOpsDUnitTest.java
Lines 358 (patched)


Complete, remove, or be more explicit in your TODO.



geode-assembly/src/test/java/org/apache/geode/rest/internal/web/controllers/RestAPIsAndInterOpsDUnitTest.java
Lines 394 (patched)


Complete, remove, or be more explicit in your TODO.



geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java
Line 3793 (original), 3791 (patched)


Complete, remove, or be more explicit in your TODO.



geode-core/src/main/java/org/apache/geode/internal/security/SecurityService.java
Lines 35-39 (patched)


Delete these?



geode-core/src/main/java/org/apache/geode/internal/security/SecurityService.java
Lines 49 (patched)


Complete, remove, or be more explicit in your TODO.



geode-core/src/main/java/org/apache/geode/internal/security/SecurityService.java
Lines 132 (patched)


This is only used once, below.  I'd drop the unused parameter from the 
signature.


- Patrick Rhomberg


On June 6, 2017, 11:57 p.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59852/
> ---
> 
> (Updated June 6, 2017, 11:57 p.m.)
> 
> 
> Review request for geode, Emily Yeh, Jinmei Liao, Jared Stewart, Ken Howe, 
> and Patrick Rhomberg.
> 
> 
> Bugs: GEODE-2632
> https://issues.apache.org/jira/browse/GEODE-2632
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> See https://github.com/apache/geode/pull/450 for JMH benchmark 
> ClientCachePutBench. I increased the runtime of ClientCachePutBench from 30 
> minutes to 2 hours to get more accurate measurement. I'll update the "Testing 
> Done" section with performance numbers when that finishes running. My 
> measurements include current develop branch and feature/GEODE-2632-21.
> 
> The changes in this change-set involve making the SecurityService 
> implementation(s) immutable to improve performance of client/server as 
> measured by the JMH benchmark ClientCachePutBench.
> 
> Sorry it's such a long diff again -- I tried to shrink this one down. I could 
> leave out the bulk of client Command classes and tests -- let me know if this 
> review is too big and unwieldy.
> 
> 
> Diffs
> -
> 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/controllers/RestAPIsAndInterOpsDUnitTest.java
>  45e7a6139b30c800e6096d61d1f23db36c017f99 
>   geode-core/src/main/java/org/apache/geode/cache/CacheFactory.java 
> 38fdac692315153cda9b4956d0fbbf66fa8f6399 
>   
> geode-core/src/main/java/org/apache/geode/cache/client/ClientCacheFactory.java
>  0d678ca4d08d100ac99266c5d550d9cee7a13ea3 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionManager.java
>  029e6377f56d80dd81e4cec430f106ac743e5178 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/InternalDistributedSystem.java
>  7caad3f33ee55f72dc61c4adc2ab3de5429a1607 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/SecurityConfig.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/MemberFactory.java
>  f324e3355e77cc64a8e1cce878b3c03ad4180106 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/MemberServices.java
>  60249663aad0a59f1d292d0c5336cac33e503204 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/GMSMemberFactory.java
>  bc94ab5afd3e6c9bb5deb9e0beed5f1f84d924fa 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/Services.java
>  1404b3b6f2a44aeaf3c76b99dad8a428b1b5d1f7 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/auth/GMSAuthenticator.java
>  ab0ca6b4533a52528818ab3b8059576c0bd1518f 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/CacheServerImpl.java 
> 670c697c7f6c3d22a3c79d10be4e9c9929cd612b 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java
>  5e352241ac114b891adb178e1820e8c74017fa64 
>   geode-core/src/main/java/org/apache/geode/internal/cache/InternalCache.java 
> d9a34e1cfa85cc08ff4f0af81b6adc2bdbd7e869 
>   geode-core/src/main/java/org/apache/geode/internal/cache/tier/Command.java 
> 

Re: Review Request 59852: GEODE-2632: make SecurityService immutable to improve client/server performance

[Patrick Rhomberg]

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



Things that are identifiable by inspections on Changed Files:

Explode wildcard imports in:
- ClientReady.java
- Default.java
- Invalid.java
- MakePrimary.java
- PeriodicAck.java
- Ping.java
- UpdateClientNotification.java

Remove unused imports.  (Some of these may be a fault of my closed side not 
linking correctly):
- BlockingHARegionJUnitTest.java
- CacheServerImpl.java
- ContainsKey66Test.java
- CQPDXPostProcessorDUnitTest.java
- CreateRegionTest.java
- Destroy65Test.java
- DestroyRegionTest.java
- DestroyTest.java
- ExecuteFunction65Test.java
- ExecuteFunction66Test.java
- ExecuteFunctionTest.java
- GemFireCacheImpl.java
- Get70Test.java
- GetAll651Test.java
- GetAll70Test.java
- GetAllTest.java
- GetAllWithCallbackTest.java
- GetClientPartitionAttributesCommand66Test.java
- GetClientPartitionAttributesCommandTest.java
- IndexCommands.java
- InvalidateTest.java
- KeySetTest.java
- LegacySecurityService.java
- LoginHandlerInterceptor.java
- MembershipJUnitTest.java
- PDXGfshPostProcessorOnRemoteServerTest.java
- PDXPostProcessorDUnitTest.java
- Put61Test.java
- Put65Test.java
- PutTest.java
- RegisterInterest61Test.java
- RegisterInterestList61Test.java
- RegisterInterestList66Test.java
- RegisterInterestListTest.java
- RegisterInterestTest.java
- RemoveAllTest.java
- RequestTest.java
- RestAPIsAndInterOpsDUnitTest.java
- ServerConnectionTest.java
- ServerRule.java
- UnregisterInterestTest.java

Remove empty dangling docstring at header in:
- ClearRegion.java
- ClientReady.java
- CloseConnection.java
- CommitCommand.java
- Default.java
- Invalid.java
- KeySet.java
- MakePrimary.java
- PeriodicAck.java
- Ping.java
- RegisterInstantiators.java
- RegisterInterest.java
- UnregisterInterestList.java
- UpdateClientNotification.java

- Patrick Rhomberg


On June 6, 2017, 11:57 p.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59852/
> ---
> 
> (Updated June 6, 2017, 11:57 p.m.)
> 
> 
> Review request for geode, Emily Yeh, Jinmei Liao, Jared Stewart, Ken Howe, 
> and Patrick Rhomberg.
> 
> 
> Bugs: GEODE-2632
> https://issues.apache.org/jira/browse/GEODE-2632
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> See https://github.com/apache/geode/pull/450 for JMH benchmark 
> ClientCachePutBench. I increased the runtime of ClientCachePutBench from 30 
> minutes to 2 hours to get more accurate measurement. I'll update the "Testing 
> Done" section with performance numbers when that finishes running. My 
> measurements include current develop branch and feature/GEODE-2632-21.
> 
> The changes in this change-set involve making the SecurityService 
> implementation(s) immutable to improve performance of client/server as 
> measured by the JMH benchmark ClientCachePutBench.
> 
> Sorry it's such a long diff again -- I tried to shrink this one down. I could 
> leave out the bulk of client Command classes and tests -- let me know if this 
> review is too big and unwieldy.
> 
> 
> Diffs
> -
> 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/controllers/RestAPIsAndInterOpsDUnitTest.java
>  45e7a6139b30c800e6096d61d1f23db36c017f99 
>   geode-core/src/main/java/org/apache/geode/cache/CacheFactory.java 
> 38fdac692315153cda9b4956d0fbbf66fa8f6399 
>   
> geode-core/src/main/java/org/apache/geode/cache/client/ClientCacheFactory.java
>  0d678ca4d08d100ac99266c5d550d9cee7a13ea3 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionManager.java
>  029e6377f56d80dd81e4cec430f106ac743e5178 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/InternalDistributedSystem.java
>  7caad3f33ee55f72dc61c4adc2ab3de5429a1607 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/SecurityConfig.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/MemberFactory.java
>  f324e3355e77cc64a8e1cce878b3c03ad4180106 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/MemberServices.java
>  60249663aad0a59f1d292d0c5336cac33e503204 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/GMSMemberFactory.java
>  bc94ab5afd3e6c9bb5deb9e0beed5f1f84d924fa 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/Services.java
>  1404b3b6f2a44aeaf3c76b99dad8a428b1b5d1f7 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/auth/GMSAuthenticator.java
>  ab0ca6b4533a52528818ab3b8059576c0bd1518f 
>   
> 

Re: Review Request 59866: GEODE-2555: Region Management docs page refers to the wrong field (id= should be refid=)

[Galen O'Sullivan]

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


Ship it!




Ship It!

- Galen O'Sullivan


On June 6, 2017, 10:50 p.m., Dave Barnes wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59866/
> ---
> 
> (Updated June 6, 2017, 10:50 p.m.)
> 
> 
> Review request for geode and Galen O'Sullivan.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2555: Region Management docs page refers to the wrong field (id= should 
> be refid=)
> 
> 
> Diffs
> -
> 
>   geode-docs/basic_config/data_regions/managing_data_regions.html.md.erb 
> c93f13a845544bcc3c1d3de4747aa7c18054ab6d 
> 
> 
> Diff: https://reviews.apache.org/r/59866/diff/1/
> 
> 
> Testing
> ---
> 
> Found and corrected 3 occurrences.
> 
> 
> Thanks,
> 
> Dave Barnes
> 
>

Re: Do you want to Tweet for @ApacheGeode?

[Greg Chase]

Thanks both Michael and Swapnil.  If you could please send me a private
response with your Twitter handle, I will authorize you to Tweet from
@ApacheGeode.

If anyone else would also like to help, please respond publicly to the dev
group first about your interest.

Thanks!

-Greg

On Wed, Jun 7, 2017 at 10:14 AM, Swapnil Bawaskar 
wrote:

> So can I.
>
> On Tue, Jun 6, 2017 at 4:40 PM Michael Stolz  wrote:
>
> > Hey Greg,
> >
> > I could tweet now and then.
> >
> > --
> > Mike Stolz
> > Principal Engineer, GemFire Product Manager
> > Mobile: +1-631-835-4771 <(631)%20835-4771>
> >
> > On Tue, Jun 6, 2017 at 12:28 PM, Greg Chase 
> wrote:
> >
> > > Greetings Apache Geode community,
> > > Tweeting for the Apache Geode project in the past has been a community
> > > effort.
> > >
> > > However, our most prolific tweeters are currently not spending much
> time
> > > with the project.
> > >
> > > As a result @ApacheGeode has fallen silent.
> > >
> > > Per ASF recommendations, we manage access to the @ApacheGeode Twitter
> > > handle through Tweet Deck. Any contributor is welcome to Tweet on
> behalf
> > of
> > > the project.  You simply need to ask for access, such as replying to
> this
> > > thread.
> > >
> > > Presuming no concerns raised by the PMC, access is granted to your
> > personal
> > > Twitter credentials to access @ApacheGeode using Tweet Deck.
> > >
> > > Administrative rights to @ApacheGeode are maintained by several PMC
> > > members.
> > >
> > > The guideline for Tweeting for @ApacheGeode is to promote the project,
> > > announce any important releases, events or topics, and to help answer
> > > questions or direct askers to u...@geode.apache.org.
> > >
> > > You are also welcome to engage in technical topics of interest to
> Apache
> > > Geode users, such as event driven architectures, caching patterns,
> > > in-memory computing, etc.
> > >
> > > We recommend not engaging in bashing other projects or products, or
> > > engaging in off-topic discussions.
> > >
> > > If you are interested in helping Tweet for @ApacheGeode, I invite you
> to
> > > volunteer by replying to this thread.
> > >
> > > Regards,
> > >
> > > -Greg
> > >
> >
>

Re: Do you want to Tweet for @ApacheGeode?

[Swapnil Bawaskar]

So can I.

On Tue, Jun 6, 2017 at 4:40 PM Michael Stolz  wrote:

> Hey Greg,
>
> I could tweet now and then.
>
> --
> Mike Stolz
> Principal Engineer, GemFire Product Manager
> Mobile: +1-631-835-4771 <(631)%20835-4771>
>
> On Tue, Jun 6, 2017 at 12:28 PM, Greg Chase  wrote:
>
> > Greetings Apache Geode community,
> > Tweeting for the Apache Geode project in the past has been a community
> > effort.
> >
> > However, our most prolific tweeters are currently not spending much time
> > with the project.
> >
> > As a result @ApacheGeode has fallen silent.
> >
> > Per ASF recommendations, we manage access to the @ApacheGeode Twitter
> > handle through Tweet Deck. Any contributor is welcome to Tweet on behalf
> of
> > the project.  You simply need to ask for access, such as replying to this
> > thread.
> >
> > Presuming no concerns raised by the PMC, access is granted to your
> personal
> > Twitter credentials to access @ApacheGeode using Tweet Deck.
> >
> > Administrative rights to @ApacheGeode are maintained by several PMC
> > members.
> >
> > The guideline for Tweeting for @ApacheGeode is to promote the project,
> > announce any important releases, events or topics, and to help answer
> > questions or direct askers to u...@geode.apache.org.
> >
> > You are also welcome to engage in technical topics of interest to Apache
> > Geode users, such as event driven architectures, caching patterns,
> > in-memory computing, etc.
> >
> > We recommend not engaging in bashing other projects or products, or
> > engaging in off-topic discussions.
> >
> > If you are interested in helping Tweet for @ApacheGeode, I invite you to
> > volunteer by replying to this thread.
> >
> > Regards,
> >
> > -Greg
> >
>

Build failed in Jenkins: Geode-release #56

[Apache Jenkins Server]

See 


Changes:

[jiliao] GEODE-2981: Fix the line feed code of the test expected value

[jiliao] GEODE-3033: Fixing NPE when jarFileNames is null in

[dbarnes] GEODE-3044: User Manual: Update Swagger example and screen shots This

--
[...truncated 98.42 KB...]
:geode-benchmarks:check
:geode-benchmarks:build
:geode-benchmarks:distributedTest UP-TO-DATE
:geode-benchmarks:integrationTest UP-TO-DATE
:geode-common:assemble
:geode-common:compileTestJava
:geode-common:processTestResources UP-TO-DATE
:geode-common:testClasses
:geode-common:checkMissedTests
:geode-common:spotlessJavaCheck
:geode-common:spotlessCheck
:geode-common:test
:geode-common:check
:geode-common:build
:geode-common:distributedTest
:geode-common:integrationTest
:geode-core:assemble
:geode-core:checkMissedTests
:geode-core:spotlessJavaCheck
:geode-core:spotlessCheck
:geode-core:test
:geode-core:check
:geode-core:build
:geode-core:distributedTest
:geode-core:integrationTest

org.apache.geode.redis.RedisServerTest > 
initializeRedisCreatesRegionsUsingSystemProperty FAILED
java.lang.RuntimeException: Could not start Server
at 
org.apache.geode.redis.GeodeRedisServer.start(GeodeRedisServer.java:387)
at 
org.apache.geode.redis.RedisServerTest.initializeRedisCreatesRegionsUsingSystemProperty(RedisServerTest.java:78)

Caused by:
java.net.BindException: Address already in use

java.lang.NullPointerException
at 
org.apache.geode.redis.GeodeRedisServer.shutdown(GeodeRedisServer.java:629)
at 
org.apache.geode.redis.RedisServerTest.teardown(RedisServerTest.java:46)

org.apache.geode.redis.RedisServerTest > initializeRedisCreatesThreeRegions 
FAILED
java.lang.AssertionError
at 
org.apache.geode.redis.RedisServerTest.initializeRedisCreatesThreeRegions(RedisServerTest.java:54)

org.apache.geode.redis.RedisServerTest > 
initializeRedisCreatesPartitionedRegionByDefault FAILED
java.lang.AssertionError
at 
org.apache.geode.redis.RedisServerTest.initializeRedisCreatesPartitionedRegionByDefault(RedisServerTest.java:64)

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

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

:geode-lucene:processTestResources
:geode-lucene:testClasses
:geode-lucene:checkMissedTests
:geode-lucene:spotlessJavaCheck
:geode-lucene:spotlessCheck
:geode-lucene:test
:geode-lucene:check
:geode-lucene:build
:geode-lucene:distributedTest
:geode-lucene:integrationTest
:geode-old-client-support:assemble
:geode-old-client-support:compileTestJavaNote: 

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

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

Build failed in Jenkins: Geode-nightly #859

[Apache Jenkins Server]

See 


Changes:

[jiliao] GEODE-3033: Fixing NPE when jarFileNames is null in

[jstewart] GEODE-2908: Adding the new tag as per swagger notification.

[dbarnes] GEODE-3044: User Manual: Update Swagger example and screen shots This

[bschuchardt] GEODE-3024 race condition between server locator preparing 
membership

[bschuchardt] GEODE-3034 exception on auto-reconnect attempt with multicast 
enabled

--
[...truncated 98.61 KB...]
Note: Recompile with -Xlint:unchecked for details.

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

:geode-lucene:processTestResources
:geode-lucene:testClasses
:geode-lucene:checkMissedTests
:geode-lucene:spotlessJavaCheck
:geode-lucene:spotlessCheck
:geode-lucene:test
:geode-lucene:check
:geode-lucene:build
:geode-lucene:distributedTest
:geode-lucene:integrationTest
:geode-old-client-support:assemble
:geode-old-client-support:compileTestJavaNote: 

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

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

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

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

:geode-pulse:processTestResources
:geode-pulse:testClasses
:geode-pulse:checkMissedTests
:geode-pulse:spotlessJavaCheck
:geode-pulse:spotlessCheck
:geode-pulse:test
:geode-pulse:check
:geode-pulse:build
:geode-pulse:distributedTest
:geode-pulse:integrationTest
:geode-rebalancer:assemble
:geode-rebalancer:compileTestJava
:geode-rebalancer:processTestResources UP-TO-DATE
:geode-rebalancer:testClasses
:geode-rebalancer:checkMissedTests
:geode-rebalancer:spotlessJavaCheck
:geode-rebalancer:spotlessCheck
:geode-rebalancer:test
:geode-rebalancer:check
:geode-rebalancer:build
:geode-rebalancer:distributedTest
:geode-rebalancer:integrationTest
:geode-wan:assemble
:geode-wan:compileTestJavaNote: Some input files use or override a deprecated 
API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

:geode-wan:processTestResources
:geode-wan:testClasses

Need information about FunctionStatistics

[Dinesh Akhand]

Hi Team,

Currently I can see Function stats are getting generated .
functionExecutionsCompleted operations/sec: samples=1955 min=0 max=0 average=0 
stddev=0 last=0
  functionExecutionsCompletedProcessingTime nanoseconds/sec: samples=1955 min=0 
max=0 average=0 stddev=0 last=0
  functionExecutionsRunning operations: samples=1956 min=0 max=0 average=0 
stddev=0 last=0
  resultsSentToResultCollector operations/sec: samples=1955 min=0 max=2.6 
average=0 stddev=0.1 last=0
  resultsReceived operations/sec: samples=1955 min=0 max=2.6 average=0 
stddev=0.1 last=0
  functionExecutionCalls operations/sec: samples=1955 min=0 max=0 average=0 
stddev=0 last=0

but I am not able to see them on JMX .

I found last end point in  MemberMBeanBridge for JMX.   Is there any 
information and document can you provide.
I want to publish FunctionStatistics on JMX , any suggestion will be welcome.


Thanks,
Dinesh Akhand
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