Re: Geode Clubhouse meeting on the integration of Lucene text search indexes in Geode

[Jagdish Mirani]

Hello Geode Enthusiasts:

Pivotal is hosting a Geode Clubhouse meeting on Sept 5th to present and
demo the integration of Lucene indexes in Geode 1.2.0.

Date: Tuesday, Sept 5th
Time: 10AM - 10:30AM PST (short meeting, the Lucene text search feature is
our only agenda item).
Meeting logistics: please see zoom meetings details below:
Join from PC, Mac, Linux, iOS or Android:
https://pivotal.zoom.us/j/341598449

Or iPhone one-tap (US Toll): +16468769923,,341598449# or
+14086380968,,341598449# Or Telephone: Dial: +1 646 876 9923 (US Toll) or
+1 408 638 0968 (US Toll) +62 21 2188 9017 (Indonesia Toll) +63 92 3099
0478 (Philippines Toll) +66 2018 2486 (Thailand Toll) +66 60 003 5790
(Thailand Toll) +84 28 4458 2373 (Vietnam Toll) +886 277 417 473 (Taiwan
Toll) +1 877 369 0926 (US Toll Free) +1 877 853 5247 (US Toll Free) Meeting
ID: 341 598 449 International numbers available:
https://pivotal.zoom.us/zoomconference?m=FOcMbPXObcTbzL7lnsIko0GM_QvcVUy3

Or an H.323/SIP room system: H.323: 162.255.37.11 (US West) 162.255.36.11
(US East) 221.122.88.195 (China) 115.114.131.7 (India) 213.19.144.110
(EMEA) 202.177.207.158 (Australia) 209.9.211.110 (Hong Kong) 64.211.144.160
(Brazil) Meeting ID: 341 598 449 SIP: 341598...@zoomcrc.com

Hope you can attend. If not, as with other clubhouse meetings, this meeting
will be recorded, and I'll send out the link to the recording.

Regards
Jagdish Mirani

On Fri, Aug 18, 2017 at 11:38 AM, Jagdish Mirani  wrote:

> Hello Geode Contributors:
> For those who may not know me, I'm in Product Marketing at Pivotal, and
> among other things, I work with our PM and Engineering teams on Geode.
>
> Congratulations for the Geode 1.2.0 release which went out about a month
> ago. The integration of Lucene indexes to enable full text search was a big
> step forward as it extends the product in to cover a large set of text
> search-based use cases. Here is a link to the release notes:
>
> https://cwiki.apache.org/confluence/display/GEODE/
> Release+Notes#ReleaseNotes-1.2.0
>
> I would like to host a Geode Clubhouse meeting so that Diane Hardman, our
> PM for this, can go over the specifics of this feature and how it works,
> including a demo. I am targeting *Tuesday, Sept 5th, 10AM PST* for the
> meeting.
>
> I'll setup the meeting and blast out the logistics to both the dev and
> user lists. Once I have the logistics sorted out, can someone help with
> getting this posted on the events calendar on geode.apache.org. Do we
> normally publicize these project specific meetings on the broader Apache
> community calendar? If so, who can help with this?
>
> Let me know if you have any comments or questions about this.
>
> --
> Regards
> Jag
>



-- 
Regards
Jag

[GitHub] geode pull request #719: GEODE-3447 Implement client authorization for the n...

[galen-pivotal]

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

https://github.com/apache/geode/pull/719#discussion_r134635734
  
--- Diff: 
geode-protobuf/src/test/java/org/apache/geode/protocol/AuthorizationIntegrationTest.java
 ---
@@ -0,0 +1,206 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more 
contributor license
+ * agreements. See the NOTICE file distributed with this work for 
additional information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache 
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the 
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software 
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF 
ANY KIND, either express
+ * or implied. See the License for the specific language governing 
permissions and limitations under
+ * the License.
+ */
+package org.apache.geode.protocol;
+
+import static org.junit.Assert.assertEquals;
+import static org.junit.Assert.assertTrue;
+import static org.mockito.ArgumentMatchers.any;
+import static org.mockito.ArgumentMatchers.same;
+import static org.mockito.Mockito.mock;
+import static org.mockito.Mockito.when;
+
+import java.io.IOException;
+import java.io.InputStream;
+import java.io.OutputStream;
+import java.net.Socket;
+import java.util.Properties;
+import java.util.concurrent.TimeUnit;
+
+import org.awaitility.Awaitility;
+import org.junit.After;
+import org.junit.Before;
+import org.junit.Rule;
+import org.junit.Test;
+import org.junit.contrib.java.lang.system.RestoreSystemProperties;
+import org.junit.experimental.categories.Category;
+
+import org.apache.geode.cache.Cache;
+import org.apache.geode.cache.CacheFactory;
+import org.apache.geode.cache.server.CacheServer;
+import org.apache.geode.internal.AvailablePortHelper;
+import org.apache.geode.management.internal.security.ResourceConstants;
+import org.apache.geode.protocol.protobuf.AuthenticationAPI;
+import org.apache.geode.protocol.protobuf.ClientProtocol;
+import org.apache.geode.protocol.protobuf.ProtobufSerializationService;
+import org.apache.geode.protocol.protobuf.ProtocolErrorCode;
+import org.apache.geode.protocol.protobuf.RegionAPI;
+import 
org.apache.geode.protocol.protobuf.serializer.ProtobufProtocolSerializer;
+import org.apache.geode.protocol.protobuf.utilities.ProtobufUtilities;
+import org.apache.geode.security.ResourcePermission;
+import org.apache.geode.security.SecurityManager;
+import 
org.apache.geode.serialization.registry.exception.CodecAlreadyRegisteredForTypeException;
+import org.apache.geode.test.junit.categories.IntegrationTest;
+
+@Category(IntegrationTest.class)
+public class AuthorizationIntegrationTest {
+
+  private static final String TEST_USERNAME = "bob";
+  private static final String TEST_PASSWORD = "bobspassword";
+  public static final String TEST_REGION = "testRegion";
+
+  @Rule
+  public final RestoreSystemProperties restoreSystemProperties = new 
RestoreSystemProperties();
+
+  private Cache cache;
+  private int cacheServerPort;
+  private CacheServer cacheServer;
+  private Socket socket;
+  private OutputStream outputStream;
+  private ProtobufSerializationService serializationService;
+  private InputStream inputStream;
+  private ProtobufProtocolSerializer protobufProtocolSerializer;
+  private Object securityPrincipal;
+  private SecurityManager mockSecurityManager;
+  private String testRegion;
+  public static final ResourcePermission READ_PERMISSION =
+  new ResourcePermission(ResourcePermission.Resource.DATA, 
ResourcePermission.Operation.READ);
+  public static final ResourcePermission WRITE_PERMISSION =
+  new ResourcePermission(ResourcePermission.Resource.DATA, 
ResourcePermission.Operation.WRITE);
+
+  @Before
+  public void setUp() throws IOException, 
CodecAlreadyRegisteredForTypeException {
+Properties expectedAuthProperties = new Properties();
+expectedAuthProperties.setProperty(ResourceConstants.USER_NAME, 
TEST_USERNAME);
+expectedAuthProperties.setProperty(ResourceConstants.PASSWORD, 
TEST_PASSWORD);
+
+securityPrincipal = new Object();
+mockSecurityManager = mock(SecurityManager.class);
+
when(mockSecurityManager.authenticate(expectedAuthProperties)).thenReturn(securityPrincipal);
+
+Properties properties = new Properties();
+CacheFactory cacheFactory = new CacheFactory(properties);
+

[GitHub] geode pull request #719: GEODE-3447 Implement client authorization for the n...

[galen-pivotal]

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

https://github.com/apache/geode/pull/719#discussion_r134634705
  
--- Diff: 
geode-protobuf/src/main/java/org/apache/geode/protocol/protobuf/registry/OperationContextRegistry.java
 ---
@@ -47,41 +48,57 @@ private void addContexts() {
 operationContexts.put(RequestAPICase.GETREQUEST,
 new OperationContext<>(ClientProtocol.Request::getGetRequest,
 new GetRequestOperationHandler(),
-opsResp -> 
ClientProtocol.Response.newBuilder().setGetResponse(opsResp)));
+opsResp -> 
ClientProtocol.Response.newBuilder().setGetResponse(opsResp),
+new ResourcePermission(ResourcePermission.Resource.DATA,
+ResourcePermission.Operation.READ)));
 
 operationContexts.put(RequestAPICase.GETALLREQUEST,
 new OperationContext<>(ClientProtocol.Request::getGetAllRequest,
 new GetAllRequestOperationHandler(),
-opsResp -> 
ClientProtocol.Response.newBuilder().setGetAllResponse(opsResp)));
+opsResp -> 
ClientProtocol.Response.newBuilder().setGetAllResponse(opsResp),
+new ResourcePermission(ResourcePermission.Resource.DATA,
+ResourcePermission.Operation.READ)));
 
 operationContexts.put(RequestAPICase.PUTREQUEST,
 new OperationContext<>(ClientProtocol.Request::getPutRequest,
 new PutRequestOperationHandler(),
-opsResp -> 
ClientProtocol.Response.newBuilder().setPutResponse(opsResp)));
+opsResp -> 
ClientProtocol.Response.newBuilder().setPutResponse(opsResp),
+new ResourcePermission(ResourcePermission.Resource.DATA,
+ResourcePermission.Operation.WRITE)));
 
 operationContexts.put(RequestAPICase.PUTALLREQUEST,
 new OperationContext<>(ClientProtocol.Request::getPutAllRequest,
 new PutAllRequestOperationHandler(),
-opsResp -> 
ClientProtocol.Response.newBuilder().setPutAllResponse(opsResp)));
+opsResp -> 
ClientProtocol.Response.newBuilder().setPutAllResponse(opsResp),
+new ResourcePermission(ResourcePermission.Resource.DATA,
+ResourcePermission.Operation.WRITE)));
 
 operationContexts.put(RequestAPICase.REMOVEREQUEST,
 new OperationContext<>(ClientProtocol.Request::getRemoveRequest,
 new RemoveRequestOperationHandler(),
-opsResp -> 
ClientProtocol.Response.newBuilder().setRemoveResponse(opsResp)));
+opsResp -> 
ClientProtocol.Response.newBuilder().setRemoveResponse(opsResp),
+new ResourcePermission(ResourcePermission.Resource.DATA,
+ResourcePermission.Operation.WRITE)));
 
 operationContexts.put(RequestAPICase.GETREGIONNAMESREQUEST,
 new 
OperationContext<>(ClientProtocol.Request::getGetRegionNamesRequest,
 new GetRegionNamesRequestOperationHandler(),
-opsResp -> 
ClientProtocol.Response.newBuilder().setGetRegionNamesResponse(opsResp)));
+opsResp -> 
ClientProtocol.Response.newBuilder().setGetRegionNamesResponse(opsResp),
+new ResourcePermission(ResourcePermission.Resource.DATA,
+ResourcePermission.Operation.READ)));
 
 operationContexts.put(RequestAPICase.GETREGIONREQUEST,
 new OperationContext<>(ClientProtocol.Request::getGetRegionRequest,
 new GetRegionRequestOperationHandler(),
-opsResp -> 
ClientProtocol.Response.newBuilder().setGetRegionResponse(opsResp)));
+opsResp -> 
ClientProtocol.Response.newBuilder().setGetRegionResponse(opsResp),
+new ResourcePermission(ResourcePermission.Resource.DATA,
+ResourcePermission.Operation.READ)));
 
