[jira] [Updated] (GEODE-4375) Mismatch deserialization of TxCommitMessage

2018-01-24 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot updated GEODE-4375:
--
Labels: pull-request-available  (was: )

> Mismatch deserialization of TxCommitMessage
> ---
>
> Key: GEODE-4375
> URL: https://issues.apache.org/jira/browse/GEODE-4375
> Project: Geode
>  Issue Type: Bug
>  Components: serialization, transactions
>Reporter: Masaki Yamakawa
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.4.0
>
>
> I am migrating from GemFire 7.x to Geode. After migration, An exception is 
> now thrown in transaction commit. I would like to fix this problem.
> There are the following three patterns as a communication of a transaction. 
> In this last pattern, a deserialization exception is thrown.
> * CacheServer (transaction) -> CacheServer
> * Client (transaction) -> CacheServer
> * CacheServer via Pool (transaction) -> CacheServer
> In toData of TxCommitMessage.RegionCommit.FarSideEntryOp it is decided 
> whether or not to serialize ShadowKey depending on whether ClientVersion 
> exists or not. In the case of the last pattern, it is serialized because 
> ClientVersion exists. In fromData case, it decides whether or not to 
> deserialize by whether it is a Loner or not. In the case of the last pattern, 
> it is not Loner. As a result, a deserialization exception is thrown.
> Therefore, instead of judging by the internal status of each process, I'd 
> like to send a flag as to whether ShadowKey exists or not.
> Note: The disadvantage is that bytes are increased slightly.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (GEODE-4375) Mismatch deserialization of TxCommitMessage

2018-01-24 Thread Masaki Yamakawa (JIRA)
Masaki Yamakawa created GEODE-4375:
--

 Summary: Mismatch deserialization of TxCommitMessage
 Key: GEODE-4375
 URL: https://issues.apache.org/jira/browse/GEODE-4375
 Project: Geode
  Issue Type: Bug
  Components: serialization, transactions
Reporter: Masaki Yamakawa
 Fix For: 1.4.0


I am migrating from GemFire 7.x to Geode. After migration, An exception is now 
thrown in transaction commit. I would like to fix this problem.

There are the following three patterns as a communication of a transaction. In 
this last pattern, a deserialization exception is thrown.

* CacheServer (transaction) -> CacheServer
* Client (transaction) -> CacheServer
* CacheServer via Pool (transaction) -> CacheServer

In toData of TxCommitMessage.RegionCommit.FarSideEntryOp it is decided whether 
or not to serialize ShadowKey depending on whether ClientVersion exists or not. 
In the case of the last pattern, it is serialized because ClientVersion exists. 
In fromData case, it decides whether or not to deserialize by whether it is a 
Loner or not. In the case of the last pattern, it is not Loner. As a result, a 
deserialization exception is thrown.

Therefore, instead of judging by the internal status of each process, I'd like 
to send a flag as to whether ShadowKey exists or not.
Note: The disadvantage is that bytes are increased slightly.




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (GEODE-4356) Remove Cacheable.hpp

2018-01-24 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on GEODE-4356:


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

