[jira] [Created] (GEODE-4013) shutdown of a cache server with ServerLauncher causes JVM to exit before completing shutdown

[Bruce Schuchardt (JIRA)]

Bruce Schuchardt created GEODE-4013:
---

 Summary: shutdown of a cache server with ServerLauncher causes JVM 
to exit before completing shutdown
 Key: GEODE-4013
 URL: https://issues.apache.org/jira/browse/GEODE-4013
 Project: Geode
  Issue Type: Bug
  Components: management
Reporter: Bruce Schuchardt


Also see GEODE-1236, concerning the same behavior with GFSH.

A server launched via ServerLauncher is kept alive by its AcceptorImpl thread.  
That is the only non-daemon thread in the JVM.  If you shutdown that server 
with ServerLauncher it will invoke cache.close() which midway through closing 
will terminate the AcceptorImpl thread and cause the JVM to exit.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3964) Add another severe-alert option

[ASF GitHub Bot (JIRA)]

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

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

galen-pivotal commented on issue #1088: GEODE-3964: More logging for suspect 
processing.
URL: https://github.com/apache/geode/pull/1088#issuecomment-346503558
 
 
   @WireBaron 


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Add another severe-alert option
> ---
>
> Key: GEODE-3964
> URL: https://issues.apache.org/jira/browse/GEODE-3964
> Project: Geode
>  Issue Type: Bug
>  Components: messaging
>Reporter: Bruce Schuchardt
>
> Since suspect processing only commences when the ack-severe-alert-threshold 
> is reached it would be nice to have yet another alert if that processing 
> failed to kick out the slow-to-respond member and a thread is stuck for a 
> long time waiting for a reply.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3964) Add another severe-alert option

[ASF GitHub Bot (JIRA)]

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

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

galen-pivotal commented on issue #1088: GEODE-3964: More logging for suspect 
processing.
URL: https://github.com/apache/geode/pull/1088#issuecomment-346503583
 
 
   @PivotalSarge 


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Add another severe-alert option
> ---
>
> Key: GEODE-3964
> URL: https://issues.apache.org/jira/browse/GEODE-3964
> Project: Geode
>  Issue Type: Bug
>  Components: messaging
>Reporter: Bruce Schuchardt
>
> Since suspect processing only commences when the ack-severe-alert-threshold 
> is reached it would be nice to have yet another alert if that processing 
> failed to kick out the slow-to-respond member and a thread is stuck for a 
> long time waiting for a reply.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3964) Add another severe-alert option

[ASF GitHub Bot (JIRA)]

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

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

galen-pivotal opened a new pull request #1088: GEODE-3964: More logging for 
suspect processing.
URL: https://github.com/apache/geode/pull/1088
 
 
   Add an extra level of logging if a view doesn't come back during severe
   alert processing.
   
   Some cleanup; the important stuff is lines 721..726 .
   Signed-off-by: Galen O'Sullivan 
   
   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`)?
   
   - [ ] Is your initial contribution a single, squashed commit?
   
   - [x] 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 d...@geode.apache.org.
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Add another severe-alert option
> ---
>
> Key: GEODE-3964
> URL: https://issues.apache.org/jira/browse/GEODE-3964
> Project: Geode
>  Issue Type: Bug
>  Components: messaging
>Reporter: Bruce Schuchardt
>
> Since suspect processing only commences when the ack-severe-alert-threshold 
> is reached it would be nice to have yet another alert if that processing 
> failed to kick out the slow-to-respond member and a thread is stuck for a 
> long time waiting for a reply.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3788) alter async event queue attributes

[ASF GitHub Bot (JIRA)]

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

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

PurelyApplied commented on a change in pull request #1084: GEODE-3788: add 
alter async-event-queue command and tests
URL: https://github.com/apache/geode/pull/1084#discussion_r152702785
 
 

 ##
 File path: 
geode-core/src/main/java/org/apache/geode/management/internal/cli/json/GfJsonObject.java
 ##
 @@ -305,6 +305,11 @@ public boolean has(String key) {
 return jsonObject.keys();
   }
 
+  /**
+   * this returns the column size
+   *
+   * @return
 
 Review comment:
   The description should be in-line with `@return` for the javadoc, i.e.,
   
   ```
 /**
  * @return the column size of the jsonObject
  */
 public int size() {
   return jsonObject.length();
 }
   ```


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> alter async event queue attributes
> --
>
> Key: GEODE-3788
> URL: https://issues.apache.org/jira/browse/GEODE-3788
> Project: Geode
>  Issue Type: Sub-task
>  Components: gfsh
>Reporter: Swapnil Bawaskar
>
> We should add a new {{alter async-event-queue}} gfsh command that will allow 
> users to change the following attributes on the AsyncEventQueue:
> - batch size
> - batch time interval
> - maximum queue memory
> Attributes changed with this command should only be reflected in cluster 
> configuration. We will require users to do a rolling re-start of the servers 
> for the new settings to take effect.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3977) .NET QueryService templating should match usage

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-3977:


Commit cb1e4e31914ada4d3f47bbefc6aa1c93ed18358b in geode-native's branch 
refs/heads/develop from [~mhansonp]
[ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=cb1e4e3 ]

GEODE-3977: Fixing the header includes.

* 

* GEODE-3571: Cleanup of QueryService vars.


> .NET QueryService templating should match usage
> ---
>
> Key: GEODE-3977
> URL: https://issues.apache.org/jira/browse/GEODE-3977
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Ernest Burghardt
>
> QueryService uses generics
>  generic
>   //generic
>   Query^ QueryService::NewQuery(String^ query)
> but only TResult is used and this can be confusing to the user/developer...



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3571) API should move from factory pattern to builder pattern and fluent model

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-3571:


Commit cb1e4e31914ada4d3f47bbefc6aa1c93ed18358b in geode-native's branch 
refs/heads/develop from [~mhansonp]
[ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=cb1e4e3 ]

GEODE-3977: Fixing the header includes.

* 

* GEODE-3571: Cleanup of QueryService vars.


> API should move from factory pattern to builder pattern and fluent model
> 
>
> Key: GEODE-3571
> URL: https://issues.apache.org/jira/browse/GEODE-3571
> Project: Geode
>  Issue Type: Improvement
>  Components: native client
>Reporter: Mark Hanson
>
> Discussion here http://markmail.org/thread/femkjloasj4yzvoj
> The basic idea is to move away from the creation of generic objects which are 
> then further specified to  specifying the object in advance then creating the 
> more specific object.
> This in addition to using a model where with each attribute set on an object, 
> the this pointer is provided as the return value. This allows call chaining.
> Obvious target changes include 
> CacheFactory
> DistributedSystem
> AttributesFactory



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (GEODE-4012) Move to var for all variables that whose type can be inferred

[Mark Hanson (JIRA)]

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

Mark Hanson updated GEODE-4012:
---
Priority: Minor  (was: Major)

> Move to var for all variables that whose type can be inferred
> -
>
> Key: GEODE-4012
> URL: https://issues.apache.org/jira/browse/GEODE-4012
> Project: Geode
>  Issue Type: Improvement
>  Components: native client
>Reporter: Mark Hanson
>Priority: Minor
>
> In the code, we have things like the following...
>   ICollection keyTypeIds = 
> CacheableWrapperFactory.GetRegisteredKeyTypeIds();
> to   
> var keyTypeIds =  CacheableWrapperFactory.GetRegisteredKeyTypeIds();
>  
>  This will make code far easier to refactor and avoid simple declaration 
> mistakes.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (GEODE-4012) Move to var for all variables that whose type can be inferred

[Mark Hanson (JIRA)]

Mark Hanson created GEODE-4012:
--

 Summary: Move to var for all variables that whose type can be 
inferred
 Key: GEODE-4012
 URL: https://issues.apache.org/jira/browse/GEODE-4012
 Project: Geode
  Issue Type: Improvement
  Components: native client
Reporter: Mark Hanson


In the code, we have things like the following...

  ICollection keyTypeIds = 
CacheableWrapperFactory.GetRegisteredKeyTypeIds();
to   
var keyTypeIds =  CacheableWrapperFactory.GetRegisteredKeyTypeIds();
 
 This will make code far easier to refactor and avoid simple declaration 
mistakes.





--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3571) API should move from factory pattern to builder pattern and fluent model

[ASF GitHub Bot (JIRA)]

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

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

mhansonp opened a new pull request #158: feature/GEODE-3571
URL: https://github.com/apache/geode-native/pull/158
 
 
   GEODE-3571: Move to the Builder and Fluent models.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> API should move from factory pattern to builder pattern and fluent model
> 
>
> Key: GEODE-3571
> URL: https://issues.apache.org/jira/browse/GEODE-3571
> Project: Geode
>  Issue Type: Improvement
>  Components: native client
>Reporter: Mark Hanson
>
> Discussion here http://markmail.org/thread/femkjloasj4yzvoj
> The basic idea is to move away from the creation of generic objects which are 
> then further specified to  specifying the object in advance then creating the 
> more specific object.
> This in addition to using a model where with each attribute set on an object, 
> the this pointer is provided as the return value. This allows call chaining.
> Obvious target changes include 
> CacheFactory
> DistributedSystem
> AttributesFactory



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3987) Enforce the uniqueness of a single gateway-receiver per member

[ASF GitHub Bot (JIRA)]

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

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

jujoramos commented on a change in pull request #1086: GEODE-3987: enforce 
GatewayReceiver uniqueness per member.
URL: https://github.com/apache/geode/pull/1086#discussion_r152694533
 
 

 ##
 File path: 
geode-core/src/main/java/org/apache/geode/internal/i18n/LocalizedStrings.java
 ##
 @@ -7713,6 +7713,8 @@
   new StringId(6664, "{0}: Providing synchronization event for key={1}; 
timestamp={2}: {3}");
   public static final StringId 
AbstractGatewaySender_ENQUEUEING_SYNCHRONIZATION_EVENT =
   new StringId(6665, "{0}: Enqueueing synchronization event: {1}");
+  public static final StringId GatewayReceiver_ALREADY_EXISTS =
+  new StringId(6665, "A Gateway Receiver already exists on this member.");
 
 Review comment:
   Thanks @jhuynh1,
   I'll directly remove the constant from the `LocalizedStrings` class, missed 
that discussion in the dev list.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Enforce the uniqueness of a single gateway-receiver per member
> --
>
> Key: GEODE-3987
> URL: https://issues.apache.org/jira/browse/GEODE-3987
> Project: Geode
>  Issue Type: Bug
>Reporter: Juan José Ramos Cassella
>Assignee: Juan José Ramos Cassella
>
> Within the documentation, both in [Configure Gateway 
> Receivers|http://geode.apache.org/docs/guide/13/topologies_and_comm/multi_site_configuration/setting_up_a_multisite_system.html#setting_up_a_multisite_system__section_E3A44F85359046C7ADD12861D261637B]
>  and [gfsh create 
> gateway-receiver|http://geode.apache.org/docs/guide/13/tools_modules/gfsh/command-pages/create.html#topic_a4x_pb1_dk],
>  we state that only one {{gateway-receiver}} is allowed per member. However, 
> there is no enforcement of this rule within the code nor within the schema 
> for the {{cache.xml}} file, so the user might end up having more than one 
> {{gateway-receiver}} per host.
> It's unknown which {{gateway-receiver}} is going to be used after a restart, 
> making it hard to configure firewall rules between clusters, if any. The 
> following exception is also printed in the logs whenever we try to register 
> (only the first one is succesfull) the MBean for the {{gateway-receiver}}:
> {noformat}
> [warning 2017/11/16 15:27:46.156 PST host1-server1  Processor1> tid=0x44] javax.management.InstanceAlreadyExistsException: 
> GemFire:service=GatewayReceiver,type=Member,member=host1-server1
> org.apache.geode.management.ManagementException: 
> javax.management.InstanceAlreadyExistsException: 
> GemFire:service=GatewayReceiver,type=Member,member=host1-server1
>   at 
> org.apache.geode.management.internal.MBeanJMXAdapter.registerMBean(MBeanJMXAdapter.java:110)
>   at 
> org.apache.geode.management.internal.SystemManagementService.registerInternalMBean(SystemManagementService.java:368)
>   at 
> org.apache.geode.management.internal.beans.ManagementAdapter.createGatewayReceiverMBean(ManagementAdapter.java:471)
>   at 
> org.apache.geode.management.internal.beans.ManagementAdapter.handleGatewayReceiverStart(ManagementAdapter.java:493)
>   at 
> org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:134)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2175)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:562)
>   at 
> org.apache.geode.internal.cache.wan.GatewayReceiverImpl.start(GatewayReceiverImpl.java:194)
>   at 
> org.apache.geode.internal.cache.wan.GatewayReceiverFactoryImpl.create(GatewayReceiverFactoryImpl.java:141)
>   at 
> org.apache.geode.management.internal.cli.functions.GatewayReceiverCreateFunction.createGatewayReceiver(GatewayReceiverCreateFunction.java:164)
>   at 
> org.apache.geode.management.internal.cli.functions.GatewayReceiverCreateFunction.execute(GatewayReceiverCreateFunction.java:63)
>   at 
> org.apache.geode.internal.cache.MemberFunctionStreamingMessage.process(MemberFunctionStreamingMessage.java:186)
>   at 
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:374)
>   at 
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:440)
>   at 
> 

[jira] [Commented] (GEODE-3987) Enforce the uniqueness of a single gateway-receiver per member

[ASF GitHub Bot (JIRA)]

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

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

jujoramos commented on a change in pull request #1086: GEODE-3987: enforce 
GatewayReceiver uniqueness per member.
URL: https://github.com/apache/geode/pull/1086#discussion_r152694113
 
 

 ##
 File path: 
geode-core/src/test/resources/org/apache/geode/internal/cache/wan/GatewayReceiverXmlParsingValidationsTest.correctConfiguration[DTD].cache.xml
 ##
 @@ -0,0 +1,26 @@
+
+
+
+
+http://www.gemstone.com/dtd/cache8_0.dtd;>
   
   If you are declaring a client cache then use this DOCTYPE:
   
 http://www.gemstone.com/dtd/cache8_0.dtd;>
   ```


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Enforce the uniqueness of a single gateway-receiver per member
> --
>
> Key: GEODE-3987
> URL: https://issues.apache.org/jira/browse/GEODE-3987
> Project: Geode
>  Issue Type: Bug
>Reporter: Juan José Ramos Cassella
>Assignee: Juan José Ramos Cassella
>
> Within the documentation, both in [Configure Gateway 
> Receivers|http://geode.apache.org/docs/guide/13/topologies_and_comm/multi_site_configuration/setting_up_a_multisite_system.html#setting_up_a_multisite_system__section_E3A44F85359046C7ADD12861D261637B]
>  and [gfsh create 
> gateway-receiver|http://geode.apache.org/docs/guide/13/tools_modules/gfsh/command-pages/create.html#topic_a4x_pb1_dk],
>  we state that only one {{gateway-receiver}} is allowed per member. However, 
> there is no enforcement of this rule within the code nor within the schema 
> for the {{cache.xml}} file, so the user might end up having more than one 
> {{gateway-receiver}} per host.
> It's unknown which {{gateway-receiver}} is going to be used after a restart, 
> making it hard to configure firewall rules between clusters, if any. The 
> following exception is also printed in the logs whenever we try to register 
> (only the first one is succesfull) the MBean for the {{gateway-receiver}}:
> {noformat}
> [warning 2017/11/16 15:27:46.156 PST host1-server1  Processor1> tid=0x44] javax.management.InstanceAlreadyExistsException: 
> GemFire:service=GatewayReceiver,type=Member,member=host1-server1
> org.apache.geode.management.ManagementException: 
> javax.management.InstanceAlreadyExistsException: 
> GemFire:service=GatewayReceiver,type=Member,member=host1-server1
>   at 
> org.apache.geode.management.internal.MBeanJMXAdapter.registerMBean(MBeanJMXAdapter.java:110)
>   at 
> org.apache.geode.management.internal.SystemManagementService.registerInternalMBean(SystemManagementService.java:368)
>   at 
> org.apache.geode.management.internal.beans.ManagementAdapter.createGatewayReceiverMBean(ManagementAdapter.java:471)
>   at 
> org.apache.geode.management.internal.beans.ManagementAdapter.handleGatewayReceiverStart(ManagementAdapter.java:493)
>   at 
> org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:134)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2175)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:562)
>   at 
> org.apache.geode.internal.cache.wan.GatewayReceiverImpl.start(GatewayReceiverImpl.java:194)
>   at 
> org.apache.geode.internal.cache.wan.GatewayReceiverFactoryImpl.create(GatewayReceiverFactoryImpl.java:141)
>   at 
> org.apache.geode.management.internal.cli.functions.GatewayReceiverCreateFunction.createGatewayReceiver(GatewayReceiverCreateFunction.java:164)
>   at 
> org.apache.geode.management.internal.cli.functions.GatewayReceiverCreateFunction.execute(GatewayReceiverCreateFunction.java:63)
>   at 
> org.apache.geode.internal.cache.MemberFunctionStreamingMessage.process(MemberFunctionStreamingMessage.java:186)
>   at 
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:374)
>   at 
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:440)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at 
> org.apache.geode.distributed.internal.DistributionManager.runUntilShutdown(DistributionManager.java:668)
>   at 
> 