-operationContexts.put(RequestAPICase.GETAVAILABLESERVERSREQUEST, new 
OperationContext<>(
-ClientProtocol.Request::getGetAvailableServersRequest,
-new GetAvailableServersOperationHandler(),
-opsResp -> 
ClientProtocol.Response.newBuilder().setGetAvailableServersResponse(opsResp)));
+operationContexts.put(RequestAPICase.GETAVAILABLESERVERSREQUEST,
--- End diff --

This is one that should be authorized for either read or write... is read a 
subset of write? I don't know.


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

[GitHub] geode pull request #719: GEODE-3447 Implement client authorization for the n...

[galen-pivotal]

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

https://github.com/apache/geode/pull/719#discussion_r134633950
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/security/StreamAuthorizer.java ---
@@ -0,0 +1,19 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more 
contributor license
+ * agreements. See the NOTICE file distributed with this work for 
additional information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache 
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the 
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software 
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF 
ANY KIND, either express
+ * or implied. See the License for the specific language governing 
permissions and limitations under
+ * the License.
+ */
+package org.apache.geode.security;
+
+public interface StreamAuthorizer {
+  boolean authorize(ResourcePermission permissionRequested);
--- End diff --

We may need to refactor this at some point when operations start needing 
more than one permission (which depends on whether write authorization implies 
read authorization), but I think that's more than a failing of the security API 
than ours, and it should be possible to do everything we need for the alpha 
anyways (no getAndSet yet).


---
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: Tombstones

[Anilkumar Gingade]

Thats right...They are not returned as part of public/user apis...

-Anil.

On Tue, Aug 22, 2017 at 11:09 AM, Dan Smith  wrote:

> I believe tombstones are not included in those operations, so you won't see
> them.
>
> -Dan
>
> On Tue, Aug 22, 2017 at 10:56 AM, Michael Stolz  wrote:
>
> > Do tombstones show up in operations that indicate presence of keys like
> > Region.keyset(), containsKey(key), etc?
> > They probably shouldn't.
> >
> > --
> > Mike Stolz
> > Principal Engineer, GemFire Product Manager
> > Mobile: +1-631-835-4771
> >
>

Re: Adding parallel import/export of snapshots to gfsh

[Anilkumar Gingade]

>> One other idea that hasn't been mentioned is making parallel the only way

My vote is to support both option; we could make parallel default but
having an option to take snapshot at one node may be useful for use-cases
where:
- Easier to manage snapshot at one file location; in a large cluster
environment.
- Control on file level security
- A node can be used for snapshot without impacting other nodes (disk i/o
ops).

-Anil.



On Tue, Aug 22, 2017 at 3:42 PM, Nick Reich  wrote:

> With minimal code change, it is possible to enable the use of —dir for both
> standard and parallel export/import, allowing —file to function only for
> standard exports (and optionally, make it depricated in favor of the —dir
> option).
>
> While not inherently opposed to forcing all Partitioned Region snapshots to
> be parallel, that seems to be a significant enough change to current
> functionality (one file one one member to multiple files on multiple
> members), I am hesitant to do so without united community backing for that
> approach.
>
> On Tue, Aug 22, 2017 at 2:24 PM, Michael Stolz  wrote:
>
> > One other idea that hasn't been mentioned is making parallel the only way
> > for Partitioned Regions, and having --file serve the purpose of defining
> > both a path and a filename pattern where the bucket ID or whatever we're
> > using gets automatically inserted before the .gfd extension.
> >
> > No need for a new option (--parallel).
> > No need for a new option (--path).
> >
> > In fact, no need for a change to gfsh command at all.
> >
> >
> > --
> > Mike Stolz
> > Principal Engineer, GemFire Product Manager
> > Mobile: +1-631-835-4771
> >
> > On Tue, Aug 22, 2017 at 2:15 PM, Nick Reich  wrote:
> >
> > > Parallel export will write the data to files on the bucket primary for
> > each
> > > bucket, distributing the work (and therefore files) to all the members.
> > > That would be a big enough deviation from the current behavior (single
> > file
> > > on single machine), that I think it makes it worth having the
> additional
> > > options (but I agree: less options is generally better).
> > >
> > > On Tue, Aug 22, 2017 at 1:59 PM, Jacob Barrett 
> > > wrote:
> > >
> > > > On Tue, Aug 22, 2017 at 1:49 PM Nick Reich 
> wrote:
> > > >
> > > > > The idea of deprecating —file in favor of path is interesting. I
> > wonder
> > > > if
> > > > > instead of making them mutually exclusive to start, having —path be
> > > able
> > > > to
> > > > > support both modes from the start would be better? That way —file
> > could
> > > > > still be used for the existing mode, but —path could be used
> instead
> > > (and
> > > > > override —file is both given?): that would provide a clear path
> > forward
> > > > for
> > > > > how the command should be used, while fully supporting existing
> > > > workflows.
> > > > >
> > > >
> > > > This is what I meant by deprecating. Maybe even providing a message
> > that
> > > if
> > > > --file is set that it is deprecated for --path.
> > > >
> > > >
> > > > > We need to continue to support both modes, as only Partitioned
> > Regions
> > > > can
> > > > > make use of parallel export (it is parallelized on a bucket level).
> > > > >
> > > >
> > > > Ok, so why not just make parallel the only mode for partitioned. Then
> > you
> > > > remove the need for --parallel and --path would work for any region,
> > > > non-partitioned would create a single file at that path and
> partitioned
> > > > would create several? I am all for less options. ;)
> > > >
> > > > -Jake
> > > >
> > >
> >
>

Review Request 61829: GEODE-3408 Flood of EOF warnings

[Bruce Schuchardt]

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

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


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


Repository: geode


Description
---

Modified the message handler to catch EOFException and effect shutdown of the 
connection & server thread.  I also fixed the handling of IOException.

The methods invoked are the same as for the old protocol's handling of 
EOFException and IOException.


Diffs
-

  
geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/GenericProtocolServerConnection.java
 cd1647a 


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


Testing
---

as this just affects logging behavior there are no new unit tests.  I verified 
that the behavior is correct with the manual test used to reproduce GEODE-3409 
(my other review that is currently open).

precheckin is running now.


Thanks,

Bruce Schuchardt

[GitHub] geode pull request #732: GEODE-3276: Managing race conditions while the send...

[jhuynh1]

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

https://github.com/apache/geode/pull/732#discussion_r134622619
  
--- Diff: 
geode-wan/src/main/java/org/apache/geode/internal/cache/wan/parallel/ParallelGatewaySenderImpl.java
 ---
@@ -107,6 +107,9 @@ public void stop() {
   if (ev != null && !ev.isStopped()) {
 ev.stopProcessing();
   }
+  if (ev != null && ev.getDispatcher() != null) {
--- End diff --

Is it possible to pull this check and shutdown into a method?  Looks like 
it's used a few times throughout the code


---
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 > #655 was SUCCESSFUL (with 2027 tests)

[Spring CI]

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

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





--
This message is automatically generated by Atlassian Bamboo

Re: Adding parallel import/export of snapshots to gfsh

[Nick Reich]

With minimal code change, it is possible to enable the use of —dir for both
standard and parallel export/import, allowing —file to function only for
standard exports (and optionally, make it depricated in favor of the —dir
option).

While not inherently opposed to forcing all Partitioned Region snapshots to
be parallel, that seems to be a significant enough change to current
functionality (one file one one member to multiple files on multiple
members), I am hesitant to do so without united community backing for that
approach.

On Tue, Aug 22, 2017 at 2:24 PM, Michael Stolz  wrote:

> One other idea that hasn't been mentioned is making parallel the only way
> for Partitioned Regions, and having --file serve the purpose of defining
> both a path and a filename pattern where the bucket ID or whatever we're
> using gets automatically inserted before the .gfd extension.
>
> No need for a new option (--parallel).
> No need for a new option (--path).
>
> In fact, no need for a change to gfsh command at all.
>
>
> --
> Mike Stolz
> Principal Engineer, GemFire Product Manager
> Mobile: +1-631-835-4771
>
> On Tue, Aug 22, 2017 at 2:15 PM, Nick Reich  wrote:
>
> > Parallel export will write the data to files on the bucket primary for
> each
> > bucket, distributing the work (and therefore files) to all the members.
> > That would be a big enough deviation from the current behavior (single
> file
> > on single machine), that I think it makes it worth having the additional
> > options (but I agree: less options is generally better).
> >
> > On Tue, Aug 22, 2017 at 1:59 PM, Jacob Barrett 
> > wrote:
> >
> > > On Tue, Aug 22, 2017 at 1:49 PM Nick Reich  wrote:
> > >
> > > > The idea of deprecating —file in favor of path is interesting. I
> wonder
> > > if
> > > > instead of making them mutually exclusive to start, having —path be
> > able
> > > to
> > > > support both modes from the start would be better? That way —file
> could
> > > > still be used for the existing mode, but —path could be used instead
> > (and
> > > > override —file is both given?): that would provide a clear path
> forward
> > > for
> > > > how the command should be used, while fully supporting existing
> > > workflows.
> > > >
> > >
> > > This is what I meant by deprecating. Maybe even providing a message
> that
> > if
> > > --file is set that it is deprecated for --path.
> > >
> > >
> > > > We need to continue to support both modes, as only Partitioned
> Regions
> > > can
> > > > make use of parallel export (it is parallelized on a bucket level).
> > > >
> > >
> > > Ok, so why not just make parallel the only mode for partitioned. Then
> you
> > > remove the need for --parallel and --path would work for any region,
> > > non-partitioned would create a single file at that path and partitioned
> > > would create several? I am all for less options. ;)
> > >
> > > -Jake
> > >
> >
>

[GitHub] geode pull request #729: GEODE-3461: increase test timeouts

[asfgit]

Github user asfgit closed the pull request at:

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


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

[GitHub] geode pull request #730: GEODE-3472: Remove a great deal of commented-out co...

[PurelyApplied]

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

https://github.com/apache/geode/pull/730#discussion_r134618712
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/management/internal/cli/result/AbstractResultData.java
 ---
@@ -147,11 +147,10 @@ public ResultData addAsFile(String fileName, String 
fileContents, String message
 
   public ResultData addAsFile(String fileName, byte[] data, int fileType, 
String message,
   boolean addTimeStampToName) {
-byte[] bytes = data;
--- End diff --

I might by projecting my Python and C expectations into my relatively new 
Java experience, but I thought this assignment wouldn't change the mutability 
of `data`.  Wouldn't this need `byte[] bytes = data.clone();` to actually 
provided immutability to `data`?  Or is Java more defensive than I realized?


---
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 #729: GEODE-3461: increase test timeouts

[kirklund]

Github user kirklund commented on the issue:

https://github.com/apache/geode/pull/729
  
This PR should also fix GEODE-3505.


---
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.
---

Passed: apache/geode#3649 (develop - a1ac45d)

[Travis CI]

Build Update for apache/geode
-

Build: #3649
Status: Passed

Duration: 22 minutes and 28 seconds
Commit: a1ac45d (develop)
Author: Dave Barnes
Message: GEODE-3504: Add Experimental caveat for Redis and Auto-rebalance

View the changeset: 
https://github.com/apache/geode/compare/c0f6c841862c...a1ac45dee947

View the full build log and details: 
https://travis-ci.org/apache/geode/builds/267363068?utm_source=email_medium=notification

--

You can configure recipients for build notifications in your .travis.yml file. 
See https://docs.travis-ci.com/user/notifications

Re: Gitbox enables the full GitHub workflow

[Bruce Schuchardt]

+1


On 8/22/17 1:48 PM, Udo Kohlmeyer wrote:

+1 to migrate :)


On 8/22/17 10:43, Anthony Baker wrote:
On Aug 7, 2017, at 6:09 PM, Roman Shaposhnik  
wrote:


Hi!

it has just come to my attention that Gitbox at ASF
has been enabling full GitHub workflow (with being
able to click Merge this PR button, etc.) for quite
some time.

This basically allows a project to have GH as a R/W
repo as opposed to R/O mirror of what we all currnently
have: https://gitbox.apache.org/repos/asf

Personally I'm not sure I like GH workflow all that much,
but if there's interest -- you can opt-in into Gitbox. Once
you do -- your source of truth moves to GH. You can't
have it both ways with git-wip-us.apache.org and Gitbox.

Thanks,
Roman.
Now that we’ve got some experience with gitbox on geode-native, are 
we ready to convert the other repos?


- geode
- geode-site
- geode-examples

I think we should.

Anthony

[GitHub] geode pull request #730: GEODE-3472: Remove a great deal of commented-out co...

[pdxrunner]

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

https://github.com/apache/geode/pull/730#discussion_r134616035
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/management/internal/cli/result/AbstractResultData.java
 ---
@@ -147,11 +147,10 @@ public ResultData addAsFile(String fileName, String 
fileContents, String message
 
   public ResultData addAsFile(String fileName, byte[] data, int fileType, 
String message,
   boolean addTimeStampToName) {
-byte[] bytes = data;
--- End diff --

I think the contents of `data` should be treated as if it were immutable in 
this usage, so don't make this and the following change.


---
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] FunctionStats over the JMX [GEODE-3462]

[Kirk Lund]

I just ran across a test in Geode which manipulates similar APIs for Client
stats on the CacheServerMXBean:

  String[] clientIds = cacheServerMXBean.getClientIds();
  ClientHealthStatus clientStatus1 =
cacheServerMXBean.showClientStats(clientIds[0]);
  ClientHealthStatus clientStatus2 =
cacheServerMXBean.showClientStats(clientIds[1]);

  ClientHealthStatus[] clientStatuses =
cacheServerMXBean.showAllClientStats();

The above code can be used to view the stats per client or for all clients
connected to that CacheServer.

We could do something similar for Functions.

On Tue, Aug 22, 2017 at 10:06 AM, Kirk Lund  wrote:

> Hi Dinesh,
>
> Check out this project by Charlie Black: https://github.com/
> charliemblack/geode-exposing-metrics-via-JMX
>
> We currently have no plans to introduce out-of-the box Geode MXBeans for
> every Function or for all stats. When you combine this with federating of
> MBeans to the JMX Manager(s), it puts too much overhead on the cluster and
> severely impacts performance. It can also result in StatSampler pauses and
> GC problems. This was a big part of the problem with the old
> pre-GemFire-7.0 JMX (com.gemstone.gemfire.admin) that lead us to
> deprecating and replacing it with the current Geode MXBeans
> (org.apache.geode.management).
>
> Users of Geode already have the ability to craft their own MBeans which
> can be federated using the ManagementService API. See
> org.apache.geode.management.ManagementService. Unfortunately, we don't
> yet have an example for this -- it's a bit more involved than Charlie's
> project and would probably involve using the (currently internal-only)
> Statistics Monitoring API.
>
> We do plan to move or mirror part of the Statistics Monitoring API
> from org.apache.geode.internal.statistics to a User API
> (org.apache.geode.statistics) which would make it easier to use the stat
> sampler for updating custom MBeans with stat values. In addition, we plan
> to provide statistic categories (basic, expert, advanced) and make more
> improvements to allow definition of monitors for statistics types before
> statistics instances are actually created. There is an important trade-off
> between monitoring and performance that needs to be carefully considered
> with any usage of the Statistics Monitoring API.
>
> The statistics that are currently exposed on Geode MXBeans fall into two
> categories: the most important stats which we believe are vital in all use
> cases of monitoring Geode are exposed as JMX *attributes* on corresponding
> MXBeans such as RegionMXBean, DiskStoreMXBean. Additional stats which are
> very important but maybe not as important are grouped together as *Metrics
> open data types and accessible by a JMX *operation* such as
> MemberMXBean#showJVMMetrics, MemberMXBean#showOSMetrics,
> DistributedSystemMXBean#showDiskMetrics. This allows us to expose a
> larger number of stats but only by active request (invoking the operation).
> If we actually exposed all of these stats as attributes instead of grouped
> together as the result of an operation then again, the impact on
> performance is too great.
>
> Geode also has aggregate MXBeans which represent the entire cluster such
> as DistributedSystemMXBean and DistributedRegionMXBean. These provide
> cluster-wide aggregate attributes and operations. There are show*Metrics
> operations exposed at this level as well which aggregate stat values across
> the entire cluster.
>
> I do think it would be reasonable to add a new FunctionMetrics open data
> type and a corresponding showFunctionMetrics operation to one of the
> MXBeans (probably the MemberMXBean). That would give the user a view of
> Function stats for that one member. It might also make sense to add
> showFunctionMetrics operation to DistributedSystemMXBean to provide an
> aggregate view of the function stats for the entire cluster.
>
> If you need to expose the function stats as attributes which are
> constantly updated instead of using a showFunctionMetrics operation then I
> think your best approach may be to use custom MBeans such as described in
> Charlie Black's project or try out using the ManagementService APIs for
> registering MBeans.
>
> On Mon, Aug 21, 2017 at 4:12 AM, Dinesh Akhand 
> wrote:
>
>> Hi Team,
>>
>> We are looking for implementing the function stats over JMX.
>> Currently Function Stats are not part of JMX. We can't see them on JMX
>> server.
>> Can you please assist what is the correct way to implementing it.
>>
>> We have many function  which are instanceOf  FunctionAdapter.
>> We want to monitor their stats on JMX server . can you please assist.
>>
>> But we having lots of user created function . for monitoring the few
>> critical functions, we want then as per configuration based.
>>
>>
>> GEODE-3462. https://github.com/apache/geode/pull/720
>>
>> Thanks,
>> Dinesh Akhand
>>
>> This message and the information contained herein is proprietary and
>> confidential and 

[GitHub] geode pull request #732: GEODE-3276: Managing race conditions while the send...

[nabarunnag]

GitHub user nabarunnag opened a pull request:

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

GEODE-3276: Managing race conditions while the senders are stopped

* When a connection is initialized, a readAckThread may be alive from a 
previous incarnation.
* This AckThread will be stuck on a read socket with no timeout as 
nothing was dispatched.
* Also while it was stuck on the read, it will hold a connection 
lifecycle read lock
* The initialize connection needs a connection life cycle write lock to 
start the connection but the read lock is held by the ack thread.
* This results in a deadlock and eventually a hang.
* Another situation is that we set the flag isStopped for the event 
processor before actually shutting down the diapatcher and ack thread.
* So after the flag is set and before actually shutting down the 
dispatcher and ackThread, a gateway proxy stomper thread gets in between these 
two steps of execution.
* The stomper thread checks the isStopped flag, which was set to true, 
and proceeds to destroy the connection pool. However the dispatcher and 
ackThread were still running.
* This results in a out of heap memory exception while the ack thread 
is reading from the socket while connection pool was destroyed.
* To solve this issue, the stomper thread checks if the event processor 
and dispatcher exists, if true then we close the input streams before 
destroying the connection pool.

Thank you for submitting a contribution to Apache Geode.

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

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

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

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

- [ ] Does `gradlew build` run cleanly?

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

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

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


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

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

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

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


commit 9618f69d2620f5a3d3a6a8576631906a61b512f9
Author: nabarun 
Date:   2017-08-17T17:51:15Z

GEODE-3276: Managing race conditions while the senders are stopped

* When a connection is initialized, a readAckThread may be alive from a 
previous incarnation.
* This AckThread will be stuck on a read socket with no timeout as 
nothing was dispatched.
* Also while it was stuck on the read, it will hold a connection 
lifecycle read lock
* The initialize connection needs a connection life cycle write lock to 
start the connection but the read lock is held by the ack thread.
* This results in a deadlock and eventually a hang.
* Another situation is that we set the flag isStopped for the event 
processor before actually shutting down the diapatcher and ack thread.
* So after the flag is set and before actually shutting down the 
dispatcher and ackThread, a gateway proxy stomper thread gets in between these 
two steps of execution.
* The stomper thread checks the isStopped flag, which was set to true, 
and proceeds to destroy the connection pool. However the dispatcher and 
ackThread were still running.
* This results in a out of heap memory exception while the ack thread 
is reading from the socket while connection pool was destroyed.
* To solve this issue, the stomper thread checks if the event processor 
and dispatcher exists, if true then we close the input streams before 
destroying the connection pool.




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

[GitHub] geode pull request #659: GEODE-3308: Lucene rolling upgrade and backwards co...

[nabarunnag]

Github user nabarunnag closed the pull request at:

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


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

Build failed in Jenkins: Geode-release-flaky #30

[Apache Jenkins Server]

See 

--
[...truncated 94.19 KB...]
:geode-wan:compileJava
:geode-wan:processResources
:geode-wan:classes
:geode-web:compileJava UP-TO-DATE
:geode-web:processResources UP-TO-DATE
:geode-web:classes UP-TO-DATE
:geode-web-api:compileJava
Download 
https://repo1.maven.org/maven2/com/fasterxml/jackson/module/jackson-module-scala_2.10/2.8.6/jackson-module-scala_2.10-2.8.6.pom
Download 
https://repo1.maven.org/maven2/io/springfox/springfox-swagger2/2.6.1/springfox-swagger2-2.6.1.pom
Download 
https://repo1.maven.org/maven2/io/springfox/springfox-swagger-ui/2.6.1/springfox-swagger-ui-2.6.1.pom
Download 
https://repo1.maven.org/maven2/org/springframework/hateoas/spring-hateoas/0.23.0.RELEASE/spring-hateoas-0.23.0.RELEASE.pom
Download 
https://repo1.maven.org/maven2/com/fasterxml/jackson/module/jackson-module-paranamer/2.8.6/jackson-module-paranamer-2.8.6.pom
Download 
https://repo1.maven.org/maven2/com/fasterxml/jackson/module/jackson-modules-base/2.8.6/jackson-modules-base-2.8.6.pom
Download 
https://repo1.maven.org/maven2/com/fasterxml/jackson/jackson-bom/2.8.6/jackson-bom-2.8.6.pom
Download 
https://repo1.maven.org/maven2/io/springfox/springfox-spi/2.6.1/springfox-spi-2.6.1.pom
Download 
https://repo1.maven.org/maven2/io/springfox/springfox-schema/2.6.1/springfox-schema-2.6.1.pom
Download 
https://repo1.maven.org/maven2/io/springfox/springfox-swagger-common/2.6.1/springfox-swagger-common-2.6.1.pom
Download 
https://repo1.maven.org/maven2/io/springfox/springfox-spring-web/2.6.1/springfox-spring-web-2.6.1.pom
Download 
https://repo1.maven.org/maven2/com/fasterxml/classmate/1.3.1/classmate-1.3.1.pom
Download 
https://repo1.maven.org/maven2/org/springframework/plugin/spring-plugin-core/1.2.0.RELEASE/spring-plugin-core-1.2.0.RELEASE.pom
Download 
https://repo1.maven.org/maven2/org/springframework/plugin/spring-plugin/1.2.0.RELEASE/spring-plugin-1.2.0.RELEASE.pom
Download 
https://repo1.maven.org/maven2/org/springframework/plugin/spring-plugin-metadata/1.2.0.RELEASE/spring-plugin-metadata-1.2.0.RELEASE.pom
Download 
https://repo1.maven.org/maven2/org/mapstruct/mapstruct/1.0.0.Final/mapstruct-1.0.0.Final.pom
Download 
https://repo1.maven.org/maven2/org/mapstruct/mapstruct-parent/1.0.0.Final/mapstruct-parent-1.0.0.Final.pom
Download 
https://repo1.maven.org/maven2/com/thoughtworks/paranamer/paranamer/2.8/paranamer-2.8.pom
Download 
https://repo1.maven.org/maven2/com/thoughtworks/paranamer/paranamer-parent/2.8/paranamer-parent-2.8.pom
Download 
https://repo1.maven.org/maven2/io/springfox/springfox-core/2.6.1/springfox-core-2.6.1.pom
Download 
https://repo1.maven.org/maven2/com/fasterxml/jackson/module/jackson-module-scala_2.10/2.8.6/jackson-module-scala_2.10-2.8.6.jar
Download 
https://repo1.maven.org/maven2/io/springfox/springfox-swagger2/2.6.1/springfox-swagger2-2.6.1.jar
Download 
https://repo1.maven.org/maven2/io/springfox/springfox-swagger-ui/2.6.1/springfox-swagger-ui-2.6.1.jar
Download 
https://repo1.maven.org/maven2/org/springframework/hateoas/spring-hateoas/0.23.0.RELEASE/spring-hateoas-0.23.0.RELEASE.jar
Download 
https://repo1.maven.org/maven2/com/fasterxml/jackson/module/jackson-module-paranamer/2.8.6/jackson-module-paranamer-2.8.6.jar
Download 
https://repo1.maven.org/maven2/io/springfox/springfox-spi/2.6.1/springfox-spi-2.6.1.jar
Download 
https://repo1.maven.org/maven2/io/springfox/springfox-schema/2.6.1/springfox-schema-2.6.1.jar
Download 
https://repo1.maven.org/maven2/io/springfox/springfox-swagger-common/2.6.1/springfox-swagger-common-2.6.1.jar
Download 
https://repo1.maven.org/maven2/io/springfox/springfox-spring-web/2.6.1/springfox-spring-web-2.6.1.jar
Download 
https://repo1.maven.org/maven2/org/springframework/plugin/spring-plugin-core/1.2.0.RELEASE/spring-plugin-core-1.2.0.RELEASE.jar
Download 
https://repo1.maven.org/maven2/org/springframework/plugin/spring-plugin-metadata/1.2.0.RELEASE/spring-plugin-metadata-1.2.0.RELEASE.jar
Download 
https://repo1.maven.org/maven2/org/mapstruct/mapstruct/1.0.0.Final/mapstruct-1.0.0.Final.jar
Download 
https://repo1.maven.org/maven2/com/thoughtworks/paranamer/paranamer/2.8/paranamer-2.8.jar
Download 
https://repo1.maven.org/maven2/io/springfox/springfox-core/2.6.1/springfox-core-2.6.1.jar
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
:geode-web-api:processResources
:geode-web-api:classes
:geode-assembly:docs
:geode-assembly:gfshDepsJar
:geode-common:javadocJar
:geode-common:sourcesJar
:geode-common:signArchives SKIPPED
:geode-core:javadocJar
:geode-core:raJar
:geode-core:jcaJar
:geode-core:sourcesJar
:geode-core:signArchives SKIPPED
:geode-core:webJar
:geode-cq:jar
:geode-cq:javadoc
:geode-cq:javadocJar
:geode-cq:sourcesJar
:geode-cq:signArchives SKIPPED
:geode-json:javadocJar
:geode-json:sourcesJar
:geode-json:signArchives SKIPPED
:geode-lucene:jar
:geode-lucene:javadoc

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

[Ken Howe]

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

(Updated Aug. 22, 2017, 9:28 p.m.)


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


Changes
---

Refactored ServerLauncher similar to the previous change to LocatorLauncher to 
remove nested ternary expressions.


Repository: geode


Description
---

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

Minor spelling corrections.


Diffs (updated)
-

  
geode-assembly/src/test/java/org/apache/geode/management/internal/cli/commands/StatusLocatorRealGfshTest.java
 3a98373938e3de21da6badcf460dae3648218ac6 
  geode-core/src/main/java/org/apache/geode/distributed/LocatorLauncher.java 
83c1ab533e3dea323a8a99f7002b9464a54dfc25 
  geode-core/src/main/java/org/apache/geode/distributed/ServerLauncher.java 
ae64691605130c9b212a3a33bb65ae37b28af02b 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/lifecycle/GfshStatusCommandsIntegrationTest.java
 dd5841f4cffca38da07a11f381cf4174d7264349 
  
geode-core/src/test/java/org/apache/geode/test/dunit/rules/GfshShellConnectionRule.java
 e7f17ef208a1708f385c7c4041affb70fd309a4c 


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

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


Testing (updated)
---

Precheckin from earlier ran green.

Re-running precheckin with this additional refactoring.


Thanks,

Ken Howe

[GitHub] geode pull request #731: GEODE-2842: Removed redundant default annotation pa...

[PurelyApplied]

GitHub user PurelyApplied opened a pull request:

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

GEODE-2842: Removed redundant default annotation parameter values.

Driven by IntelliJ inspection, I have extended the reach of this ticket to 
include any annotation, not only `@CliOption`.





Thank you for submitting a contribution to Apache Geode.

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

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

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

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

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

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

- [n/a] 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/PurelyApplied/geode geode-2842

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

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


commit 2f27ae65508935fcf3b4145f2412b450d65019f4
Author: Patrick Rhomberg 
Date:   2017-08-22T21:20:12Z

GEODE-2842: Removed redundant default annotation parameter values.




---
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: Adding parallel import/export of snapshots to gfsh

[Michael Stolz]

One other idea that hasn't been mentioned is making parallel the only way
for Partitioned Regions, and having --file serve the purpose of defining
both a path and a filename pattern where the bucket ID or whatever we're
using gets automatically inserted before the .gfd extension.

No need for a new option (--parallel).
No need for a new option (--path).

In fact, no need for a change to gfsh command at all.


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

On Tue, Aug 22, 2017 at 2:15 PM, Nick Reich  wrote:

> Parallel export will write the data to files on the bucket primary for each
> bucket, distributing the work (and therefore files) to all the members.
> That would be a big enough deviation from the current behavior (single file
> on single machine), that I think it makes it worth having the additional
> options (but I agree: less options is generally better).
>
> On Tue, Aug 22, 2017 at 1:59 PM, Jacob Barrett 
> wrote:
>
> > On Tue, Aug 22, 2017 at 1:49 PM Nick Reich  wrote:
> >
> > > The idea of deprecating —file in favor of path is interesting. I wonder
> > if
> > > instead of making them mutually exclusive to start, having —path be
> able
> > to
> > > support both modes from the start would be better? That way —file could
> > > still be used for the existing mode, but —path could be used instead
> (and
> > > override —file is both given?): that would provide a clear path forward
> > for
> > > how the command should be used, while fully supporting existing
> > workflows.
> > >
> >
> > This is what I meant by deprecating. Maybe even providing a message that
> if
> > --file is set that it is deprecated for --path.
> >
> >
> > > We need to continue to support both modes, as only Partitioned Regions
> > can
> > > make use of parallel export (it is parallelized on a bucket level).
> > >
> >
> > Ok, so why not just make parallel the only mode for partitioned. Then you
> > remove the need for --parallel and --path would work for any region,
> > non-partitioned would create a single file at that path and partitioned
> > would create several? I am all for less options. ;)
> >
> > -Jake
> >
>

Re: Adding parallel import/export of snapshots to gfsh

[Nick Reich]

Parallel export will write the data to files on the bucket primary for each
bucket, distributing the work (and therefore files) to all the members.
That would be a big enough deviation from the current behavior (single file
on single machine), that I think it makes it worth having the additional
options (but I agree: less options is generally better).

On Tue, Aug 22, 2017 at 1:59 PM, Jacob Barrett  wrote:

> On Tue, Aug 22, 2017 at 1:49 PM Nick Reich  wrote:
>
> > The idea of deprecating —file in favor of path is interesting. I wonder
> if
> > instead of making them mutually exclusive to start, having —path be able
> to
> > support both modes from the start would be better? That way —file could
> > still be used for the existing mode, but —path could be used instead (and
> > override —file is both given?): that would provide a clear path forward
> for
> > how the command should be used, while fully supporting existing
> workflows.
> >
>
> This is what I meant by deprecating. Maybe even providing a message that if
> --file is set that it is deprecated for --path.
>
>
> > We need to continue to support both modes, as only Partitioned Regions
> can
> > make use of parallel export (it is parallelized on a bucket level).
> >
>
> Ok, so why not just make parallel the only mode for partitioned. Then you
> remove the need for --parallel and --path would work for any region,
> non-partitioned would create a single file at that path and partitioned
> would create several? I am all for less options. ;)
>
> -Jake
>

Re: Adding parallel import/export of snapshots to gfsh

[Dan Smith]

I don't really like the idea of adding a separate command. It really is the
same command - you just want to have the parallel flag interact with other
options. A separate command would be more confusing for users, and more of
a maintenance issue as we add more options to export.

Having a --path that could be a file or directory depending on whether your
export is parallel or serial also seems unintuitive.  Kirk's idea of
mutually exclusive options seems more reasonable. Or better yet, just add
--dir and make it work the same way for both serial and a parallel exports
- we generate a files and put them in that directory.

-Dan

On Tue, Aug 22, 2017 at 1:59 PM, Jacob Barrett  wrote:

> On Tue, Aug 22, 2017 at 1:49 PM Nick Reich  wrote:
>
> > The idea of deprecating —file in favor of path is interesting. I wonder
> if
> > instead of making them mutually exclusive to start, having —path be able
> to
> > support both modes from the start would be better? That way —file could
> > still be used for the existing mode, but —path could be used instead (and
> > override —file is both given?): that would provide a clear path forward
> for
> > how the command should be used, while fully supporting existing
> workflows.
> >
>
> This is what I meant by deprecating. Maybe even providing a message that if
> --file is set that it is deprecated for --path.
>
>
> > We need to continue to support both modes, as only Partitioned Regions
> can
> > make use of parallel export (it is parallelized on a bucket level).
> >
>
> Ok, so why not just make parallel the only mode for partitioned. Then you
> remove the need for --parallel and --path would work for any region,
> non-partitioned would create a single file at that path and partitioned
> would create several? I am all for less options. ;)
>
> -Jake
>

[GitHub] geode pull request #719: GEODE-3447 Implement client authorization for the n...

[bschuchardt]

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

https://github.com/apache/geode/pull/719#discussion_r134600589
  
--- Diff: 
geode-protobuf/src/main/java/org/apache/geode/protocol/protobuf/ProtobufSimpleAuthenticator.java
 ---
@@ -40,20 +42,28 @@ public void receiveMessage(InputStream inputStream, 
OutputStream outputStream,
 properties.setProperty("username", 
authenticationRequest.getUsername());
 properties.setProperty("password", 
authenticationRequest.getPassword());
 
+authorizer = null; // authenticating a new user clears current 
authorizer
 try {
   Object principal = securityManager.authenticate(properties);
-  authenticated = principal != null;
+  if (principal != null) {
+authorizer = new ProtobufSimpleAuthorizer(principal, 
securityManager);
+  }
 } catch (AuthenticationFailedException e) {
-  authenticated = false;
+  authorizer = null;
 }
 
-
AuthenticationAPI.SimpleAuthenticationResponse.newBuilder().setAuthenticated(authenticated)
+
AuthenticationAPI.SimpleAuthenticationResponse.newBuilder().setAuthenticated(isAuthenticated())
 .build().writeDelimitedTo(outputStream);
   }
 
   @Override
   public boolean isAuthenticated() {
-return authenticated;
+return authorizer != null;
--- End diff --

A authorizer IS only constructed BECAUSE something was authenticated.  
Therefore this is a valid implementation of isAuthenticated().


---
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: Adding parallel import/export of snapshots to gfsh

[Jacob Barrett]

On Tue, Aug 22, 2017 at 1:49 PM Nick Reich  wrote:

> The idea of deprecating —file in favor of path is interesting. I wonder if
> instead of making them mutually exclusive to start, having —path be able to
> support both modes from the start would be better? That way —file could
> still be used for the existing mode, but —path could be used instead (and
> override —file is both given?): that would provide a clear path forward for
> how the command should be used, while fully supporting existing workflows.
>

This is what I meant by deprecating. Maybe even providing a message that if
--file is set that it is deprecated for --path.


> We need to continue to support both modes, as only Partitioned Regions can
> make use of parallel export (it is parallelized on a bucket level).
>

Ok, so why not just make parallel the only mode for partitioned. Then you
remove the need for --parallel and --path would work for any region,
non-partitioned would create a single file at that path and partitioned
would create several? I am all for less options. ;)

-Jake

[GitHub] geode pull request #719: GEODE-3447 Implement client authorization for the n...

[bschuchardt]

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

https://github.com/apache/geode/pull/719#discussion_r134599066
  
--- Diff: 
geode-protobuf/src/main/java/org/apache/geode/protocol/protobuf/ProtobufSimpleAuthorizer.java
 ---
@@ -0,0 +1,42 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more 
contributor license
+ * agreements. See the NOTICE file distributed with this work for 
additional information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache 
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the 
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software 
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF 
ANY KIND, either express
+ * or implied. See the License for the specific language governing 
permissions and limitations under
+ * the License.
+ */
+package org.apache.geode.protocol.protobuf;
+
+import java.io.EOFException;
+import java.io.IOException;
+import java.io.InputStream;
+import java.io.OutputStream;
+import java.util.Properties;
+
+import org.apache.geode.security.AuthenticationFailedException;
+import org.apache.geode.security.ResourcePermission;
+import org.apache.geode.security.SecurityManager;
+import org.apache.geode.security.StreamAuthenticator;
+import org.apache.geode.security.StreamAuthorizer;
+
+public class ProtobufSimpleAuthorizer implements StreamAuthorizer {
+  private final Object authenticatedPrincipal;
+  private final SecurityManager securityManager;
+
+  public ProtobufSimpleAuthorizer(Object authenticatedPrincipal, 
SecurityManager securityManager) {
+this.authenticatedPrincipal = authenticatedPrincipal;
+this.securityManager = securityManager;
+  }
+
+  @Override
+  public boolean authorize(ResourcePermission permissionRequested) {
--- End diff --

I'd rather not have other code deal with the Principal.  Other 
implementations may not have a Principal.  I.e., a no-op implementation.


---
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 61816: GEODE-3409 Protobuf Client Can't Connect Once Connection Limit Has Been Reached, Even After Connections Closed

[Udo Kohlmeyer]

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


Ship it!




Ship It!

- Udo Kohlmeyer


On Aug. 22, 2017, 5:16 p.m., Bruce Schuchardt wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/61816/
> ---
> 
> (Updated Aug. 22, 2017, 5:16 p.m.)
> 
> 
> Review request for geode, Alexander Murmann, Galen O'Sullivan, Hitesh 
> Khamesra, Udo Kohlmeyer, and Brian Rowe.
> 
> 
> Bugs: GEODE-3409
> https://issues.apache.org/jira/browse/GEODE-3409
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> ServerConnection cleanup was not decrementing the Acceptor's client 
> connection count when the protobuf communications mode was in effect.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/ClientHealthMonitor.java
>  35cc33f 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/ServerConnection.java
>  394d261 
>   
> geode-protobuf/src/test/java/org/apache/geode/protocol/RoundTripCacheConnectionJUnitTest.java
>  12cc08b 
> 
> 
> Diff: https://reviews.apache.org/r/61816/diff/1/
> 
> 
> Testing
> ---
> 
> new integration test
> 
> 
> Thanks,
> 
> Bruce Schuchardt
> 
>

Re: Adding parallel import/export of snapshots to gfsh

[Nick Reich]

I thought about a mutually exclusive —file and —dir, but in that case, -—file
is required for standard and —path required for parallel export, which I
think could be better than overloading —file, but still has potential for
confusion.

The idea of deprecating —file in favor of path is interesting. I wonder if
instead of making them mutually exclusive to start, having —path be able to
support both modes from the start would be better? That way —file could
still be used for the existing mode, but —path could be used instead (and
override —file is both given?): that would provide a clear path forward for
how the command should be used, while fully supporting existing workflows.


We need to continue to support both modes, as only Partitioned Regions can
make use of parallel export (it is parallelized on a bucket level).

On Tue, Aug 22, 2017 at 12:55 PM, Jacob Barrett  wrote:

> How about deprecate —file and replace with —path? In the transition make
> them mutually exclusive and —path required for —parallel.
>
> Any reason to not just make all export parallel rather than supporting two
> different modes?
>
> -Jake
>
>
> Sent from my iPhone
>
> > On Aug 22, 2017, at 12:27 PM, Kenneth Howe  wrote:
> >
> > I agrees that overloading the “file” option seems like a bad idea. As an
> alternative to separate commands, what about mutually exclusive options,
> ‘—file’ and ‘—dir’?
> >
> > If you go for implementing the new functionality as a separate command,
> I would suggest calling the gfsh commands: “export data-parallel” and
> “import data-parallel"
> >
> >> On Aug 22, 2017, at 11:32 AM, Nick Reich  wrote:
> >>
> >> Team,
> >>
> >> I am working on exposing the parallel export/import of snapshots through
> >> gfsh and would appreciate input on the best approach to adding to /
> >> updating the existing interface.
> >>
> >> Currently, ExportDataCommand and ImportDataCommand take a region name, a
> >> member to run the command on, and a file location (that must end in
> .gfd).
> >> Parallel import and export require a directory location instead of a
> single
> >> file name (as there can be multiple files and need for uniquely named
> >> files). It is possible to add a parallel flag and have the meaning of
> the
> >> "file" parameter be different depending on that flag, but that seems
> overly
> >> confusing to me. I am instead leaning towards creating new commands
> (e.g.
> >> ParallelExportDataCommand) that has a "directory" parameter to replace
> >> "file", but is otherwise identical in usage to the existing commands.
> >>
> >> Do others have different views or approaches to suggest?
> >
>

Re: Gitbox enables the full GitHub workflow

[Udo Kohlmeyer]

+1 to migrate :)


On 8/22/17 10:43, Anthony Baker wrote:

On Aug 7, 2017, at 6:09 PM, Roman Shaposhnik  wrote:

Hi!

it has just come to my attention that Gitbox at ASF
has been enabling full GitHub workflow (with being
able to click Merge this PR button, etc.) for quite
some time.

This basically allows a project to have GH as a R/W
repo as opposed to R/O mirror of what we all currnently
have: https://gitbox.apache.org/repos/asf

Personally I'm not sure I like GH workflow all that much,
but if there's interest -- you can opt-in into Gitbox. Once
you do -- your source of truth moves to GH. You can't
have it both ways with git-wip-us.apache.org and Gitbox.

Thanks,
Roman.

Now that we’ve got some experience with gitbox on geode-native, are we ready to 
convert the other repos?

- geode
- geode-site
- geode-examples

I think we should.

Anthony

[GitHub] geode issue #730: GEODE-3472: Remove a great deal of commented-out code.

[PurelyApplied]

Github user PurelyApplied commented on the issue:

https://github.com/apache/geode/pull/730
  
Precheckin green after merge with 
`be4551191a17b9f50169f375798785ab5373e975`.  Subsequently rebased again with 
minor merge conflict resolved.


---
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: Gitbox enables the full GitHub workflow

[Ernest Burghardt]

+1

On Tue, Aug 22, 2017 at 12:28 PM, Joey McAllister 
wrote:

> +1
>
> On Tue, Aug 22, 2017 at 11:28 AM Ken Howe  wrote:
>
> > +1 Yes, let’s make the move
> >
> > > On Aug 22, 2017, at 11:21 AM, Nabarun Nag  wrote:
> > >
> > > +1
> > >
> > > On Tue, Aug 22, 2017 at 11:15 AM Kirk Lund  wrote:
> > >
> > >> +1 to move all our repos to gitbox
> > >>
> > >> On Tue, Aug 22, 2017 at 11:08 AM, Jacob Barrett 
> > >> wrote:
> > >>
> > >>> +1
> > >>>
> > >>> Sent from my iPhone
> > >>>
> >  On Aug 22, 2017, at 10:49 AM, Jared Stewart 
> > >> wrote:
> > 
> >  +1 for moving the other repos to Gitbox
> > 
> >  On Aug 22, 2017 10:43 AM, "Anthony Baker" 
> wrote:
> > 
> > 
> > > On Aug 7, 2017, at 6:09 PM, Roman Shaposhnik  >
> > >>> wrote:
> > >
> > > Hi!
> > >
> > > it has just come to my attention that Gitbox at ASF
> > > has been enabling full GitHub workflow (with being
> > > able to click Merge this PR button, etc.) for quite
> > > some time.
> > >
> > > This basically allows a project to have GH as a R/W
> > > repo as opposed to R/O mirror of what we all currnently
> > > have: https://gitbox.apache.org/repos/asf
> > >
> > > Personally I'm not sure I like GH workflow all that much,
> > > but if there's interest -- you can opt-in into Gitbox. Once
> > > you do -- your source of truth moves to GH. You can't
> > > have it both ways with git-wip-us.apache.org and Gitbox.
> > >
> > > Thanks,
> > > Roman.
> > 
> >  Now that we’ve got some experience with gitbox on geode-native, are
> we
> >  ready to convert the other repos?
> > 
> >  - geode
> >  - geode-site
> >  - geode-examples
> > 
> >  I think we should.
> > 
> >  Anthony
> > >>>
> > >>
> >
> >
>

Re: Adding parallel import/export of snapshots to gfsh

[Jacob Barrett]

How about deprecate —file and replace with —path? In the transition make them 
mutually exclusive and —path required for —parallel. 

Any reason to not just make all export parallel rather than supporting two 
different modes?

-Jake


Sent from my iPhone

> On Aug 22, 2017, at 12:27 PM, Kenneth Howe  wrote:
> 
> I agrees that overloading the “file” option seems like a bad idea. As an 
> alternative to separate commands, what about mutually exclusive options, 
> ‘—file’ and ‘—dir’?
> 
> If you go for implementing the new functionality as a separate command, I 
> would suggest calling the gfsh commands: “export data-parallel” and “import 
> data-parallel"
> 
>> On Aug 22, 2017, at 11:32 AM, Nick Reich  wrote:
>> 
>> Team,
>> 
>> I am working on exposing the parallel export/import of snapshots through
>> gfsh and would appreciate input on the best approach to adding to /
>> updating the existing interface.
>> 
>> Currently, ExportDataCommand and ImportDataCommand take a region name, a
>> member to run the command on, and a file location (that must end in .gfd).
>> Parallel import and export require a directory location instead of a single
>> file name (as there can be multiple files and need for uniquely named
>> files). It is possible to add a parallel flag and have the meaning of the
>> "file" parameter be different depending on that flag, but that seems overly
>> confusing to me. I am instead leaning towards creating new commands (e.g.
>> ParallelExportDataCommand) that has a "directory" parameter to replace
>> "file", but is otherwise identical in usage to the existing commands.
>> 
>> Do others have different views or approaches to suggest?
> 

Re: Review Request 61722: GEODE-3047 Atomic creation flag is not set if the region is recoverd from the disk.

[Darrel Schneider]

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


Ship it!




Ship It!

- Darrel Schneider


On Aug. 18, 2017, 9:58 a.m., anilkumar gingade wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/61722/
> ---
> 
> (Updated Aug. 18, 2017, 9:58 a.m.)
> 
> 
> Review request for geode, Darrel Schneider, Eric Shu, Lynn Gallinat, and Nick 
> Reich.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> While creating bucket region, to satisfy the redudndancy copies the bucket 
> regions
> are created on all available nodes. The initialization (setting 
> persistentIDs) of
> these buckets are done after creating buckets on all the nodes. This 
> introduced
> a race condition for the bucket region which are recovered from the disk to
> exchange thier old id with the peer node resulting in 
> ConflictingPersistentData
> Exception.
> 
> The changes are done so that the regions persistent ids are set as soon as 
> they
> are created/initialized.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/BucketPersistenceAdvisor.java
>  367bb75e9 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/BucketPersistenceAdvisorTest.java
>  PRE-CREATION 
> 
> 
> Diff: https://reviews.apache.org/r/61722/diff/1/
> 
> 
> Testing
> ---
> 
> added new unit test.
> run PartitionedRegionSingleHopDUnitTest.testClientMetadataForPersistentPrs 
> 1400 times
> 
> 
> Thanks,
> 
> anilkumar gingade
> 
>

Re: Adding parallel import/export of snapshots to gfsh

[Kenneth Howe]

I agrees that overloading the “file” option seems like a bad idea. As an 
alternative to separate commands, what about mutually exclusive options, 
‘—file’ and ‘—dir’?

If you go for implementing the new functionality as a separate command, I would 
suggest calling the gfsh commands: “export data-parallel” and “import 
data-parallel"

> On Aug 22, 2017, at 11:32 AM, Nick Reich  wrote:
> 
> Team,
> 
> I am working on exposing the parallel export/import of snapshots through
> gfsh and would appreciate input on the best approach to adding to /
> updating the existing interface.
> 
> Currently, ExportDataCommand and ImportDataCommand take a region name, a
> member to run the command on, and a file location (that must end in .gfd).
> Parallel import and export require a directory location instead of a single
> file name (as there can be multiple files and need for uniquely named
> files). It is possible to add a parallel flag and have the meaning of the
> "file" parameter be different depending on that flag, but that seems overly
> confusing to me. I am instead leaning towards creating new commands (e.g.
> ParallelExportDataCommand) that has a "directory" parameter to replace
> "file", but is otherwise identical in usage to the existing commands.
> 
> Do others have different views or approaches to suggest?

Re: Native commit messages going to dev instead of commit list

[Mark Bretl]

Hey Jake,

Sorry I missed your ticket last week, my ticket has been completed and the
commits should now be going to commits@geode and notifications should be
going to dev@geode. I set my issue Type to GitBox Request and got though
the queue fairly quickly.

I don't know the GitBox configuration well enough to know what permissions
we can have. I would email the INFRA list or contact them on HipChat, as
the documentation is still lacking for the GitBox workflow setup.

--Mark

On Mon, Aug 21, 2017 at 6:42 PM, Jacob Barrett  wrote:

> Mark,
>
> I opened https://issues.apache.org/jira/browse/INFRA-14900 last week.
>
> Do you know if we can get permissions to edit repo settings ourselves? I’d
> like to change the description so it doesn’t say mirror. Hate interrupting
> infra for every minor change we may have along the way.
>
> Thanks,
> Jake
>
>
> Sent from my iPhone
>
> > On Aug 21, 2017, at 5:56 PM, Mark Bretl  wrote:
> >
> > Oops...that was my copy-paste error on the request. I have opened a new
> > ticket to update the commit mail,
> > https://issues.apache.org/jira/browse/INFRA-14924.
> >
> > --Mark
> >
> >> On Thu, Aug 17, 2017 at 1:43 PM, Dan Smith  wrote:
> >>
> >> Was: Re: [geode-native] branch develop updated: GEODE-3455: Update
> Solaris
> >> build images.
> >>
> >> Probably need to file an infra ticket. I'm guessing this was caused by
> the
> >> gitbox migration.
> >>
> >> On Thu, Aug 17, 2017 at 1:40 PM, Jacob Barrett 
> >> wrote:
> >>
> >>> I wonder if the native repo wasn't reconfigured when the main repo was.
> >> It
> >>> is not something I can change even though we are not a mirror site.
> >>>
> >>>
> >>> Mark, do you have karma to change this?
> >>>
> >>> -Jake
> >>>
> >>>
>  On Thu, Aug 17, 2017 at 11:25 AM Dan Smith  wrote:
> 
>  I think these messages should be going to commits@geode?
> 
> > On Thu, Aug 17, 2017 at 11:15 AM,  wrote:
> >
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > jbarrett pushed a commit to branch develop
> > in repository https://gitbox.apache.org/repos/asf/geode-native.git
> >
> >
> > The following commit(s) were added to refs/heads/develop by this
> >> push:
> > new 0fba5ce  GEODE-3455: Update Solaris build images.
> > 0fba5ce is described below
> >
> > commit 0fba5cee59d5d53eaab6cc9396eab45df4b8d79c
> > Author: Jacob Barrett 
> > AuthorDate: Wed Aug 2 12:32:34 2017 -0700
> >
> >GEODE-3455: Update Solaris build images.
> >
> > - Fixes Solaris SPARC image.
> > - Addes developer images.
> > ---
> > packer/build-solaris-sparc.json | 10 +
> > packer/build-solaris-x86.json   |  7 +++---
> > packer/dev-solaris-sparc.json   | 38
> > +
> > packer/dev-solaris-x86.json | 38
> > +
> > packer/solaris/install-cmake.sh |  8 ---
> > packer/solaris/install-solarisstudio.sh |  1 -
> > 6 files changed, 91 insertions(+), 11 deletions(-)
> >
> > diff --git a/packer/build-solaris-sparc.json
>  b/packer/build-solaris-sparc.
> > json
> > index 34aea96..0ce5eec 100644
> > --- a/packer/build-solaris-sparc.json
> > +++ b/packer/build-solaris-sparc.json
> > @@ -1,8 +1,9 @@
> > {
> >   "variables":{
> > "image_name":"build-solaris-sparc",
> > -"openstack_source_image":"7e1e66f1-8256-4e29-a314-
> >> ee7f54b2f720",
> > -"vmware_source_image_name":"X.vmx",
> > +"openstack_source_image":"",
> > +"openstack_flavor":"Oracle Solaris non-global zone - tiny",
> > +"vmware_source_image_name":"",
> > "gemfire_archive":"gemfire.tar.gz",
> > "pkg_oracle_com_certificate":"pkg.oracle.com.certificate.pem",
> > "pkg_oracle_com_key":"pkg.oracle.com.key.pem"
> > @@ -18,7 +19,7 @@
> >   "ssh_username":"root",
> >   "image_name":"native-{{user `version`}}-{{user `image_name`}}
> > {{timestamp}}",
> >   "source_image":"{{user `openstack_source_image`}}",
> > -  "flavor":"Oracle Solaris non-global zone - tiny",
> > +  "flavor":"{{user `openstack_flavor`}}",
> >   "insecure":"true"
> > }
> >   ],
> > @@ -38,7 +39,8 @@
> >   "scripts":[
> > "solaris/install-opencsw.sh",
> > "solaris/install-build-tools.sh",
> > -"solaris/install-solarisstudio.sh"
> > +"solaris/install-solarisstudio.sh",
> > +"solaris/install-cmake.sh"
> >   ]
> > },
> > {
> > diff --git a/packer/build-solaris-x86.json
>  b/packer/build-solaris-x86.json
> > index b01519e..6a55c82 100644
> > --- 

Adding parallel import/export of snapshots to gfsh

[Nick Reich]

Team,

I am working on exposing the parallel export/import of snapshots through
gfsh and would appreciate input on the best approach to adding to /
updating the existing interface.

Currently, ExportDataCommand and ImportDataCommand take a region name, a
member to run the command on, and a file location (that must end in .gfd).
Parallel import and export require a directory location instead of a single
file name (as there can be multiple files and need for uniquely named
files). It is possible to add a parallel flag and have the meaning of the
"file" parameter be different depending on that flag, but that seems overly
confusing to me. I am instead leaning towards creating new commands (e.g.
ParallelExportDataCommand) that has a "directory" parameter to replace
"file", but is otherwise identical in usage to the existing commands.

Do others have different views or approaches to suggest?

Re: Gitbox enables the full GitHub workflow

[Joey McAllister]

+1

On Tue, Aug 22, 2017 at 11:28 AM Ken Howe  wrote:

> +1 Yes, let’s make the move
>
> > On Aug 22, 2017, at 11:21 AM, Nabarun Nag  wrote:
> >
> > +1
> >
> > On Tue, Aug 22, 2017 at 11:15 AM Kirk Lund  wrote:
> >
> >> +1 to move all our repos to gitbox
> >>
> >> On Tue, Aug 22, 2017 at 11:08 AM, Jacob Barrett 
> >> wrote:
> >>
> >>> +1
> >>>
> >>> Sent from my iPhone
> >>>
>  On Aug 22, 2017, at 10:49 AM, Jared Stewart 
> >> wrote:
> 
>  +1 for moving the other repos to Gitbox
> 
>  On Aug 22, 2017 10:43 AM, "Anthony Baker"  wrote:
> 
> 
> > On Aug 7, 2017, at 6:09 PM, Roman Shaposhnik 
> >>> wrote:
> >
> > Hi!
> >
> > it has just come to my attention that Gitbox at ASF
> > has been enabling full GitHub workflow (with being
> > able to click Merge this PR button, etc.) for quite
> > some time.
> >
> > This basically allows a project to have GH as a R/W
> > repo as opposed to R/O mirror of what we all currnently
> > have: https://gitbox.apache.org/repos/asf
> >
> > Personally I'm not sure I like GH workflow all that much,
> > but if there's interest -- you can opt-in into Gitbox. Once
> > you do -- your source of truth moves to GH. You can't
> > have it both ways with git-wip-us.apache.org and Gitbox.
> >
> > Thanks,
> > Roman.
> 
>  Now that we’ve got some experience with gitbox on geode-native, are we
>  ready to convert the other repos?
> 
>  - geode
>  - geode-site
>  - geode-examples
> 
>  I think we should.
> 
>  Anthony
> >>>
> >>
>
>

Re: Gitbox enables the full GitHub workflow

[Ken Howe]

+1 Yes, let’s make the move

> On Aug 22, 2017, at 11:21 AM, Nabarun Nag  wrote:
> 
> +1
> 
> On Tue, Aug 22, 2017 at 11:15 AM Kirk Lund  wrote:
> 
>> +1 to move all our repos to gitbox
>> 
>> On Tue, Aug 22, 2017 at 11:08 AM, Jacob Barrett 
>> wrote:
>> 
>>> +1
>>> 
>>> Sent from my iPhone
>>> 
 On Aug 22, 2017, at 10:49 AM, Jared Stewart 
>> wrote:
 
 +1 for moving the other repos to Gitbox
 
 On Aug 22, 2017 10:43 AM, "Anthony Baker"  wrote:
 
 
> On Aug 7, 2017, at 6:09 PM, Roman Shaposhnik 
>>> wrote:
> 
> Hi!
> 
> it has just come to my attention that Gitbox at ASF
> has been enabling full GitHub workflow (with being
> able to click Merge this PR button, etc.) for quite
> some time.
> 
> This basically allows a project to have GH as a R/W
> repo as opposed to R/O mirror of what we all currnently
> have: https://gitbox.apache.org/repos/asf
> 
> Personally I'm not sure I like GH workflow all that much,
> but if there's interest -- you can opt-in into Gitbox. Once
> you do -- your source of truth moves to GH. You can't
> have it both ways with git-wip-us.apache.org and Gitbox.
> 
> Thanks,
> Roman.
 
 Now that we’ve got some experience with gitbox on geode-native, are we
 ready to convert the other repos?
 
 - geode
 - geode-site
 - geode-examples
 
 I think we should.
 
 Anthony
>>> 
>> 

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

[Ken Howe]

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

(Updated Aug. 22, 2017, 6:26 p.m.)


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


Changes
---

Refactored ```LocatorLauncher.LocatorState``` constructor as suggested, 
removing nested ternary expressions.


Repository: geode


Description (updated)
---

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

Minor spelling corrections.


Diffs (updated)
-

  
geode-assembly/src/test/java/org/apache/geode/management/internal/cli/commands/StatusLocatorRealGfshTest.java
 3a98373938e3de21da6badcf460dae3648218ac6 
  geode-core/src/main/java/org/apache/geode/distributed/LocatorLauncher.java 
83c1ab533e3dea323a8a99f7002b9464a54dfc25 
  geode-core/src/main/java/org/apache/geode/distributed/ServerLauncher.java 
ae64691605130c9b212a3a33bb65ae37b28af02b 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/lifecycle/GfshStatusCommandsIntegrationTest.java
 dd5841f4cffca38da07a11f381cf4174d7264349 
  
geode-core/src/test/java/org/apache/geode/test/dunit/rules/GfshShellConnectionRule.java
 e7f17ef208a1708f385c7c4041affb70fd309a4c 


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

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


Testing (updated)
---

Re-running precheckin


Thanks,

Ken Howe

Re: Gitbox enables the full GitHub workflow

[Nabarun Nag]

+1

On Tue, Aug 22, 2017 at 11:15 AM Kirk Lund  wrote:

> +1 to move all our repos to gitbox
>
> On Tue, Aug 22, 2017 at 11:08 AM, Jacob Barrett 
> wrote:
>
> > +1
> >
> > Sent from my iPhone
> >
> > > On Aug 22, 2017, at 10:49 AM, Jared Stewart 
> wrote:
> > >
> > > +1 for moving the other repos to Gitbox
> > >
> > > On Aug 22, 2017 10:43 AM, "Anthony Baker"  wrote:
> > >
> > >
> > >> On Aug 7, 2017, at 6:09 PM, Roman Shaposhnik 
> > wrote:
> > >>
> > >> Hi!
> > >>
> > >> it has just come to my attention that Gitbox at ASF
> > >> has been enabling full GitHub workflow (with being
> > >> able to click Merge this PR button, etc.) for quite
> > >> some time.
> > >>
> > >> This basically allows a project to have GH as a R/W
> > >> repo as opposed to R/O mirror of what we all currnently
> > >> have: https://gitbox.apache.org/repos/asf
> > >>
> > >> Personally I'm not sure I like GH workflow all that much,
> > >> but if there's interest -- you can opt-in into Gitbox. Once
> > >> you do -- your source of truth moves to GH. You can't
> > >> have it both ways with git-wip-us.apache.org and Gitbox.
> > >>
> > >> Thanks,
> > >> Roman.
> > >
> > > Now that we’ve got some experience with gitbox on geode-native, are we
> > > ready to convert the other repos?
> > >
> > > - geode
> > > - geode-site
> > > - geode-examples
> > >
> > > I think we should.
> > >
> > > Anthony
> >
>

Re: Gitbox enables the full GitHub workflow

[Kirk Lund]

+1 to move all our repos to gitbox

On Tue, Aug 22, 2017 at 11:08 AM, Jacob Barrett  wrote:

> +1
>
> Sent from my iPhone
>
> > On Aug 22, 2017, at 10:49 AM, Jared Stewart  wrote:
> >
> > +1 for moving the other repos to Gitbox
> >
> > On Aug 22, 2017 10:43 AM, "Anthony Baker"  wrote:
> >
> >
> >> On Aug 7, 2017, at 6:09 PM, Roman Shaposhnik 
> wrote:
> >>
> >> Hi!
> >>
> >> it has just come to my attention that Gitbox at ASF
> >> has been enabling full GitHub workflow (with being
> >> able to click Merge this PR button, etc.) for quite
> >> some time.
> >>
> >> This basically allows a project to have GH as a R/W
> >> repo as opposed to R/O mirror of what we all currnently
> >> have: https://gitbox.apache.org/repos/asf
> >>
> >> Personally I'm not sure I like GH workflow all that much,
> >> but if there's interest -- you can opt-in into Gitbox. Once
> >> you do -- your source of truth moves to GH. You can't
> >> have it both ways with git-wip-us.apache.org and Gitbox.
> >>
> >> Thanks,
> >> Roman.
> >
> > Now that we’ve got some experience with gitbox on geode-native, are we
> > ready to convert the other repos?
> >
> > - geode
> > - geode-site
> > - geode-examples
> >
> > I think we should.
> >
> > Anthony
>

Re: Tombstones

[Dan Smith]

I believe tombstones are not included in those operations, so you won't see
them.

-Dan

On Tue, Aug 22, 2017 at 10:56 AM, Michael Stolz  wrote:

> Do tombstones show up in operations that indicate presence of keys like
> Region.keyset(), containsKey(key), etc?
> They probably shouldn't.
>
> --
> Mike Stolz
> Principal Engineer, GemFire Product Manager
> Mobile: +1-631-835-4771
>

Re: Gitbox enables the full GitHub workflow

[Jacob Barrett]

+1

Sent from my iPhone

> On Aug 22, 2017, at 10:49 AM, Jared Stewart  wrote:
> 
> +1 for moving the other repos to Gitbox
> 
> On Aug 22, 2017 10:43 AM, "Anthony Baker"  wrote:
> 
> 
>> On Aug 7, 2017, at 6:09 PM, Roman Shaposhnik  wrote:
>> 
>> Hi!
>> 
>> it has just come to my attention that Gitbox at ASF
>> has been enabling full GitHub workflow (with being
>> able to click Merge this PR button, etc.) for quite
>> some time.
>> 
>> This basically allows a project to have GH as a R/W
>> repo as opposed to R/O mirror of what we all currnently
>> have: https://gitbox.apache.org/repos/asf
>> 
>> Personally I'm not sure I like GH workflow all that much,
>> but if there's interest -- you can opt-in into Gitbox. Once
>> you do -- your source of truth moves to GH. You can't
>> have it both ways with git-wip-us.apache.org and Gitbox.
>> 
>> Thanks,
>> Roman.
> 
> Now that we’ve got some experience with gitbox on geode-native, are we
> ready to convert the other repos?
> 
> - geode
> - geode-site
> - geode-examples
> 
> I think we should.
> 
> Anthony

Re: Gitbox enables the full GitHub workflow

[Dan Smith]

+1 - Let's do it!

-Dan

On Tue, Aug 22, 2017 at 10:58 AM, Dave Barnes  wrote:

> +1
> I'm interested to see how it works for geode-site, which has a sorta quirky
> build/branch structure.
>
> On Tue, Aug 22, 2017 at 10:49 AM, Jared Stewart 
> wrote:
>
> > +1 for moving the other repos to Gitbox
> >
> > On Aug 22, 2017 10:43 AM, "Anthony Baker"  wrote:
> >
> >
> > > On Aug 7, 2017, at 6:09 PM, Roman Shaposhnik 
> > wrote:
> > >
> > > Hi!
> > >
> > > it has just come to my attention that Gitbox at ASF
> > > has been enabling full GitHub workflow (with being
> > > able to click Merge this PR button, etc.) for quite
> > > some time.
> > >
> > > This basically allows a project to have GH as a R/W
> > > repo as opposed to R/O mirror of what we all currnently
> > > have: https://gitbox.apache.org/repos/asf
> > >
> > > Personally I'm not sure I like GH workflow all that much,
> > > but if there's interest -- you can opt-in into Gitbox. Once
> > > you do -- your source of truth moves to GH. You can't
> > > have it both ways with git-wip-us.apache.org and Gitbox.
> > >
> > > Thanks,
> > > Roman.
> >
> > Now that we’ve got some experience with gitbox on geode-native, are we
> > ready to convert the other repos?
> >
> > - geode
> > - geode-site
> > - geode-examples
> >
> > I think we should.
> >
> > Anthony
> >
>

Re: Gitbox enables the full GitHub workflow

[Dave Barnes]

+1
I'm interested to see how it works for geode-site, which has a sorta quirky
build/branch structure.

On Tue, Aug 22, 2017 at 10:49 AM, Jared Stewart  wrote:

> +1 for moving the other repos to Gitbox
>
> On Aug 22, 2017 10:43 AM, "Anthony Baker"  wrote:
>
>
> > On Aug 7, 2017, at 6:09 PM, Roman Shaposhnik 
> wrote:
> >
> > Hi!
> >
> > it has just come to my attention that Gitbox at ASF
> > has been enabling full GitHub workflow (with being
> > able to click Merge this PR button, etc.) for quite
> > some time.
> >
> > This basically allows a project to have GH as a R/W
> > repo as opposed to R/O mirror of what we all currnently
> > have: https://gitbox.apache.org/repos/asf
> >
> > Personally I'm not sure I like GH workflow all that much,
> > but if there's interest -- you can opt-in into Gitbox. Once
> > you do -- your source of truth moves to GH. You can't
> > have it both ways with git-wip-us.apache.org and Gitbox.
> >
> > Thanks,
> > Roman.
>
> Now that we’ve got some experience with gitbox on geode-native, are we
> ready to convert the other repos?
>
> - geode
> - geode-site
> - geode-examples
>
> I think we should.
>
> Anthony
>

Tombstones

[Michael Stolz]

Do tombstones show up in operations that indicate presence of keys like
Region.keyset(), containsKey(key), etc?
They probably shouldn't.

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

Re: Gitbox enables the full GitHub workflow

[Jared Stewart]

+1 for moving the other repos to Gitbox

On Aug 22, 2017 10:43 AM, "Anthony Baker"  wrote:


> On Aug 7, 2017, at 6:09 PM, Roman Shaposhnik  wrote:
>
> Hi!
>
> it has just come to my attention that Gitbox at ASF
> has been enabling full GitHub workflow (with being
> able to click Merge this PR button, etc.) for quite
> some time.
>
> This basically allows a project to have GH as a R/W
> repo as opposed to R/O mirror of what we all currnently
> have: https://gitbox.apache.org/repos/asf
>
> Personally I'm not sure I like GH workflow all that much,
> but if there's interest -- you can opt-in into Gitbox. Once
> you do -- your source of truth moves to GH. You can't
> have it both ways with git-wip-us.apache.org and Gitbox.
>
> Thanks,
> Roman.

Now that we’ve got some experience with gitbox on geode-native, are we
ready to convert the other repos?

- geode
- geode-site
- geode-examples

I think we should.

Anthony

Re: Gitbox enables the full GitHub workflow

[Anthony Baker]

> On Aug 7, 2017, at 6:09 PM, Roman Shaposhnik  wrote:
> 
> Hi!
> 
> it has just come to my attention that Gitbox at ASF
> has been enabling full GitHub workflow (with being
> able to click Merge this PR button, etc.) for quite
> some time.
> 
> This basically allows a project to have GH as a R/W
> repo as opposed to R/O mirror of what we all currnently
> have: https://gitbox.apache.org/repos/asf
> 
> Personally I'm not sure I like GH workflow all that much,
> but if there's interest -- you can opt-in into Gitbox. Once
> you do -- your source of truth moves to GH. You can't
> have it both ways with git-wip-us.apache.org and Gitbox.
> 
> Thanks,
> Roman.

Now that we’ve got some experience with gitbox on geode-native, are we ready to 
convert the other repos?

- geode
- geode-site
- geode-examples

I think we should.

Anthony

Review Request 61816: GEODE-3409 Protobuf Client Can't Connect Once Connection Limit Has Been Reached, Even After Connections Closed

[Bruce Schuchardt]

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

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


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


Repository: geode


Description
---

ServerConnection cleanup was not decrementing the Acceptor's client connection 
count when the protobuf communications mode was in effect.


Diffs
-

  
geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/ClientHealthMonitor.java
 35cc33f 
  
geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/ServerConnection.java
 394d261 
  
geode-protobuf/src/test/java/org/apache/geode/protocol/RoundTripCacheConnectionJUnitTest.java
 12cc08b 


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


Testing
---

new integration test


Thanks,

Bruce Schuchardt

Re: [Discuss] FunctionStats over the JMX [GEODE-3462]

[Kirk Lund]

Hi Dinesh,

Check out this project by Charlie Black:
https://github.com/charliemblack/geode-exposing-metrics-via-JMX

We currently have no plans to introduce out-of-the box Geode MXBeans for
every Function or for all stats. When you combine this with federating of
MBeans to the JMX Manager(s), it puts too much overhead on the cluster and
severely impacts performance. It can also result in StatSampler pauses and
GC problems. This was a big part of the problem with the old
pre-GemFire-7.0 JMX (com.gemstone.gemfire.admin) that lead us to
deprecating and replacing it with the current Geode MXBeans
(org.apache.geode.management).

Users of Geode already have the ability to craft their own MBeans which can
be federated using the ManagementService API. See
org.apache.geode.management.ManagementService. Unfortunately, we don't yet
have an example for this -- it's a bit more involved than Charlie's project
and would probably involve using the (currently internal-only) Statistics
Monitoring API.

We do plan to move or mirror part of the Statistics Monitoring API
from org.apache.geode.internal.statistics to a User API
(org.apache.geode.statistics) which would make it easier to use the stat
sampler for updating custom MBeans with stat values. In addition, we plan
to provide statistic categories (basic, expert, advanced) and make more
improvements to allow definition of monitors for statistics types before
statistics instances are actually created. There is an important trade-off
between monitoring and performance that needs to be carefully considered
with any usage of the Statistics Monitoring API.

The statistics that are currently exposed on Geode MXBeans fall into two
categories: the most important stats which we believe are vital in all use
cases of monitoring Geode are exposed as JMX *attributes* on corresponding
MXBeans such as RegionMXBean, DiskStoreMXBean. Additional stats which are
very important but maybe not as important are grouped together as *Metrics
open data types and accessible by a JMX *operation* such as
MemberMXBean#showJVMMetrics, MemberMXBean#showOSMetrics,
DistributedSystemMXBean#showDiskMetrics. This allows us to expose a larger
number of stats but only by active request (invoking the operation). If we
actually exposed all of these stats as attributes instead of grouped
together as the result of an operation then again, the impact on
performance is too great.

Geode also has aggregate MXBeans which represent the entire cluster such
as DistributedSystemMXBean and DistributedRegionMXBean. These provide
cluster-wide aggregate attributes and operations. There are show*Metrics
operations exposed at this level as well which aggregate stat values across
the entire cluster.

I do think it would be reasonable to add a new FunctionMetrics open data
type and a corresponding showFunctionMetrics operation to one of the
MXBeans (probably the MemberMXBean). That would give the user a view of
Function stats for that one member. It might also make sense to add
showFunctionMetrics operation to DistributedSystemMXBean to provide an
aggregate view of the function stats for the entire cluster.

If you need to expose the function stats as attributes which are constantly
updated instead of using a showFunctionMetrics operation then I think your
best approach may be to use custom MBeans such as described in Charlie
Black's project or try out using the ManagementService APIs for registering
MBeans.

On Mon, Aug 21, 2017 at 4:12 AM, Dinesh Akhand  wrote:

> Hi Team,
>
> We are looking for implementing the function stats over JMX.
> Currently Function Stats are not part of JMX. We can't see them on JMX
> server.
> Can you please assist what is the correct way to implementing it.
>
> We have many function  which are instanceOf  FunctionAdapter.
> We want to monitor their stats on JMX server . can you please assist.
>
> But we having lots of user created function . for monitoring the few
> critical functions, we want then as per configuration based.
>
>
> GEODE-3462. https://github.com/apache/geode/pull/720
>
> 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 <
> https://www.amdocs.com/about/email-disclaimer>
>

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

[Jared Stewart]

> On Aug. 17, 2017, 5:35 p.m., Jared Stewart wrote:
> > geode-core/src/main/java/org/apache/geode/distributed/LocatorLauncher.java
> > Lines 2017 (patched)
> > 
> >
> > I think this double-ternary might be easier to read if we split it up 
> > into a few separate statements.
> 
> Ken Howe wrote:
> Agree with you that the double ternary sin't the most readable construct. 
> However, I ended up using it because the `this()` call has to be the first 
> statement in the constructor. The conditionals guard against NPEs from the 
> possible locations where this error constructor is called.
> 
> I'm open to other refactoring suggestions to make this easier to 
> understand.

I would suggest this sort of pattern: 

```
public LocatorState(final LocatorLauncher launcher, final Status status,
final String errorMessage) {
  this(status, // status
  errorMessage, // statusMessage
  System.currentTimeMillis(), // timestamp
  getLocatorLocation(launcher),
  null, // pid
  0L, // uptime
  launcher.getWorkingDirectory(), // workingDirectory
  ManagementFactory.getRuntimeMXBean().getInputArguments(), // 
jvmArguments
  null, // classpath
  GemFireVersion.getGemFireVersion(), // gemfireVersion
  System.getProperty("java.version"), // javaVersion
  null, // logFile
  launcher.getBindAddressAsString(), // host
  launcher.getPortAsString(), // port
  null);// memberName
}

private static String getLocatorLocation(LocatorLauncher launcher) {
  return launcher.getPort() == null ? launcher.getId()
  : HostUtils.getLocatorId((launcher.getBindAddress() == null)
  ? HostUtils.getLocalHost() : 
launcher.getBindAddress().getCanonicalHostName(),
  launcher.getPort());
}
```

where then you can split up them implementation of `getLocatorLocation` into 
several separate lines.


- Jared


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


On Aug. 16, 2017, 9:21 p.m., Ken Howe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/61701/
> ---
> 
> (Updated Aug. 16, 2017, 9:21 p.m.)
> 
> 
> Review request for geode, Emily Yeh, Jinmei Liao, Jared Stewart, Kirk Lund, 
> and Patrick Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Updated tests for changes in the error constructors for ServerState and
> LocatorState.
> 
> Minor spelling corrections.
> 
> I've updated the fix for GEODE-3277 and rebased on top of the @klund's recent 
> process controller updates
> 
> 
> Diffs
> -
> 
>   
> geode-assembly/src/test/java/org/apache/geode/management/internal/cli/commands/StatusLocatorRealGfshTest.java
>  3a98373938e3de21da6badcf460dae3648218ac6 
>   geode-core/src/main/java/org/apache/geode/distributed/LocatorLauncher.java 
> 83c1ab533e3dea323a8a99f7002b9464a54dfc25 
>   geode-core/src/main/java/org/apache/geode/distributed/ServerLauncher.java 
> ae64691605130c9b212a3a33bb65ae37b28af02b 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/lifecycle/GfshStatusCommandsIntegrationTest.java
>  dd5841f4cffca38da07a11f381cf4174d7264349 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/rules/GfshShellConnectionRule.java
>  e7f17ef208a1708f385c7c4041affb70fd309a4c 
> 
> 
> Diff: https://reviews.apache.org/r/61701/diff/1/
> 
> 
> Testing
> ---
> 
> Precheckin is in progress.
> 
> 
> Thanks,
> 
> Ken Howe
> 
>

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

[Ken Howe]

> On Aug. 17, 2017, 5:35 p.m., Jared Stewart wrote:
> > geode-core/src/main/java/org/apache/geode/distributed/LocatorLauncher.java
> > Lines 2017 (patched)
> > 
> >
> > I think this double-ternary might be easier to read if we split it up 
> > into a few separate statements.

Agree with you that the double ternary sin't the most readable construct. 
However, I ended up using it because the `this()` call has to be the first 
statement in the constructor. The conditionals guard against NPEs from the 
possible locations where this error constructor is called.

I'm open to other refactoring suggestions to make this easier to understand.


> On Aug. 17, 2017, 5:35 p.m., Jared Stewart wrote:
> > geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/lifecycle/GfshStatusCommandsIntegrationTest.java
> > Lines 85 (patched)
> > 
> >
> > Looks like you intended to uncomment this line.

Acutally I forgot to delete this line. I found that some fields from 
`LocatorStatusResponse` (e.g.`logFile`) that are included in the `GFJsonObject` 
in `CommandResult` contain the string `"null"`. The intent of this test is to 
insure that the status command correctly shows the locator is online when given 
the correct `--port=...` value.


- Ken


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


On Aug. 16, 2017, 9:21 p.m., Ken Howe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/61701/
> ---
> 
> (Updated Aug. 16, 2017, 9:21 p.m.)
> 
> 
> Review request for geode, Emily Yeh, Jinmei Liao, Jared Stewart, Kirk Lund, 
> and Patrick Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Updated tests for changes in the error constructors for ServerState and
> LocatorState.
> 
> Minor spelling corrections.
> 
> I've updated the fix for GEODE-3277 and rebased on top of the @klund's recent 
> process controller updates
> 
> 
> Diffs
> -
> 
>   
> geode-assembly/src/test/java/org/apache/geode/management/internal/cli/commands/StatusLocatorRealGfshTest.java
>  3a98373938e3de21da6badcf460dae3648218ac6 
>   geode-core/src/main/java/org/apache/geode/distributed/LocatorLauncher.java 
> 83c1ab533e3dea323a8a99f7002b9464a54dfc25 
>   geode-core/src/main/java/org/apache/geode/distributed/ServerLauncher.java 
> ae64691605130c9b212a3a33bb65ae37b28af02b 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/lifecycle/GfshStatusCommandsIntegrationTest.java
>  dd5841f4cffca38da07a11f381cf4174d7264349 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/rules/GfshShellConnectionRule.java
>  e7f17ef208a1708f385c7c4041affb70fd309a4c 
> 
> 
> Diff: https://reviews.apache.org/r/61701/diff/1/
> 
> 
> Testing
> ---
> 
> Precheckin is in progress.
> 
> 
> Thanks,
> 
> Ken Howe
> 
>

[GitHub] geode pull request #702: GEODE-3416: Reduce synchronization blockages in Soc...

[asfgit]

Github user asfgit closed the pull request at:

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


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

[GitHub] geode pull request #668: GEODE-3306: Remove whitespace StringBuffers/nodes c...

[asfgit]

Github user asfgit closed the pull request at:

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


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

[GitHub] geode pull request #716: GEODE-3406: Locator accepts Protobuf requests

[kohlmu-pivotal]

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

https://github.com/apache/geode/pull/716#discussion_r134514607
  
--- Diff: 
geode-protobuf/src/main/java/org/apache/geode/protocol/protobuf/operations/GetAvailableServersOperationHandler.java
 ---
@@ -50,51 +37,23 @@
   @Override
   public Result process(
   SerializationService serializationService, 
ServerAPI.GetAvailableServersRequest request,
-  Cache cache) {
-
-InternalDistributedSystem distributedSystem =
-(InternalDistributedSystem) cache.getDistributedSystem();
-Properties properties = distributedSystem.getProperties();
-String locatorsString = 
properties.getProperty(ConfigurationProperties.LOCATORS);
+  MessageExecutionContext executionContext) throws 
InvalidExecutionContextException {
 
-HashSet locators = new HashSet();
-StringTokenizer stringTokenizer = new StringTokenizer(locatorsString, 
",");
-while (stringTokenizer.hasMoreTokens()) {
-  String locator = stringTokenizer.nextToken();
-  if (StringUtils.isNotEmpty(locator)) {
-locators.add(new DistributionLocatorId(locator));
-  }
+InternalLocator locator = executionContext.getLocator();
+ArrayList serversFromSnapshot =
--- End diff --

I think the chances of the Locator changing on us would be really hard, as 
this code is running on a locator.


---
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.
---

Monitor the neighbour JVM using neihbour's member-timeout

[Aravind Musigumpula]

Hi Team,

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


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

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

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

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

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

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

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

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

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

Thanks,
Aravind Musigumpula

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

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

Jenkins build is back to normal : Geode-release #80

[Apache Jenkins Server]

See 

Build failed in Jenkins: Geode-nightly #931

[Apache Jenkins Server]

See 


Changes:

[ukohlmeyer] GEODE-3474: protobuf auth with ExampleSecurityManager. This closes 
#726

[klund] GEODE-3322: delete empty javadocs to fix javadoc warning

[abaker] GEODE-3495 Bump log4j to v2.8.2

[mbretl] GEODE-2708: Update Gradle Wrapper To 3.5.1

[boglesby] GEODE-3470: Increased serial gateway sender token timeout

[upthewaterspout] Don't download geode 1.2 every time a build runs

[klund] GEODE-1279: rename tests with old bug system numbers

[klund] GEODE-3430: fix varargs usage

[klund] GEODE-3469: prevent zero pid from AvailablePid for tests

[ukohlmeyer] GEODE-3474: Fixed failing tests

[upthewaterspout] Don't download geode 1.2 every time a build runs

[jstewart] GEODE-3471: Identify NPE in MBeanProxyFactory

[jstewart] GEODE-2859: Fix ShowDeadlockDUnitTest

--
[...truncated 213.38 KB...]

17: Task failed with an exception.
---
* What went wrong:
Execution failed for task ':geode-web:distributedTest'.
> Could not find matching constructor for: 
> org.gradle.process.internal.worker.DefaultWorkerProcessFactory(org.gradle.api.logging.LogLevel,
>  com.pedjak.gradle.plugins.dockerizedtest.DockerizedTestPlugin$MessageServer, 
> org.gradle.api.internal.DefaultClassPathRegistry, 
> org.gradle.internal.id.LongIdGenerator, java.io.File, 
> org.gradle.api.internal.file.TmpDirTemporaryFileProvider, 
> com.sun.proxy.$Proxy84)

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

18: Task failed with an exception.
---
* What went wrong:
Execution failed for task ':geode-web-api:distributedTest'.
> Could not find matching constructor for: 
> org.gradle.process.internal.worker.DefaultWorkerProcessFactory(org.gradle.api.logging.LogLevel,
>  com.pedjak.gradle.plugins.dockerizedtest.DockerizedTestPlugin$MessageServer, 
> org.gradle.api.internal.DefaultClassPathRegistry, 
> org.gradle.internal.id.LongIdGenerator, java.io.File, 
> org.gradle.api.internal.file.TmpDirTemporaryFileProvider, 
> com.sun.proxy.$Proxy84)

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

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

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

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

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

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

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

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

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

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

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

* What went wrong:
Execution failed for task ':geode-cq:uploadArchives'.
> Could not find which method repositories() to invoke from this list:
public