GEODE-4356: Moved Cacheable typedef to Serializable.hpp (#193)



> Remove Cacheable.hpp 
> -
>
> Key: GEODE-4356
> URL: https://issues.apache.org/jira/browse/GEODE-4356
> Project: Geode
>  Issue Type: Improvement
>  Components: native client
>Reporter: Jacob S. Barrett
>Priority: Major
>  Labels: pull-request-available
>
> Cacheable.hpp is pretty empty. Can it be removed? The single typedef needs to 
> be moved. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (GEODE-4356) Remove Cacheable.hpp

2018-01-24 Thread ASF GitHub Bot (JIRA)

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

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

pivotal-jbarrett closed pull request #193: GEODE-4356: Moved Cacheable typedef 
to Serializable.hpp
URL: https://github.com/apache/geode-native/pull/193
 
 
   

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/cppcache/include/geode/CacheLoader.hpp 
b/cppcache/include/geode/CacheLoader.hpp
index cb8759d3..3ea8e2d6 100644
--- a/cppcache/include/geode/CacheLoader.hpp
+++ b/cppcache/include/geode/CacheLoader.hpp
@@ -26,7 +26,7 @@
 
 #include "internal/geode_globals.hpp"
 #include "CacheableKey.hpp"
-#include "Cacheable.hpp"
+#include "Serializable.hpp"
 
 namespace apache {
 namespace geode {
diff --git a/cppcache/include/geode/Cacheable.hpp 
b/cppcache/include/geode/Cacheable.hpp
deleted file mode 100644
index c465bb7d..
--- a/cppcache/include/geode/Cacheable.hpp
+++ /dev/null
@@ -1,41 +0,0 @@
-/*
- * 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.
- */
-
-#pragma once
-
-#ifndef GEODE_CACHEABLE_H_
-#define GEODE_CACHEABLE_H_
-
-#include 
-#include 
-#include 
-
-#include "internal/geode_globals.hpp"
-#include "Serializable.hpp"
-#include "internal/functional.hpp"
-
-namespace apache {
-namespace geode {
-namespace client {
-
-typedef Serializable Cacheable;
-
-}  // namespace client
-}  // namespace geode
-}  // namespace apache
-
-#endif  // GEODE_CACHEABLE_H_
diff --git a/cppcache/include/geode/CacheableBuiltins.hpp 
b/cppcache/include/geode/CacheableBuiltins.hpp
index 31843775..beba9df4 100644
--- a/cppcache/include/geode/CacheableBuiltins.hpp
+++ b/cppcache/include/geode/CacheableBuiltins.hpp
@@ -27,7 +27,7 @@
 
 #include 
 
-#include "Cacheable.hpp"
+#include "Serializable.hpp"
 #include "CacheableKey.hpp"
 #include "Serializer.hpp"
 #include "CacheableKeys.hpp"
diff --git a/cppcache/include/geode/CacheableKey.hpp 
b/cppcache/include/geode/CacheableKey.hpp
index 90dbd896..7f523bd3 100644
--- a/cppcache/include/geode/CacheableKey.hpp
+++ b/cppcache/include/geode/CacheableKey.hpp
@@ -25,7 +25,7 @@
 #include 
 
 #include "internal/geode_globals.hpp"
-#include "Cacheable.hpp"
+#include "Serializable.hpp"
 #include "internal/functional.hpp"
 
 /**
diff --git a/cppcache/include/geode/CacheableObjectArray.hpp 
b/cppcache/include/geode/CacheableObjectArray.hpp
index 170e295e..0e318d2c 100644
--- a/cppcache/include/geode/CacheableObjectArray.hpp
+++ b/cppcache/include/geode/CacheableObjectArray.hpp
@@ -24,7 +24,7 @@
 #include 
 
 #include "internal/geode_globals.hpp"
-#include "Cacheable.hpp"
+#include "Serializable.hpp"
 
 /** @file
  */
diff --git a/cppcache/include/geode/CacheableUndefined.hpp 
b/cppcache/include/geode/CacheableUndefined.hpp
index b4ad91e2..ee17adef 100644
--- a/cppcache/include/geode/CacheableUndefined.hpp
+++ b/cppcache/include/geode/CacheableUndefined.hpp
@@ -23,7 +23,7 @@
 #include 
 
 #include "internal/geode_globals.hpp"
-#include "Cacheable.hpp"
+#include "Serializable.hpp"
 
 /** @file
  */
diff --git a/cppcache/include/geode/CqEvent.hpp 
b/cppcache/include/geode/CqEvent.hpp
index d8e6f687..677a312a 100644
--- a/cppcache/include/geode/CqEvent.hpp
+++ b/cppcache/include/geode/CqEvent.hpp
@@ -23,7 +23,7 @@
 #include "internal/geode_globals.hpp"
 #include "Exception.hpp"
 #include "CqOperation.hpp"
-#include "Cacheable.hpp"
+#include "Serializable.hpp"
 #include "CacheableKey.hpp"
 #include "CacheableBuiltins.hpp"
 
diff --git a/cppcache/include/geode/EntryEvent.hpp 
b/cppcache/include/geode/EntryEvent.hpp
index 52c2ca86..56f7f795 100644
--- a/cppcache/include/geode/EntryEvent.hpp
+++ b/cppcache/include/geode/EntryEvent.hpp
@@ -24,7 +24,7 @@
 
 #include "CacheableKey.hpp"
 #include "Region.hpp"
-#include "geode/Cacheable.hpp"
+#include "geode/Serializable.hpp"
 #include "internal/geode_globals.hpp"
 
 /** @file
diff --git a/cppcache/include/geode/Partition

[jira] [Resolved] (GEODE-4314) Serializable should not need to extend std::enable_shared_from_this anymore.

2018-01-24 Thread Jacob S. Barrett (JIRA)

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

Jacob S. Barrett resolved GEODE-4314.
-
Resolution: Fixed

> Serializable should not need to extend std::enable_shared_from_this anymore.
> 
>
> Key: GEODE-4314
> URL: https://issues.apache.org/jira/browse/GEODE-4314
> Project: Geode
>  Issue Type: Improvement
>  Components: native client
>Reporter: Jacob S. Barrett
>Assignee: Jacob S. Barrett
>Priority: Major
>
> Serializable should not need to extend std::enable_shared_from_this anymore 
> since fromData no longer returns a potentially new object.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (GEODE-4370) jar deployment should not require additional ports to be opened

2018-01-24 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot updated GEODE-4370:
--
Labels: pull-request-available  (was: )

> jar deployment should not require additional ports to be opened
> ---
>
> Key: GEODE-4370
> URL: https://issues.apache.org/jira/browse/GEODE-4370
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh, jmx
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
>  Labels: pull-request-available
>
> The way we're currently using the new rmi-io library ends up opening 
> ephemeral ports on the locator/manager. We should be able to piggy-back off 
> the existing default JMX/RMI port.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (GEODE-4374) ShutdownCommandOverHttpDUnitTest appears to be flaky

2018-01-24 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on GEODE-4374:


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

GEODE-4374: Mark ShutdownCommandOverHttpDUnitTest as Flaky


> ShutdownCommandOverHttpDUnitTest appears to be flaky
> 
>
> Key: GEODE-4374
> URL: https://issues.apache.org/jira/browse/GEODE-4374
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: Jens Deppe
>Priority: Major
>
> After having some successful runs in precheckin, while adding this test, it 
> now appears to be intermittently failing. I'm marking it as flaky for now.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (GEODE-4374) ShutdownCommandOverHttpDUnitTest appears to be flaky

2018-01-24 Thread Jens Deppe (JIRA)

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

Jens Deppe commented on GEODE-4374:
---

The test fails with the following in the log:
{noformat}
Command result for http://localhost:29970/geode-mgmt/v1>: 
_ __
   / _/ __/ __/ // /
  / /  __/ /___  /_  / _  / 
 / /__/ / /  _/ / // /  
/__/_/  /__/_//_/1.5.0-SNAPSHOT

Monitor and Manage Apache Geode
Successfully connected to: GemFire Manager HTTP service @ 
org.apache.geode.management.internal.web.http.support.HttpRequester@7efaad5a


[vm1] [info 2018/01/24 18:56:06.641 PST  tid=86] 
Received GFSH shutdown. Shutting down member 
192.168.1.15(Server1:76187):32771

[vm1] [info 2018/01/24 18:56:06.666 PST  tid=87] 
GemFireCache[id = 1426004240; isClosing = true; isShutDownAll = false; created 
= Wed Jan 24 18:56:05 PST 2018; server = false; copyOnRead = false; lockLease = 
120; lockTimeout = 60]: Now closing.

org.springframework.web.client.ResourceAccessException: I/O error on POST 
request for "http://localhost:29970/geode-mgmt/v1/management/commands": 
Unexpected end of file from server; nested exception is 
java.net.SocketException: Unexpected end of file from server
at 
org.springframework.web.client.RestTemplate.doExecute(RestTemplate.java:673)
at 
org.springframework.web.client.RestTemplate.execute(RestTemplate.java:635)
at 
org.apache.geode.management.internal.web.http.support.HttpRequester.executeWithResponseExtractor(HttpRequester.java:149)
at 
org.apache.geode.management.internal.web.shell.HttpOperationInvoker.processCommand(HttpOperationInvoker.java:435)
at 
org.apache.geode.management.internal.cli.shell.GfshExecutionStrategy.executeOnRemote(GfshExecutionStrategy.java:187)
at 
org.apache.geode.management.internal.cli.shell.GfshExecutionStrategy.execute(GfshExecutionStrategy.java:90)
at 
org.springframework.shell.core.AbstractShell.executeCommand(AbstractShell.java:134)
at 
org.springframework.shell.core.AbstractShell.executeScriptLine(AbstractShell.java:74)
at 
org.apache.geode.management.internal.cli.shell.Gfsh.executeScriptLine(Gfsh.java:589)
at 
org.apache.geode.management.internal.cli.HeadlessGfsh.executeCommand(HeadlessGfsh.java:101)
at 
org.apache.geode.test.junit.rules.GfshCommandRule.executeCommand(GfshCommandRule.java:222)
at 
org.apache.geode.test.junit.rules.GfshCommandRule.executeAndAssertThat(GfshCommandRule.java:248)
at 
org.apache.geode.management.internal.cli.commands.ShutdownCommandDUnitTest.testShutdownAll(ShutdownCommandDUnitTest.java:106)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
at 
org.apache.geode.test.junit.rules.DescribedExternalResource$1.evaluate(DescribedExternalResource.java:37)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:27)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.

[jira] [Created] (GEODE-4374) ShutdownCommandOverHttpDUnitTest appears to be flaky

2018-01-24 Thread Jens Deppe (JIRA)
Jens Deppe created GEODE-4374:
-

 Summary: ShutdownCommandOverHttpDUnitTest appears to be flaky
 Key: GEODE-4374
 URL: https://issues.apache.org/jira/browse/GEODE-4374
 Project: Geode
  Issue Type: Bug
  Components: gfsh
Reporter: Jens Deppe


After having some successful runs in precheckin, while adding this test, it now 
appears to be intermittently failing. I'm marking it as flaky for now.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (GEODE-4372) RemoteOperationMessage and subclasses are confusing

2018-01-24 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot updated GEODE-4372:
--
Labels: pull-request-available  (was: )

> RemoteOperationMessage and subclasses are confusing
> ---
>
> Key: GEODE-4372
> URL: https://issues.apache.org/jira/browse/GEODE-4372
> Project: Geode
>  Issue Type: Improvement
>  Components: transactions
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>Priority: Major
>  Labels: pull-request-available
>
> The RemoteOperationMessage is actually part of geode transactions but it is 
> very hard to figure this out by looking at the class. It claims in many 
> places to be part of the implementation of PartitionedRegions but is not. It 
> also throws ForceReattemptException (which should only be done when trying to 
> send a message to a PartitionedRegion bucket) and then does not handle that 
> exception and ends up throwing an InternalGemFireException.
> Action items:
>  # repackage these messages to be in a tx package
>  # remove references to PartitionedRegion in comments
>  # stop throwing ForceReattemptException
>  # change code that uses these messages that is not transactional to use some 
> other message



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (GEODE-4373) gfsh 'describe region' not showing accessor region description

2018-01-24 Thread Sai Boorlagadda (JIRA)

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

Sai Boorlagadda updated GEODE-4373:
---
Description: 
gfsh not displaying accessor region description.

on Develop:
{noformat}
Command result for : 
..
Name : testRegion
Data Policy : persistent replicate
Hosting Members : server-5
server-4
server-3
server-2

Non-Default Attributes Shared By Hosting Members 

Type   | Name| Value
-- | --- | 
Region | data-policy | PERSISTENT_REPLICATE
   | disk-store-name | testDiskStore
   | size| 0
   | scope   | distributed-ack{noformat}
 

But in v1.3.0 it used to display accessor region description as a separate 
table.
{noformat}
Command result for : 
...
Name: testRegion
Data Policy : persistent replicate
Hosting Members : server-3
  server-2

Non-Default Attributes Shared By Hosting Members  

 Type  |  Name   | Value
-- | --- | 
Region | data-policy | PERSISTENT_REPLICATE
   | disk-store-name | testDiskStore
   | size| 0
   | scope   | distributed-ack


...
Name : testRegion
Data Policy  : empty
Accessor Members : server-1

Non-Default Attributes Shared By Accessor Members  

 Type  |Name | Value
-- | --- | ---
Region | data-policy | EMPTY
   | size| 0
   | scope   | distributed-ack
{noformat}

  was:
on Develop:
{noformat}
Command result for : 
..
Name : testRegion
Data Policy : persistent replicate
Hosting Members : server-5
server-4
server-3
server-2

Non-Default Attributes Shared By Hosting Members 

Type   | Name| Value
-- | --- | 
Region | data-policy | PERSISTENT_REPLICATE
   | disk-store-name | testDiskStore
   | size| 0
   | scope   | distributed-ack{noformat}
 

But in v1.3.0 it used to display accessor region description as a separate 
table.
{noformat}
Command result for : 
...
Name: testRegion
Data Policy : persistent replicate
Hosting Members : server-3
  server-2

Non-Default Attributes Shared By Hosting Members  

 Type  |  Name   | Value
-- | --- | 
Region | data-policy | PERSISTENT_REPLICATE
   | disk-store-name | testDiskStore
   | size| 0
   | scope   | distributed-ack


...
Name : testRegion
Data Policy  : empty
Accessor Members : server-1

Non-Default Attributes Shared By Accessor Members  

 Type  |Name | Value
-- | --- | ---
Region | data-policy | EMPTY
   | size| 0
   | scope   | distributed-ack
{noformat}


> gfsh 'describe region' not showing accessor region description
> --
>
> Key: GEODE-4373
> URL: https://issues.apache.org/jira/browse/GEODE-4373
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: Sai Boorlagadda
>Priority: Major
>
> gfsh not displaying accessor region description.
> on Develop:
> {noformat}
> Command result for : 
> ..
> Name : testRegion
> Data Policy : persistent replicate
> Hosting Members : server-5
> server-4
> server-3
> server-2
> Non-Default Attributes Shared By Hosting Members 
> Type   | Name| Value
> -- | --- | 
> Region | data-policy | PERSISTENT_REPLICATE
>| disk-store-name | testDiskStore
>| size| 0
>| scope   | distributed-ack{noformat}
>  
> But in v1.3.0 it used to display accessor region description as a separate 
> table.
> {noformat}
> Command result for : 
> ...
> Name: testRegion
> Data Policy : persistent replicate
> Hosting Members : server-3
>   server-2
> Non-Default Attributes Shared By Hosting Members  
>  Type  |  Name   | Value
> -- | --- | 
> Region | data-policy | PERSISTENT_REPLICATE
>| disk-store-name | testDiskStore
>| size| 0
>| scope   | distributed-ack
> ...
> Name : testRegion
> Data Policy  : empty
> Accessor Members 

[jira] [Created] (GEODE-4373) gfsh 'describe region' not showing accessor region description

2018-01-24 Thread Sai Boorlagadda (JIRA)
Sai Boorlagadda created GEODE-4373:
--

 Summary: gfsh 'describe region' not showing accessor region 
description
 Key: GEODE-4373
 URL: https://issues.apache.org/jira/browse/GEODE-4373
 Project: Geode
  Issue Type: Bug
  Components: gfsh
Reporter: Sai Boorlagadda


on Develop:
{noformat}
Command result for : 
..
Name : testRegion
Data Policy : persistent replicate
Hosting Members : server-5
server-4
server-3
server-2

Non-Default Attributes Shared By Hosting Members 

Type   | Name| Value
-- | --- | 
Region | data-policy | PERSISTENT_REPLICATE
   | disk-store-name | testDiskStore
   | size| 0
   | scope   | distributed-ack{noformat}
 

But in v1.3.0 it used to display accessor region description as a separate 
table.
{noformat}
Command result for : 
...
Name: testRegion
Data Policy : persistent replicate
Hosting Members : server-3
  server-2

Non-Default Attributes Shared By Hosting Members  

 Type  |  Name   | Value
-- | --- | 
Region | data-policy | PERSISTENT_REPLICATE
   | disk-store-name | testDiskStore
   | size| 0
   | scope   | distributed-ack


...
Name : testRegion
Data Policy  : empty
Accessor Members : server-1

Non-Default Attributes Shared By Accessor Members  

 Type  |Name | Value
-- | --- | ---
Region | data-policy | EMPTY
   | size| 0
   | scope   | distributed-ack
{noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (GEODE-4360) User Guide: Remove --eviction-enabled option from gfsh create region doc

2018-01-24 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on GEODE-4360:


Commit 4a80ed552168e2bf177e9042d8551072f60ed395 in geode's branch 
refs/heads/release/1.4.0 from [~dbarnes97]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=4a80ed5 ]

GEODE-4360: User Guide: Remove --eviction-enabled option from gfsh create 
region doc


> User Guide: Remove --eviction-enabled option from gfsh create region doc
> 
>
> Key: GEODE-4360
> URL: https://issues.apache.org/jira/browse/GEODE-4360
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Affects Versions: 1.4.0
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>Priority: Minor
>
> This option was added to the docs per the writeup of GEODE-1897, but the 
> option was never, in fact, implemented. Remove from docs.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (GEODE-4079) Deprecate Hash Index and Hash Index APIs

2018-01-24 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on GEODE-4079:


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

GEODE-4079 Identify hash indexes as deprecated in docs for gfsh create index 
command


> Deprecate Hash Index and Hash Index APIs
> 
>
> Key: GEODE-4079
> URL: https://issues.apache.org/jira/browse/GEODE-4079
> Project: Geode
>  Issue Type: Bug
>  Components: docs, querying
>Reporter: Jason Huynh
>Assignee: Karen Smoler Miller
>Priority: Major
> Fix For: 1.4.0
>
>
> As discussed on the user and dev list, we should deprecate the Hash Index and 
> the corresponding Hash Index APIs.
> The proposal:
> Currently the Hash Index name causes confusion. It is not a traditional hash 
> look up index, but more of memory savings index.  The index does not store 
> index keys in memory and must hash the keys every time.  The index 
> synchronizes on a backing array and when the backing array needs to be 
> expanded, it currently needs to rehash all elements in the array.  This can 
> be very problematic for larger data sets.
> There were improvements made to one of the functional indexes (compact range 
> index) prior to open sourcing.  These improvements helped reduce the memory 
> consumption of that index and makes it very similar sized to a hash index, 
> but the keys still are stored in memory.  Probably close enough to be a 
> replacement for the hash index in most cases.  The read/write performance on 
> it is also faster than the hash index.
> This works includes:
> Deprecating the Hash Index Class
> Deprecating the createHashIndex API's in query Service
> Deprecating the Hash Index type in IndexTypes (if possible)
> Deprecating the gfsh commands to create hash index and hash index types



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (GEODE-4061) Adding coordinator in list member command output

2018-01-24 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on GEODE-4061:


Commit 77ea2fb87552c1fc86b6f57b79c59a8d39d8aa69 in geode's branch 
refs/heads/release/1.4.0 from Karen Miller
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=77ea2fb ]

GEODE-4061 Update docs output for gfsh list members; (#1309)

include membership coordinator in the output

> Adding coordinator in list member command output
> 
>
> Key: GEODE-4061
> URL: https://issues.apache.org/jira/browse/GEODE-4061
> Project: Geode
>  Issue Type: Bug
>  Components: docs, gfsh, messaging
>Reporter: dinesh ak
>Assignee: Karen Smoler Miller
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.4.0
>
>
> no way to find out the coordinator apart from log messages.
> i have added coordinator in list member command output.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (GEODE-4358) If internalDestory is called on a QueueConnectionImpl followed by internalClose, an NPE will occur

2018-01-24 Thread Barry Oglesby (JIRA)

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

Barry Oglesby resolved GEODE-4358.
--
   Resolution: Fixed
Fix Version/s: 1.5.0

> If internalDestory is called on a QueueConnectionImpl followed by 
> internalClose, an NPE will occur
> --
>
> Key: GEODE-4358
> URL: https://issues.apache.org/jira/browse/GEODE-4358
> Project: Geode
>  Issue Type: Bug
>  Components: client queues
>Reporter: Barry Oglesby
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.5.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> {{QueueConnectionImpl internalDestroy}} sets {{updater = null}}, but 
> {{internalClose}} does not check for null before attempting to call {{close}} 
> on the updater.
> A warning like below occurs in this case:
> {noformat}
> [warning 2017/05/30 20:13:55.512 PDT 
> edgegemfire5_rs-qnqTesting-client-7_27065  tid=0xc3] 
> Error destroying client to server connection to rs-qnqTesting-client-7:20606
> java.lang.NullPointerException
> at 
> org.apache.geode.cache.client.internal.QueueConnectionImpl.internalClose(QueueConnectionImpl.java:76)
> at 
> org.apache.geode.cache.client.internal.QueueManagerImpl.addToConnectionList(QueueManagerImpl.java:1031)
> at 
> org.apache.geode.cache.client.internal.QueueManagerImpl.recoverPrimary(QueueManagerImpl.java:897)
> at 
> org.apache.geode.cache.client.internal.QueueManagerImpl$RedundancySatisfierTask.run2(QueueManagerImpl.java:1467)
> at 
> org.apache.geode.cache.client.internal.PoolImpl$PoolTask.run(PoolImpl.java:1315)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (GEODE-4358) If internalDestory is called on a QueueConnectionImpl followed by internalClose, an NPE will occur

2018-01-24 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on GEODE-4358:


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

GEODE-4358: Added check for null updater



> If internalDestory is called on a QueueConnectionImpl followed by 
> internalClose, an NPE will occur
> --
>
> Key: GEODE-4358
> URL: https://issues.apache.org/jira/browse/GEODE-4358
> Project: Geode
>  Issue Type: Bug
>  Components: client queues
>Reporter: Barry Oglesby
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> {{QueueConnectionImpl internalDestroy}} sets {{updater = null}}, but 
> {{internalClose}} does not check for null before attempting to call {{close}} 
> on the updater.
> A warning like below occurs in this case:
> {noformat}
> [warning 2017/05/30 20:13:55.512 PDT 
> edgegemfire5_rs-qnqTesting-client-7_27065  tid=0xc3] 
> Error destroying client to server connection to rs-qnqTesting-client-7:20606
> java.lang.NullPointerException
> at 
> org.apache.geode.cache.client.internal.QueueConnectionImpl.internalClose(QueueConnectionImpl.java:76)
> at 
> org.apache.geode.cache.client.internal.QueueManagerImpl.addToConnectionList(QueueManagerImpl.java:1031)
> at 
> org.apache.geode.cache.client.internal.QueueManagerImpl.recoverPrimary(QueueManagerImpl.java:897)
> at 
> org.apache.geode.cache.client.internal.QueueManagerImpl$RedundancySatisfierTask.run2(QueueManagerImpl.java:1467)
> at 
> org.apache.geode.cache.client.internal.PoolImpl$PoolTask.run(PoolImpl.java:1315)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (GEODE-3843) gfsh shutdown error message suggests non-existent option

2018-01-24 Thread Dave Barnes (JIRA)

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

Dave Barnes resolved GEODE-3843.

   Resolution: Fixed
Fix Version/s: 1.4.0

> gfsh shutdown error message suggests non-existent option
> 
>
> Key: GEODE-3843
> URL: https://issues.apache.org/jira/browse/GEODE-3843
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: Dave Barnes
>Assignee: Srikanth Manvi
>Priority: Minor
> Fix For: 1.4.0
>
>
> 1. Start gfsh.
> 2. Start a locator.
> 3. Issue the 'shutdown' command.
> gfsh prompts for 'do you really want to...', then issues an error message 
> alerting you to the lack of data nodes. OK so far.
> This is followed by a line recommending that you use '--shutdown-locators' to 
> stop your locator.
> Should be '--include-locators=true'.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (GEODE-4372) RemoteOperationMessage and subclasses are confusing

2018-01-24 Thread Darrel Schneider (JIRA)

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

Darrel Schneider reassigned GEODE-4372:
---

Assignee: Darrel Schneider

> RemoteOperationMessage and subclasses are confusing
> ---
>
> Key: GEODE-4372
> URL: https://issues.apache.org/jira/browse/GEODE-4372
> Project: Geode
>  Issue Type: Improvement
>  Components: transactions
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>Priority: Major
>
> The RemoteOperationMessage is actually part of geode transactions but it is 
> very hard to figure this out by looking at the class. It claims in many 
> places to be part of the implementation of PartitionedRegions but is not. It 
> also throws ForceReattemptException (which should only be done when trying to 
> send a message to a PartitionedRegion bucket) and then does not handle that 
> exception and ends up throwing an InternalGemFireException.
> Action items:
>  # repackage these messages to be in a tx package
>  # remove references to PartitionedRegion in comments
>  # stop throwing ForceReattemptException
>  # change code that uses these messages that is not transactional to use some 
> other message



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (GEODE-4372) RemoteOperationMessage and subclasses are confusing

2018-01-24 Thread Darrel Schneider (JIRA)
Darrel Schneider created GEODE-4372:
---

 Summary: RemoteOperationMessage and subclasses are confusing
 Key: GEODE-4372
 URL: https://issues.apache.org/jira/browse/GEODE-4372
 Project: Geode
  Issue Type: Improvement
  Components: transactions
Reporter: Darrel Schneider


The RemoteOperationMessage is actually part of geode transactions but it is 
very hard to figure this out by looking at the class. It claims in many places 
to be part of the implementation of PartitionedRegions but is not. It also 
throws ForceReattemptException (which should only be done when trying to send a 
message to a PartitionedRegion bucket) and then does not handle that exception 
and ends up throwing an InternalGemFireException.

Action items:
 # repackage these messages to be in a tx package
 # remove references to PartitionedRegion in comments
 # stop throwing ForceReattemptException
 # change code that uses these messages that is not transactional to use some 
other message



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (GEODE-4371) Dump stacks when ci pipeline is hung

2018-01-24 Thread Jason Huynh (JIRA)
Jason Huynh created GEODE-4371:
--

 Summary: Dump stacks when ci pipeline is hung
 Key: GEODE-4371
 URL: https://issues.apache.org/jira/browse/GEODE-4371
 Project: Geode
  Issue Type: Bug
  Components: build
Reporter: Jason Huynh


When a test is hung and causes the pipeline to fail, it would be nice to have 
stacks be dumped into a location for post-mortem analysis



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (GEODE-4355) ControlFileWatchdogIntegrationTest.invokesRequestHandler_afterFileCreation fails intermittently in CI

2018-01-24 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot updated GEODE-4355:
--
Labels: Flaky pull-request-available  (was: Flaky)

> ControlFileWatchdogIntegrationTest.invokesRequestHandler_afterFileCreation 
> fails intermittently in CI
> -
>
> Key: GEODE-4355
> URL: https://issues.apache.org/jira/browse/GEODE-4355
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh, tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
>  Labels: Flaky, pull-request-available
>
> This test usually passes but failed in these CI runs:
> * 
> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/IntegrationTest/builds/98
> * 
> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/IntegrationTest/builds/123



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (GEODE-4355) ControlFileWatchdogIntegrationTest.invokesRequestHandler_afterFileCreation fails intermittently in CI

2018-01-24 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on GEODE-4355:


Commit 1c95035734f2e7266ccb01da401b1fbb13657331 in geode's branch 
refs/heads/develop from [~apa...@the9muses.net]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=1c95035 ]

GEODE-4355: use Awaitility to fix ControlFileWatchdogIntegrationTest flakiness 
(#1329)



> ControlFileWatchdogIntegrationTest.invokesRequestHandler_afterFileCreation 
> fails intermittently in CI
> -
>
> Key: GEODE-4355
> URL: https://issues.apache.org/jira/browse/GEODE-4355
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh, tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
>  Labels: Flaky, pull-request-available
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> This test usually passes but failed in these CI runs:
> * 
> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/IntegrationTest/builds/98
> * 
> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/IntegrationTest/builds/123



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (GEODE-4370) jar deployment should not require additional ports to be opened

2018-01-24 Thread Jens Deppe (JIRA)

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

Jens Deppe updated GEODE-4370:
--
Issue Type: Bug  (was: Improvement)

> jar deployment should not require additional ports to be opened
> ---
>
> Key: GEODE-4370
> URL: https://issues.apache.org/jira/browse/GEODE-4370
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh, jmx
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
>
> The way we're currently using the new rmi-io library ends up opening 
> ephemeral ports on the locator/manager. We should be able to piggy-back off 
> the existing default JMX/RMI port.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (GEODE-4370) jar deployment should not require additional ports to be opened

2018-01-24 Thread Jens Deppe (JIRA)

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

Jens Deppe reassigned GEODE-4370:
-

Assignee: Jens Deppe

> jar deployment should not require additional ports to be opened
> ---
>
> Key: GEODE-4370
> URL: https://issues.apache.org/jira/browse/GEODE-4370
> Project: Geode
>  Issue Type: Improvement
>  Components: gfsh, jmx
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
>
> The way we're currently using the new rmi-io library ends up opening 
> ephemeral ports on the locator/manager. We should be able to piggy-back off 
> the existing default JMX/RMI port.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (GEODE-4370) jar deployment should not require additional ports to be opened

2018-01-24 Thread Jens Deppe (JIRA)
Jens Deppe created GEODE-4370:
-

 Summary: jar deployment should not require additional ports to be 
opened
 Key: GEODE-4370
 URL: https://issues.apache.org/jira/browse/GEODE-4370
 Project: Geode
  Issue Type: Improvement
  Components: gfsh, jmx
Reporter: Jens Deppe


The way we're currently using the new rmi-io library ends up opening ephemeral 
ports on the locator/manager. We should be able to piggy-back off the existing 
default JMX/RMI port.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (GEODE-4250) Users would like a command to re-establish redundancy without rebalancing

2018-01-24 Thread Fred Krone (JIRA)

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

Fred Krone commented on GEODE-4250:
---

[~gideonlow] we'll probably have a community proposal for this ... but was 
wondering if you had an opinion on what the command should look like?

quickest route: It can be added in as a parameter onto current rebalance 
(basically set --moveBuckets and --movePrimary to false t'll check for 
redundancy but wont rebalance). Or cleanest route but a little more work: it 
can be a new gfsh command 'gfsh redundancy --check'

> Users would like a command to re-establish redundancy without rebalancing
> -
>
> Key: GEODE-4250
> URL: https://issues.apache.org/jira/browse/GEODE-4250
> Project: Geode
>  Issue Type: Improvement
>  Components: docs, regions
>Reporter: Fred Krone
>Priority: Major
>
> Acceptance criteria:
> -- There is a way for a user to detect that redundancy is restored
> -- There is a way to check current redundancy
> -- Can set moveBuckets and movePrimary to false and run rebalance
>  
> Command would only succeed when the system is fully redundant.
> Re-establishing Redundancy after the loss of a peer node is typically far 
> more urgent and important than achieving better balance. The operational 
> impact of rebalancing is also much higher, forcing impacted buckets' updates 
> to be distributed to _redundancy-copies + 1_ peer processes and potentially 
> spiking p2p connections/threads (and thus load) far beyond normal operations. 
> If the system is already close to exhausting available capacity for some 
> hardware component, this can be enough to push it over-the-edge (and may 
> force the original fault to recur). This problem is exacerbated when the 
> cluster's overall capacity has been reduced due to the loss of a physical 
> server. Without the ability to separate the operational tasks of 
> re-establishing full data redundancy and rebalancing bucket partitions (that 
> are already safely redundant), system administrators may be forced to 
> provision replacement capacity _before_ they can restore full service, thus 
> increasing downtime unnecessarily.
> For these reasons, we must add the option to execute these operational tasks 
> separately.
> It still makes sense for _rebalancing_ ops to first re-establish redundancy, 
> so we can keep the existing GFSH command/behavior (it would still be useful 
> to clearly log completion of one step before the next one begins). We need a 
> new GFSH command/ResourceManager API to execute re-establishment of 
> redundancy _without_ rebalancing.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (GEODE-4330) Move logic for temporary files during backups out of BackupManager

2018-01-24 Thread Fred Krone (JIRA)

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

Fred Krone resolved GEODE-4330.
---
   Resolution: Fixed
Fix Version/s: 1.5.0

> Move logic for temporary files during backups out of BackupManager
> --
>
> Key: GEODE-4330
> URL: https://issues.apache.org/jira/browse/GEODE-4330
> Project: Geode
>  Issue Type: Sub-task
>  Components: persistence
>Reporter: Nick Reich
>Priority: Major
> Fix For: 1.5.0
>
>
> Keep track of files to be removed after backup is complete in their own class.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (GEODE-4366) GemFireCacheImpl.isClient should be implemented like GemFireCacheImpl.hasPool

2018-01-24 Thread Darrel Schneider (JIRA)

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

Darrel Schneider commented on GEODE-4366:
-

The original thinking on calling isClient instead of hasPool may have been for 
backwards compatibility.

If you are using the newer ClientCacheFactory then you are not allowed to 
create a cacheServer or gateway in that JVM. But, for backwards compatibility, 
if you do it the old way then we allowed it.

The cleanest thing to do may be to just get rid of the old way of creating a 
cache in a client.

> GemFireCacheImpl.isClient should be implemented like GemFireCacheImpl.hasPool
> -
>
> Key: GEODE-4366
> URL: https://issues.apache.org/jira/browse/GEODE-4366
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Reporter: Darrel Schneider
>Priority: Major
>
> I think you can have a "client" that does not create its cache using 
> ClientCacheFactory. Instead it can use PoolManager to create a client 
> connection pool and then use CacheFactory and configure client regions to use 
> its pools.
> If this is done then the code that calls "isClient" will return false 
> indicating that we are not a client. But if you have a pool then you are a 
> client. I think the more proper implementation of "isClient" is this:
>     return this.isClient || !getAllPools().isEmpty();
> which is the current implementation of "hasPool".
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (GEODE-4369) the InternalRegion and InternalDistributedRegion interfaces should not have generic parameters

2018-01-24 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot updated GEODE-4369:
--
Labels: pull-request-available  (was: )

> the InternalRegion and InternalDistributedRegion interfaces should not have 
> generic parameters
> --
>
> Key: GEODE-4369
> URL: https://issues.apache.org/jira/browse/GEODE-4369
> Project: Geode
>  Issue Type: Improvement
>  Components: regions
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>Priority: Major
>  Labels: pull-request-available
>
> The InternalRegion and InternalDistributedRegion interfaces exist for 
> internal code to be able to access internal implementation on classes the 
> implement the Region interface.
> The Region interface has generics so that application code can say what class 
> is used for the "key" and "value". This allows applications to be less error 
> prone and not have a bunch of casts in them.
> But internally we never know at compile time what the type of the key and 
> value of a Region instance will be. So internally we do not want the generics 
> on these classes. It just causes us to always need to add  whenever we 
> use this interface or live with a warning about using raw types.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Reopened] (GEODE-3570) Standardize on model for infinity that doesn't use int overloading

2018-01-24 Thread Addison (JIRA)

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

Addison reopened GEODE-3570:


> Standardize on model for infinity that doesn't use int overloading
> --
>
> Key: GEODE-3570
> URL: https://issues.apache.org/jira/browse/GEODE-3570
> Project: Geode
>  Issue Type: Improvement
>  Components: native client
>Reporter: Mark Hanson
>Assignee: Jacob S. Barrett
>Priority: Major
>  Labels: pull-request-available
>
> See discussion here http://markmail.org/thread/hwrkg5cra57lyvo3
> Currently the code in the native client follows various conventions. We would 
> like to standardize the code to use a model where instead of overloading int 
> to mean infinity on a wait, to create two separate function calls. One for 
> wait indefinitely wait()  and one to wait for a duration 
> waitDuration(duration)
> ThinClientRegion.cpp:2996 executeFunction needs refactoring.
> PoolAttributes.hpp:69 setRetryAttempts needs to be retitled attempts and then 
> the using functions need to use it appropriately.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (GEODE-3570) Standardize on model for infinity that doesn't use int overloading

2018-01-24 Thread Addison (JIRA)

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

Addison resolved GEODE-3570.

Resolution: Fixed

> Standardize on model for infinity that doesn't use int overloading
> --
>
> Key: GEODE-3570
> URL: https://issues.apache.org/jira/browse/GEODE-3570
> Project: Geode
>  Issue Type: Improvement
>  Components: native client
>Reporter: Mark Hanson
>Assignee: Jacob S. Barrett
>Priority: Major
>  Labels: pull-request-available
>
> See discussion here http://markmail.org/thread/hwrkg5cra57lyvo3
> Currently the code in the native client follows various conventions. We would 
> like to standardize the code to use a model where instead of overloading int 
> to mean infinity on a wait, to create two separate function calls. One for 
> wait indefinitely wait()  and one to wait for a duration 
> waitDuration(duration)
> ThinClientRegion.cpp:2996 executeFunction needs refactoring.
> PoolAttributes.hpp:69 setRetryAttempts needs to be retitled attempts and then 
> the using functions need to use it appropriately.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (GEODE-3570) Standardize on model for infinity that doesn't use int overloading

2018-01-24 Thread Addison (JIRA)

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

Addison resolved GEODE-3570.

Resolution: Done

> Standardize on model for infinity that doesn't use int overloading
> --
>
> Key: GEODE-3570
> URL: https://issues.apache.org/jira/browse/GEODE-3570
> Project: Geode
>  Issue Type: Improvement
>  Components: native client
>Reporter: Mark Hanson
>Assignee: Jacob S. Barrett
>Priority: Major
>  Labels: pull-request-available
>
> See discussion here http://markmail.org/thread/hwrkg5cra57lyvo3
> Currently the code in the native client follows various conventions. We would 
> like to standardize the code to use a model where instead of overloading int 
> to mean infinity on a wait, to create two separate function calls. One for 
> wait indefinitely wait()  and one to wait for a duration 
> waitDuration(duration)
> ThinClientRegion.cpp:2996 executeFunction needs refactoring.
> PoolAttributes.hpp:69 setRetryAttempts needs to be retitled attempts and then 
> the using functions need to use it appropriately.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (GEODE-4300) Server logs warning message when protobuf client closes socket

2018-01-24 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot updated GEODE-4300:
--
Labels: pull-request-available  (was: )

> Server logs warning message when protobuf client closes socket
> --
>
> Key: GEODE-4300
> URL: https://issues.apache.org/jira/browse/GEODE-4300
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Reporter: Bruce Schuchardt
>Priority: Major
>  Labels: pull-request-available
>
> I noticed this in my test output when shutting down protobuf clients that 
> were using the experimental Driver:
>  
> [warning 2018/01/16 15:04:17.984 PST bridgegemfire1_bruces-mbpro_8128 
>  tid=0x55] java.io.IOException: 
> org.apache.geode.internal.protocol.exception.InvalidProtocolMessageException: 
> Failed to parse Protobuf Message
>  
> Servers shouldn't be logging warning messages when a client shuts down.  This 
> can cause an alert to go to operation monitors.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (GEODE-4300) Server logs warning message when protobuf client closes socket

2018-01-24 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on GEODE-4300:


Commit 622e2edce8a8c7539ebd16c2857dd2b8c826563e in geode's branch 
refs/heads/feature/GEODE-4300 from [~bschuchardt]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=622e2ed ]

GEODE-4300 Server logs warning message when protobuf client closes socket

Inhibit logging of a warning message on IOExceptions if the socket is
closed.


> Server logs warning message when protobuf client closes socket
> --
>
> Key: GEODE-4300
> URL: https://issues.apache.org/jira/browse/GEODE-4300
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Reporter: Bruce Schuchardt
>Priority: Major
>
> I noticed this in my test output when shutting down protobuf clients that 
> were using the experimental Driver:
>  
> [warning 2018/01/16 15:04:17.984 PST bridgegemfire1_bruces-mbpro_8128 
>  tid=0x55] java.io.IOException: 
> org.apache.geode.internal.protocol.exception.InvalidProtocolMessageException: 
> Failed to parse Protobuf Message
>  
> Servers shouldn't be logging warning messages when a client shuts down.  This 
> can cause an alert to go to operation monitors.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (GEODE-4329) Move logic for copying backup files out of BackupManager

2018-01-24 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot updated GEODE-4329:
--
Labels: pull-request-available  (was: )

> Move logic for copying backup files out of BackupManager
> 
>
> Key: GEODE-4329
> URL: https://issues.apache.org/jira/browse/GEODE-4329
> Project: Geode
>  Issue Type: Sub-task
>  Components: persistence
>Reporter: Nick Reich
>Priority: Major
>  Labels: pull-request-available
>
> Refactor out logic for copying the different files (oplogs, user files, jar, 
> etc) into own class for easier testing and separation of concerns.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (GEODE-4369) the InternalRegion and InternalDistributedRegion interfaces should not have generic parameters

2018-01-24 Thread Darrel Schneider (JIRA)
Darrel Schneider created GEODE-4369:
---

 Summary: the InternalRegion and InternalDistributedRegion 
interfaces should not have generic parameters
 Key: GEODE-4369
 URL: https://issues.apache.org/jira/browse/GEODE-4369
 Project: Geode
  Issue Type: Improvement
  Components: regions
Reporter: Darrel Schneider


The InternalRegion and InternalDistributedRegion interfaces exist for internal 
code to be able to access internal implementation on classes the implement the 
Region interface.

The Region interface has generics so that application code can say what class 
is used for the "key" and "value". This allows applications to be less error 
prone and not have a bunch of casts in them.

But internally we never know at compile time what the type of the key and value 
of a Region instance will be. So internally we do not want the generics on 
these classes. It just causes us to always need to add  whenever we use 
this interface or live with a warning about using raw types.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (GEODE-4369) the InternalRegion and InternalDistributedRegion interfaces should not have generic parameters

2018-01-24 Thread Darrel Schneider (JIRA)

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

Darrel Schneider reassigned GEODE-4369:
---

Assignee: Darrel Schneider

> the InternalRegion and InternalDistributedRegion interfaces should not have 
> generic parameters
> --
>
> Key: GEODE-4369
> URL: https://issues.apache.org/jira/browse/GEODE-4369
> Project: Geode
>  Issue Type: Improvement
>  Components: regions
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>Priority: Major
>
> The InternalRegion and InternalDistributedRegion interfaces exist for 
> internal code to be able to access internal implementation on classes the 
> implement the Region interface.
> The Region interface has generics so that application code can say what class 
> is used for the "key" and "value". This allows applications to be less error 
> prone and not have a bunch of casts in them.
> But internally we never know at compile time what the type of the key and 
> value of a Region instance will be. So internally we do not want the generics 
> on these classes. It just causes us to always need to add  whenever we 
> use this interface or live with a warning about using raw types.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (GEODE-4354) On create region command change option --skip-if-exists to --if-not-exists

2018-01-24 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot updated GEODE-4354:
--
Labels: pull-request-available  (was: )

> On create region command change option --skip-if-exists to --if-not-exists
> --
>
> Key: GEODE-4354
> URL: https://issues.apache.org/jira/browse/GEODE-4354
> Project: Geode
>  Issue Type: Improvement
>  Components: docs, gfsh
>Reporter: Barbara Pruijn
>Assignee: Dave Barnes
>Priority: Major
>  Labels: pull-request-available
>
> The gfsh {{create region}} command tries to be idempotent. If I try to create 
> the same region twice I get the below message:
> {noformat}
> Member | Status
> -- | --
> serv1  | Skipping "serv1". Region "foo" already exists.{noformat}
> Currently, there is a 
> {{--skip-if-exists}} 
> option. This should be consistent with other gfsh commands and should be 
> rename 
> {{--if-not-exists}}
> This option should also be added the {{help create region}} command.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (GEODE-4365) refactor TXCommitMessage.basicProcess() to not call getExisting

2018-01-24 Thread Darrel Schneider (JIRA)

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

Darrel Schneider resolved GEODE-4365.
-
   Resolution: Fixed
Fix Version/s: 1.5.0

> refactor TXCommitMessage.basicProcess() to not call getExisting
> ---
>
> Key: GEODE-4365
> URL: https://issues.apache.org/jira/browse/GEODE-4365
> Project: Geode
>  Issue Type: Improvement
>  Components: transactions
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.5.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> The method TXCommitMessage.basicProcess() should be changed to not call the 
> static method GemFireCacheImpl.getExisting(String).
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (GEODE-4365) refactor TXCommitMessage.basicProcess() to not call getExisting

2018-01-24 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on GEODE-4365:


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

GEODE-4365: do not call GemFireCacheImpl.getExisting (#1331)

The method already had an instance of DistributionManager
so it is now used to get the cache.

> refactor TXCommitMessage.basicProcess() to not call getExisting
> ---
>
> Key: GEODE-4365
> URL: https://issues.apache.org/jira/browse/GEODE-4365
> Project: Geode
>  Issue Type: Improvement
>  Components: transactions
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> The method TXCommitMessage.basicProcess() should be changed to not call the 
> static method GemFireCacheImpl.getExisting(String).
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (GEODE-4356) Remove Cacheable.hpp

2018-01-24 Thread ASF GitHub Bot (JIRA)

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

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

mhansonp opened a new pull request #193: GEODE-4356: Moved Cacheable typedef to 
Serializable.hpp
URL: https://github.com/apache/geode-native/pull/193
 
 
   


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


> Remove Cacheable.hpp 
> -
>
> Key: GEODE-4356
> URL: https://issues.apache.org/jira/browse/GEODE-4356
> Project: Geode
>  Issue Type: Improvement
>  Components: native client
>Reporter: Jacob S. Barrett
>Priority: Major
>  Labels: pull-request-available
>
> Cacheable.hpp is pretty empty. Can it be removed? The single typedef needs to 
> be moved. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (GEODE-4356) Remove Cacheable.hpp

2018-01-24 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot updated GEODE-4356:
--
Labels: pull-request-available  (was: )

> Remove Cacheable.hpp 
> -
>
> Key: GEODE-4356
> URL: https://issues.apache.org/jira/browse/GEODE-4356
> Project: Geode
>  Issue Type: Improvement
>  Components: native client
>Reporter: Jacob S. Barrett
>Priority: Major
>  Labels: pull-request-available
>
> Cacheable.hpp is pretty empty. Can it be removed? The single typedef needs to 
> be moved. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (GEODE-3915) supply arguments over gfsh while initializing Declarable

2018-01-24 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot updated GEODE-3915:
--
Labels: pull-request-available  (was: )

> supply arguments over gfsh while initializing Declarable
> 
>
> Key: GEODE-3915
> URL: https://issues.apache.org/jira/browse/GEODE-3915
> Project: Geode
>  Issue Type: Sub-task
>  Components: docs, gfsh
>Reporter: Swapnil Bawaskar
>Priority: Major
>  Labels: pull-request-available
>
> User implementations of the Declarable interface may want to pass in 
> arguments while the class is being initialized. We should provide ability to 
> pass these arguments from gfsh. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (GEODE-2563) All destroy commands in gfsh should be idempotent

2018-01-24 Thread Barbara Pruijn (JIRA)

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

Barbara Pruijn updated GEODE-2563:
--
Fix Version/s: 1.4.0

> All destroy commands in gfsh should be idempotent
> -
>
> Key: GEODE-2563
> URL: https://issues.apache.org/jira/browse/GEODE-2563
> Project: Geode
>  Issue Type: Improvement
>  Components: docs, gfsh
>Reporter: Swapnil Bawaskar
>Priority: Major
> Fix For: 1.4.0
>
>
> If a developer is using gfsh script to define the geode cluster, we should 
> support the ability to run the gfsh script multiple times.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (GEODE-2563) All destroy commands in gfsh should be idempotent

2018-01-24 Thread Barbara Pruijn (JIRA)

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

Barbara Pruijn updated GEODE-2563:
--
Component/s: docs

> All destroy commands in gfsh should be idempotent
> -
>
> Key: GEODE-2563
> URL: https://issues.apache.org/jira/browse/GEODE-2563
> Project: Geode
>  Issue Type: Improvement
>  Components: docs, gfsh
>Reporter: Swapnil Bawaskar
>Priority: Major
>
> If a developer is using gfsh script to define the geode cluster, we should 
> support the ability to run the gfsh script multiple times.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (GEODE-2564) gfsh destroy region should be idempotent

2018-01-24 Thread Barbara Pruijn (JIRA)

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

Barbara Pruijn resolved GEODE-2564.
---
Resolution: Fixed

> gfsh destroy region should be idempotent
> 
>
> Key: GEODE-2564
> URL: https://issues.apache.org/jira/browse/GEODE-2564
> Project: Geode
>  Issue Type: Sub-task
>  Components: gfsh
>Reporter: Swapnil Bawaskar
>Priority: Major
> Fix For: 1.4.0
>
>
> Currently, destroy region gfsh command throws an error if the region does not 
> exist. We should an option {{--if-exists}} to the destroy region command so 
> that it can be scripted.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (GEODE-2564) gfsh destroy region should be idempotent

2018-01-24 Thread Barbara Pruijn (JIRA)

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

Barbara Pruijn updated GEODE-2564:
--
Fix Version/s: 1.4.0

> gfsh destroy region should be idempotent
> 
>
> Key: GEODE-2564
> URL: https://issues.apache.org/jira/browse/GEODE-2564
> Project: Geode
>  Issue Type: Sub-task
>  Components: gfsh
>Reporter: Swapnil Bawaskar
>Priority: Major
> Fix For: 1.4.0
>
>
> Currently, destroy region gfsh command throws an error if the region does not 
> exist. We should an option {{--if-exists}} to the destroy region command so 
> that it can be scripted.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (GEODE-4079) Deprecate Hash Index and Hash Index APIs

2018-01-24 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on GEODE-4079:


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

GEODE-4079 Identify hash indexes as deprecated in docs for gfsh create index 
command


> Deprecate Hash Index and Hash Index APIs
> 
>
> Key: GEODE-4079
> URL: https://issues.apache.org/jira/browse/GEODE-4079
> Project: Geode
>  Issue Type: Bug
>  Components: docs, querying
>Reporter: Jason Huynh
>Assignee: Karen Smoler Miller
>Priority: Major
> Fix For: 1.4.0
>
>
> As discussed on the user and dev list, we should deprecate the Hash Index and 
> the corresponding Hash Index APIs.
> The proposal:
> Currently the Hash Index name causes confusion. It is not a traditional hash 
> look up index, but more of memory savings index.  The index does not store 
> index keys in memory and must hash the keys every time.  The index 
> synchronizes on a backing array and when the backing array needs to be 
> expanded, it currently needs to rehash all elements in the array.  This can 
> be very problematic for larger data sets.
> There were improvements made to one of the functional indexes (compact range 
> index) prior to open sourcing.  These improvements helped reduce the memory 
> consumption of that index and makes it very similar sized to a hash index, 
> but the keys still are stored in memory.  Probably close enough to be a 
> replacement for the hash index in most cases.  The read/write performance on 
> it is also faster than the hash index.
> This works includes:
> Deprecating the Hash Index Class
> Deprecating the createHashIndex API's in query Service
> Deprecating the Hash Index type in IndexTypes (if possible)
> Deprecating the gfsh commands to create hash index and hash index types



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (GEODE-4368) Rename LegacyServerConnection

2018-01-24 Thread Bruce Schuchardt (JIRA)
Bruce Schuchardt created GEODE-4368:
---

 Summary: Rename LegacyServerConnection
 Key: GEODE-4368
 URL: https://issues.apache.org/jira/browse/GEODE-4368
 Project: Geode
  Issue Type: Bug
  Components: client/server
Reporter: Bruce Schuchardt


When the Protobuf server module was created the class ServerConnection became 
an abstract class with LegacyServerConnection as one of its subclasses.  This 
class serves our current java and native clients and I find it very odd that 
it's named *Legacy*ServerConnection.  Let's name this something else since I 
really doubt that our native client and java client are going away any time 
soon.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (GEODE-4368) Rename LegacyServerConnection

2018-01-24 Thread Bruce Schuchardt (JIRA)

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

Bruce Schuchardt updated GEODE-4368:

Affects Version/s: 1.3.0

> Rename LegacyServerConnection
> -
>
> Key: GEODE-4368
> URL: https://issues.apache.org/jira/browse/GEODE-4368
> Project: Geode
>  Issue Type: Wish
>  Components: client/server
>Affects Versions: 1.3.0
>Reporter: Bruce Schuchardt
>Priority: Major
>
> When the Protobuf server module was created the class ServerConnection became 
> an abstract class with LegacyServerConnection as one of its subclasses.  This 
> class serves our current java and native clients and I find it very odd that 
> it's named *Legacy*ServerConnection.  Let's name this something else since I 
> really doubt that our native client and java client are going away any time 
> soon.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (GEODE-4368) Rename LegacyServerConnection

2018-01-24 Thread Bruce Schuchardt (JIRA)

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

Bruce Schuchardt updated GEODE-4368:

Issue Type: Wish  (was: Bug)

> Rename LegacyServerConnection
> -
>
> Key: GEODE-4368
> URL: https://issues.apache.org/jira/browse/GEODE-4368
> Project: Geode
>  Issue Type: Wish
>  Components: client/server
>Affects Versions: 1.3.0
>Reporter: Bruce Schuchardt
>Priority: Major
>
> When the Protobuf server module was created the class ServerConnection became 
> an abstract class with LegacyServerConnection as one of its subclasses.  This 
> class serves our current java and native clients and I find it very odd that 
> it's named *Legacy*ServerConnection.  Let's name this something else since I 
> really doubt that our native client and java client are going away any time 
> soon.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (GEODE-4322) Locator fails to start with NPE during join to the distributed system

2018-01-24 Thread Bruce Schuchardt (JIRA)

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

Bruce Schuchardt commented on GEODE-4322:
-

If you're going to shut down the whole cluster you can delete the .dat file 
when you stop each locator.  If you shut down the first locator and then change 
your mind that's okay, too.  If you restart it the locator will recover its 
state from the still-running locator.

I've asked Brian Baynes to talk with you about this ticket and am re-assigning 
it to him.

> Locator fails to start with NPE during join to the distributed system
> -
>
> Key: GEODE-4322
> URL: https://issues.apache.org/jira/browse/GEODE-4322
> Project: Geode
>  Issue Type: Bug
>  Components: membership
>Affects Versions: 1.2.0
>Reporter: Vahram Aharonyan
>Assignee: Brian Baynes
>Priority: Major
>
> Found out that after setting security-udp-dhalgo=AES:128 in prorperties files 
> sometimes  locator is failing to come online with the following Exception:
> [severe 2018/01/19 04:22:12.194 PST  tid=0x45] 
> Exception in processing request from 10.144.248.41
> java.lang.RuntimeException: Not found public key for member 
> 16nodedata6(d4b4f5d4-47d2-44b1-a07c-6a7f5755e52d:11493):10002
>  at 
> org.apache.geode.distributed.internal.membership.gms.messenger.GMSEncrypt.getPublicKey(GMSEncrypt.java:177)
>  at 
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger.getPublicKey(JGroupsMessenger.java:1365)
>  at 
> org.apache.geode.distributed.internal.membership.gms.locator.GMSLocator.processRequest(GMSLocator.java:271)
>  at 
> org.apache.geode.distributed.internal.InternalLocator$PrimaryHandler.processRequest(InternalLocator.java:1256)
>  at 
> org.apache.geode.distributed.internal.tcpserver.TcpServer.lambda$processRequest$0(TcpServer.java:401)
>  at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>  at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>  at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.NullPointerException
>  at 
> org.apache.geode.distributed.internal.membership.gms.messenger.GMSEncrypt.getPeerEncryptor(GMSEncrypt.java:258)
>  at 
> org.apache.geode.distributed.internal.membership.gms.messenger.GMSEncrypt.getPublicKey(GMSEncrypt.java:175)
>  ... 7 more
>  at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>  at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>  at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.NullPointerException
>  at 
> org.apache.geode.distributed.internal.membership.gms.messenger.GMSEncrypt.getPeerEncryptor(GMSEncrypt.java:258)
>  at 
> org.apache.geode.distributed.internal.membership.gms.messenger.GMSEncrypt.getPublicKey(GMSEncrypt.java:175)
>  ... 7 more
> Please note, that generally this issue is hit after cluster restart. This is 
> important, as during poweroff locator can go offline first and one of other 
> members will become coordinator and update view file accordingly.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (GEODE-4322) Locator fails to start with NPE during join to the distributed system

2018-01-24 Thread Bruce Schuchardt (JIRA)

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

Bruce Schuchardt reassigned GEODE-4322:
---

Assignee: Brian Baynes  (was: Bruce Schuchardt)

> Locator fails to start with NPE during join to the distributed system
> -
>
> Key: GEODE-4322
> URL: https://issues.apache.org/jira/browse/GEODE-4322
> Project: Geode
>  Issue Type: Bug
>  Components: membership
>Affects Versions: 1.2.0
>Reporter: Vahram Aharonyan
>Assignee: Brian Baynes
>Priority: Major
>
> Found out that after setting security-udp-dhalgo=AES:128 in prorperties files 
> sometimes  locator is failing to come online with the following Exception:
> [severe 2018/01/19 04:22:12.194 PST  tid=0x45] 
> Exception in processing request from 10.144.248.41
> java.lang.RuntimeException: Not found public key for member 
> 16nodedata6(d4b4f5d4-47d2-44b1-a07c-6a7f5755e52d:11493):10002
>  at 
> org.apache.geode.distributed.internal.membership.gms.messenger.GMSEncrypt.getPublicKey(GMSEncrypt.java:177)
>  at 
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger.getPublicKey(JGroupsMessenger.java:1365)
>  at 
> org.apache.geode.distributed.internal.membership.gms.locator.GMSLocator.processRequest(GMSLocator.java:271)
>  at 
> org.apache.geode.distributed.internal.InternalLocator$PrimaryHandler.processRequest(InternalLocator.java:1256)
>  at 
> org.apache.geode.distributed.internal.tcpserver.TcpServer.lambda$processRequest$0(TcpServer.java:401)
>  at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>  at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>  at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.NullPointerException
>  at 
> org.apache.geode.distributed.internal.membership.gms.messenger.GMSEncrypt.getPeerEncryptor(GMSEncrypt.java:258)
>  at 
> org.apache.geode.distributed.internal.membership.gms.messenger.GMSEncrypt.getPublicKey(GMSEncrypt.java:175)
>  ... 7 more
>  at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>  at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>  at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.NullPointerException
>  at 
> org.apache.geode.distributed.internal.membership.gms.messenger.GMSEncrypt.getPeerEncryptor(GMSEncrypt.java:258)
>  at 
> org.apache.geode.distributed.internal.membership.gms.messenger.GMSEncrypt.getPublicKey(GMSEncrypt.java:175)
>  ... 7 more
> Please note, that generally this issue is hit after cluster restart. This is 
> important, as during poweroff locator can go offline first and one of other 
> members will become coordinator and update view file accordingly.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (GEODE-3003) Geode doesn't start after cluster restart when using cluster-configuration

2018-01-24 Thread Bruce Schuchardt (JIRA)

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

Bruce Schuchardt commented on GEODE-3003:
-

I think this is fixed by the changes for GEODE-3052 & can be closed.

> Geode doesn't start after cluster restart when using cluster-configuration
> --
>
> Key: GEODE-3003
> URL: https://issues.apache.org/jira/browse/GEODE-3003
> Project: Geode
>  Issue Type: Bug
>  Components: configuration, membership
>Reporter: Anton Mironenko
>Assignee: Jinmei Liao
>Priority: Major
> Attachments: 20170522-geode-klyazma.zip, 20170522-geode-vyazma.zip, 
> 20170608-host1-locator0.zip, 20170608-host2-locator0.zip, geode-host1.zip, 
> geode-host2.zip, readme.txt
>
>
> There is a two-host Geode cluster with locator and server on each host.
> First start of all nodes goes well.
> Then all nodes are gracefully stopped (kill [locator-PID] [server-PID]).
> The second start goes wrong: the locator on the first host always doesn't 
> join the rest of the cluster with the error in the locator log:
> "Region /_ConfigurationRegion has potentially stale data. It is waiting for 
> another member to recover the latest data."
> And sometimes (once per 5 starts) some server shuts down just after start 
> with the error 
> "org.apache.geode.GemFireConfigException: cluster configuration service not 
> available".
> This bug started appearing only when we moved to Geode 1.1.1. And it totally 
> blocks us.
> On GemFire 8.2.1 there was no such a bug.
> This is very easy to reproduce.
> 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)-3) for host2, the folder where you unzip the file should 
> be the same as on the first host
> Test running:
> ---
> 1) rm -rf {locator0,server1}
> 2) run ./start-locator.sh; ./start-server.sh on host1, then on host2. See 
> that this cluster start is successful.
> 3) kill locator and server processes first on host1, then on host2
>   kill [locator-PID] [server-PID]
> 4) run 
>   ./start-locator.sh; ./start-server.sh 
> on host1, then on host2. Make sure the interval between this command run on 
> two hosts is less than 1 second!
> 5) see via gfsh that actually there are two clusters: "host1-locator" and 
> "host1-server, host2-locator, host2-server" instead of one cluster. And 
> sometimes there is no "host1-server", because it shutdown with the error 
>   "Region /_ConfigurationRegion has potentially stale data. It is waiting for 
> another member to recover the latest data.".



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (GEODE-4138) Skipped DistributedTest ShutdownCommandDUnitTest fails over http

2018-01-24 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on GEODE-4138:


Commit 051349b0992cd374bb6e3323d625812ca2deb709 in geode's branch 
refs/heads/feature/GEODE-3928 from [~jens.deppe]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=051349b ]

GEODE-4138: Move http related test to geode-web (#1320)



> Skipped DistributedTest ShutdownCommandDUnitTest fails over http
> 
>
> Key: GEODE-4138
> URL: https://issues.apache.org/jira/browse/GEODE-4138
> Project: Geode
>  Issue Type: Sub-task
>  Components: gfsh, tests
>Reporter: Patrick Rhomberg
>Assignee: Jens Deppe
>Priority: Major
> Fix For: 1.5.0
>
>
> Test fails in {{gfsh.connectAndVerify}} dependent on environment.  Similar to 
> GEODE-4136.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (GEODE-4136) Skipped IntegrationTest QueryCommandTest fails under HTTP

2018-01-24 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on GEODE-4136:


Commit 4d829959d435740fb06f88f3b186290da328a803 in geode's branch 
refs/heads/feature/GEODE-3928 from [~jens.deppe]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=4d82995 ]

GEODE-4136: Move http related test to geode-web (#1319)



> Skipped IntegrationTest QueryCommandTest fails under HTTP
> -
>
> Key: GEODE-4136
> URL: https://issues.apache.org/jira/browse/GEODE-4136
> Project: Geode
>  Issue Type: Sub-task
>  Components: gfsh
>Reporter: Patrick Rhomberg
>Assignee: Jens Deppe
>Priority: Major
> Fix For: 1.5.0
>
>
> These tests can fail at {{gfsh.connectAndVerify}}, dependent on testing 
> environment.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (GEODE-4330) Move logic for temporary files during backups out of BackupManager

2018-01-24 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on GEODE-4330:


Commit 6501fb55edc11291e06d285227d5714a416916b0 in geode's branch 
refs/heads/feature/GEODE-3928 from [~nreich]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=6501fb5 ]

GEODE-4330: Move logic for handling temporary files during backup (#1323)



> Move logic for temporary files during backups out of BackupManager
> --
>
> Key: GEODE-4330
> URL: https://issues.apache.org/jira/browse/GEODE-4330
> Project: Geode
>  Issue Type: Sub-task
>  Components: persistence
>Reporter: Nick Reich
>Priority: Major
>
> Keep track of files to be removed after backup is complete in their own class.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (GEODE-3928) After calling Internal API to create lucene index after region is created, data in the region should be included in the lucene index

2018-01-24 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on GEODE-3928:


Commit 8b30367040ff7c18710493c5d50144a43c8b1027 in geode's branch 
refs/heads/feature/GEODE-3928 from [~lhughesgodfrey]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=8b30367 ]

GEODE-3928: createIndex on existing region creates lucene indexes for existing 
data


> After calling Internal API to create lucene index after region is created, 
> data in the region should be included in the lucene index
> 
>
> Key: GEODE-3928
> URL: https://issues.apache.org/jira/browse/GEODE-3928
> Project: Geode
>  Issue Type: Sub-task
>  Components: lucene
>Reporter: Jason Huynh
>Priority: Major
>
> After GEODE-3030 is complete, we will have an internal API to create an index 
> on an existing region.
> After someone calls that API on all members that have the user's region we 
> should index all of the data in the existing region.
> Acceptance:
> After calling the API to add the index to an existing region, at some point 
> in the future calling a query on the region should include all of the entries 
> that were in the existing region.
> Implementation Details:
> We think this should be implemented by modifying computeRepository so that it 
> goes through the following steps:
> # If there is no COMPLETE file in the fileAndChunkRegion for this bucket
> ## Iterate over the contents of the user region and add them to the lucene 
> index
> ## Write a COMPLETE file to the fileAndChunkRegion
> ## Return the IndexRepository
> # If there is a COMPLETE file, just return the IndexRepository.
> Note: When this task is complete, it's possible queries may block until the 
> indexing is complete. We will address that issue in GEODE-3926



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (GEODE-3974) improve permission for Internal functions

2018-01-24 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on GEODE-3974:


Commit 6df14c8b1e3c644f9f810149e80bba0c2f073dab in geode's branch 
refs/heads/feature/GEODE-3928 from [~jinmeiliao]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=6df14c8 ]

GEODE-3974: Core function security improvement (#1310)




> improve permission for Internal functions
> -
>
> Key: GEODE-3974
> URL: https://issues.apache.org/jira/browse/GEODE-3974
> Project: Geode
>  Issue Type: Bug
>  Components: docs, management
>Reporter: Jinmei Liao
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.5.0
>
>
> Internal functions needs to be updated to require appropriate permissions



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (GEODE-4317) add error handling to the experimental ProtobufDriver's Region implementation

2018-01-24 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on GEODE-4317:


Commit 63a96d9e6512fe4ba11f2e4afe382c6977322f9f in geode's branch 
refs/heads/feature/GEODE-3928 from [~bschuchardt]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=63a96d9 ]

GEODE-4317 add error handling to the experimental ProtobufDriver's Region 
implementation

I've added checks to ProtobufRegion for "error" responses from the server.
Along the way I found we were converting some keys to their string
representations and fixed that as well.

The exceptions thrown show the error text returned by the server.  The
handling of putAll responses was already looking for errors but wasn't
including the server's message text so I changed it to do so.

This closes #1322


> add error handling to the experimental ProtobufDriver's Region implementation
> -
>
> Key: GEODE-4317
> URL: https://issues.apache.org/jira/browse/GEODE-4317
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Reporter: Bruce Schuchardt
>Assignee: Bruce Schuchardt
>Priority: Major
> Fix For: 1.5.0
>
>
> The experimental Protobuf driver is not checking for error responses from the 
> server.  For instance, a put() operation with a malformed JSON document will 
> appear to succeed even though the server rejected the value.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (GEODE-4306) TTL (time to live) expiration not working properly in client side

2018-01-24 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on GEODE-4306:


Commit ea7721613a4d3ccde904a3ad820ecd2b4f9f5527 in geode's branch 
refs/heads/feature/GEODE-3928 from [~barry.oglesby]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=ea77216 ]

GEODE-4306: Added concurrent checks enabled test to event time



> TTL (time to live) expiration not working properly in client side
> -
>
> Key: GEODE-4306
> URL: https://issues.apache.org/jira/browse/GEODE-4306
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Reporter: Barry Oglesby
>Assignee: Barry Oglesby
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.5.0
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (GEODE-4315) Convert JSONWrapper to an interface

2018-01-24 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on GEODE-4315:


Commit aabad5f895f67c9432e2e4da0518346687188bad in geode's branch 
refs/heads/feature/GEODE-3928 from [~bschuchardt]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=aabad5f ]

GEODE-4315 Convert JSONWrapper to an interface

JSONWrapper is now an interface.  JSONWrapperImpl is what will be returned
by the experimental driver but it will accept anything implementing
JSONWrapper as input.


> Convert JSONWrapper to an interface
> ---
>
> Key: GEODE-4315
> URL: https://issues.apache.org/jira/browse/GEODE-4315
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Reporter: Bruce Schuchardt
>Assignee: Bruce Schuchardt
>Priority: Major
> Fix For: 1.5.0
>
>
> The experimental Protobuf driver has a JSONWrapper class to hold JSON 
> documents.  It would be nice if this can be changed to be an interface so 
> that I can write my own wrapper.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (GEODE-4360) User Guide: Remove --eviction-enabled option from gfsh create region doc

2018-01-24 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on GEODE-4360:


Commit c9a832ba673585c94f7430d9f780b7151ac49633 in geode's branch 
refs/heads/feature/GEODE-3928 from [~dbarnes97]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=c9a832b ]

GEODE-4360: User Guide: Remove --eviction-enabled option from gfsh create 
region doc


> User Guide: Remove --eviction-enabled option from gfsh create region doc
> 
>
> Key: GEODE-4360
> URL: https://issues.apache.org/jira/browse/GEODE-4360
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Affects Versions: 1.4.0
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>Priority: Minor
>
> This option was added to the docs per the writeup of GEODE-1897, but the 
> option was never, in fact, implemented. Remove from docs.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (GEODE-3570) Standardize on model for infinity that doesn't use int overloading

2018-01-24 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on GEODE-3570:


Commit 3506808f892e5f84c49f83c507d1b14477491602 in geode-native's branch 
refs/heads/develop from Jacob Barrett
[ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=3506808 ]

 GEODE-3570: Standardizes time values. (#191)

* GEODE-3570: Standardizes time values.

- Durations that can be disabled use std::chrono::duration::zero().
- Fixes durations that are out of range based on documention.
- Fixes comparison of durations against limits or disabled.
- Updates documentation for changes to duration values.
- Fixes exception throw for invalid arguments.
- Updates .NET API documents.


> Standardize on model for infinity that doesn't use int overloading
> --
>
> Key: GEODE-3570
> URL: https://issues.apache.org/jira/browse/GEODE-3570
> Project: Geode
>  Issue Type: Improvement
>  Components: native client
>Reporter: Mark Hanson
>Assignee: Jacob S. Barrett
>Priority: Major
>  Labels: pull-request-available
>
> See discussion here http://markmail.org/thread/hwrkg5cra57lyvo3
> Currently the code in the native client follows various conventions. We would 
> like to standardize the code to use a model where instead of overloading int 
> to mean infinity on a wait, to create two separate function calls. One for 
> wait indefinitely wait()  and one to wait for a duration 
> waitDuration(duration)
> ThinClientRegion.cpp:2996 executeFunction needs refactoring.
> PoolAttributes.hpp:69 setRetryAttempts needs to be retitled attempts and then 
> the using functions need to use it appropriately.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (GEODE-3570) Standardize on model for infinity that doesn't use int overloading

2018-01-24 Thread ASF GitHub Bot (JIRA)

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

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

pivotal-jbarrett closed pull request #191:  GEODE-3570: Standardizes time 
values.
URL: https://github.com/apache/geode-native/pull/191
 
 
   

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/clicache/src/PoolFactory.hpp b/clicache/src/PoolFactory.hpp
index 25ebafeb..a9c891e6 100644
--- a/clicache/src/PoolFactory.hpp
+++ b/clicache/src/PoolFactory.hpp
@@ -75,11 +75,11 @@ namespace Apache
 /// 
 /// 
 /// loadConditioningInterval the connection lifetime
-/// A value of -1 disables load conditioning.
+/// A value of 0 disables load conditioning.
 /// 
 /// 
 /// throws IllegalArgumentException if connectionLifetime
-/// is less than -1.
+/// is less than 0.
 /// 
 PoolFactory^ SetLoadConditioningInterval(TimeSpan 
loadConditioningInterval);
 
@@ -156,7 +156,7 @@ namespace Apache
 /// 
 /// 
 /// idleTimeout The amount of time that an idle connection
-/// should live before expiring. -1 indicates that connections should 
never expire.
+/// should live before expiring. 0 indicates that connections should 
never expire.
 /// 
 /// 
 /// throws IllegalArgumentException if idleTimout is less than 0.
@@ -213,7 +213,7 @@ namespace Apache
 /// 
 /// 
 /// Doing this allows gfmon to monitor clients.
-/// A value of -1 disables the sending of client statistics
+/// A value of 0 disables the sending of client statistics
 /// to the server.
 /// 
 /// 
@@ -222,7 +222,7 @@ namespace Apache
 /// 
 /// 
 /// throws IllegalArgumentException if statisticInterval
-/// is less than -1.
+/// is less than 0.
 /// 
 PoolFactory^ SetStatisticInterval(TimeSpan statisticInterval);
 
diff --git a/cppcache/include/geode/PoolFactory.hpp 
b/cppcache/include/geode/PoolFactory.hpp
index b19411dd..f77bf598 100644
--- a/cppcache/include/geode/PoolFactory.hpp
+++ b/cppcache/include/geode/PoolFactory.hpp
@@ -134,7 +134,8 @@ class _GEODE_EXPORT PoolFactory {
 
   /**
* The default frequency that client statistics are sent to the server.
-   * Current value: -1 (disabled).
+   * Current value: std::chrono::milliseconds::zero()
+   * (disabled).
*/
   static const std::chrono::milliseconds DEFAULT_STATISTIC_INTERVAL;
 
@@ -204,23 +205,25 @@ class _GEODE_EXPORT PoolFactory {
* @param connectionTimeout is the connection timeout
*
* @return a reference to this
-   * @throws std::invalid_argument if connectionTimeout
-   * is less than or equal to 0.
+   * @throws IllegalArgumentException if connectionTimeout
+   * is less than or equal to std::chrono::milliseconds::zero().
*/
-  PoolFactory& setFreeConnectionTimeout(std::chrono::milliseconds 
connectionTimeout);
+  PoolFactory& setFreeConnectionTimeout(
+  std::chrono::milliseconds connectionTimeout);
 
   /**
* Sets the load conditioning interval for this pool.
* This interval controls how frequently the pool will check to see if
* a connection to a given server should be moved to a different
* server to improve the load balance.
-   * A value of -1 disables load conditioning
+   * A value of std::chrono::milliseconds::zero() disables load
+   * conditioning.
*
* @param loadConditioningInterval is the connection lifetime
*
* @return a reference to this
-   * @throws std::invalid_argument if connectionLifetime
-   * is less than -1.
+   * @throws IllegalArgumentException if connectionLifetime
+   * is less than std::chrono::milliseconds::zero().
*/
   PoolFactory& setLoadConditioningInterval(
   std::chrono::milliseconds loadConditioningInterval);
@@ -267,8 +270,8 @@ class _GEODE_EXPORT PoolFactory {
* @param timeout duration to wait for a response from a
* server
* @return a reference to this
-   * @throws std::invalid_argument if timeout
-   * is less than or equal to 0.
+   * @throws IllegalArgumentException if timeout
+   * is less than or equal to std::chrono::milliseconds::zero().
*/
   PoolFactory& setReadTimeout(std::chrono::milliseconds timeout);
 
@@ -313,8 +316,8 @@ class _GEODE_EXPORT PoolFactory {
*
* @param idleTimeout is the duration that an idle connection
* should live no less than before expiring, actual time may be longer
-   * depending on clock resolution. A duration less than 0 indicates
-   * that connections should never expi

[jira] [Commented] (GEODE-3570) Standardize on model for infinity that doesn't use int overloading

2018-01-24 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on GEODE-3570:


Commit 3506808f892e5f84c49f83c507d1b14477491602 in geode-native's branch 
refs/heads/develop from Jacob Barrett
[ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=3506808 ]

 GEODE-3570: Standardizes time values. (#191)

* GEODE-3570: Standardizes time values.

- Durations that can be disabled use std::chrono::duration::zero().
- Fixes durations that are out of range based on documention.
- Fixes comparison of durations against limits or disabled.
- Updates documentation for changes to duration values.
- Fixes exception throw for invalid arguments.
- Updates .NET API documents.


> Standardize on model for infinity that doesn't use int overloading
> --
>
> Key: GEODE-3570
> URL: https://issues.apache.org/jira/browse/GEODE-3570
> Project: Geode
>  Issue Type: Improvement
>  Components: native client
>Reporter: Mark Hanson
>Assignee: Jacob S. Barrett
>Priority: Major
>  Labels: pull-request-available
>
> See discussion here http://markmail.org/thread/hwrkg5cra57lyvo3
> Currently the code in the native client follows various conventions. We would 
> like to standardize the code to use a model where instead of overloading int 
> to mean infinity on a wait, to create two separate function calls. One for 
> wait indefinitely wait()  and one to wait for a duration 
> waitDuration(duration)
> ThinClientRegion.cpp:2996 executeFunction needs refactoring.
> PoolAttributes.hpp:69 setRetryAttempts needs to be retitled attempts and then 
> the using functions need to use it appropriately.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (GEODE-3570) Standardize on model for infinity that doesn't use int overloading

2018-01-24 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot updated GEODE-3570:
--
Labels: pull-request-available  (was: )

> Standardize on model for infinity that doesn't use int overloading
> --
>
> Key: GEODE-3570
> URL: https://issues.apache.org/jira/browse/GEODE-3570
> Project: Geode
>  Issue Type: Improvement
>  Components: native client
>Reporter: Mark Hanson
>Assignee: Jacob S. Barrett
>Priority: Major
>  Labels: pull-request-available
>
> See discussion here http://markmail.org/thread/hwrkg5cra57lyvo3
> Currently the code in the native client follows various conventions. We would 
> like to standardize the code to use a model where instead of overloading int 
> to mean infinity on a wait, to create two separate function calls. One for 
> wait indefinitely wait()  and one to wait for a duration 
> waitDuration(duration)
> ThinClientRegion.cpp:2996 executeFunction needs refactoring.
> PoolAttributes.hpp:69 setRetryAttempts needs to be retitled attempts and then 
> the using functions need to use it appropriately.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (GEODE-4322) Locator fails to start with NPE during join to the distributed system

2018-01-24 Thread Vahram Aharonyan (JIRA)

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

Vahram Aharonyan commented on GEODE-4322:
-

Hi [~bschuchardt],

Thanks for the info.

Actually yes, we are shutting down whole cluster. 

BTW, lets assume we have 2 locators(Loc-1 and Loc-2). We stop Loc-1 and remove 
its dat file before start (while Loc-2 remains alive) , will this cause 
problems? Or we should remove all the dat files from all locator nodes only 
when whole cluster is powered off?

Thanks,

Vahram.

> Locator fails to start with NPE during join to the distributed system
> -
>
> Key: GEODE-4322
> URL: https://issues.apache.org/jira/browse/GEODE-4322
> Project: Geode
>  Issue Type: Bug
>  Components: membership
>Affects Versions: 1.2.0
>Reporter: Vahram Aharonyan
>Assignee: Bruce Schuchardt
>Priority: Major
>
> Found out that after setting security-udp-dhalgo=AES:128 in prorperties files 
> sometimes  locator is failing to come online with the following Exception:
> [severe 2018/01/19 04:22:12.194 PST  tid=0x45] 
> Exception in processing request from 10.144.248.41
> java.lang.RuntimeException: Not found public key for member 
> 16nodedata6(d4b4f5d4-47d2-44b1-a07c-6a7f5755e52d:11493):10002
>  at 
> org.apache.geode.distributed.internal.membership.gms.messenger.GMSEncrypt.getPublicKey(GMSEncrypt.java:177)
>  at 
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger.getPublicKey(JGroupsMessenger.java:1365)
>  at 
> org.apache.geode.distributed.internal.membership.gms.locator.GMSLocator.processRequest(GMSLocator.java:271)
>  at 
> org.apache.geode.distributed.internal.InternalLocator$PrimaryHandler.processRequest(InternalLocator.java:1256)
>  at 
> org.apache.geode.distributed.internal.tcpserver.TcpServer.lambda$processRequest$0(TcpServer.java:401)
>  at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>  at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>  at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.NullPointerException
>  at 
> org.apache.geode.distributed.internal.membership.gms.messenger.GMSEncrypt.getPeerEncryptor(GMSEncrypt.java:258)
>  at 
> org.apache.geode.distributed.internal.membership.gms.messenger.GMSEncrypt.getPublicKey(GMSEncrypt.java:175)
>  ... 7 more
>  at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>  at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>  at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.NullPointerException
>  at 
> org.apache.geode.distributed.internal.membership.gms.messenger.GMSEncrypt.getPeerEncryptor(GMSEncrypt.java:258)
>  at 
> org.apache.geode.distributed.internal.membership.gms.messenger.GMSEncrypt.getPublicKey(GMSEncrypt.java:175)
>  ... 7 more
> Please note, that generally this issue is hit after cluster restart. This is 
> important, as during poweroff locator can go offline first and one of other 
> members will become coordinator and update view file accordingly.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)