[jira] [Commented] (GEODE-3539) Add more test coverage for p2p commands

[ASF GitHub Bot (JIRA)]

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

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

PurelyApplied commented on a change in pull request #1070: GEODE-3539: Add test 
coverage to 'alter disk-store'.
URL: https://github.com/apache/geode/pull/1070#discussion_r152693598
 
 

 ##
 File path: 
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/AlterDiskStoreDUnitTest.java
 ##
 @@ -0,0 +1,170 @@
+/*
+ * 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.management.internal.cli.commands;
+
+import static org.assertj.core.api.Assertions.assertThat;
+
+import java.io.File;
+import java.io.IOException;
+import java.io.Serializable;
+
+import org.junit.Before;
+import org.junit.Rule;
+import org.junit.Test;
+import org.junit.experimental.categories.Category;
+
+import org.apache.geode.cache.Cache;
+import org.apache.geode.cache.DataPolicy;
+import org.apache.geode.cache.EvictionAction;
+import org.apache.geode.cache.EvictionAttributes;
+import org.apache.geode.cache.Region;
+import org.apache.geode.cache.RegionFactory;
+import org.apache.geode.cache.Scope;
+import org.apache.geode.management.internal.cli.i18n.CliStrings;
+import org.apache.geode.management.internal.cli.util.CommandStringBuilder;
+import org.apache.geode.test.dunit.rules.LocatorServerStartupRule;
+import org.apache.geode.test.dunit.rules.MemberVM;
+import org.apache.geode.test.junit.categories.DistributedTest;
+import org.apache.geode.test.junit.rules.GfshCommandRule;
+import org.apache.geode.test.junit.rules.GfshCommandRule.PortType;
+
+@Category(DistributedTest.class)
+public class AlterDiskStoreDUnitTest implements Serializable {
+  private static final String regionName = "region1";
+  private static final String diskStoreName = "disk-store1";
+  private static final String diskDirName = "diskStoreDir";
+  private static final String aKey = "key1";
+
+  private static MemberVM locator;
+  private static MemberVM server1;
+
+  @Rule
+  public LocatorServerStartupRule startupRule = new 
LocatorServerStartupRule().withTempWorkingDir();
 
 Review comment:
   I was a bit worried that just using the `gfsh` working directory could cause 
problems if the `--remove` test was run first, but that appears to have been a 
misplaced fear.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Add more test coverage for p2p commands
> ---
>
> Key: GEODE-3539
> URL: https://issues.apache.org/jira/browse/GEODE-3539
> Project: Geode
>  Issue Type: Improvement
>  Components: gfsh
>Reporter: Jinmei Liao
>
> Add more command tests that would eventually get rid of the legacy tests.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3987) Enforce the uniqueness of a single gateway-receiver per member

[ASF GitHub Bot (JIRA)]

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

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

jujoramos commented on a change in pull request #1086: GEODE-3987: enforce 
GatewayReceiver uniqueness per member.
URL: https://github.com/apache/geode/pull/1086#discussion_r152693076
 
 

 ##
 File path: 
geode-core/src/test/java/org/apache/geode/internal/cache/wan/GatewayReceiverXmlParsingValidationsTest.java
 ##
 @@ -0,0 +1,111 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more 
contributor license
+ * agreements. See the NOTICE file distributed with this work for additional 
information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache 
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the 
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software 
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY 
KIND, either express
+ * or implied. See the License for the specific language governing permissions 
and limitations under
+ * the License.
+ */
+/**
+ *
+ */
+package org.apache.geode.internal.cache.wan;
+
+import static 
org.apache.geode.distributed.ConfigurationProperties.CACHE_XML_FILE;
+import static org.apache.geode.distributed.ConfigurationProperties.MCAST_PORT;
+import static org.assertj.core.api.Assertions.assertThat;
+import static org.mockito.ArgumentMatchers.any;
+import static org.mockito.Mockito.spy;
+import static org.mockito.Mockito.times;
+import static org.mockito.Mockito.verify;
+import static org.powermock.api.mockito.PowerMockito.mockStatic;
+import static org.powermock.api.mockito.PowerMockito.when;
+
+import java.util.Arrays;
+import java.util.Collection;
+
+import org.junit.After;
+import org.junit.Before;
+import org.junit.Rule;
+import org.junit.Test;
+import org.junit.experimental.categories.Category;
+import org.junit.rules.TestName;
+import org.junit.runner.RunWith;
+import org.junit.runners.Parameterized;
+import org.powermock.core.classloader.annotations.PowerMockIgnore;
+import org.powermock.core.classloader.annotations.PrepareForTest;
+import org.powermock.modules.junit4.PowerMockRunner;
+import org.powermock.modules.junit4.PowerMockRunnerDelegate;
+
+import org.apache.geode.cache.Cache;
+import org.apache.geode.cache.CacheFactory;
+import org.apache.geode.cache.CacheXmlException;
+import org.apache.geode.cache.wan.GatewayReceiverFactory;
+import org.apache.geode.test.junit.categories.IntegrationTest;
+import org.apache.geode.test.junit.rules.serializable.SerializableTestName;
+import org.apache.geode.util.test.TestUtil;
+
+@RunWith(PowerMockRunner.class)
+@Category(IntegrationTest.class)
+@PrepareForTest(WANServiceProvider.class)
+@PowerMockRunnerDelegate(Parameterized.class)
+@PowerMockIgnore({"javax.management.*", "javax.security.*", 
"*.IntegrationTest"})
+public class GatewayReceiverXmlParsingValidationsTest {
 
 Review comment:
   Done!


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Enforce the uniqueness of a single gateway-receiver per member
> --
>
> Key: GEODE-3987
> URL: https://issues.apache.org/jira/browse/GEODE-3987
> Project: Geode
>  Issue Type: Bug
>Reporter: Juan José Ramos Cassella
>Assignee: Juan José Ramos Cassella
>
> Within the documentation, both in [Configure Gateway 
> Receivers|http://geode.apache.org/docs/guide/13/topologies_and_comm/multi_site_configuration/setting_up_a_multisite_system.html#setting_up_a_multisite_system__section_E3A44F85359046C7ADD12861D261637B]
>  and [gfsh create 
> gateway-receiver|http://geode.apache.org/docs/guide/13/tools_modules/gfsh/command-pages/create.html#topic_a4x_pb1_dk],
>  we state that only one {{gateway-receiver}} is allowed per member. However, 
> there is no enforcement of this rule within the code nor within the schema 
> for the {{cache.xml}} file, so the user might end up having more than one 
> {{gateway-receiver}} per host.
> It's unknown which {{gateway-receiver}} is going to be used after a restart, 
> making it hard to configure firewall rules between clusters, if any. The 
> following exception is also printed in the logs whenever we try to register 
> (only the first one is succesfull) the MBean for the {{gateway-receiver}}:
> {noformat}
> [warning 2017/11/16 

[jira] [Commented] (GEODE-4007) Authentication failures/bad handshake should close the socket from the server side

[ASF GitHub Bot (JIRA)]

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

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

WireBaron commented on issue #1087: GEODE-4007: Authentication/Handshake errors 
should close the socket
URL: https://github.com/apache/geode/pull/1087#issuecomment-346489921
 
 
   Also force pushed a new version with some commits that were missed.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Authentication failures/bad handshake should close the socket from the server 
> side
> --
>
> Key: GEODE-4007
> URL: https://issues.apache.org/jira/browse/GEODE-4007
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Reporter: Brian Rowe
>
> Ensure after failed auth/handshake the server (after sending error response) 
> closes the socket and cleans up.
> While going over the code together, it looks like maybe authentication errors 
> simply leave the socket in a state where it is expecting another 
> authentication request. It might be better to close the socket from the 
> server side for various error conditions like a failed handshake or 
> authentication.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-4007) Authentication failures/bad handshake should close the socket from the server side

[ASF GitHub Bot (JIRA)]

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

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

WireBaron commented on a change in pull request #1087: GEODE-4007: 
Authentication/Handshake errors should close the socket
URL: https://github.com/apache/geode/pull/1087#discussion_r152692573
 
 

 ##
 File path: 
geode-client-protocol/src/main/java/org/apache/geode/internal/protocol/operations/OperationHandler.java
 ##
 @@ -30,7 +31,11 @@
   /**
* Decode the message, deserialize contained values using the serialization 
service, do the work
* indicated on the provided cache, and return a response.
+   *
+   * @throws ConnectionStateException if the connection is in an invalid state 
for the operation in
+   * question.
*/
   Result process(SerializationService serializationService, 
Req request,
-  MessageExecutionContext messageExecutionContext) throws 
InvalidExecutionContextException;
+  MessageExecutionContext messageExecutionContext)
+  throws InvalidExecutionContextException, ConnectionStateException;
 
 Review comment:
   ConnectionStateException is newly thrown in this change, Galen made the 
observation that the code we're using to handle this inside the OpHandler is 
identical to the catch code we're using in the function calling this.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Authentication failures/bad handshake should close the socket from the server 
> side
> --
>
> Key: GEODE-4007
> URL: https://issues.apache.org/jira/browse/GEODE-4007
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Reporter: Brian Rowe
>
> Ensure after failed auth/handshake the server (after sending error response) 
> closes the socket and cleans up.
> While going over the code together, it looks like maybe authentication errors 
> simply leave the socket in a state where it is expecting another 
> authentication request. It might be better to close the socket from the 
> server side for various error conditions like a failed handshake or 
> authentication.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3539) Add more test coverage for p2p commands

[ASF GitHub Bot (JIRA)]

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

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

PurelyApplied commented on a change in pull request #1070: GEODE-3539: Add test 
coverage to 'alter disk-store'.
URL: https://github.com/apache/geode/pull/1070#discussion_r152691736
 
 

 ##
 File path: 
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/AlterDiskStoreIntegrationTest.java
 ##
 @@ -0,0 +1,67 @@
+/*
+ * 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.management.internal.cli.commands;
+
+import java.io.IOException;
+
+import org.junit.Rule;
+import org.junit.Test;
+import org.junit.experimental.categories.Category;
+
+import org.apache.geode.cache.RegionShortcut;
+import org.apache.geode.management.internal.cli.i18n.CliStrings;
+import org.apache.geode.management.internal.cli.util.CommandStringBuilder;
+import org.apache.geode.test.junit.categories.IntegrationTest;
+import org.apache.geode.test.junit.rules.GfshCommandRule;
+import org.apache.geode.test.junit.rules.GfshCommandRule.PortType;
+import org.apache.geode.test.junit.rules.ServerStarterRule;
+
+@Category(IntegrationTest.class)
+public class AlterDiskStoreIntegrationTest {
+  private static final String regionName = "region1";
+  private static final String memberName = "server";
+  private static final String diskStoreName = "disk-store1";
+
+  @Rule
+  public ServerStarterRule server =
 
 Review comment:
   Can the GfshParserRule do that?  I thought that rule only determined if the 
string could find the function to call, not to test the mutual exclusion of 
options within the code itself.
   
   Definitely don't need the server, though.  I missed that when I pulled this 
out of the DUnit.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Add more test coverage for p2p commands
> ---
>
> Key: GEODE-3539
> URL: https://issues.apache.org/jira/browse/GEODE-3539
> Project: Geode
>  Issue Type: Improvement
>  Components: gfsh
>Reporter: Jinmei Liao
>
> Add more command tests that would eventually get rid of the legacy tests.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3539) Add more test coverage for p2p commands

[ASF GitHub Bot (JIRA)]

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

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

PurelyApplied commented on a change in pull request #1070: GEODE-3539: Add test 
coverage to 'alter disk-store'.
URL: https://github.com/apache/geode/pull/1070#discussion_r152691736
 
 

 ##
 File path: 
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/AlterDiskStoreIntegrationTest.java
 ##
 @@ -0,0 +1,67 @@
+/*
+ * 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.management.internal.cli.commands;
+
+import java.io.IOException;
+
+import org.junit.Rule;
+import org.junit.Test;
+import org.junit.experimental.categories.Category;
+
+import org.apache.geode.cache.RegionShortcut;
+import org.apache.geode.management.internal.cli.i18n.CliStrings;
+import org.apache.geode.management.internal.cli.util.CommandStringBuilder;
+import org.apache.geode.test.junit.categories.IntegrationTest;
+import org.apache.geode.test.junit.rules.GfshCommandRule;
+import org.apache.geode.test.junit.rules.GfshCommandRule.PortType;
+import org.apache.geode.test.junit.rules.ServerStarterRule;
+
+@Category(IntegrationTest.class)
+public class AlterDiskStoreIntegrationTest {
+  private static final String regionName = "region1";
+  private static final String memberName = "server";
+  private static final String diskStoreName = "disk-store1";
+
+  @Rule
+  public ServerStarterRule server =
 
 Review comment:
   ~~Can the GfshParserRule do that?  I thought that rule only determined if 
the string could find the function to call, not to test the mutual exclusion of 
options within the code itself.~~ Oh, I was only looking at `.parse` and not 
`executeCommandWithInstance`.  Gotcha.
   
   Definitely don't need the server, though.  I missed that when I pulled this 
out of the DUnit.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Add more test coverage for p2p commands
> ---
>
> Key: GEODE-3539
> URL: https://issues.apache.org/jira/browse/GEODE-3539
> Project: Geode
>  Issue Type: Improvement
>  Components: gfsh
>Reporter: Jinmei Liao
>
> Add more command tests that would eventually get rid of the legacy tests.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3539) Add more test coverage for p2p commands

[ASF GitHub Bot (JIRA)]

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

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

PurelyApplied commented on a change in pull request #1070: GEODE-3539: Add test 
coverage to 'alter disk-store'.
URL: https://github.com/apache/geode/pull/1070#discussion_r152691736
 
 

 ##
 File path: 
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/AlterDiskStoreIntegrationTest.java
 ##
 @@ -0,0 +1,67 @@
+/*
+ * 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.management.internal.cli.commands;
+
+import java.io.IOException;
+
+import org.junit.Rule;
+import org.junit.Test;
+import org.junit.experimental.categories.Category;
+
+import org.apache.geode.cache.RegionShortcut;
+import org.apache.geode.management.internal.cli.i18n.CliStrings;
+import org.apache.geode.management.internal.cli.util.CommandStringBuilder;
+import org.apache.geode.test.junit.categories.IntegrationTest;
+import org.apache.geode.test.junit.rules.GfshCommandRule;
+import org.apache.geode.test.junit.rules.GfshCommandRule.PortType;
+import org.apache.geode.test.junit.rules.ServerStarterRule;
+
+@Category(IntegrationTest.class)
+public class AlterDiskStoreIntegrationTest {
+  private static final String regionName = "region1";
+  private static final String memberName = "server";
+  private static final String diskStoreName = "disk-store1";
+
+  @Rule
+  public ServerStarterRule server =
 
 Review comment:
   Can the GfshParserRule do that?  I thought that rule only determined if the 
string could find the function to call, not to test the mutual exclusion of 
options within the code itself.
   
   Definitely don't need the server, though.  I missed that when I pulled this 
out of the DUnit.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Add more test coverage for p2p commands
> ---
>
> Key: GEODE-3539
> URL: https://issues.apache.org/jira/browse/GEODE-3539
> Project: Geode
>  Issue Type: Improvement
>  Components: gfsh
>Reporter: Jinmei Liao
>
> Add more command tests that would eventually get rid of the legacy tests.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (GEODE-4002) User Guide: Consolidate cache element descriptions

[Dave Barnes (JIRA)]

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

Dave Barnes resolved GEODE-4002.

   Resolution: Fixed
Fix Version/s: 1.4.0

> User Guide: Consolidate cache element descriptions
> --
>
> Key: GEODE-4002
> URL: https://issues.apache.org/jira/browse/GEODE-4002
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Dave Barnes
>Assignee: Dave Barnes
> Fix For: 1.4.0
>
>
> The  Element Reference is implemented as two largely redundant files. 
> This creates multiple paths to apparently identical, but duplicate, targets 
> and confuses navigation. Consolidate into one file, fix up embedded 
> references, update left-side subnav.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-4002) User Guide: Consolidate cache element descriptions

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-4002:


Commit b3f1c42b47712d4cc886f339bd694ac1acc060c0 in geode's branch 
refs/heads/develop from [~dbarnes97]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=b3f1c42 ]

GEODE-4002 User Guide: Consolidate cache element descriptions


> User Guide: Consolidate cache element descriptions
> --
>
> Key: GEODE-4002
> URL: https://issues.apache.org/jira/browse/GEODE-4002
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>
> The  Element Reference is implemented as two largely redundant files. 
> This creates multiple paths to apparently identical, but duplicate, targets 
> and confuses navigation. Consolidate into one file, fix up embedded 
> references, update left-side subnav.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3539) Add more test coverage for p2p commands

[ASF GitHub Bot (JIRA)]

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

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

PurelyApplied commented on a change in pull request #1070: GEODE-3539: Add test 
coverage to 'alter disk-store'.
URL: https://github.com/apache/geode/pull/1070#discussion_r152685714
 
 

 ##
 File path: 
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/AlterDiskStoreDUnitTest.java
 ##
 @@ -0,0 +1,170 @@
+/*
+ * 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.management.internal.cli.commands;
+
+import static org.assertj.core.api.Assertions.assertThat;
+
+import java.io.File;
+import java.io.IOException;
+import java.io.Serializable;
+
+import org.junit.Before;
+import org.junit.Rule;
+import org.junit.Test;
+import org.junit.experimental.categories.Category;
+
+import org.apache.geode.cache.Cache;
+import org.apache.geode.cache.DataPolicy;
+import org.apache.geode.cache.EvictionAction;
+import org.apache.geode.cache.EvictionAttributes;
+import org.apache.geode.cache.Region;
+import org.apache.geode.cache.RegionFactory;
+import org.apache.geode.cache.Scope;
+import org.apache.geode.management.internal.cli.i18n.CliStrings;
+import org.apache.geode.management.internal.cli.util.CommandStringBuilder;
+import org.apache.geode.test.dunit.rules.LocatorServerStartupRule;
+import org.apache.geode.test.dunit.rules.MemberVM;
+import org.apache.geode.test.junit.categories.DistributedTest;
+import org.apache.geode.test.junit.rules.GfshCommandRule;
+import org.apache.geode.test.junit.rules.GfshCommandRule.PortType;
+
+@Category(DistributedTest.class)
+public class AlterDiskStoreDUnitTest implements Serializable {
 
 Review comment:
   I was running into some RMIs during testing and had thought that was the 
culprit, looking at other DUnits.  But it looks like I was wrong on that front, 
or the root cause was massaged out.  Will remove. 


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Add more test coverage for p2p commands
> ---
>
> Key: GEODE-3539
> URL: https://issues.apache.org/jira/browse/GEODE-3539
> Project: Geode
>  Issue Type: Improvement
>  Components: gfsh
>Reporter: Jinmei Liao
>
> Add more command tests that would eventually get rid of the legacy tests.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3539) Add more test coverage for p2p commands

[ASF GitHub Bot (JIRA)]

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

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

PurelyApplied closed pull request #1065: GEODE-3539: Add missing test coverage 
to 'list disk-stores' and …
URL: https://github.com/apache/geode/pull/1065
 
 
   

This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:

As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):

diff --git 
a/geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/DescribeDiskStoreCommandIntegrationTest.java
 
b/geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/DescribeDiskStoreCommandIntegrationTest.java
new file mode 100644
index 00..3edc944ce2
--- /dev/null
+++ 
b/geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/DescribeDiskStoreCommandIntegrationTest.java
@@ -0,0 +1,108 @@
+/*
+ * 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.management.internal.cli.commands;
+
+import java.util.Arrays;
+import java.util.List;
+
+import org.junit.Before;
+import org.junit.BeforeClass;
+import org.junit.ClassRule;
+import org.junit.Rule;
+import org.junit.Test;
+import org.junit.experimental.categories.Category;
+
+import org.apache.geode.cache.RegionShortcut;
+import org.apache.geode.test.junit.categories.IntegrationTest;
+import org.apache.geode.test.junit.rules.GfshCommandRule;
+import org.apache.geode.test.junit.rules.GfshCommandRule.PortType;
+import org.apache.geode.test.junit.rules.ServerStarterRule;
+
+@Category(IntegrationTest.class)
+public class DescribeDiskStoreCommandIntegrationTest {
+  private static final String REGION_NAME = "test-region";
+  private static final String MEMBER_NAME = "testServer";
+  private static final String DISK_STORE_NAME = "testDiskStore";
+
+  private static final List expectedData = Arrays.asList("Disk Store 
ID", "Disk Store Name",
+  "Member ID", "Member Name", "Allow Force Compaction", "Auto Compaction",
+  "Compaction Threshold", "Max Oplog Size", "Queue Size", "Time Interval", 
"Write Buffer Size",
+  "Disk Usage Warning Percentage", "Disk Usage Critical Percentage ",
+  "PDX Serialization Meta-Data Stored", "Disk Directory", "Size");
+
+  @ClassRule
+  public static ServerStarterRule server =
+  new ServerStarterRule().withRegion(RegionShortcut.REPLICATE, REGION_NAME)
+  .withName(MEMBER_NAME).withJMXManager().withAutoStart();
+
+  @BeforeClass
+  public static void beforeClass() throws Exception {
+server.getCache().createDiskStoreFactory().create(DISK_STORE_NAME);
+gfsh.connectAndVerify(server.getJmxPort(), PortType.jmxManager);
+
+  }
+
+  @ClassRule
+  public static GfshCommandRule gfsh = new GfshCommandRule();
+
+  @Before
+  public void setTimeout() {
+gfsh.setTimeout(1);
+  }
+
+  @Test
+  public void commandFailsWithoutOptions() throws Exception {
+String cmd = "describe disk-store";
+gfsh.executeAndAssertThat(cmd).statusIsError().containsOutput("You should 
specify option (",
+"--name", "--member", ") for this command");
+
+  }
+
+  @Test
+  public void commandFailsWithOnlyMember() throws Exception {
+String cmd = "describe disk-store --member=" + MEMBER_NAME;
+gfsh.executeAndAssertThat(cmd).statusIsError().containsOutput("You should 
specify option (",
+"--name", ") for this command");
+  }
+
+  @Test
+  public void commandFailsWithOnlyName() throws Exception {
+String cmd = "describe disk-store --name=" + DISK_STORE_NAME;
+gfsh.executeAndAssertThat(cmd).statusIsError().containsOutput("You should 
specify option (",
+"--member", ") for this command");
+  }
+
+  @Test
+  public void commandFailsWithBadMember() throws Exception {
+String cmd = "describe disk-store --member=invalid-member-name --name=" + 
DISK_STORE_NAME;
+gfsh.executeAndAssertThat(cmd).statusIsError().containsOutput("Member",
+"could not be found.  Please verify the member name or 

[jira] [Commented] (GEODE-3539) Add more test coverage for p2p commands

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-3539:


Commit f3a021991d239dfc05357d6250d937a90d971f32 in geode's branch 
refs/heads/develop from [~prhomberg]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=f3a0219 ]

GEODE-3539: Add missing test coverage to 'list disk-stores' and 'describe 
disk-stores' commands

* Refactor cumbersome DUnit test to individual IntegrationTests

> Add more test coverage for p2p commands
> ---
>
> Key: GEODE-3539
> URL: https://issues.apache.org/jira/browse/GEODE-3539
> Project: Geode
>  Issue Type: Improvement
>  Components: gfsh
>Reporter: Jinmei Liao
>
> Add more command tests that would eventually get rid of the legacy tests.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3038) A server process shuts down quietly when path to cache.xml is incorrect

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-3038:


Commit 0d5d2cbadc50c5ec5d43889fc65eb8622a7f742e in geode's branch 
refs/heads/develop from [~agingade]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=0d5d2cb ]

GEODE-3038 Fix suspect string found in logs during test run


> A server process shuts down quietly when path to cache.xml is incorrect
> ---
>
> Key: GEODE-3038
> URL: https://issues.apache.org/jira/browse/GEODE-3038
> Project: Geode
>  Issue Type: Bug
>  Components: configuration
>Reporter: Anton Mironenko
>Priority: Minor
> Fix For: 1.4.0
>
>
> Geode version: 1.1.1, 1.3.0 (latest develop snapshot)
> If I start a server with incorrect path to Server.xml, it shuts down quietly 
> without any message in the log. 
> An expected behavior would be the error message "Server.xml not found in the 
> path [...], shutting down"
> Here are the steps to reproduce, please use GEODE-3003 for zip files.
> Test preparation:
> -
> Here are two attached zip files - "geode-host1.zip" and "geode-host2.zip"
> 1) unzip "geode-host1.zip" into some folder on your first host
> 2) in start-locator.sh change the IPs of locators to the values of your host1 
> and host2
> "--locators=10.50.3.38[20236],10.50.3.14[20236]"
> 3) in start-server.sh
> "locators=10.50.3.38[20236],10.50.3.14[20236]" change the IPs of locators to 
> the values of your host1 and host2
> 4) do the bullets 1)-4) for host2, the folder where you unzip the file should 
> be the same as on the first host
> Test running:
> ---
> 0) change start-server.sh so that the path to Server.xml is wrong
> cache-xml-file=$SERVERXML_DIR/Server.xml
> ->
> cache-xml-file=$SERVERXML_DIR/Server_.xml
> 1) run ./start-locator.sh on host1
> 2) after some pause run ./start-server
> 3) observe the server started and immediately stopped,
> 4) observe in the server logs, server1/cacheserver.log:
> [info 2017/06/06 18:32:05.141 MSK host1-server-1  tid=0x1] Received 
> cluster configuration from the locator
> [info 2017/06/06 18:32:05.141 MSK host1-server-1  tid=0x1] 
>   ***
>   Configuration for  'cluster'
>   
>   Jar files to deployed
> [info 2017/06/06 18:32:05.141 MSK host1-server-1  tid=0x1] Requesting 
> cluster configuration
> [info 2017/06/06 18:32:05.143 MSK host1-server-1  tid=0x1] Got response 
> with jars: 
> [info 2017/06/06 18:32:05.209 MSK host1-server-1  tid=0x1] Initializing 
> region _monitoringRegion_10.50.3.381025
> [info 2017/06/06 18:32:05.222 MSK host1-server-1  tid=0x1] Region 
> _monitoringRegion_10.50.3.381025 requesting initial image from 
> 10.50.3.38(host1-locator-0-20236:27511:locator):1024
> [info 2017/06/06 18:32:05.227 MSK host1-server-1  tid=0x1] 
> _monitoringRegion_10.50.3.381025 is done getting image from 
> 10.50.3.38(host1-locator-0-20236:27511:locator):1024. isDeltaGII is 
> false
> [info 2017/06/06 18:32:05.228 MSK host1-server-1  tid=0x1] 
> Initialization of region _monitoringRegion_10.50.3.381025 completed
> [info 2017/06/06 18:32:05.812 MSK host1-server-1  tid=0x1] 
> GemFireCache[id = 2117642238; isClosing = true; isShutDownAll = false; 
> created = Tue Jun 06 18:32:05 MSK 2017; server = false; copyOnRead = false; 
> lockLease = 120; lockTimeout = 60]: Now closing.
> [info 2017/06/06 18:32:05.855 MSK host1-server-1  tid=0x1] Shutting 
> down DistributionManager 10.50.3.38(host1-server-1:27773):1025. 
> [info 2017/06/06 18:32:05.961 MSK host1-server-1  tid=0x1] Now closing 
> distribution for 10.50.3.38(host1-server-1:27773):1025
> [info 2017/06/06 18:32:05.962 MSK host1-server-1  tid=0x1] Stopping 
> membership services
> [info 2017/06/06 18:32:05.964 MSK host1-server-1  Server thread 0> tid=0x1d] GMSHealthMonitor server thread exiting
> [info 2017/06/06 18:32:05.964 MSK host1-server-1  tid=0x1] 
> GMSHealthMonitor server socket is closed in stopServices().
> [info 2017/06/06 18:32:05.968 MSK host1-server-1  tid=0x1] 
> GMSHealthMonitor serverSocketExecutor is terminated
> [info 2017/06/06 18:32:05.974 MSK host1-server-1  tid=0x1] 
> DistributionManager stopped in 119ms.
> [info 2017/06/06 18:32:05.974 MSK host1-server-1  tid=0x1] Marking 
> DistributionManager 10.50.3.38(host1-server-1:27773):1025 as closed.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-4011) ConcurrentDeployDUnitTest is polluting test VMs

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-4011:


Commit 57712d4320ce25f92f7e5b1ceab9dbc1bcd875f0 in geode's branch 
refs/heads/develop from [~jens.deppe]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=57712d4 ]

GEODE-4011: Disable test until we can fix it properly


> ConcurrentDeployDUnitTest is polluting test VMs
> ---
>
> Key: GEODE-4011
> URL: https://issues.apache.org/jira/browse/GEODE-4011
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>
> This test launches gfsh from within 3 separate VMs. gfsh does some logger 
> manipulation which results in stdout being redirected. Subsequent tests then 
> may fail if they produce 'scary' suspect messages in the logs.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (GEODE-4011) ConcurrentDeployDUnitTest is polluting test VMs

[Jens Deppe (JIRA)]

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

Jens Deppe reassigned GEODE-4011:
-

Assignee: Jens Deppe

> ConcurrentDeployDUnitTest is polluting test VMs
> ---
>
> Key: GEODE-4011
> URL: https://issues.apache.org/jira/browse/GEODE-4011
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>
> This test launches gfsh from within 3 separate VMs. gfsh does some logger 
> manipulation which results in stdout being redirected. Subsequent tests then 
> may fail if they produce 'scary' suspect messages in the logs.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (GEODE-4011) ConcurrentDeployDUnitTest is polluting test VMs

[Jens Deppe (JIRA)]

Jens Deppe created GEODE-4011:
-

 Summary: ConcurrentDeployDUnitTest is polluting test VMs
 Key: GEODE-4011
 URL: https://issues.apache.org/jira/browse/GEODE-4011
 Project: Geode
  Issue Type: Bug
  Components: gfsh
Reporter: Jens Deppe


This test launches gfsh from within 3 separate VMs. gfsh does some logger 
manipulation which results in stdout being redirected. Subsequent tests then 
may fail if they produce 'scary' suspect messages in the logs.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3987) Enforce the uniqueness of a single gateway-receiver per member

[ASF GitHub Bot (JIRA)]

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

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

jhuynh1 commented on a change in pull request #1086: GEODE-3987: enforce 
GatewayReceiver uniqueness per member.
URL: https://github.com/apache/geode/pull/1086#discussion_r152671902
 
 

 ##
 File path: 
geode-core/src/main/java/org/apache/geode/internal/i18n/LocalizedStrings.java
 ##
 @@ -7713,6 +7713,8 @@
   new StringId(6664, "{0}: Providing synchronization event for key={1}; 
timestamp={2}: {3}");
   public static final StringId 
AbstractGatewaySender_ENQUEUEING_SYNCHRONIZATION_EVENT =
   new StringId(6665, "{0}: Enqueueing synchronization event: {1}");
+  public static final StringId GatewayReceiver_ALREADY_EXISTS =
+  new StringId(6665, "A Gateway Receiver already exists on this member.");
 
 Review comment:
   This StringId probably needs to be bumped to  or something that isn't 
already being used.
   
   It was actually discussed on the dev list that we probably can add this 
string to the message itself and not have to update LocalizedStrings any 
longer. 


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Enforce the uniqueness of a single gateway-receiver per member
> --
>
> Key: GEODE-3987
> URL: https://issues.apache.org/jira/browse/GEODE-3987
> Project: Geode
>  Issue Type: Bug
>Reporter: Juan José Ramos Cassella
>Assignee: Juan José Ramos Cassella
>
> Within the documentation, both in [Configure Gateway 
> Receivers|http://geode.apache.org/docs/guide/13/topologies_and_comm/multi_site_configuration/setting_up_a_multisite_system.html#setting_up_a_multisite_system__section_E3A44F85359046C7ADD12861D261637B]
>  and [gfsh create 
> gateway-receiver|http://geode.apache.org/docs/guide/13/tools_modules/gfsh/command-pages/create.html#topic_a4x_pb1_dk],
>  we state that only one {{gateway-receiver}} is allowed per member. However, 
> there is no enforcement of this rule within the code nor within the schema 
> for the {{cache.xml}} file, so the user might end up having more than one 
> {{gateway-receiver}} per host.
> It's unknown which {{gateway-receiver}} is going to be used after a restart, 
> making it hard to configure firewall rules between clusters, if any. The 
> following exception is also printed in the logs whenever we try to register 
> (only the first one is succesfull) the MBean for the {{gateway-receiver}}:
> {noformat}
> [warning 2017/11/16 15:27:46.156 PST host1-server1  Processor1> tid=0x44] javax.management.InstanceAlreadyExistsException: 
> GemFire:service=GatewayReceiver,type=Member,member=host1-server1
> org.apache.geode.management.ManagementException: 
> javax.management.InstanceAlreadyExistsException: 
> GemFire:service=GatewayReceiver,type=Member,member=host1-server1
>   at 
> org.apache.geode.management.internal.MBeanJMXAdapter.registerMBean(MBeanJMXAdapter.java:110)
>   at 
> org.apache.geode.management.internal.SystemManagementService.registerInternalMBean(SystemManagementService.java:368)
>   at 
> org.apache.geode.management.internal.beans.ManagementAdapter.createGatewayReceiverMBean(ManagementAdapter.java:471)
>   at 
> org.apache.geode.management.internal.beans.ManagementAdapter.handleGatewayReceiverStart(ManagementAdapter.java:493)
>   at 
> org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:134)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2175)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:562)
>   at 
> org.apache.geode.internal.cache.wan.GatewayReceiverImpl.start(GatewayReceiverImpl.java:194)
>   at 
> org.apache.geode.internal.cache.wan.GatewayReceiverFactoryImpl.create(GatewayReceiverFactoryImpl.java:141)
>   at 
> org.apache.geode.management.internal.cli.functions.GatewayReceiverCreateFunction.createGatewayReceiver(GatewayReceiverCreateFunction.java:164)
>   at 
> org.apache.geode.management.internal.cli.functions.GatewayReceiverCreateFunction.execute(GatewayReceiverCreateFunction.java:63)
>   at 
> org.apache.geode.internal.cache.MemberFunctionStreamingMessage.process(MemberFunctionStreamingMessage.java:186)
>   at 
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:374)
>   at 
> 

[jira] [Commented] (GEODE-3987) Enforce the uniqueness of a single gateway-receiver per member

[ASF GitHub Bot (JIRA)]

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

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

jhuynh1 commented on a change in pull request #1086: GEODE-3987: enforce 
GatewayReceiver uniqueness per member.
URL: https://github.com/apache/geode/pull/1086#discussion_r152671902
 
 

 ##
 File path: 
geode-core/src/main/java/org/apache/geode/internal/i18n/LocalizedStrings.java
 ##
 @@ -7713,6 +7713,8 @@
   new StringId(6664, "{0}: Providing synchronization event for key={1}; 
timestamp={2}: {3}");
   public static final StringId 
AbstractGatewaySender_ENQUEUEING_SYNCHRONIZATION_EVENT =
   new StringId(6665, "{0}: Enqueueing synchronization event: {1}");
+  public static final StringId GatewayReceiver_ALREADY_EXISTS =
+  new StringId(6665, "A Gateway Receiver already exists on this member.");
 
 Review comment:
   This StringId probably needs to be bumped to  or something that isn't 
already being used.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Enforce the uniqueness of a single gateway-receiver per member
> --
>
> Key: GEODE-3987
> URL: https://issues.apache.org/jira/browse/GEODE-3987
> Project: Geode
>  Issue Type: Bug
>Reporter: Juan José Ramos Cassella
>Assignee: Juan José Ramos Cassella
>
> Within the documentation, both in [Configure Gateway 
> Receivers|http://geode.apache.org/docs/guide/13/topologies_and_comm/multi_site_configuration/setting_up_a_multisite_system.html#setting_up_a_multisite_system__section_E3A44F85359046C7ADD12861D261637B]
>  and [gfsh create 
> gateway-receiver|http://geode.apache.org/docs/guide/13/tools_modules/gfsh/command-pages/create.html#topic_a4x_pb1_dk],
>  we state that only one {{gateway-receiver}} is allowed per member. However, 
> there is no enforcement of this rule within the code nor within the schema 
> for the {{cache.xml}} file, so the user might end up having more than one 
> {{gateway-receiver}} per host.
> It's unknown which {{gateway-receiver}} is going to be used after a restart, 
> making it hard to configure firewall rules between clusters, if any. The 
> following exception is also printed in the logs whenever we try to register 
> (only the first one is succesfull) the MBean for the {{gateway-receiver}}:
> {noformat}
> [warning 2017/11/16 15:27:46.156 PST host1-server1  Processor1> tid=0x44] javax.management.InstanceAlreadyExistsException: 
> GemFire:service=GatewayReceiver,type=Member,member=host1-server1
> org.apache.geode.management.ManagementException: 
> javax.management.InstanceAlreadyExistsException: 
> GemFire:service=GatewayReceiver,type=Member,member=host1-server1
>   at 
> org.apache.geode.management.internal.MBeanJMXAdapter.registerMBean(MBeanJMXAdapter.java:110)
>   at 
> org.apache.geode.management.internal.SystemManagementService.registerInternalMBean(SystemManagementService.java:368)
>   at 
> org.apache.geode.management.internal.beans.ManagementAdapter.createGatewayReceiverMBean(ManagementAdapter.java:471)
>   at 
> org.apache.geode.management.internal.beans.ManagementAdapter.handleGatewayReceiverStart(ManagementAdapter.java:493)
>   at 
> org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:134)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2175)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:562)
>   at 
> org.apache.geode.internal.cache.wan.GatewayReceiverImpl.start(GatewayReceiverImpl.java:194)
>   at 
> org.apache.geode.internal.cache.wan.GatewayReceiverFactoryImpl.create(GatewayReceiverFactoryImpl.java:141)
>   at 
> org.apache.geode.management.internal.cli.functions.GatewayReceiverCreateFunction.createGatewayReceiver(GatewayReceiverCreateFunction.java:164)
>   at 
> org.apache.geode.management.internal.cli.functions.GatewayReceiverCreateFunction.execute(GatewayReceiverCreateFunction.java:63)
>   at 
> org.apache.geode.internal.cache.MemberFunctionStreamingMessage.process(MemberFunctionStreamingMessage.java:186)
>   at 
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:374)
>   at 
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:440)
>   at 
> 

[jira] [Updated] (GEODE-4003) User Guide: Update Element Hierarchy

[Dave Barnes (JIRA)]

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

Dave Barnes updated GEODE-4003:
---
Description: 
The  Element Hierarcy (../reference/topics/cache-elements-list.html) 
needs updating. It contains deprecated elements such as  and 
, and is missing some elements, such as 
.

Consider replacing this page with a pointer to the relevant XSD(?)

  was:The  Element Hierarcy 
(../reference/topics/cache-elements-list.html) needs updating. It contains 
deprecated elements such as  and , and is missing 
some elements, such as .


> User Guide: Update  Element Hierarchy
> 
>
> Key: GEODE-4003
> URL: https://issues.apache.org/jira/browse/GEODE-4003
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Dave Barnes
>
> The  Element Hierarcy (../reference/topics/cache-elements-list.html) 
> needs updating. It contains deprecated elements such as  and 
> , and is missing some elements, such as 
> .
> Consider replacing this page with a pointer to the relevant XSD(?)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3987) Enforce the uniqueness of a single gateway-receiver per member

[ASF GitHub Bot (JIRA)]

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

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

nabarunnag commented on a change in pull request #1086: GEODE-3987: enforce 
GatewayReceiver uniqueness per member.
URL: https://github.com/apache/geode/pull/1086#discussion_r152665633
 
 

 ##
 File path: 
geode-core/src/test/resources/org/apache/geode/internal/cache/wan/GatewayReceiverXmlParsingValidationsTest.correctConfiguration[DTD].cache.xml
 ##
 @@ -0,0 +1,26 @@
+
+
+
+
+ Enforce the uniqueness of a single gateway-receiver per member
> --
>
> Key: GEODE-3987
> URL: https://issues.apache.org/jira/browse/GEODE-3987
> Project: Geode
>  Issue Type: Bug
>Reporter: Juan José Ramos Cassella
>Assignee: Juan José Ramos Cassella
>
> Within the documentation, both in [Configure Gateway 
> Receivers|http://geode.apache.org/docs/guide/13/topologies_and_comm/multi_site_configuration/setting_up_a_multisite_system.html#setting_up_a_multisite_system__section_E3A44F85359046C7ADD12861D261637B]
>  and [gfsh create 
> gateway-receiver|http://geode.apache.org/docs/guide/13/tools_modules/gfsh/command-pages/create.html#topic_a4x_pb1_dk],
>  we state that only one {{gateway-receiver}} is allowed per member. However, 
> there is no enforcement of this rule within the code nor within the schema 
> for the {{cache.xml}} file, so the user might end up having more than one 
> {{gateway-receiver}} per host.
> It's unknown which {{gateway-receiver}} is going to be used after a restart, 
> making it hard to configure firewall rules between clusters, if any. The 
> following exception is also printed in the logs whenever we try to register 
> (only the first one is succesfull) the MBean for the {{gateway-receiver}}:
> {noformat}
> [warning 2017/11/16 15:27:46.156 PST host1-server1  Processor1> tid=0x44] javax.management.InstanceAlreadyExistsException: 
> GemFire:service=GatewayReceiver,type=Member,member=host1-server1
> org.apache.geode.management.ManagementException: 
> javax.management.InstanceAlreadyExistsException: 
> GemFire:service=GatewayReceiver,type=Member,member=host1-server1
>   at 
> org.apache.geode.management.internal.MBeanJMXAdapter.registerMBean(MBeanJMXAdapter.java:110)
>   at 
> org.apache.geode.management.internal.SystemManagementService.registerInternalMBean(SystemManagementService.java:368)
>   at 
> org.apache.geode.management.internal.beans.ManagementAdapter.createGatewayReceiverMBean(ManagementAdapter.java:471)
>   at 
> org.apache.geode.management.internal.beans.ManagementAdapter.handleGatewayReceiverStart(ManagementAdapter.java:493)
>   at 
> org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:134)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2175)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:562)
>   at 
> org.apache.geode.internal.cache.wan.GatewayReceiverImpl.start(GatewayReceiverImpl.java:194)
>   at 
> org.apache.geode.internal.cache.wan.GatewayReceiverFactoryImpl.create(GatewayReceiverFactoryImpl.java:141)
>   at 
> org.apache.geode.management.internal.cli.functions.GatewayReceiverCreateFunction.createGatewayReceiver(GatewayReceiverCreateFunction.java:164)
>   at 
> org.apache.geode.management.internal.cli.functions.GatewayReceiverCreateFunction.execute(GatewayReceiverCreateFunction.java:63)
>   at 
> org.apache.geode.internal.cache.MemberFunctionStreamingMessage.process(MemberFunctionStreamingMessage.java:186)
>   at 
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:374)
>   at 
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:440)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at 
> org.apache.geode.distributed.internal.DistributionManager.runUntilShutdown(DistributionManager.java:668)
>   at 
> org.apache.geode.distributed.internal.DistributionManager$9$1.run(DistributionManager.java:1114)
>   at java.lang.Thread.run(Thread.java:745)
> Caused by: javax.management.InstanceAlreadyExistsException: 
> GemFire:service=GatewayReceiver,type=Member,member=host1-server1
>   at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:437)
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1898)
>   at 
> 

[jira] [Commented] (GEODE-3987) Enforce the uniqueness of a single gateway-receiver per member

[ASF GitHub Bot (JIRA)]

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

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

nabarunnag commented on a change in pull request #1086: GEODE-3987: enforce 
GatewayReceiver uniqueness per member.
URL: https://github.com/apache/geode/pull/1086#discussion_r152657597
 
 

 ##
 File path: 
geode-core/src/test/java/org/apache/geode/internal/cache/wan/GatewayReceiverXmlParsingValidationsTest.java
 ##
 @@ -0,0 +1,111 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more 
contributor license
+ * agreements. See the NOTICE file distributed with this work for additional 
information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache 
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the 
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software 
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY 
KIND, either express
+ * or implied. See the License for the specific language governing permissions 
and limitations under
+ * the License.
+ */
+/**
+ *
+ */
+package org.apache.geode.internal.cache.wan;
+
+import static 
org.apache.geode.distributed.ConfigurationProperties.CACHE_XML_FILE;
+import static org.apache.geode.distributed.ConfigurationProperties.MCAST_PORT;
+import static org.assertj.core.api.Assertions.assertThat;
+import static org.mockito.ArgumentMatchers.any;
+import static org.mockito.Mockito.spy;
+import static org.mockito.Mockito.times;
+import static org.mockito.Mockito.verify;
+import static org.powermock.api.mockito.PowerMockito.mockStatic;
+import static org.powermock.api.mockito.PowerMockito.when;
+
+import java.util.Arrays;
+import java.util.Collection;
+
+import org.junit.After;
+import org.junit.Before;
+import org.junit.Rule;
+import org.junit.Test;
+import org.junit.experimental.categories.Category;
+import org.junit.rules.TestName;
+import org.junit.runner.RunWith;
+import org.junit.runners.Parameterized;
+import org.powermock.core.classloader.annotations.PowerMockIgnore;
+import org.powermock.core.classloader.annotations.PrepareForTest;
+import org.powermock.modules.junit4.PowerMockRunner;
+import org.powermock.modules.junit4.PowerMockRunnerDelegate;
+
+import org.apache.geode.cache.Cache;
+import org.apache.geode.cache.CacheFactory;
+import org.apache.geode.cache.CacheXmlException;
+import org.apache.geode.cache.wan.GatewayReceiverFactory;
+import org.apache.geode.test.junit.categories.IntegrationTest;
+import org.apache.geode.test.junit.rules.serializable.SerializableTestName;
+import org.apache.geode.util.test.TestUtil;
+
+@RunWith(PowerMockRunner.class)
+@Category(IntegrationTest.class)
+@PrepareForTest(WANServiceProvider.class)
+@PowerMockRunnerDelegate(Parameterized.class)
+@PowerMockIgnore({"javax.management.*", "javax.security.*", 
"*.IntegrationTest"})
+public class GatewayReceiverXmlParsingValidationsTest {
 
 Review comment:
   Could this be renamed to GatewayReceiverXmlParsingValidationsJUnitTest.java


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Enforce the uniqueness of a single gateway-receiver per member
> --
>
> Key: GEODE-3987
> URL: https://issues.apache.org/jira/browse/GEODE-3987
> Project: Geode
>  Issue Type: Bug
>Reporter: Juan José Ramos Cassella
>Assignee: Juan José Ramos Cassella
>
> Within the documentation, both in [Configure Gateway 
> Receivers|http://geode.apache.org/docs/guide/13/topologies_and_comm/multi_site_configuration/setting_up_a_multisite_system.html#setting_up_a_multisite_system__section_E3A44F85359046C7ADD12861D261637B]
>  and [gfsh create 
> gateway-receiver|http://geode.apache.org/docs/guide/13/tools_modules/gfsh/command-pages/create.html#topic_a4x_pb1_dk],
>  we state that only one {{gateway-receiver}} is allowed per member. However, 
> there is no enforcement of this rule within the code nor within the schema 
> for the {{cache.xml}} file, so the user might end up having more than one 
> {{gateway-receiver}} per host.
> It's unknown which {{gateway-receiver}} is going to be used after a restart, 
> making it hard to configure firewall rules between clusters, if any. The 
> following exception is also printed in the logs whenever we try to register 
> (only the first one is succesfull) the MBean 

[jira] [Commented] (GEODE-4007) Authentication failures/bad handshake should close the socket from the server side

[ASF GitHub Bot (JIRA)]

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

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

PivotalSarge commented on a change in pull request #1087: GEODE-4007: 
Authentication/Handshake errors should close the socket
URL: https://github.com/apache/geode/pull/1087#discussion_r152656013
 
 

 ##
 File path: 
geode-client-protocol/src/main/java/org/apache/geode/internal/protocol/operations/OperationHandler.java
 ##
 @@ -30,7 +31,11 @@
   /**
* Decode the message, deserialize contained values using the serialization 
service, do the work
* indicated on the provided cache, and return a response.
+   *
+   * @throws ConnectionStateException if the connection is in an invalid state 
for the operation in
+   * question.
*/
   Result process(SerializationService serializationService, 
Req request,
-  MessageExecutionContext messageExecutionContext) throws 
InvalidExecutionContextException;
+  MessageExecutionContext messageExecutionContext)
+  throws InvalidExecutionContextException, ConnectionStateException;
 
 Review comment:
   Is `ConnectionStateException` still thrown? Or is the `throws` just 
inherited from `ConnectionStateProcessor`?


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Authentication failures/bad handshake should close the socket from the server 
> side
> --
>
> Key: GEODE-4007
> URL: https://issues.apache.org/jira/browse/GEODE-4007
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Reporter: Brian Rowe
>
> Ensure after failed auth/handshake the server (after sending error response) 
> closes the socket and cleans up.
> While going over the code together, it looks like maybe authentication errors 
> simply leave the socket in a state where it is expecting another 
> authentication request. It might be better to close the socket from the 
> server side for various error conditions like a failed handshake or 
> authentication.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Reopened] (GEODE-3749) CI Failure: DeltaPropagationDUnitTest.testBug40165ClientReconnects

[Brian Rowe (JIRA)]

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

Brian Rowe reopened GEODE-3749:
---

Still seeing NoSubscriptionServersAvailableException with the stack trace in 
the description above even with the change Udo pushed.

> CI Failure: DeltaPropagationDUnitTest.testBug40165ClientReconnects
> --
>
> Key: GEODE-3749
> URL: https://issues.apache.org/jira/browse/GEODE-3749
> Project: Geode
>  Issue Type: Bug
>Reporter: Udo Kohlmeyer
>Assignee: Udo Kohlmeyer
> Fix For: 1.3.0
>
>
> org.apache.geode.internal.cache.DeltaPropagationDUnitTest > 
> testBug40165ClientReconnects FAILED
> org.apache.geode.cache.NoSubscriptionServersAvailableException: 
> org.apache.geode.cache.NoSubscriptionServersAvailableException: Could not 
> initialize a primary queue on startup. No queue servers available.
> at 
> org.apache.geode.cache.client.internal.QueueManagerImpl.getAllConnections(QueueManagerImpl.java:190)
> at 
> org.apache.geode.cache.client.internal.OpExecutorImpl.executeOnQueuesAndReturnPrimaryResult(OpExecutorImpl.java:540)
> at 
> org.apache.geode.cache.client.internal.PoolImpl.executeOnQueuesAndReturnPrimaryResult(PoolImpl.java:842)
> at 
> org.apache.geode.cache.client.internal.RegisterInterestOp.execute(RegisterInterestOp.java:58)
> at 
> org.apache.geode.cache.client.internal.ServerRegionProxy.registerInterest(ServerRegionProxy.java:359)
> at 
> org.apache.geode.internal.cache.LocalRegion.processSingleInterest(LocalRegion.java:3734)
> at 
> org.apache.geode.internal.cache.LocalRegion.registerInterest(LocalRegion.java:3823)
> at 
> org.apache.geode.internal.cache.LocalRegion.registerInterest(LocalRegion.java:3625)
> at 
> org.apache.geode.internal.cache.LocalRegion.registerInterest(LocalRegion.java:3620)
> at 
> org.apache.geode.internal.cache.LocalRegion.registerInterest(LocalRegion.java:3615)
> at 
> org.apache.geode.internal.cache.DeltaPropagationDUnitTest.createDurableCacheClient(DeltaPropagationDUnitTest.java:1372)
> at 
> org.apache.geode.internal.cache.DeltaPropagationDUnitTest.testBug40165ClientReconnects(DeltaPropagationDUnitTest.java:698)
> Caused by:
> org.apache.geode.cache.NoSubscriptionServersAvailableException: Could 
> not initialize a primary queue on startup. No queue servers available.
> at 
> org.apache.geode.cache.client.internal.QueueManagerImpl.initializeConnections(QueueManagerImpl.java:592)
> at 
> org.apache.geode.cache.client.internal.QueueManagerImpl.start(QueueManagerImpl.java:303)
> at 
> org.apache.geode.cache.client.internal.PoolImpl.start(PoolImpl.java:346)
> at 
> org.apache.geode.cache.client.internal.PoolImpl.finishCreate(PoolImpl.java:172)
> at 
> org.apache.geode.cache.client.internal.PoolImpl.create(PoolImpl.java:158)
> at 
> org.apache.geode.internal.cache.PoolFactoryImpl.create(PoolFactoryImpl.java:338)
> at 
> org.apache.geode.internal.cache.DeltaPropagationDUnitTest.createDurableCacheClient(DeltaPropagationDUnitTest.java:1362)
> ... 1 more



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-4007) Authentication failures/bad handshake should close the socket from the server side

[ASF GitHub Bot (JIRA)]

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

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

WireBaron opened a new pull request #1087: GEODE-4007: Authentication/Handshake 
errors should close the socket
URL: https://github.com/apache/geode/pull/1087
 
 
   @PivotalSarge @galen-pivotal @bschuchardt @upthewaterspout 
   
   This will cause the connection to be closed whenever a handshake or
authentication message fails.
   The connection will also be broken if we ever receive an unexpected 
handshake or
authenticantication message.
   
   Signed-off-by: Brian Rowe 
   
   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?
   
   - [x] 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 d...@geode.apache.org.
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Authentication failures/bad handshake should close the socket from the server 
> side
> --
>
> Key: GEODE-4007
> URL: https://issues.apache.org/jira/browse/GEODE-4007
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Reporter: Brian Rowe
>
> Ensure after failed auth/handshake the server (after sending error response) 
> closes the socket and cleans up.
> While going over the code together, it looks like maybe authentication errors 
> simply leave the socket in a state where it is expecting another 
> authentication request. It might be better to close the socket from the 
> server side for various error conditions like a failed handshake or 
> authentication.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3824) Create JDBC connection via GFSH

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-3824:


Commit a54832f3e1a05ee74cc42bd1385ae05a9081482a in geode's branch 
refs/heads/feature/GEODE-3781 from [~apa...@the9muses.net]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=a54832f ]

GEODE-3824: Allow JDBC connection configuration for gfsh

  * Fix XML parsing issues that prevented new command from functioning
  * Add missing support for extra database connection parameters


> Create JDBC connection via GFSH
> ---
>
> Key: GEODE-3824
> URL: https://issues.apache.org/jira/browse/GEODE-3824
> Project: Geode
>  Issue Type: Sub-task
>  Components: docs, regions
>Reporter: Fred Krone
>Assignee: Nick Reich
>
> Need to be able to configure establish a JDBC connection via GFSH and 
> reference it when tying a region to a DB via PDX-JDBC.
> {noformat}
> NAME
> create jdbc-connection
> SYNOPSIS
> This provides the ability to specify the parameters necessary to 
> communicate with a database through JDBC.
> SYNTAX
> create jdbc connection --name=value --url=value [--user=value] 
> [--password=value] [--params=key:value[,key:value...]]
> PARAMETERS
> name
> Set name for this connection
> Required: true
> url
> Set the url location for the database
> Required: true
> user
> Set name of user to connect to database as
> Required: false
> password
> Set the password to use when connecting to database
> Required: false
> Params
> Set of additional parameters to use when connecting to database. No 
> parameters are yet supported
> Required: false
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (GEODE-3824) Create JDBC connection via GFSH

[Nick Reich (JIRA)]

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

Nick Reich reassigned GEODE-3824:
-

Assignee: Nick Reich

> Create JDBC connection via GFSH
> ---
>
> Key: GEODE-3824
> URL: https://issues.apache.org/jira/browse/GEODE-3824
> Project: Geode
>  Issue Type: Sub-task
>  Components: docs, regions
>Reporter: Fred Krone
>Assignee: Nick Reich
>
> Need to be able to configure establish a JDBC connection via GFSH and 
> reference it when tying a region to a DB via PDX-JDBC.
> {noformat}
> NAME
> create jdbc-connection
> SYNOPSIS
> This provides the ability to specify the parameters necessary to 
> communicate with a database through JDBC.
> SYNTAX
> create jdbc connection --name=value --url=value [--user=value] 
> [--password=value] [--params=key:value[,key:value...]]
> PARAMETERS
> name
> Set name for this connection
> Required: true
> url
> Set the url location for the database
> Required: true
> user
> Set name of user to connect to database as
> Required: false
> password
> Set the password to use when connecting to database
> Required: false
> Params
> Set of additional parameters to use when connecting to database. No 
> parameters are yet supported
> Required: false
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (GEODE-3824) Create JDBC connection via GFSH

[Nick Reich (JIRA)]

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

Nick Reich updated GEODE-3824:
--
Description: 
Need to be able to configure establish a JDBC connection via GFSH and reference 
it when tying a region to a DB via PDX-JDBC.

{noformat}
NAME
create jdbc-connection
SYNOPSIS
This provides the ability to specify the parameters necessary to 
communicate with a database through JDBC.
SYNTAX
create jdbc connection --name=value --url=value [--user=value] 
[--password=value] [--params=key:value[,key:value...]]
PARAMETERS
name
Set name for this connection
Required: true
url
Set the url location for the database
Required: true
user
Set name of user to connect to database as
Required: false
password
Set the password to use when connecting to database
Required: false
Params
Set of additional parameters to use when connecting to database. No 
parameters are yet supported
Required: false
{noformat}

  was:
Need to be able to configure establish a JDBC connection via GFSH and reference 
it when tying a region to a DB via PDX-JDBC.

{noformat}
NAME
create jdbc-connection
SYNOPSIS
This provides the ability to specify the parameters necessary to 
communicate with a database through JDBC.
SYNTAX
create jdbc connection --name=value --url=value [--user=value] 
[--password=value] [--params=value[,value...]]
PARAMETERS
name
Set name for this connection
Required: true
url
Set the url location for the database
Required: true
user
Set name of user to connect to database as
Required: false
password
Set the password to use when connecting to database
Required: false
Params
Set of additional parameters to use when connecting to database. No 
parameters are yet supported
Required: false
{noformat}


> Create JDBC connection via GFSH
> ---
>
> Key: GEODE-3824
> URL: https://issues.apache.org/jira/browse/GEODE-3824
> Project: Geode
>  Issue Type: Sub-task
>  Components: docs, regions
>Reporter: Fred Krone
>
> Need to be able to configure establish a JDBC connection via GFSH and 
> reference it when tying a region to a DB via PDX-JDBC.
> {noformat}
> NAME
> create jdbc-connection
> SYNOPSIS
> This provides the ability to specify the parameters necessary to 
> communicate with a database through JDBC.
> SYNTAX
> create jdbc connection --name=value --url=value [--user=value] 
> [--password=value] [--params=key:value[,key:value...]]
> PARAMETERS
> name
> Set name for this connection
> Required: true
> url
> Set the url location for the database
> Required: true
> user
> Set name of user to connect to database as
> Required: false
> password
> Set the password to use when connecting to database
> Required: false
> Params
> Set of additional parameters to use when connecting to database. No 
> parameters are yet supported
> Required: false
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3824) Create JDBC connection via GFSH

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-3824:


Commit a54832f3e1a05ee74cc42bd1385ae05a9081482a in geode's branch 
refs/heads/feature/GEODE-3824 from [~apa...@the9muses.net]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=a54832f ]

GEODE-3824: Allow JDBC connection configuration for gfsh

  * Fix XML parsing issues that prevented new command from functioning
  * Add missing support for extra database connection parameters


> Create JDBC connection via GFSH
> ---
>
> Key: GEODE-3824
> URL: https://issues.apache.org/jira/browse/GEODE-3824
> Project: Geode
>  Issue Type: Sub-task
>  Components: docs, regions
>Reporter: Fred Krone
>
> Need to be able to configure establish a JDBC connection via GFSH and 
> reference it when tying a region to a DB via PDX-JDBC.
> {noformat}
> NAME
> create jdbc-connection
> SYNOPSIS
> This provides the ability to specify the parameters necessary to 
> communicate with a database through JDBC.
> SYNTAX
> create jdbc connection --name=value --url=value [--user=value] 
> [--password=value] [--params=value[,value...]]
> PARAMETERS
> name
> Set name for this connection
> Required: true
> url
> Set the url location for the database
> Required: true
> user
> Set name of user to connect to database as
> Required: false
> password
> Set the password to use when connecting to database
> Required: false
> Params
> Set of additional parameters to use when connecting to database. No 
> parameters are yet supported
> Required: false
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (GEODE-4010) Locator should not require non-gossip request version to be written for new protocol

[Michael Dodge (JIRA)]

Michael Dodge created GEODE-4010:


 Summary: Locator should not require non-gossip request version to 
be written for new protocol
 Key: GEODE-4010
 URL: https://issues.apache.org/jira/browse/GEODE-4010
 Project: Geode
  Issue Type: Bug
  Components: client/server
Reporter: Michael Dodge
 Fix For: 1.4.0


When connecting to a server using the new protocol, two bytes must be written, 
the communication mode and the major version. The locator, however, currently 
insists on four bytes of non-gossip request version (all zeros) being written 
_before_ the other two bytes. This insistence should be removed to ensure 
consistent behavior between locator and server for the new protocol.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (GEODE-4009) Add in JDBC library for PDX-JDBC

[Fred Krone (JIRA)]

Fred Krone created GEODE-4009:
-

 Summary: Add in JDBC library for PDX-JDBC
 Key: GEODE-4009
 URL: https://issues.apache.org/jira/browse/GEODE-4009
 Project: Geode
  Issue Type: Sub-task
  Components: regions
Reporter: Fred Krone


We need a JDBC library for connection pooling, etc.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (GEODE-4008) InvalidClassException when deserializing FunctionAdapter from pre Geode clients

[Jason Huynh (JIRA)]

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

Jason Huynh reassigned GEODE-4008:
--

Assignee: Jason Huynh

> InvalidClassException when deserializing FunctionAdapter from pre Geode 
> clients
> ---
>
> Key: GEODE-4008
> URL: https://issues.apache.org/jira/browse/GEODE-4008
> Project: Geode
>  Issue Type: Bug
>  Components: functions
>Reporter: Jason Huynh
>Assignee: Jason Huynh
>
> There was a change to deprecate FunctionAdapter in Geode, and this removed 
> the method signatures of the class.  This causes Java to assign a new 
> serialVersionUID to the class.  However we have clients pre Geode that when 
> they attempt to execute a function by serializing the function across (not 
> using a function id), the FunctionAdapter class is unable to deserialize 
> properly.
> The proposed fix is to assign a serialVersionUID to the class that matches 
> that of the pre Geode FunctionAdapter.  This will cause any Geode 1.0-1.3 
> clients to run into this same error.  However FunctionAdapter has been 
> deprecated and it would be easy enough to just change the classes to 
> implement Function.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (GEODE-4008) InvalidClassException when deserializing FunctionAdapter from pre Geode clients

[Jason Huynh (JIRA)]

Jason Huynh created GEODE-4008:
--

 Summary: InvalidClassException when deserializing FunctionAdapter 
from pre Geode clients
 Key: GEODE-4008
 URL: https://issues.apache.org/jira/browse/GEODE-4008
 Project: Geode
  Issue Type: Bug
  Components: functions
Reporter: Jason Huynh


There was a change to deprecate FunctionAdapter in Geode, and this removed the 
method signatures of the class.  This causes Java to assign a new 
serialVersionUID to the class.  However we have clients pre Geode that when 
they attempt to execute a function by serializing the function across (not 
using a function id), the FunctionAdapter class is unable to deserialize 
properly.

The proposed fix is to assign a serialVersionUID to the class that matches that 
of the pre Geode FunctionAdapter.  This will cause any Geode 1.0-1.3 clients to 
run into this same error.  However FunctionAdapter has been deprecated and it 
would be easy enough to just change the classes to implement Function.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3937) Fix NPE when executing removeFromDisk

[ASF GitHub Bot (JIRA)]

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

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

jhuynh1 commented on issue #1002: GEODE-3937:Fix NPE when executing 
removeFromDisk
URL: https://github.com/apache/geode/pull/1002#issuecomment-346399562
 
 
   You would need to do that if you want to remove a key from a 
bucketRegionQueue. Based on your test code it would be:
   
   private void clearBucketRegionTestOnly(BucketRegion bucketRegion) {
   Set keySet = bucketRegion.keySet();
for (Iterator iterator = keySet.iterator(); iterator.hasNext();) {
  Object key = iterator.next();
 ((BucketRegionQueue) bucketRegion).destroyKey(key);
}
 }
   
   However this pull request is about an NPE that does not exist in the product 
at this time, so I don't think this pull request should be committed


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Fix NPE when executing  removeFromDisk
> --
>
> Key: GEODE-3937
> URL: https://issues.apache.org/jira/browse/GEODE-3937
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Reporter: dinesh akhand
>Priority: Trivial
>
> While executing the test case or clearQueueTestOnly method. we can see 
> exception
> [vm4] java.lang.NullPointerException
> [vm4] at 
> org.apache.geode.internal.cache.entries.DiskEntry$Helper.removeFromDisk(DiskEntry.java:1519)
> [vm4] at 
> org.apache.geode.internal.cache.entries.AbstractOplogDiskRegionEntry.removePhase1(AbstractOplogDiskRegionEntry.java:50)
> [vm4] at 
> org.apache.geode.internal.cache.entries.AbstractRegionEntry.destroy(AbstractRegionEntry.java:914)
> [vm4] at 
> org.apache.geode.internal.cache.AbstractRegionMap.destroyEntry(AbstractRegionMap.java:3100)
> [vm4] at 
> org.apache.geode.internal.cache.AbstractRegionMap.destroy(AbstractRegionMap.java:1429)
> [vm4] at 
> org.apache.geode.internal.cache.LocalRegion.mapDestroy(LocalRegion.java:6465)
> [vm4] at 
> org.apache.geode.internal.cache.LocalRegion.mapDestroy(LocalRegion.java:6439)
> [vm4] at 
> org.apache.geode.internal.cache.BucketRegion.basicDestroy(BucketRegion.java:1167)
> [vm4] at 
> org.apache.geode.internal.cache.AbstractBucketRegionQueue.basicDestroy(AbstractBucketRegionQueue.java:352)
> [vm4] at 
> org.apache.geode.internal.cache.BucketRegionQueue.basicDestroy(BucketRegionQueue.java:366)
> [vm4] at 
> org.apache.geode.internal.cache.LocalRegion.validatedDestroy(LocalRegion.java:1101)
> [vm4] at 
> org.apache.geode.internal.cache.DistributedRegion.validatedDestroy(DistributedRegion.java:942)
> [vm4] at 
> org.apache.geode.internal.cache.LocalRegion.destroy(LocalRegion.java:1086)
> [vm4] at 
> org.apache.geode.internal.cache.AbstractRegion.destroy(AbstractRegion.java:315)
> [vm4] at 
> org.apache.geode.internal.cache.LocalRegion.remove(LocalRegion.java:8870)
> [vm4] at 
> org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueue.clearPartitionedRegion(ParallelGatewaySenderQueue.java:1820)
> [vm4] at 
> org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueue.clearQueue(ParallelGatewaySenderQueue.java:1795)
> [vm4] at 
> org.apache.geode.internal.cache.wan.parallel.ConcurrentParallelGatewaySenderQueue.clearQueue(ConcurrentParallelGatewaySenderQueue.java:236)
> [vm4] at 
> org.apache.geode.internal.cache.wan.WANTestBase.clearGatewaySender(WANTestBase.java:256)
> [vm4] at 
> org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueueOverflowDUnitTest.lambda$8(ParallelGatewaySenderQueueOverflowDUnitTest.java:96)
> [vm4] at 
> org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueueOverflowDUnitTest$$Lambda$42/144498586.run(Unknown
>  Source)
> [vm4] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3987) Enforce the uniqueness of a single gateway-receiver per member

[ASF GitHub Bot (JIRA)]

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

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

jujoramos opened a new pull request #1086: GEODE-3987: enforce GatewayReceiver 
uniqueness per member.
URL: https://github.com/apache/geode/pull/1086
 
 
   Enforcements added in the different creation entry points to prevent
   the existence of more than one gateway receiver per member.
   
   - Added several XML parsing tests.
   - Added integration and Junit tests.
   - DTD allows 0 or 1 occurrences of the  element.
   - XSD allows 0 or 1 occurrences of the  element.
   - GatewayReceiverFactory checks before creating new gateway receiver.
   - Existing tests modified to use new MemberVM/GfshCommandRule features.
   
   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?
   
   - [X] 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 d...@geode.apache.org.
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Enforce the uniqueness of a single gateway-receiver per member
> --
>
> Key: GEODE-3987
> URL: https://issues.apache.org/jira/browse/GEODE-3987
> Project: Geode
>  Issue Type: Bug
>Reporter: Juan José Ramos Cassella
>Assignee: Juan José Ramos Cassella
>
> Within the documentation, both in [Configure Gateway 
> Receivers|http://geode.apache.org/docs/guide/13/topologies_and_comm/multi_site_configuration/setting_up_a_multisite_system.html#setting_up_a_multisite_system__section_E3A44F85359046C7ADD12861D261637B]
>  and [gfsh create 
> gateway-receiver|http://geode.apache.org/docs/guide/13/tools_modules/gfsh/command-pages/create.html#topic_a4x_pb1_dk],
>  we state that only one {{gateway-receiver}} is allowed per member. However, 
> there is no enforcement of this rule within the code nor within the schema 
> for the {{cache.xml}} file, so the user might end up having more than one 
> {{gateway-receiver}} per host.
> It's unknown which {{gateway-receiver}} is going to be used after a restart, 
> making it hard to configure firewall rules between clusters, if any. The 
> following exception is also printed in the logs whenever we try to register 
> (only the first one is succesfull) the MBean for the {{gateway-receiver}}:
> {noformat}
> [warning 2017/11/16 15:27:46.156 PST host1-server1  Processor1> tid=0x44] javax.management.InstanceAlreadyExistsException: 
> GemFire:service=GatewayReceiver,type=Member,member=host1-server1
> org.apache.geode.management.ManagementException: 
> javax.management.InstanceAlreadyExistsException: 
> GemFire:service=GatewayReceiver,type=Member,member=host1-server1
>   at 
> org.apache.geode.management.internal.MBeanJMXAdapter.registerMBean(MBeanJMXAdapter.java:110)
>   at 
> org.apache.geode.management.internal.SystemManagementService.registerInternalMBean(SystemManagementService.java:368)
>   at 
> org.apache.geode.management.internal.beans.ManagementAdapter.createGatewayReceiverMBean(ManagementAdapter.java:471)
>   at 
> org.apache.geode.management.internal.beans.ManagementAdapter.handleGatewayReceiverStart(ManagementAdapter.java:493)
>   at 
> org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:134)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2175)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:562)
>   at 
> org.apache.geode.internal.cache.wan.GatewayReceiverImpl.start(GatewayReceiverImpl.java:194)
>   at 
> 

[jira] [Commented] (GEODE-3937) Fix NPE when executing removeFromDisk

[ASF GitHub Bot (JIRA)]

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

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

dineshpune2006 commented on issue #1002: GEODE-3937:Fix NPE when executing 
removeFromDisk
URL: https://github.com/apache/geode/pull/1002#issuecomment-346314086
 
 
   i need to use 
   BucketRegionQueue q=   
this.getBucketRegionQueueByBucketId(partitionedRegion, bucketId);
q.destroyKey(key);\
   ??


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Fix NPE when executing  removeFromDisk
> --
>
> Key: GEODE-3937
> URL: https://issues.apache.org/jira/browse/GEODE-3937
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Reporter: dinesh akhand
>Priority: Trivial
>
> While executing the test case or clearQueueTestOnly method. we can see 
> exception
> [vm4] java.lang.NullPointerException
> [vm4] at 
> org.apache.geode.internal.cache.entries.DiskEntry$Helper.removeFromDisk(DiskEntry.java:1519)
> [vm4] at 
> org.apache.geode.internal.cache.entries.AbstractOplogDiskRegionEntry.removePhase1(AbstractOplogDiskRegionEntry.java:50)
> [vm4] at 
> org.apache.geode.internal.cache.entries.AbstractRegionEntry.destroy(AbstractRegionEntry.java:914)
> [vm4] at 
> org.apache.geode.internal.cache.AbstractRegionMap.destroyEntry(AbstractRegionMap.java:3100)
> [vm4] at 
> org.apache.geode.internal.cache.AbstractRegionMap.destroy(AbstractRegionMap.java:1429)
> [vm4] at 
> org.apache.geode.internal.cache.LocalRegion.mapDestroy(LocalRegion.java:6465)
> [vm4] at 
> org.apache.geode.internal.cache.LocalRegion.mapDestroy(LocalRegion.java:6439)
> [vm4] at 
> org.apache.geode.internal.cache.BucketRegion.basicDestroy(BucketRegion.java:1167)
> [vm4] at 
> org.apache.geode.internal.cache.AbstractBucketRegionQueue.basicDestroy(AbstractBucketRegionQueue.java:352)
> [vm4] at 
> org.apache.geode.internal.cache.BucketRegionQueue.basicDestroy(BucketRegionQueue.java:366)
> [vm4] at 
> org.apache.geode.internal.cache.LocalRegion.validatedDestroy(LocalRegion.java:1101)
> [vm4] at 
> org.apache.geode.internal.cache.DistributedRegion.validatedDestroy(DistributedRegion.java:942)
> [vm4] at 
> org.apache.geode.internal.cache.LocalRegion.destroy(LocalRegion.java:1086)
> [vm4] at 
> org.apache.geode.internal.cache.AbstractRegion.destroy(AbstractRegion.java:315)
> [vm4] at 
> org.apache.geode.internal.cache.LocalRegion.remove(LocalRegion.java:8870)
> [vm4] at 
> org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueue.clearPartitionedRegion(ParallelGatewaySenderQueue.java:1820)
> [vm4] at 
> org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueue.clearQueue(ParallelGatewaySenderQueue.java:1795)
> [vm4] at 
> org.apache.geode.internal.cache.wan.parallel.ConcurrentParallelGatewaySenderQueue.clearQueue(ConcurrentParallelGatewaySenderQueue.java:236)
> [vm4] at 
> org.apache.geode.internal.cache.wan.WANTestBase.clearGatewaySender(WANTestBase.java:256)
> [vm4] at 
> org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueueOverflowDUnitTest.lambda$8(ParallelGatewaySenderQueueOverflowDUnitTest.java:96)
> [vm4] at 
> org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueueOverflowDUnitTest$$Lambda$42/144498586.run(Unknown
>  Source)
> [vm4] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)