[jira] [Commented] (GEODE-8241) Locator does not observe locator-wait-time

2020-06-10 Thread ASF GitHub Bot (Jira)


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

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

vfordpivotal commented on pull request #5236:
URL: https://github.com/apache/geode/pull/5236#issuecomment-642423913


   I can further support this code change by having run this change multiple 
times in another test context and it addressed our start-up issues around 
start-up of locators when DNS resolution was slow. I feel very confident this 
code change addresses our issues, but would like additional feedback on the 
test code provided.



This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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


> Locator does not observe locator-wait-time
> --
>
> Key: GEODE-8241
> URL: https://issues.apache.org/jira/browse/GEODE-8241
> Project: Geode
>  Issue Type: Bug
>Reporter: Aaron Lindsey
>Assignee: Aaron Lindsey
>Priority: Major
>
> In the case where a locator starts up and is unable to connect to any other 
> locators, it may decide to become the membership coordinator even if 
> locator-wait-time has not elapsed.
> The following conditional from GMSJoinLeave.java causes the issue. There 
> should be an additional check for locator-wait-time before becoming 
> coordinator.
> {code:java}
> if (state.joinedMembersContacted <= 0 &&
> (tries >= minimumRetriesBeforeBecomingCoordinator ||
> state.locatorsContacted >= locators.size())) {
>   synchronized (viewInstallationLock) {
> becomeCoordinator();
>   }
>   return true;
> }
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8151) Convert all redis commands to return RedisResponse

2020-06-10 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on GEODE-8151:


Commit 3897ab1c7d1d526ee29f3e0da7c9fd846914b425 in geode's branch 
refs/heads/develop from Jens Deppe
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=3897ab1 ]

GEODE-8151: Convert remaining commands to use RedisResponse (#5228)



> Convert all redis commands to return RedisResponse
> --
>
> Key: GEODE-8151
> URL: https://issues.apache.org/jira/browse/GEODE-8151
> Project: Geode
>  Issue Type: Improvement
>  Components: redis
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
>
> This is an ongoing effort to refactor all redis commands to return 
> RedisResponse



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8151) Convert all redis commands to return RedisResponse

2020-06-10 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on GEODE-8151:


Commit 3897ab1c7d1d526ee29f3e0da7c9fd846914b425 in geode's branch 
refs/heads/develop from Jens Deppe
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=3897ab1 ]

GEODE-8151: Convert remaining commands to use RedisResponse (#5228)



> Convert all redis commands to return RedisResponse
> --
>
> Key: GEODE-8151
> URL: https://issues.apache.org/jira/browse/GEODE-8151
> Project: Geode
>  Issue Type: Improvement
>  Components: redis
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
>
> This is an ongoing effort to refactor all redis commands to return 
> RedisResponse



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8151) Convert all redis commands to return RedisResponse

2020-06-10 Thread ASF GitHub Bot (Jira)


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

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

jdeppe-pivotal merged pull request #5228:
URL: https://github.com/apache/geode/pull/5228


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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


> Convert all redis commands to return RedisResponse
> --
>
> Key: GEODE-8151
> URL: https://issues.apache.org/jira/browse/GEODE-8151
> Project: Geode
>  Issue Type: Improvement
>  Components: redis
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
>
> This is an ongoing effort to refactor all redis commands to return 
> RedisResponse



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8190) Create JBoss Module to load jar with manifest and classpath

2020-06-10 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on GEODE-8190:


Commit a4f50151325011c36ad1f37b260e416d8ee9af12 in geode's branch 
refs/heads/feature/GEODE-8067 from Patrick Johnson
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=a4f5015 ]

GEODE-8190 - Completed GeodeJarModuleFinder to register and load Modules. 
(#5234)

JBossModuleServiceImpl can now register and load Modules using 
ModuleDescriptor. The ModuleDescriptor
can now contain source paths to be included in the module as code sources or
have dependencies on other modules.

The same functionality can now be represented/retrieved from the Manifest file
contained within the jar files.

Amended gradle scripts for geode-common-services and geode-common to now 
generate
manifest files containing "Class-Path" dependencies and project module 
dependencies
described in the "Dependent-Modules" attribute in the manifest file.

> Create JBoss Module to load jar with manifest and classpath
> ---
>
> Key: GEODE-8190
> URL: https://issues.apache.org/jira/browse/GEODE-8190
> Project: Geode
>  Issue Type: Sub-task
>  Components: client/server
>Reporter: Udo Kohlmeyer
>Priority: Major
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8190) Create JBoss Module to load jar with manifest and classpath

2020-06-10 Thread ASF GitHub Bot (Jira)


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

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

kohlmu-pivotal merged pull request #5234:
URL: https://github.com/apache/geode/pull/5234


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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


> Create JBoss Module to load jar with manifest and classpath
> ---
>
> Key: GEODE-8190
> URL: https://issues.apache.org/jira/browse/GEODE-8190
> Project: Geode
>  Issue Type: Sub-task
>  Components: client/server
>Reporter: Udo Kohlmeyer
>Priority: Major
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8231) C++ native client keeps trying to connect to down cache server hosting a partitioned region

2020-06-10 Thread ASF GitHub Bot (Jira)


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

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

moleske commented on a change in pull request #615:
URL: https://github.com/apache/geode-native/pull/615#discussion_r438502781



##
File path: cppcache/integration/test/CMakeLists.txt
##
@@ -27,6 +27,7 @@ add_executable(cpp-integration-test
   ExampleTest.cpp
   ExpirationTest.cpp
   FunctionExecutionTest.cpp
+  PartitionRegionOpsWithRedundancyAndServerGoesDown.cpp

Review comment:
   I think it general we've been having test files end in `Test` just to 
make it super obvious when browsing files it is a test.  Also the file reads 
more like a test case rather than an identifier for a set of tests.  I think 
the test file being called `PartitionRegionOpsTest.cpp` would work since you 
use `getPartitionedRegionWithRedundancyServerGoesDown` and 
putPartitionedRegionWithRedundancyServerGoesDown` as your test names.  We can 
see if others have thoughts about naming





This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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


> C++ native client keeps trying to connect to down cache server hosting a 
> partitioned region
> ---
>
> Key: GEODE-8231
> URL: https://issues.apache.org/jira/browse/GEODE-8231
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Alberto Gomez
>Assignee: Alberto Gomez
>Priority: Major
> Fix For: 1.14.0
>
>
> If a C++ client connected to a cluster is sending operations to a partitioned 
> region and one of the server goes down, the client keeps trying to send 
> operations to the down server. This can be observed in the logs by a 
> continuous flow of lines containing: "IO error in handshake with endpoint..."
> The Java client, once it detects a server is down, it deletes it from the 
> client metadata so there are no tries to connect to the server until the 
> server is up again which is notified via a metadata refresh.
> The aim of this ticket is to align the behavior of the C++ native client to 
> the Java client.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8241) Locator does not observe locator-wait-time

2020-06-10 Thread ASF GitHub Bot (Jira)


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

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

aaronlindsey commented on pull request #5236:
URL: https://github.com/apache/geode/pull/5236#issuecomment-642340466


   FWIW, I ran the test 100x on my machine and it passed each time. When I 
reverted the change to `GMSJoinLeave.java`, I saw the test fail about 30x 
consistently.



This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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


> Locator does not observe locator-wait-time
> --
>
> Key: GEODE-8241
> URL: https://issues.apache.org/jira/browse/GEODE-8241
> Project: Geode
>  Issue Type: Bug
>Reporter: Aaron Lindsey
>Assignee: Aaron Lindsey
>Priority: Major
>
> In the case where a locator starts up and is unable to connect to any other 
> locators, it may decide to become the membership coordinator even if 
> locator-wait-time has not elapsed.
> The following conditional from GMSJoinLeave.java causes the issue. There 
> should be an additional check for locator-wait-time before becoming 
> coordinator.
> {code:java}
> if (state.joinedMembersContacted <= 0 &&
> (tries >= minimumRetriesBeforeBecomingCoordinator ||
> state.locatorsContacted >= locators.size())) {
>   synchronized (viewInstallationLock) {
> becomeCoordinator();
>   }
>   return true;
> }
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8241) Locator does not observe locator-wait-time

2020-06-10 Thread ASF GitHub Bot (Jira)


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

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

aaronlindsey opened a new pull request #5236:
URL: https://github.com/apache/geode/pull/5236


   In the case where a locator starts up and is unable to connect to any
   other locators, it may decide to become the membership coordinator even
   if locator-wait-time has not elapsed.
   
   This change addresses this issue by requiring a locator to wait for
   locator-wait-time before deciding to become the coordinator.
   
   Co-authored-by: Aaron Lindsey 
   Co-Authored-By: Vincent Ford 
   Co-authored-by: Bill Burcham 
   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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


> Locator does not observe locator-wait-time
> --
>
> Key: GEODE-8241
> URL: https://issues.apache.org/jira/browse/GEODE-8241
> Project: Geode
>  Issue Type: Bug
>Reporter: Aaron Lindsey
>Assignee: Aaron Lindsey
>Priority: Major
>
> In the case where a locator starts up and is unable to connect to any other 
> locators, it may decide to become the membership coordinator even if 
> locator-wait-time has not elapsed.
> The following conditional from GMSJoinLeave.java causes the issue. There 
> should be an additional check for locator-wait-time before becoming 
> coordinator.
> {code:java}
> if (state.joinedMembersContacted <= 0 &&
> (tries >= minimumRetriesBeforeBecomingCoordinator ||
> state.locatorsContacted >= locators.size())) {
>   synchronized (viewInstallationLock) {
> becomeCoordinator();
>   }
>   return true;
> }
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8241) Locator does not observe locator-wait-time

2020-06-10 Thread ASF GitHub Bot (Jira)


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

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

aaronlindsey commented on pull request #5236:
URL: https://github.com/apache/geode/pull/5236#issuecomment-642338908


   @vfordpivotal please review



This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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


> Locator does not observe locator-wait-time
> --
>
> Key: GEODE-8241
> URL: https://issues.apache.org/jira/browse/GEODE-8241
> Project: Geode
>  Issue Type: Bug
>Reporter: Aaron Lindsey
>Assignee: Aaron Lindsey
>Priority: Major
>
> In the case where a locator starts up and is unable to connect to any other 
> locators, it may decide to become the membership coordinator even if 
> locator-wait-time has not elapsed.
> The following conditional from GMSJoinLeave.java causes the issue. There 
> should be an additional check for locator-wait-time before becoming 
> coordinator.
> {code:java}
> if (state.joinedMembersContacted <= 0 &&
> (tries >= minimumRetriesBeforeBecomingCoordinator ||
> state.locatorsContacted >= locators.size())) {
>   synchronized (viewInstallationLock) {
> becomeCoordinator();
>   }
>   return true;
> }
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Assigned] (GEODE-8241) Locator does not observe locator-wait-time

2020-06-10 Thread Aaron Lindsey (Jira)


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

Aaron Lindsey reassigned GEODE-8241:


Assignee: Aaron Lindsey

> Locator does not observe locator-wait-time
> --
>
> Key: GEODE-8241
> URL: https://issues.apache.org/jira/browse/GEODE-8241
> Project: Geode
>  Issue Type: Bug
>Reporter: Aaron Lindsey
>Assignee: Aaron Lindsey
>Priority: Major
>
> In the case where a locator starts up and is unable to connect to any other 
> locators, it may decide to become the membership coordinator even if 
> locator-wait-time has not elapsed.
> The following conditional from GMSJoinLeave.java causes the issue. There 
> should be an additional check for locator-wait-time before becoming 
> coordinator.
> {code:java}
> if (state.joinedMembersContacted <= 0 &&
> (tries >= minimumRetriesBeforeBecomingCoordinator ||
> state.locatorsContacted >= locators.size())) {
>   synchronized (viewInstallationLock) {
> becomeCoordinator();
>   }
>   return true;
> }
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (GEODE-8241) Locator does not observe locator-wait-time

2020-06-10 Thread Aaron Lindsey (Jira)
Aaron Lindsey created GEODE-8241:


 Summary: Locator does not observe locator-wait-time
 Key: GEODE-8241
 URL: https://issues.apache.org/jira/browse/GEODE-8241
 Project: Geode
  Issue Type: Bug
Reporter: Aaron Lindsey


In the case where a locator starts up and is unable to connect to any other 
locators, it may decide to become the membership coordinator even if 
locator-wait-time has not elapsed.

The following conditional from GMSJoinLeave.java causes the issue. There should 
be an additional check for locator-wait-time before becoming coordinator.

{code:java}
if (state.joinedMembersContacted <= 0 &&
(tries >= minimumRetriesBeforeBecomingCoordinator ||
state.locatorsContacted >= locators.size())) {
  synchronized (viewInstallationLock) {
becomeCoordinator();
  }
  return true;
}
{code}




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Assigned] (GEODE-8240) Rolling upgrade fails for Locator

2020-06-10 Thread Bill Burcham (Jira)


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

Bill Burcham reassigned GEODE-8240:
---

Assignee: Ernest Burghardt

> Rolling upgrade fails for Locator
> -
>
> Key: GEODE-8240
> URL: https://issues.apache.org/jira/browse/GEODE-8240
> Project: Geode
>  Issue Type: Bug
>  Components: client/server, membership
>Reporter: Ernest Burghardt
>Assignee: Ernest Burghardt
>Priority: Major
>
> as shown in [https://github.com/apache/geode/pull/5224]
>  
>  upgrade from version 1.12 doesn't seem to occur on the Locator 
>  
> testRollServersOnPartitionedRegion_dataserializable  failure results:
> Expecting:
>  <"Member Count : 3
>  Name | Id
>   | 
> ---
>  vm2 | 127.0.0.1(vm2:35019:locator):41000(version:GEODE 1.12.0) 
> [Coordinator]
>  vm0 | 10.0.0.111(vm0:35025):41001
>  vm1 | 10.0.0.111(vm1:35030):41002
>  ">
>  not to contain:
>  <"1.12.0">



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8197) Embedded Pulse fails to start with custom log4j2.xml

2020-06-10 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on GEODE-8197:


Commit 3a2cf76b77be63f2a67df1901fe5b588cdc2c94a in geode's branch 
refs/heads/develop from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=3a2cf76 ]

GEODE-8197: Add launcher acceptance tests for custom logging config (#5196)



> Embedded Pulse fails to start with custom log4j2.xml
> 
>
> Key: GEODE-8197
> URL: https://issues.apache.org/jira/browse/GEODE-8197
> Project: Geode
>  Issue Type: Bug
>  Components: logging, pulse
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
>  Labels: GeodeOperationAPI
>
> Starting a Locator with a custom log4j2.xml referencing Geode appenders or 
> converters fails to correctly start embedded Pulse web application.
> {noformat}
> [info 2020/05/28 10:51:51.954 PDT  tid=1] Adding webapp /pulse
> 2020-05-28 10:51:53,328 main ERROR Unable to invoke factory method in class 
> org.apache.geode.alerting.log4j.internal.impl.AlertAppender for element 
> GeodeAlert: java.lang.IllegalStateException: No factory method found for 
> class org.apache.geode.alerting.log4j.internal.impl.AlertAppender 
> java.lang.IllegalStateException: No factory method found for class 
> org.apache.geode.alerting.log4j.internal.impl.AlertAppender
>   at 
> org.apache.logging.log4j.core.config.plugins.util.PluginBuilder.findFactoryMethod(PluginBuilder.java:234)
>   at 
> org.apache.logging.log4j.core.config.plugins.util.PluginBuilder.build(PluginBuilder.java:134)
>   at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.createPluginObject(AbstractConfiguration.java:1002)
>   at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:942)
>   at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:934)
>   at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.doConfigure(AbstractConfiguration.java:552)
>   at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.initialize(AbstractConfiguration.java:241)
>   at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:288)
>   at 
> org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:618)
>   at 
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:691)
>   at 
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:708)
>   at 
> org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:263)
>   at 
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:153)
>   at 
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45)
>   at org.apache.logging.log4j.LogManager.getContext(LogManager.java:194)
>   at 
> org.apache.logging.log4j.spi.AbstractLoggerAdapter.getContext(AbstractLoggerAdapter.java:138)
>   at 
> org.apache.logging.log4j.jcl.LogAdapter.getContext(LogAdapter.java:39)
>   at 
> org.apache.logging.log4j.spi.AbstractLoggerAdapter.getLogger(AbstractLoggerAdapter.java:48)
>   at 
> org.apache.logging.log4j.jcl.LogFactoryImpl.getInstance(LogFactoryImpl.java:40)
>   at 
> org.apache.logging.log4j.jcl.LogFactoryImpl.getInstance(LogFactoryImpl.java:55)
>   at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:655)
>   at 
> org.springframework.web.filter.GenericFilterBean.(GenericFilterBean.java:86)
>   at 
> org.springframework.web.filter.DelegatingFilterProxy.(DelegatingFilterProxy.java:107)
>   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>   at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>   at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler$Context.createInstance(ContextHandler.java:2520)
>   at 
> org.eclipse.jetty.servlet.ServletContextHandler$Context.createFilter(ServletContextHandler.java:1284)
>   at 
> org.eclipse.jetty.servlet.FilterHolder.initialize(FilterHolder.java:118)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.lambda$initialize$0(ServletHandler.java:751)
>   at 
> java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)
>   at 
> java.util.stream.Streams$ConcatSpliterator.forEachRemaining(Streams.java:742)
>   at 
> 

[jira] [Commented] (GEODE-8197) Embedded Pulse fails to start with custom log4j2.xml

2020-06-10 Thread ASF GitHub Bot (Jira)


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

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

kirklund merged pull request #5196:
URL: https://github.com/apache/geode/pull/5196


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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


> Embedded Pulse fails to start with custom log4j2.xml
> 
>
> Key: GEODE-8197
> URL: https://issues.apache.org/jira/browse/GEODE-8197
> Project: Geode
>  Issue Type: Bug
>  Components: logging, pulse
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
>  Labels: GeodeOperationAPI
>
> Starting a Locator with a custom log4j2.xml referencing Geode appenders or 
> converters fails to correctly start embedded Pulse web application.
> {noformat}
> [info 2020/05/28 10:51:51.954 PDT  tid=1] Adding webapp /pulse
> 2020-05-28 10:51:53,328 main ERROR Unable to invoke factory method in class 
> org.apache.geode.alerting.log4j.internal.impl.AlertAppender for element 
> GeodeAlert: java.lang.IllegalStateException: No factory method found for 
> class org.apache.geode.alerting.log4j.internal.impl.AlertAppender 
> java.lang.IllegalStateException: No factory method found for class 
> org.apache.geode.alerting.log4j.internal.impl.AlertAppender
>   at 
> org.apache.logging.log4j.core.config.plugins.util.PluginBuilder.findFactoryMethod(PluginBuilder.java:234)
>   at 
> org.apache.logging.log4j.core.config.plugins.util.PluginBuilder.build(PluginBuilder.java:134)
>   at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.createPluginObject(AbstractConfiguration.java:1002)
>   at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:942)
>   at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:934)
>   at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.doConfigure(AbstractConfiguration.java:552)
>   at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.initialize(AbstractConfiguration.java:241)
>   at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:288)
>   at 
> org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:618)
>   at 
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:691)
>   at 
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:708)
>   at 
> org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:263)
>   at 
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:153)
>   at 
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45)
>   at org.apache.logging.log4j.LogManager.getContext(LogManager.java:194)
>   at 
> org.apache.logging.log4j.spi.AbstractLoggerAdapter.getContext(AbstractLoggerAdapter.java:138)
>   at 
> org.apache.logging.log4j.jcl.LogAdapter.getContext(LogAdapter.java:39)
>   at 
> org.apache.logging.log4j.spi.AbstractLoggerAdapter.getLogger(AbstractLoggerAdapter.java:48)
>   at 
> org.apache.logging.log4j.jcl.LogFactoryImpl.getInstance(LogFactoryImpl.java:40)
>   at 
> org.apache.logging.log4j.jcl.LogFactoryImpl.getInstance(LogFactoryImpl.java:55)
>   at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:655)
>   at 
> org.springframework.web.filter.GenericFilterBean.(GenericFilterBean.java:86)
>   at 
> org.springframework.web.filter.DelegatingFilterProxy.(DelegatingFilterProxy.java:107)
>   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>   at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>   at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler$Context.createInstance(ContextHandler.java:2520)
>   at 
> org.eclipse.jetty.servlet.ServletContextHandler$Context.createFilter(ServletContextHandler.java:1284)
>   at 
> org.eclipse.jetty.servlet.FilterHolder.initialize(FilterHolder.java:118)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.lambda$initialize$0(ServletHandler.java:751)
>   at 
> 

[jira] [Commented] (GEODE-8197) Embedded Pulse fails to start with custom log4j2.xml

2020-06-10 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on GEODE-8197:


Commit 3a2cf76b77be63f2a67df1901fe5b588cdc2c94a in geode's branch 
refs/heads/develop from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=3a2cf76 ]

GEODE-8197: Add launcher acceptance tests for custom logging config (#5196)



> Embedded Pulse fails to start with custom log4j2.xml
> 
>
> Key: GEODE-8197
> URL: https://issues.apache.org/jira/browse/GEODE-8197
> Project: Geode
>  Issue Type: Bug
>  Components: logging, pulse
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
>  Labels: GeodeOperationAPI
>
> Starting a Locator with a custom log4j2.xml referencing Geode appenders or 
> converters fails to correctly start embedded Pulse web application.
> {noformat}
> [info 2020/05/28 10:51:51.954 PDT  tid=1] Adding webapp /pulse
> 2020-05-28 10:51:53,328 main ERROR Unable to invoke factory method in class 
> org.apache.geode.alerting.log4j.internal.impl.AlertAppender for element 
> GeodeAlert: java.lang.IllegalStateException: No factory method found for 
> class org.apache.geode.alerting.log4j.internal.impl.AlertAppender 
> java.lang.IllegalStateException: No factory method found for class 
> org.apache.geode.alerting.log4j.internal.impl.AlertAppender
>   at 
> org.apache.logging.log4j.core.config.plugins.util.PluginBuilder.findFactoryMethod(PluginBuilder.java:234)
>   at 
> org.apache.logging.log4j.core.config.plugins.util.PluginBuilder.build(PluginBuilder.java:134)
>   at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.createPluginObject(AbstractConfiguration.java:1002)
>   at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:942)
>   at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:934)
>   at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.doConfigure(AbstractConfiguration.java:552)
>   at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.initialize(AbstractConfiguration.java:241)
>   at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:288)
>   at 
> org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:618)
>   at 
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:691)
>   at 
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:708)
>   at 
> org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:263)
>   at 
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:153)
>   at 
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45)
>   at org.apache.logging.log4j.LogManager.getContext(LogManager.java:194)
>   at 
> org.apache.logging.log4j.spi.AbstractLoggerAdapter.getContext(AbstractLoggerAdapter.java:138)
>   at 
> org.apache.logging.log4j.jcl.LogAdapter.getContext(LogAdapter.java:39)
>   at 
> org.apache.logging.log4j.spi.AbstractLoggerAdapter.getLogger(AbstractLoggerAdapter.java:48)
>   at 
> org.apache.logging.log4j.jcl.LogFactoryImpl.getInstance(LogFactoryImpl.java:40)
>   at 
> org.apache.logging.log4j.jcl.LogFactoryImpl.getInstance(LogFactoryImpl.java:55)
>   at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:655)
>   at 
> org.springframework.web.filter.GenericFilterBean.(GenericFilterBean.java:86)
>   at 
> org.springframework.web.filter.DelegatingFilterProxy.(DelegatingFilterProxy.java:107)
>   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>   at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>   at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler$Context.createInstance(ContextHandler.java:2520)
>   at 
> org.eclipse.jetty.servlet.ServletContextHandler$Context.createFilter(ServletContextHandler.java:1284)
>   at 
> org.eclipse.jetty.servlet.FilterHolder.initialize(FilterHolder.java:118)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.lambda$initialize$0(ServletHandler.java:751)
>   at 
> java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)
>   at 
> java.util.stream.Streams$ConcatSpliterator.forEachRemaining(Streams.java:742)
>   at 
> 

[jira] [Commented] (GEODE-8240) Rolling upgrade fails for Locator

2020-06-10 Thread Ernest Burghardt (Jira)


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

Ernest Burghardt commented on GEODE-8240:
-

Dev list discussion regarding this matter: 
https://markmail.org/thread/ufvbooarcu6dkfma

> Rolling upgrade fails for Locator
> -
>
> Key: GEODE-8240
> URL: https://issues.apache.org/jira/browse/GEODE-8240
> Project: Geode
>  Issue Type: Bug
>  Components: client/server, membership
>Reporter: Ernest Burghardt
>Priority: Major
>
> as shown in [https://github.com/apache/geode/pull/5224]
>  
>  upgrade from version 1.12 doesn't seem to occur on the Locator 
>  
> testRollServersOnPartitionedRegion_dataserializable  failure results:
> Expecting:
>  <"Member Count : 3
>  Name | Id
>   | 
> ---
>  vm2 | 127.0.0.1(vm2:35019:locator):41000(version:GEODE 1.12.0) 
> [Coordinator]
>  vm0 | 10.0.0.111(vm0:35025):41001
>  vm1 | 10.0.0.111(vm1:35030):41002
>  ">
>  not to contain:
>  <"1.12.0">



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8190) Create JBoss Module to load jar with manifest and classpath

2020-06-10 Thread ASF GitHub Bot (Jira)


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

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

lgtm-com[bot] commented on pull request #5234:
URL: https://github.com/apache/geode/pull/5234#issuecomment-642321035


   This pull request **introduces 2 alerts** and **fixes 1** when merging 
6c8e4a33efc066358597b77f4dbce3e3c04dcfdc into 
923735772bc7d46b84fe430170be875f43713a48 - [view on 
LGTM.com](https://lgtm.com/projects/g/apache/geode/rev/pr-a054db37385626719a0ed1daa7fdb9e8b497f055)
   
   **new alerts:**
   
   * 2 for Potential input resource leak
   
   **fixed alerts:**
   
   * 1 for Potential input resource leak



This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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


> Create JBoss Module to load jar with manifest and classpath
> ---
>
> Key: GEODE-8190
> URL: https://issues.apache.org/jira/browse/GEODE-8190
> Project: Geode
>  Issue Type: Sub-task
>  Components: client/server
>Reporter: Udo Kohlmeyer
>Priority: Major
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (GEODE-8240) Rolling upgrade fails for Locator

2020-06-10 Thread Ernest Burghardt (Jira)
Ernest Burghardt created GEODE-8240:
---

 Summary: Rolling upgrade fails for Locator
 Key: GEODE-8240
 URL: https://issues.apache.org/jira/browse/GEODE-8240
 Project: Geode
  Issue Type: Bug
  Components: client/server, membership
Reporter: Ernest Burghardt


as shown in [https://github.com/apache/geode/pull/5224]

 

 upgrade from version 1.12 doesn't seem to occur on the Locator 

 

testRollServersOnPartitionedRegion_dataserializable  failure results:

Expecting:
 <"Member Count : 3
 Name | Id
  | 
---
 vm2 | 127.0.0.1(vm2:35019:locator):41000(version:GEODE 1.12.0) 
[Coordinator]
 vm0 | 10.0.0.111(vm0:35025):41001
 vm1 | 10.0.0.111(vm1:35030):41002
 ">
 not to contain:
 <"1.12.0">



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8172) CI failure: ParallelWANPersistenceEnabledGatewaySenderOffHeapDUnitTest.testpersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived

2020-06-10 Thread John Hutchison (Jira)


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

John Hutchison commented on GEODE-8172:
---

in case it's helpful,  occurred in this run:  DistributedTestOpenJDK11 #8311

> CI failure: 
> ParallelWANPersistenceEnabledGatewaySenderOffHeapDUnitTest.testpersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived
> ---
>
> Key: GEODE-8172
> URL: https://issues.apache.org/jira/browse/GEODE-8172
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Reporter: Bruce J Schuchardt
>Assignee: Mario Ivanac
>Priority: Major
>
> Failed in a CI run 
> (https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/191#A).
> No previous failures for this issue are found in JIRA and no recent WAN 
> changes could be detected.  Flaky?
> {noformat}
> > Task :geode-wan:distributedTest
> org.apache.geode.internal.cache.wan.offheap.ParallelWANPersistenceEnabledGatewaySenderOffHeapDUnitTest
>  > 
> testpersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived 
> FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.internal.cache.wan.parallel.ParallelWANPersistenceEnabledGatewaySenderDUnitTest$$Lambda$487/908301056.run
>  in VM 2 running on Host 8e35f765a792 with 8 VMs
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Assertion condition 
> defined as a lambda expression in 
> org.apache.geode.internal.cache.wan.WANTestBase that uses int, 
> intorg.apache.geode.cache.Region Expected region entries: 0 but actual 
> entries: 20 present region keyset [3, 5, 8, 13, 16, 21, 27, 30, 35, 38, 43, 
> 45, 50, 54, 58, 62, 65, 68, 73, 78] expected:<0> but was:<20> within 5 
> minutes.
> Caused by:
> java.lang.AssertionError: Expected region entries: 0 but actual 
> entries: 20 present region keyset [3, 5, 8, 13, 16, 21, 27, 30, 35, 38, 43, 
> 45, 50, 54, 58, 62, 65, 68, 73, 78] expected:<0> but was:<20>
> 824 tests completed, 1 failed, 59 skipped
> > Task :geode-wan:distributedTest FAILED
> {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (GEODE-6901) If a region is replicate and replicate persistent in different members and a replicate persistent member crashes, the replicate members throw a ToDataException attempting

2020-06-10 Thread Barrett Oglesby (Jira)


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

Barrett Oglesby updated GEODE-6901:
---
Attachment: 0001-GEODE-6901-Modified-RegionVersionVector-to-handle-a-.patch

> If a region is replicate and replicate persistent in different members and a 
> replicate persistent member crashes, the replicate members throw a 
> ToDataException attempting to synchronize the region
> 
>
> Key: GEODE-6901
> URL: https://issues.apache.org/jira/browse/GEODE-6901
> Project: Geode
>  Issue Type: Bug
>  Components: persistence, regions
>Reporter: Barrett Oglesby
>Priority: Major
>  Labels: caching-applications
> Attachments: 
> 0001-GEODE-6901-Modified-RegionVersionVector-to-handle-a-.patch
>
>
> If a region is replicate and replicate persistent in different members and a 
> replicate persistent member crashes, the replicate members throw a 
> ToDataException attempting to synchronize the region
> In this case, an exception like this is thrown in the replicate member:
> {noformat}
> [warn 2019/06/21 17:06:33.516 PDT  tid=0x2b] Timer task 
>  encountered 
> exception
> org.apache.geode.ToDataException: class 
> org.apache.geode.internal.cache.versions.VMRegionVersionVector
>  at 
> org.apache.geode.internal.InternalDataSerializer.invokeToData(InternalDataSerializer.java:2331)
>  at 
> org.apache.geode.internal.InternalDataSerializer.writeDSFID(InternalDataSerializer.java:1492)
>  at 
> org.apache.geode.internal.InternalDataSerializer.basicWriteObject(InternalDataSerializer.java:2067)
>  at org.apache.geode.DataSerializer.writeObject(DataSerializer.java:2943)
>  at 
> org.apache.geode.internal.cache.InitialImageOperation$RequestImageMessage.toData(InitialImageOperation.java:2135)
>  at 
> org.apache.geode.internal.InternalDataSerializer.invokeToData(InternalDataSerializer.java:2300)
>  at 
> org.apache.geode.internal.InternalDataSerializer.writeDSFID(InternalDataSerializer.java:1492)
>  at 
> org.apache.geode.internal.tcp.MsgStreamer.writeMessage(MsgStreamer.java:242)
>  at 
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:385)
>  at 
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:241)
>  at 
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:596)
>  at 
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.directChannelSend(GMSMembershipManager.java:1711)
>  at 
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.send(GMSMembershipManager.java:1892)
>  at 
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2852)
>  at 
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:2779)
>  at 
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2816)
>  at 
> org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1526)
>  at 
> org.apache.geode.internal.cache.InitialImageOperation.synchronizeWith(InitialImageOperation.java:649)
>  at 
> org.apache.geode.internal.cache.DistributedRegion.synchronizeWith(DistributedRegion.java:1321)
>  at 
> org.apache.geode.internal.cache.DistributedRegion.synchronizeForLostMember(DistributedRegion.java:1310)
>  at 
> org.apache.geode.internal.cache.DistributedRegion.performSynchronizeForLostMemberTask(DistributedRegion.java:1295)
>  at 
> org.apache.geode.internal.cache.DistributedRegion$1.run2(DistributedRegion.java:1285)
>  at 
> org.apache.geode.internal.SystemTimer$SystemTimerTask.run(SystemTimer.java:445)
>  at java.util.TimerThread.mainLoop(Timer.java:555)
>  at java.util.TimerThread.run(Timer.java:505)
> Caused by: java.lang.ClassCastException: 
> org.apache.geode.internal.cache.persistence.DiskStoreID cannot be cast to 
> org.apache.geode.distributed.internal.membership.InternalDistributedMember
>  at 
> org.apache.geode.internal.cache.versions.VMRegionVersionVector.writeMember(VMRegionVersionVector.java:31)
>  at 
> org.apache.geode.internal.cache.versions.RegionVersionVector.toData(RegionVersionVector.java:1204)
>  at 
> org.apache.geode.internal.InternalDataSerializer.invokeToData(InternalDataSerializer.java:2300)
>  ... 24 more
> {noformat}
> RegionVersionVector.java:1204 is here:
> {noformat}
>  for (Map.Entry> entry : 
> this.memberToVersion.entrySet()) {
> -> writeMember(entry.getKey(), out);
>  InternalDataSerializer.invokeToData(entry.getValue(), out);
>  }
> 

[jira] [Commented] (GEODE-6901) If a region is replicate and replicate persistent in different members and a replicate persistent member crashes, the replicate members throw a ToDataException attempti

2020-06-10 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on GEODE-6901:


Commit 095011b06e4ecb36a28849f5a2178e9ed8ae2c39 in geode's branch 
refs/heads/feature/GEODE-6901 from Barry Oglesby
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=095011b ]

GEODE-6901: Added unit test


> If a region is replicate and replicate persistent in different members and a 
> replicate persistent member crashes, the replicate members throw a 
> ToDataException attempting to synchronize the region
> 
>
> Key: GEODE-6901
> URL: https://issues.apache.org/jira/browse/GEODE-6901
> Project: Geode
>  Issue Type: Bug
>  Components: persistence, regions
>Reporter: Barrett Oglesby
>Priority: Major
>  Labels: caching-applications
>
> If a region is replicate and replicate persistent in different members and a 
> replicate persistent member crashes, the replicate members throw a 
> ToDataException attempting to synchronize the region
> In this case, an exception like this is thrown in the replicate member:
> {noformat}
> [warn 2019/06/21 17:06:33.516 PDT  tid=0x2b] Timer task 
>  encountered 
> exception
> org.apache.geode.ToDataException: class 
> org.apache.geode.internal.cache.versions.VMRegionVersionVector
>  at 
> org.apache.geode.internal.InternalDataSerializer.invokeToData(InternalDataSerializer.java:2331)
>  at 
> org.apache.geode.internal.InternalDataSerializer.writeDSFID(InternalDataSerializer.java:1492)
>  at 
> org.apache.geode.internal.InternalDataSerializer.basicWriteObject(InternalDataSerializer.java:2067)
>  at org.apache.geode.DataSerializer.writeObject(DataSerializer.java:2943)
>  at 
> org.apache.geode.internal.cache.InitialImageOperation$RequestImageMessage.toData(InitialImageOperation.java:2135)
>  at 
> org.apache.geode.internal.InternalDataSerializer.invokeToData(InternalDataSerializer.java:2300)
>  at 
> org.apache.geode.internal.InternalDataSerializer.writeDSFID(InternalDataSerializer.java:1492)
>  at 
> org.apache.geode.internal.tcp.MsgStreamer.writeMessage(MsgStreamer.java:242)
>  at 
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:385)
>  at 
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:241)
>  at 
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:596)
>  at 
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.directChannelSend(GMSMembershipManager.java:1711)
>  at 
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.send(GMSMembershipManager.java:1892)
>  at 
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2852)
>  at 
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:2779)
>  at 
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2816)
>  at 
> org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1526)
>  at 
> org.apache.geode.internal.cache.InitialImageOperation.synchronizeWith(InitialImageOperation.java:649)
>  at 
> org.apache.geode.internal.cache.DistributedRegion.synchronizeWith(DistributedRegion.java:1321)
>  at 
> org.apache.geode.internal.cache.DistributedRegion.synchronizeForLostMember(DistributedRegion.java:1310)
>  at 
> org.apache.geode.internal.cache.DistributedRegion.performSynchronizeForLostMemberTask(DistributedRegion.java:1295)
>  at 
> org.apache.geode.internal.cache.DistributedRegion$1.run2(DistributedRegion.java:1285)
>  at 
> org.apache.geode.internal.SystemTimer$SystemTimerTask.run(SystemTimer.java:445)
>  at java.util.TimerThread.mainLoop(Timer.java:555)
>  at java.util.TimerThread.run(Timer.java:505)
> Caused by: java.lang.ClassCastException: 
> org.apache.geode.internal.cache.persistence.DiskStoreID cannot be cast to 
> org.apache.geode.distributed.internal.membership.InternalDistributedMember
>  at 
> org.apache.geode.internal.cache.versions.VMRegionVersionVector.writeMember(VMRegionVersionVector.java:31)
>  at 
> org.apache.geode.internal.cache.versions.RegionVersionVector.toData(RegionVersionVector.java:1204)
>  at 
> org.apache.geode.internal.InternalDataSerializer.invokeToData(InternalDataSerializer.java:2300)
>  ... 24 more
> {noformat}
> RegionVersionVector.java:1204 is here:
> {noformat}
>  for (Map.Entry> entry : 
> this.memberToVersion.entrySet()) {
> -> 

[jira] [Created] (GEODE-8239) Gradle configuration to create manifests for all Geode jars

2020-06-10 Thread Patrick Johnsn (Jira)
Patrick Johnsn created GEODE-8239:
-

 Summary: Gradle configuration to create manifests for all Geode 
jars
 Key: GEODE-8239
 URL: https://issues.apache.org/jira/browse/GEODE-8239
 Project: Geode
  Issue Type: Sub-task
Reporter: Patrick Johnsn


Modify the Gradle configuration to generate a manifest file with "Class-Path" 
and "Dependent-Modules" attributes inside the jars. This manifest will be used 
when defining modules using the jars.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8190) Create JBoss Module to load jar with manifest and classpath

2020-06-10 Thread ASF GitHub Bot (Jira)


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

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

lgtm-com[bot] commented on pull request #5234:
URL: https://github.com/apache/geode/pull/5234#issuecomment-642251305


   This pull request **introduces 2 alerts** and **fixes 1** when merging 
af021bc39d24556d42a72769c3efb8f73e0e8d95 into 
923735772bc7d46b84fe430170be875f43713a48 - [view on 
LGTM.com](https://lgtm.com/projects/g/apache/geode/rev/pr-dd4c7a5d95ac7cebf90faf85a7bbf644a1b7f3e1)
   
   **new alerts:**
   
   * 2 for Potential input resource leak
   
   **fixed alerts:**
   
   * 1 for Potential input resource leak



This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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


> Create JBoss Module to load jar with manifest and classpath
> ---
>
> Key: GEODE-8190
> URL: https://issues.apache.org/jira/browse/GEODE-8190
> Project: Geode
>  Issue Type: Sub-task
>  Components: client/server
>Reporter: Udo Kohlmeyer
>Priority: Major
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8146) Restore winrm-cli to latest from source

2020-06-10 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on GEODE-8146:


Commit a738616ed00ca9cea9335fe310c9624b2be662ff in geode's branch 
refs/heads/support/1.12 from Robert Houghton
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=a738616 ]

GEODE-8146: use latest winrm in tools image (#5134)

* Built cleanly in multistage build
* Moved from python2 -> python3
* Pin concourse-pipeline resource

Authored-by: Robert Houghton 
(cherry picked from commit f2392d0403a292f8e85c5d466329bce5f0d5b819)


> Restore winrm-cli to latest from source
> ---
>
> Key: GEODE-8146
> URL: https://issues.apache.org/jira/browse/GEODE-8146
> Project: Geode
>  Issue Type: Improvement
>  Components: ci, tests
>Reporter: Robert Houghton
>Priority: Major
> Fix For: 1.14.0
>
>
> winrm-cli has updated to fix the bug causing GEODE-7788, as reported in 
> [their github|https://github.com/masterzen/winrm/issues/101]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-7876) OldFreeListOffHeapRegionJUnitTest testPersistentChangeFromHeapToOffHeap

2020-06-10 Thread Bruce J Schuchardt (Jira)


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

Bruce J Schuchardt commented on GEODE-7876:
---

This failed again with ece3a5a6.  The call stacks are the same so there is no 
new information.

{noformat}
"Test worker" #25 prio=5 os_prio=0 tid=0x7feb44a8b000 nid=0x5e in 
Object.wait() [0x7fea3678]
   java.lang.Thread.State: TIMED_WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at 
org.apache.geode.internal.cache.DiskStoreImpl.waitForBackgroundTasks(DiskStoreImpl.java:2631)
- locked <0xfe190c88> (a 
java.util.concurrent.atomic.AtomicInteger)
at 
org.apache.geode.internal.cache.DiskStoreImpl.close(DiskStoreImpl.java:2387)
at 
org.apache.geode.internal.cache.DiskStoreImpl.close(DiskStoreImpl.java:2297)
at 
org.apache.geode.internal.cache.GemFireCacheImpl.closeDiskStores(GemFireCacheImpl.java:2582)
at 
org.apache.geode.internal.cache.GemFireCacheImpl.doClose(GemFireCacheImpl.java:2311)
- locked <0xd020d198> (a java.lang.Class for 
org.apache.geode.internal.cache.GemFireCacheImpl)
at 
org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:2130)
at 
org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:1998)
at 
org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:1988)
at 
org.apache.geode.internal.offheap.OffHeapRegionBase.closeCache(OffHeapRegionBase.java:106)
at 
org.apache.geode.internal.offheap.OffHeapRegionBase.testPersistentChangeFromHeapToOffHeap(OffHeapRegionBase
{noformat}

This is the only other thread in the JVM that looks geode-related:

{noformat}

"DiskStoreMonitor1" #103 daemon prio=5 os_prio=0 tid=0x7fe9b4aba800 
nid=0xac waiting on condition [0x7fea2ecf7000]
   java.lang.Thread.State: TIMED_WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for  <0xfe0837c8> (a 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{noformat}

> OldFreeListOffHeapRegionJUnitTest testPersistentChangeFromHeapToOffHeap
> ---
>
> Key: GEODE-7876
> URL: https://issues.apache.org/jira/browse/GEODE-7876
> Project: Geode
>  Issue Type: Bug
>  Components: tests
>Affects Versions: 1.12.0
>Reporter: Mark Hanson
>Priority: Major
>  Labels: flaky
>
> CI Failure 
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/IntegrationTestOpenJDK11/builds/1587
>  
> Test worker" #27 prio=5 os_prio=0 cpu=7943.09ms elapsed=1126.77s 
> tid=0x7f60e0b7e000 nid=0x19 in Object.wait()  [0x7f60a2a4b000]
>java.lang.Thread.State: TIMED_WAITING (on object monitor)
>   at java.lang.Object.wait(java.base@11.0.6/Native Method)
>   - waiting on 
>   at 
> org.apache.geode.internal.cache.DiskStoreImpl.waitForBackgroundTasks(DiskStoreImpl.java:2630)
>   - waiting to re-lock in wait() <0xffbb6438> (a 
> java.util.concurrent.atomic.AtomicInteger)
>   at 
> org.apache.geode.internal.cache.DiskStoreImpl.close(DiskStoreImpl.java:2386)
>   at 
> org.apache.geode.internal.cache.DiskStoreImpl.close(DiskStoreImpl.java:2296)
>   at 
> org.apache.geode.internal.cache.GemFireCacheImpl.closeDiskStores(GemFireCacheImpl.java:2476)
>   at 
> org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:2234)
>   - locked <0xd0a42a00> (a java.lang.Class for 
> org.apache.geode.internal.cache.GemFireCacheImpl)
>   at 
> org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:1931)
>   at 
> org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:1921)
>   at 
> org.apache.geode.internal.offheap.OffHeapRegionBase.closeCache(OffHeapRegionBase.java:106)
>   at 
> 

[jira] [Commented] (GEODE-8146) Restore winrm-cli to latest from source

2020-06-10 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on GEODE-8146:


Commit 447dc1a135e43538a915f812780536844bd00133 in geode's branch 
refs/heads/support/1.13 from Robert Houghton
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=447dc1a ]

GEODE-8146: use latest winrm in tools image (#5134)

* Built cleanly in multistage build
* Moved from python2 -> python3
* Pin concourse-pipeline resource

Authored-by: Robert Houghton 
(cherry picked from commit f2392d0403a292f8e85c5d466329bce5f0d5b819)


> Restore winrm-cli to latest from source
> ---
>
> Key: GEODE-8146
> URL: https://issues.apache.org/jira/browse/GEODE-8146
> Project: Geode
>  Issue Type: Improvement
>  Components: ci, tests
>Reporter: Robert Houghton
>Priority: Major
> Fix For: 1.14.0
>
>
> winrm-cli has updated to fix the bug causing GEODE-7788, as reported in 
> [their github|https://github.com/masterzen/winrm/issues/101]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8205) Feature flag unsupported Redis commands

2020-06-10 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on GEODE-8205:


Commit fe43bc60cb5432d03da6040d333a3822b50b44b0 in geode's branch 
refs/heads/develop from Sarah Abbey
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=fe43bc6 ]

GEODE-8205: fix locally failing tests



> Feature flag unsupported Redis commands
> ---
>
> Key: GEODE-8205
> URL: https://issues.apache.org/jira/browse/GEODE-8205
> Project: Geode
>  Issue Type: Improvement
>  Components: redis
>Reporter: Jens Deppe
>Assignee: Darrel Schneider
>Priority: Major
> Fix For: 1.14.0
>
>
> Hide unsupported Redis commands behind system property 
> {{enable-unsupported-redis-commands}}.
> This will be removed once all commands are supported.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (GEODE-8205) Feature flag unsupported Redis commands

2020-06-10 Thread Darrel Schneider (Jira)


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

Darrel Schneider resolved GEODE-8205.
-
Resolution: Fixed

> Feature flag unsupported Redis commands
> ---
>
> Key: GEODE-8205
> URL: https://issues.apache.org/jira/browse/GEODE-8205
> Project: Geode
>  Issue Type: Improvement
>  Components: redis
>Reporter: Jens Deppe
>Assignee: Darrel Schneider
>Priority: Major
> Fix For: 1.14.0
>
>
> Hide unsupported Redis commands behind system property 
> {{enable-unsupported-redis-commands}}.
> This will be removed once all commands are supported.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8205) Feature flag unsupported Redis commands

2020-06-10 Thread ASF GitHub Bot (Jira)


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

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

dschneider-pivotal merged pull request #5235:
URL: https://github.com/apache/geode/pull/5235


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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


> Feature flag unsupported Redis commands
> ---
>
> Key: GEODE-8205
> URL: https://issues.apache.org/jira/browse/GEODE-8205
> Project: Geode
>  Issue Type: Improvement
>  Components: redis
>Reporter: Jens Deppe
>Assignee: Darrel Schneider
>Priority: Major
> Fix For: 1.14.0
>
>
> Hide unsupported Redis commands behind system property 
> {{enable-unsupported-redis-commands}}.
> This will be removed once all commands are supported.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8099) Make ClusterConfiguration Service thread safe

2020-06-10 Thread ASF GitHub Bot (Jira)


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

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

jchen21 commented on a change in pull request #5188:
URL: https://github.com/apache/geode/pull/5188#discussion_r438353291



##
File path: 
geode-core/src/main/java/org/apache/geode/management/internal/BaseManagementService.java
##
@@ -94,6 +94,13 @@ public static void 
setManagementService(InternalCacheForClientAccess cache,
 }
   }
 
+  @VisibleForTesting
+  public static void clearManagementService(InternalCacheForClientAccess 
cache) {
+synchronized (instances) {
+  instances.remove(cache);

Review comment:
   Looking at `BaseManagementService`, this is the only `instances.remove` 
statement to remove an entry from the `HashMap`. Entries are put to the 
`HashMap`, but never removed individually. There is `instances.clear`, but it 
removes everything in the `HashMap`. This concern maybe outside the scope of 
this JIRA ticket though.





This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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


> Make ClusterConfiguration Service thread safe
> -
>
> Key: GEODE-8099
> URL: https://issues.apache.org/jira/browse/GEODE-8099
> Project: Geode
>  Issue Type: Bug
>  Components: configuration
>Reporter: Anilkumar Gingade
>Priority: Major
>  Labels: GeodeOperationAPI
> Fix For: 1.14.0
>
>
> When multiple cluster configuration clients (multiple rest clients) connects 
> and issue configuration commands, the cluster configuration should handle 
> concurrent request and modify/save/execute the configuration definition in 
> thread safe manner.  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Comment Edited] (GEODE-8212) Change in PdxType class "<" operator impacts performance

2020-06-10 Thread Blake Bender (Jira)


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

Blake Bender edited comment on GEODE-8212 at 6/10/20, 6:56 PM:
---

Okay, here's the latest:

 
 * First, the call to PdxInstanceFactory::writeString was being called in the 
order (value, key) rather than (key, value).  This meant that _literally_ every 
iteration was producing a new Pdx type.  Swapping the order from:

{code:java}
auto repetitions = 5000; 
for (auto i = 0; i < repetitions; ++i) { 
auto instance_factory = 
cache.createPdxInstanceFactory(gemfireJsonClassName);   
instance_factory.writeString(std::to_string(i), "bar");
}{code}
to:
{code:java}
auto repetitions = 5000; 
for (auto i = 0; i < repetitions; ++i) { 
auto instance_factory = 
cache.createPdxInstanceFactory(gemfireJsonClassName);   
instance_factory.writeString("bar", std::to_string(i));
} {code}
Took the timing way down, as shown below:

before:
{code:java}
○ → ctest -R testCreateInstanceFactory -VV 2>&1 | grep Elapsed
30: Elapsed Time (createPdxInstanceFactory): 17 milliseconds
30: Elapsed Time (instance_factory.writeString): 5 milliseconds
30: Elapsed Time (instance_factory.create): 12817 milliseconds
30: Elapsed Time (whole test): 12854 milliseconds{code}
after:
{code:java}
○ → ctest -R testCreateInstanceFactory -VV 2>&1 | grep Elapsed
30: Elapsed Time (createPdxInstanceFactory): 9 milliseconds
30: Elapsed Time (instance_factory.writeString): 2 milliseconds
30: Elapsed Time (instance_factory.create): 2299 milliseconds
30: Elapsed Time (whole test): 2328 milliseconds {code}
Then, I realized that I had turned on debug-level logging as part of my 
investigation, so my results were probably still too high.  Turning logging 
off, I got the following:
{code:java}
○ → ctest -R testCreateInstanceFactory -VV 2>&1 | grep Elapsed
30: Elapsed Time (createPdxInstanceFactory): 10 milliseconds
30: Elapsed Time (instance_factory.writeString): 1 milliseconds
30: Elapsed Time (instance_factory.create): 442 milliseconds
30: Elapsed Time (whole test): 471 milliseconds {code}
I checked to see if perhaps something in the code was confusing compiler 
optimization, and made a change I think we'll keep anyway because it makes the 
operation more explicit.

before:
{code:java}
auto typeIdLessThan = this->m_geodeTypeId < other.m_geodeTypeId;
auto typeIdsBothZero = (m_geodeTypeId == 0) && (other.m_geodeTypeId == 0);
auto classnameLessThan = this->m_className < other.m_className;
return (typeIdLessThan || (typeIdsBothZero && classnameLessThan)); {code}
after:
{code:java}
if (m_geodeTypeId < other.m_geodeTypeId) {
  return true;
}

if ((m_geodeTypeId == 0) && (other.m_geodeTypeId == 0)) {
  return this->m_className < other.m_className;
}

return false; {code}
Unsurprisingly, this made no discernible difference in the timing.

I also tried moving `operator<` into the header and marking it inline, just to 
be absolutely sure.  Again, no discernible improvement.

At this point, I believe we can lower the priority of this bug.  The 
performance difference is still a thing, but again the prior implementation was 
_wrong_, and fast but wrong is still wrong.  I believe the current 
implementation is as slow as it has to be, and no slower.


was (Author: bbender):
Okay, here's the latest:

 
 * First, the call to 

{code:java}
auto repetitions = 5000;
for (auto i = 0; i < repetitions; ++i) {
auto instance_factory =
cache.createPdxInstanceFactory(gemfireJsonClassName);
instance_factory.writeString("bar", std::to_string(i));{code}

> Change in PdxType class "<" operator impacts performance
> 
>
> Key: GEODE-8212
> URL: https://issues.apache.org/jira/browse/GEODE-8212
> Project: Geode
>  Issue Type: Improvement
>  Components: native client
>Reporter: Alberto Bustamante Reyes
>Assignee: Blake Bender
>Priority: Major
> Attachments: performance_after_GEODE-7694.patch
>
>
> While investigating a performance problem of the C++ native client, it has 
> been observed that change in the PdxType class "<" operator introduced by 
> GEODE-7694 impacts performance of PdxHelper::serializePdx().
> Im attaching a patch with some code and a test case I have used to benchmark 
> that method. With the current implementation in develop branch, creating just 
> 10 instances is enough to see the difference. The calls to serializePdx take 
> these times:
> {noformat}
> Elapsed Time (serializePdx): 32.1322 milliseconds​
> Elapsed Time (serializePdx): 3.06044 milliseconds​
> Elapsed Time (serializePdx): 1.58791 milliseconds​
> Elapsed Time (serializePdx): 1.62466 milliseconds​
> Elapsed Time (serializePdx): 1.53676 milliseconds​
> Elapsed Time (serializePdx): 1.59278 milliseconds​

[jira] [Resolved] (GEODE-8238) message loss during shutdown in Shutdown Hook when JVM exits

2020-06-10 Thread Bruce J Schuchardt (Jira)


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

Bruce J Schuchardt resolved GEODE-8238.
---
Fix Version/s: 1.14.0
   Resolution: Fixed

> message loss during shutdown in Shutdown Hook when JVM exits
> 
>
> Key: GEODE-8238
> URL: https://issues.apache.org/jira/browse/GEODE-8238
> Project: Geode
>  Issue Type: Bug
>  Components: membership, messaging
>Reporter: Bruce J Schuchardt
>Priority: Major
> Fix For: 1.14.0
>
>
> In a test I was running a JVM was told to exit and Geode's Shutdown Hook 
> initiated cache shutdown.  This thread hung once in a while either waiting 
> for a reply to a release of a distributed lock or for a reply to a 
> region-destroy message.
> I traced this down by adding some logging to TCPConduit and DirectChannel and 
> it's due to the changes for GEODE-7727 ("modify sender thread to detect 
> relese of connection").  Those changes cause the P2P Handshake thread to stay 
> active reading from a shared Connection socket.  Unfortunately, when this 
> thread eventually exits it is invoking removeEndpoint, which closes all the 
> other connections to the other node.  This is causing messages to be lost.
> Here's an example:
> one node (19919) fails to form a connection and invokes removeEndpoint for 
> the other node (23898)
> {noformat}
> bridgegemfire1_19919/system.log: [info 2020/06/09 11:05:08.862 PDT  handshake reader@31e492f-45> tid=0x14f] BRUCE: asyncClose closing Connection, 
> uid=4 shared=true ordered=false 
> remoteAddr=rs-Awesome-14-1023a0i3xlarge-hydra-client-8(bridgegemfire4_host1_23898:23898):41005
>  isReceiver=true
> java.lang.Exception: stack trace
>   at 
> org.apache.geode.internal.tcp.Connection.asyncClose(Connection.java:833)
>   at org.apache.geode.internal.tcp.Connection.close(Connection.java:1338)
>   at 
> org.apache.geode.internal.tcp.Connection.closePartialConnect(Connection.java:1276)
>   at 
> org.apache.geode.internal.tcp.ConnectionTable.closeCon(ConnectionTable.java:612)
>   at 
> org.apache.geode.internal.tcp.ConnectionTable.closeCon(ConnectionTable.java:604)
>   at 
> org.apache.geode.internal.tcp.ConnectionTable.removeEndpoint(ConnectionTable.java:851)
>   at 
> org.apache.geode.internal.tcp.ConnectionTable.removeEndpoint(ConnectionTable.java:751)
>   at org.apache.geode.internal.tcp.Connection.close(Connection.java:1400)
>   at 
> org.apache.geode.internal.tcp.Connection.requestClose(Connection.java:1268)
>   at 
> org.apache.geode.internal.tcp.Connection.readMessages(Connection.java:1661)
>   at org.apache.geode.internal.tcp.Connection.run(Connection.java:1460)
>   at java.base/java.lang.Thread.run(Thread.java:834)
> {noformat}
> The other node's shared/unordered connection was unexpectedly terminated, 
> causing it to also invoke removeEndpoint():
> {noformat}
> bridgegemfire4_23898/system.log: [info 2020/06/09 11:05:08.862 PDT  handshake reader@2e1ef958-4> tid=0x36] BRUCE: asyncClose closing Connection, 
> uid=4 shared=true ordered=false 
> remoteAddr=rs-Awesome-14-1023a0i3xlarge-hydra-client-8(bridgegemfire1_host1_19919:19919):41002
>  isReceiver=false
> java.lang.Exception: stack trace
>   at 
> org.apache.geode.internal.tcp.Connection.asyncClose(Connection.java:833)
>   at org.apache.geode.internal.tcp.Connection.close(Connection.java:1338)
>   at 
> org.apache.geode.internal.tcp.Connection.requestClose(Connection.java:1268)
>   at 
> org.apache.geode.internal.tcp.Connection.readMessages(Connection.java:1619)
>   at org.apache.geode.internal.tcp.Connection.run(Connection.java:1460)
>   at 
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
>   at 
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
>   at java.base/java.lang.Thread.run(Thread.java:834)
> bridgegemfire4_23898/system.log: [info 2020/06/09 11:05:08.862 PDT  handshake reader@2e1ef958-4> tid=0x36] BRUCE: removeEndpoint invoked for 
> rs-Awesome-14-1023a0i3xlarge-hydra-client-8(bridgegemfire1_host1_19919:19919):41002
>  reason=SocketChannel.read returned EOF notifyDisconnect=true
> java.lang.Exception: stack trace
>   at 
> org.apache.geode.internal.tcp.ConnectionTable.removeEndpoint(ConnectionTable.java:758)
>   at 
> org.apache.geode.internal.tcp.ConnectionTable.removeEndpoint(ConnectionTable.java:751)
>   at org.apache.geode.internal.tcp.Connection.close(Connection.java:1400)
>   at 
> org.apache.geode.internal.tcp.Connection.requestClose(Connection.java:1268)
>   at 
> org.apache.geode.internal.tcp.Connection.readMessages(Connection.java:1619)
>   at org.apache.geode.internal.tcp.Connection.run(Connection.java:1460)
>   

[jira] [Commented] (GEODE-8212) Change in PdxType class "<" operator impacts performance

2020-06-10 Thread Blake Bender (Jira)


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

Blake Bender commented on GEODE-8212:
-

Okay, here's the latest:

 
 * First, the call to 

{code:java}
auto repetitions = 5000;
for (auto i = 0; i < repetitions; ++i) {
auto instance_factory =
cache.createPdxInstanceFactory(gemfireJsonClassName);
instance_factory.writeString("bar", std::to_string(i));{code}

> Change in PdxType class "<" operator impacts performance
> 
>
> Key: GEODE-8212
> URL: https://issues.apache.org/jira/browse/GEODE-8212
> Project: Geode
>  Issue Type: Improvement
>  Components: native client
>Reporter: Alberto Bustamante Reyes
>Assignee: Blake Bender
>Priority: Major
> Attachments: performance_after_GEODE-7694.patch
>
>
> While investigating a performance problem of the C++ native client, it has 
> been observed that change in the PdxType class "<" operator introduced by 
> GEODE-7694 impacts performance of PdxHelper::serializePdx().
> Im attaching a patch with some code and a test case I have used to benchmark 
> that method. With the current implementation in develop branch, creating just 
> 10 instances is enough to see the difference. The calls to serializePdx take 
> these times:
> {noformat}
> Elapsed Time (serializePdx): 32.1322 milliseconds​
> Elapsed Time (serializePdx): 3.06044 milliseconds​
> Elapsed Time (serializePdx): 1.58791 milliseconds​
> Elapsed Time (serializePdx): 1.62466 milliseconds​
> Elapsed Time (serializePdx): 1.53676 milliseconds​
> Elapsed Time (serializePdx): 1.59278 milliseconds​
> Elapsed Time (serializePdx): 1.82878 milliseconds​
> Elapsed Time (serializePdx): 1.36811 milliseconds​
> Elapsed Time (serializePdx): 1.6956 milliseconds​
> Elapsed Time (serializePdx): 1.46873 milliseconds​
> Elapsed Time (serializePdx): 1.53206 milliseconds​
> {noformat}
> While these are the times using the old "<" operator:
> {noformat}
> Elapsed Time (serializePdx): 56.1524 milliseconds
> Elapsed Time (serializePdx): 0.012327 milliseconds
> Elapsed Time (serializePdx): 0.006325 milliseconds
> Elapsed Time (serializePdx): 0.005419 milliseconds
> Elapsed Time (serializePdx): 0.005266 milliseconds
> Elapsed Time (serializePdx): 0.005662 milliseconds
> Elapsed Time (serializePdx): 0.005407 milliseconds
> Elapsed Time (serializePdx): 0.005286 milliseconds
> Elapsed Time (serializePdx): 0.005467 milliseconds
> Elapsed Time (serializePdx): 0.005276 milliseconds
> Elapsed Time (serializePdx): 0.005298 milliseconds
> {noformat}
> And after creating 50.000 instances, these are the times for the last 10 
> calls with the current "<" operator and with the old one respectively::
> {noformat}
> Elapsed Time (serializePdx): 8.11767 milliseconds​
> Elapsed Time (serializePdx): 8.15727 milliseconds​
> Elapsed Time (serializePdx): 8.09303 milliseconds​
> Elapsed Time (serializePdx): 7.89909 milliseconds​
> Elapsed Time (serializePdx): 8.37956 milliseconds​
> Elapsed Time (serializePdx): 8.21303 milliseconds​
> Elapsed Time (serializePdx): 8.14189 milliseconds​
> Elapsed Time (serializePdx): 8.21266 milliseconds​
> Elapsed Time (serializePdx): 8.21683 milliseconds​
> Elapsed Time (serializePdx): 7.78765 milliseconds
> {noformat}
> {noformat}
> Elapsed Time (serializePdx): 0.003014 milliseconds​
> Elapsed Time (serializePdx): 0.003 milliseconds​
> Elapsed Time (serializePdx): 0.003084 milliseconds​
> Elapsed Time (serializePdx): 0.003112 milliseconds​
> Elapsed Time (serializePdx): 0.00305 milliseconds​
> Elapsed Time (serializePdx): 0.003018 milliseconds​
> Elapsed Time (serializePdx): 0.003029 milliseconds​
> Elapsed Time (serializePdx): 0.003061 milliseconds​
> Elapsed Time (serializePdx): 0.003043 milliseconds​
> Elapsed Time (serializePdx): 0.003086 milliseconds​
> {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8029) java.lang.IllegalArgumentException: Too large (805306401 expected elements with load factor 0.75)

2020-06-10 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on GEODE-8029:


Commit 7c1ffd528ff72b920dd606604de2a744c1728b23 in geode's branch 
refs/heads/support/1.13 from Juan José Ramos
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=7c1ffd5 ]

GEODE-8029: Delete orphaned drf files (2nd try) (#5099)

This reverts the revert of the original commit and also fixes the
originally introduced issues.



The OpLog initialization now delete unused drf files to prevent the
proliferation of unused records and files within the system, which
can could cause members to fail during startup while recovering
disk-stores (especially when they are isolated for gateway-senders).

- Added distributed tests.
- Delete orphaned drf files when deleting the corresponding
  crf during recovery.

(cherry picked from commit bc0090dc93643fd4d09c79a4b0c29d883172b546)


> java.lang.IllegalArgumentException: Too large (805306401 expected elements 
> with load factor 0.75)
> -
>
> Key: GEODE-8029
> URL: https://issues.apache.org/jira/browse/GEODE-8029
> Project: Geode
>  Issue Type: Bug
>  Components: configuration, core, gfsh
>Affects Versions: 1.9.0
>Reporter: Jagadeesh sivasankaran
>Assignee: Juan Ramos
>Priority: Major
>  Labels: GeodeCommons, caching-applications
> Fix For: 1.14.0
>
> Attachments: Screen Shot 2020-04-27 at 12.21.19 PM.png, Screen Shot 
> 2020-04-27 at 12.21.19 PM.png, server02.log
>
>
> we have a cluster of three Locator Geode and three Cache Server running in 
> CentOS servers. Today (April 27) after patching our CENTOS servers , all 
> locator and 2 servers came up , But one Cache server was not starting . here 
> is the Exception details.  Please let me know how to resolve the beloe issue 
> and need any configuration changes to diskstore ? 
>  
>  
> Starting a Geode Server in /app/provServerHO2...
> The
>  Cache Server process terminated unexpectedly with exit status 1. Please 
> refer to the log file in /app/provServerHO2 for full details.
> Exception in thread "main" java.lang.IllegalArgumentException: Too large 
> (805306401 expected elements with load factor 0.75)
> at it.unimi.dsi.fastutil.HashCommon.arraySize(HashCommon.java:222)
> at it.unimi.dsi.fastutil.ints.IntOpenHashSet.add(IntOpenHashSet.java:308)
> at 
> org.apache.geode.internal.cache.DiskStoreImpl$OplogEntryIdSet.add(DiskStoreImpl.java:3474)
> at org.apache.geode.internal.cache.Oplog.readDelEntry(Oplog.java:3007)
> at org.apache.geode.internal.cache.Oplog.recoverDrf(Oplog.java:1500)
> at 
> org.apache.geode.internal.cache.PersistentOplogSet.recoverOplogs(PersistentOplogSet.java:445)
> at 
> org.apache.geode.internal.cache.PersistentOplogSet.recoverRegionsThatAreReady(PersistentOplogSet.java:369)
> at 
> org.apache.geode.internal.cache.DiskStoreImpl.recoverRegionsThatAreReady(DiskStoreImpl.java:2053)
> at 
> org.apache.geode.internal.cache.DiskStoreImpl.initializeIfNeeded(DiskStoreImpl.java:2041)
> security-peer-auth-init=
> at 
> org.apache.geode.internal.cache.DiskStoreImpl.doInitialRecovery(DiskStoreImpl.java:2046)
> at 
> org.apache.geode.internal.cache.DiskStoreFactoryImpl.initializeDiskStore(DiskStoreFactoryImpl.java:184)
> at 
> org.apache.geode.internal.cache.DiskStoreFactoryImpl.create(DiskStoreFactoryImpl.java:150)
> at 
> org.apache.geode.internal.cache.xmlcache.CacheCreation.createDiskStore(CacheCreation.java:794)
> at 
> org.apache.geode.internal.cache.xmlcache.CacheCreation.initializePdxDiskStore(CacheCreation.java:785)
> at 
> org.apache.geode.internal.cache.xmlcache.CacheCreation.create(CacheCreation.java:509)
> at 
> org.apache.geode.internal.cache.xmlcache.CacheXmlParser.create(CacheXmlParser.java:337)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4272)
> at 
> org.apache.geode.internal.cache.ClusterConfigurationLoader.applyClusterXmlConfiguration(ClusterConfigurationLoader.java:197)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.applyJarAndXmlFromClusterConfig(GemFireCacheImpl.java:1240)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1206)
> at 
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:207)
> at 
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:164)
> at 

[jira] [Commented] (GEODE-8190) Create JBoss Module to load jar with manifest and classpath

2020-06-10 Thread ASF GitHub Bot (Jira)


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

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

yozaner1324 commented on a change in pull request #5234:
URL: https://github.com/apache/geode/pull/5234#discussion_r438314213



##
File path: gradle/java.gradle
##
@@ -74,9 +74,9 @@ gradle.taskGraph.whenReady({ graph ->
 }
 jar.metaInf {
   from("$rootDir/geode-assembly/src/main/dist/LICENSE")
-  if (jar.source.filter({ it.name.contains('NOTICE') }).empty) {
-from("$rootDir/NOTICE")
-  }
+//  if (jar.source.filter({ it.name.contains('NOTICE') }).empty) {
+//from("$rootDir/NOTICE")
+//  }

Review comment:
   Nope, not sure where this change came from.





This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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


> Create JBoss Module to load jar with manifest and classpath
> ---
>
> Key: GEODE-8190
> URL: https://issues.apache.org/jira/browse/GEODE-8190
> Project: Geode
>  Issue Type: Sub-task
>  Components: client/server
>Reporter: Udo Kohlmeyer
>Priority: Major
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8029) java.lang.IllegalArgumentException: Too large (805306401 expected elements with load factor 0.75)

2020-06-10 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on GEODE-8029:


Commit bdeff9d6144c47ea687cf3b7d25f12598228 in geode's branch 
refs/heads/support/1.12 from Juan José Ramos
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=bdeff9d ]

GEODE-8029: Delete orphaned drf files (2nd try) (#5099)

This reverts the revert of the original commit and also fixes the
originally introduced issues.



The OpLog initialization now delete unused drf files to prevent the
proliferation of unused records and files within the system, which
can could cause members to fail during startup while recovering
disk-stores (especially when they are isolated for gateway-senders).

- Added distributed tests.
- Delete orphaned drf files when deleting the corresponding
  crf during recovery.

(cherry picked from commit bc0090dc93643fd4d09c79a4b0c29d883172b546)


> java.lang.IllegalArgumentException: Too large (805306401 expected elements 
> with load factor 0.75)
> -
>
> Key: GEODE-8029
> URL: https://issues.apache.org/jira/browse/GEODE-8029
> Project: Geode
>  Issue Type: Bug
>  Components: configuration, core, gfsh
>Affects Versions: 1.9.0
>Reporter: Jagadeesh sivasankaran
>Assignee: Juan Ramos
>Priority: Major
>  Labels: GeodeCommons, caching-applications
> Fix For: 1.14.0
>
> Attachments: Screen Shot 2020-04-27 at 12.21.19 PM.png, Screen Shot 
> 2020-04-27 at 12.21.19 PM.png, server02.log
>
>
> we have a cluster of three Locator Geode and three Cache Server running in 
> CentOS servers. Today (April 27) after patching our CENTOS servers , all 
> locator and 2 servers came up , But one Cache server was not starting . here 
> is the Exception details.  Please let me know how to resolve the beloe issue 
> and need any configuration changes to diskstore ? 
>  
>  
> Starting a Geode Server in /app/provServerHO2...
> The
>  Cache Server process terminated unexpectedly with exit status 1. Please 
> refer to the log file in /app/provServerHO2 for full details.
> Exception in thread "main" java.lang.IllegalArgumentException: Too large 
> (805306401 expected elements with load factor 0.75)
> at it.unimi.dsi.fastutil.HashCommon.arraySize(HashCommon.java:222)
> at it.unimi.dsi.fastutil.ints.IntOpenHashSet.add(IntOpenHashSet.java:308)
> at 
> org.apache.geode.internal.cache.DiskStoreImpl$OplogEntryIdSet.add(DiskStoreImpl.java:3474)
> at org.apache.geode.internal.cache.Oplog.readDelEntry(Oplog.java:3007)
> at org.apache.geode.internal.cache.Oplog.recoverDrf(Oplog.java:1500)
> at 
> org.apache.geode.internal.cache.PersistentOplogSet.recoverOplogs(PersistentOplogSet.java:445)
> at 
> org.apache.geode.internal.cache.PersistentOplogSet.recoverRegionsThatAreReady(PersistentOplogSet.java:369)
> at 
> org.apache.geode.internal.cache.DiskStoreImpl.recoverRegionsThatAreReady(DiskStoreImpl.java:2053)
> at 
> org.apache.geode.internal.cache.DiskStoreImpl.initializeIfNeeded(DiskStoreImpl.java:2041)
> security-peer-auth-init=
> at 
> org.apache.geode.internal.cache.DiskStoreImpl.doInitialRecovery(DiskStoreImpl.java:2046)
> at 
> org.apache.geode.internal.cache.DiskStoreFactoryImpl.initializeDiskStore(DiskStoreFactoryImpl.java:184)
> at 
> org.apache.geode.internal.cache.DiskStoreFactoryImpl.create(DiskStoreFactoryImpl.java:150)
> at 
> org.apache.geode.internal.cache.xmlcache.CacheCreation.createDiskStore(CacheCreation.java:794)
> at 
> org.apache.geode.internal.cache.xmlcache.CacheCreation.initializePdxDiskStore(CacheCreation.java:785)
> at 
> org.apache.geode.internal.cache.xmlcache.CacheCreation.create(CacheCreation.java:509)
> at 
> org.apache.geode.internal.cache.xmlcache.CacheXmlParser.create(CacheXmlParser.java:337)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4272)
> at 
> org.apache.geode.internal.cache.ClusterConfigurationLoader.applyClusterXmlConfiguration(ClusterConfigurationLoader.java:197)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.applyJarAndXmlFromClusterConfig(GemFireCacheImpl.java:1240)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1206)
> at 
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:207)
> at 
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:164)
> at 

[jira] [Commented] (GEODE-8190) Create JBoss Module to load jar with manifest and classpath

2020-06-10 Thread ASF GitHub Bot (Jira)


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

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

lgtm-com[bot] commented on pull request #5233:
URL: https://github.com/apache/geode/pull/5233#issuecomment-642149662


   This pull request **introduces 2 alerts** when merging 
f0574afef7bc2bab8f1dff503ad5ac78f9f13966 into 
1231db1c70632c3f822a63cbd6a4e662d542c961 - [view on 
LGTM.com](https://lgtm.com/projects/g/apache/geode/rev/pr-9655b101c167823181e9e83bd70187b14682c4bd)
   
   **new alerts:**
   
   * 2 for Potential input resource leak



This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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


> Create JBoss Module to load jar with manifest and classpath
> ---
>
> Key: GEODE-8190
> URL: https://issues.apache.org/jira/browse/GEODE-8190
> Project: Geode
>  Issue Type: Sub-task
>  Components: client/server
>Reporter: Udo Kohlmeyer
>Priority: Major
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8205) Feature flag unsupported Redis commands

2020-06-10 Thread ASF GitHub Bot (Jira)


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

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

sabbeyPivotal opened a new pull request #5235:
URL: https://github.com/apache/geode/pull/5235


   fix locally failing tests



This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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


> Feature flag unsupported Redis commands
> ---
>
> Key: GEODE-8205
> URL: https://issues.apache.org/jira/browse/GEODE-8205
> Project: Geode
>  Issue Type: Improvement
>  Components: redis
>Reporter: Jens Deppe
>Assignee: Darrel Schneider
>Priority: Major
> Fix For: 1.14.0
>
>
> Hide unsupported Redis commands behind system property 
> {{enable-unsupported-redis-commands}}.
> This will be removed once all commands are supported.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8190) Create JBoss Module to load jar with manifest and classpath

2020-06-10 Thread ASF GitHub Bot (Jira)


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

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

kohlmu-pivotal commented on a change in pull request #5234:
URL: https://github.com/apache/geode/pull/5234#discussion_r438264180



##
File path: gradle/java.gradle
##
@@ -74,9 +74,9 @@ gradle.taskGraph.whenReady({ graph ->
 }
 jar.metaInf {
   from("$rootDir/geode-assembly/src/main/dist/LICENSE")
-  if (jar.source.filter({ it.name.contains('NOTICE') }).empty) {
-from("$rootDir/NOTICE")
-  }
+//  if (jar.source.filter({ it.name.contains('NOTICE') }).empty) {
+//from("$rootDir/NOTICE")
+//  }

Review comment:
   Any idea why these lines were commented out





This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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


> Create JBoss Module to load jar with manifest and classpath
> ---
>
> Key: GEODE-8190
> URL: https://issues.apache.org/jira/browse/GEODE-8190
> Project: Geode
>  Issue Type: Sub-task
>  Components: client/server
>Reporter: Udo Kohlmeyer
>Priority: Major
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8190) Create JBoss Module to load jar with manifest and classpath

2020-06-10 Thread ASF GitHub Bot (Jira)


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

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

yozaner1324 opened a new pull request #5234:
URL: https://github.com/apache/geode/pull/5234


   
   JBossModuleServiceImpl can now register and load Modules using 
ModuleDescriptor. The ModuleDescriptor
   can now contain source paths to be included in the module as code sources or
   have dependencies on other modules.
   
   The same functionality can now be represented/retrieved from the Manifest 
file
   contained within the jar files.
   
   Amended gradle scripts for geode-common-services and geode-common to now 
generate
   manifest files containing "Class-Path" dependencies and project module 
dependencies
   described in the "Dependent-Modules" attribute in the manifest file.
   
   Thank you for submitting a contribution to Apache Geode.
   
   In order to streamline the review of the contribution we ask you
   to ensure the following steps have been taken:
   
   ### For all changes:
   - [ ] Is there a JIRA ticket associated with this PR? Is it referenced in 
the commit message?
   
   - [ ] Has your PR been rebased against the latest commit within the target 
branch (typically `develop`)?
   
   - [ ] Is your initial contribution a single, squashed commit?
   
   - [ ] Does `gradlew build` run cleanly?
   
   - [ ] Have you written or updated unit tests to verify your changes?
   
   - [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)?
   
   ### Note:
   Please ensure that once the PR is submitted, check Concourse for build 
issues and
   submit an update to your PR as soon as possible. If you need help, please 
send an
   email to d...@geode.apache.org.
   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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


> Create JBoss Module to load jar with manifest and classpath
> ---
>
> Key: GEODE-8190
> URL: https://issues.apache.org/jira/browse/GEODE-8190
> Project: Geode
>  Issue Type: Sub-task
>  Components: client/server
>Reporter: Udo Kohlmeyer
>Priority: Major
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8190) Create JBoss Module to load jar with manifest and classpath

2020-06-10 Thread ASF GitHub Bot (Jira)


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

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

yozaner1324 closed pull request #5233:
URL: https://github.com/apache/geode/pull/5233


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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


> Create JBoss Module to load jar with manifest and classpath
> ---
>
> Key: GEODE-8190
> URL: https://issues.apache.org/jira/browse/GEODE-8190
> Project: Geode
>  Issue Type: Sub-task
>  Components: client/server
>Reporter: Udo Kohlmeyer
>Priority: Major
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8190) Create JBoss Module to load jar with manifest and classpath

2020-06-10 Thread ASF GitHub Bot (Jira)


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

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

yozaner1324 opened a new pull request #5233:
URL: https://github.com/apache/geode/pull/5233


   Thank you for submitting a contribution to Apache Geode.
   
   In order to streamline the review of the contribution we ask you
   to ensure the following steps have been taken:
   
   ### For all changes:
   - [ ] Is there a JIRA ticket associated with this PR? Is it referenced in 
the commit message?
   
   - [ ] Has your PR been rebased against the latest commit within the target 
branch (typically `develop`)?
   
   - [ ] Is your initial contribution a single, squashed commit?
   
   - [ ] Does `gradlew build` run cleanly?
   
   - [ ] Have you written or updated unit tests to verify your changes?
   
   - [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)?
   
   ### Note:
   Please ensure that once the PR is submitted, check Concourse for build 
issues and
   submit an update to your PR as soon as possible. If you need help, please 
send an
   email to d...@geode.apache.org.
   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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


> Create JBoss Module to load jar with manifest and classpath
> ---
>
> Key: GEODE-8190
> URL: https://issues.apache.org/jira/browse/GEODE-8190
> Project: Geode
>  Issue Type: Sub-task
>  Components: client/server
>Reporter: Udo Kohlmeyer
>Priority: Major
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8234) the internal redis functions should all implement InternalFunction

2020-06-10 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on GEODE-8234:


Commit 6e65b075351cf25f36c6023edc6b6608e48bf257 in geode's branch 
refs/heads/feature/GEODE-8067 from Darrel Schneider
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=6e65b07 ]

GEODE-8234: change redis functions to implement InternalFunction (#5229)



> the internal redis functions should all implement InternalFunction
> --
>
> Key: GEODE-8234
> URL: https://issues.apache.org/jira/browse/GEODE-8234
> Project: Geode
>  Issue Type: Bug
>  Components: redis
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>Priority: Major
> Fix For: 1.14.0
>
>
> The redis internal functions should all implement InternalFunction. This will 
> prevent users from directly executing them from a client.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8137) Implement loadService on JBossModuleService

2020-06-10 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on GEODE-8137:


Commit 5c1fbcd70ec25e94722d58109b67b5bdbd171ae3 in geode's branch 
refs/heads/feature/GEODE-8067 from Patrick Johnson
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=5c1fbcd ]

GEODE-8137 - Implement loadService. (#5136)



> Implement loadService on JBossModuleService
> ---
>
> Key: GEODE-8137
> URL: https://issues.apache.org/jira/browse/GEODE-8137
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Patrick Johnsn
>Assignee: Patrick Johnsn
>Priority: Major
>
> Implement loadService to load implementations of a given interface from JBoss 
> Modules.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8148) Implement unloadModule in JBossModuleService

2020-06-10 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on GEODE-8148:


Commit 923735772bc7d46b84fe430170be875f43713a48 in geode's branch 
refs/heads/feature/GEODE-8067 from Patrick Johnson
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=9237357 ]

GEODE-8148 - Implement unloadModule. (#5151)



> Implement unloadModule in JBossModuleService
> 
>
> Key: GEODE-8148
> URL: https://issues.apache.org/jira/browse/GEODE-8148
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Patrick Johnsn
>Assignee: Patrick Johnsn
>Priority: Major
>
> unloadModule will unload JBoss modules previously loaded by loadModule. 
> unloadModule takes a String that represents the name of the module to find 
> and unload. It should return true when successfully unloading a module and 
> false if it cannot find or cannot unload the specified module.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8176) CI Failure: ClientServerMiscBCDUnitTest > testPingWrongServer[1]

2020-06-10 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on GEODE-8176:


Commit 6dabaeb519de64d53029d02541d69010d8c2f3f4 in geode's branch 
refs/heads/feature/GEODE-8067 from Alberto Bustamante Reyes
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=6dabaeb ]

GEODE-8176: Add more checks in the flaky ping test (#5176)



> CI Failure: ClientServerMiscBCDUnitTest > testPingWrongServer[1] 
> -
>
> Key: GEODE-8176
> URL: https://issues.apache.org/jira/browse/GEODE-8176
> Project: Geode
>  Issue Type: Bug
>Reporter: Donal Evans
>Assignee: Alberto Bustamante Reyes
>Priority: Major
>
> Failed in 
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/UpgradeTestOpenJDK8/builds/192#A
> {noformat}
> org.apache.geode.internal.cache.tier.sockets.ClientServerMiscBCDUnitTest > 
> testPingWrongServer[1] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.internal.cache.tier.sockets.ClientServerMiscDUnitTestBase$$Lambda$310/201549247.run
>  in VM 3 running on Host c0a964e32781 with 5 VMs
> Caused by:
> org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
> {noformat}
> I ran the test 200 times locally with no failure, so this is possibly just a 
> blip.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8043) Create JBoss-Modules ModuleService Implementation - loadModule

2020-06-10 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on GEODE-8043:


Commit 1b057c361ee06f5a0e39f05ad2ce1485c91f35fe in geode's branch 
refs/heads/feature/GEODE-8067 from Udo Kohlmeyer
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=1b057c3 ]

GEODE-8043 - Create JBossModuleService and implement loadModule. (#5081)


> Create JBoss-Modules ModuleService Implementation - loadModule
> --
>
> Key: GEODE-8043
> URL: https://issues.apache.org/jira/browse/GEODE-8043
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Patrick Johnsn
>Assignee: Patrick Johnsn
>Priority: Major
>
> Implement the loadModule method of the ModuleService interface using 
> JBoss-Modules.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8232) Add better error message for know redis commands that are not implemented

2020-06-10 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on GEODE-8232:


Commit 20ed5a89246e465e8c79d3da61144e7911067d5b in geode's branch 
refs/heads/feature/GEODE-8067 from Darrel Schneider
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=20ed5a8 ]

GEODE-8232: add better error message for unimplemented redis commands (#5219)

* If a known redis command that is not implemented is executed then
it will fail with the message ' is not implemented'.
* An "info" level message will also be logged on the redis server.

> Add better error message for know redis commands that are not implemented
> -
>
> Key: GEODE-8232
> URL: https://issues.apache.org/jira/browse/GEODE-8232
> Project: Geode
>  Issue Type: Improvement
>  Components: redis
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>Priority: Major
> Fix For: 1.14.0
>
>
> Currently a known, unimplemented, redis command gives the same error message 
> as does executing a redis command that does not exist in any redis release.
> It would be helpful to users if they get a different error message for these 
> two classes of commands.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8041) Create ManagementService Interface

2020-06-10 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on GEODE-8041:


Commit 202d7ac040696f19715b8c853580d4c1b2694007 in geode's branch 
refs/heads/feature/GEODE-8067 from Patrick Johnson
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=202d7ac ]

GEODE-8041 - Create ManagementService interface. (#5062)



> Create ManagementService Interface
> --
>
> Key: GEODE-8041
> URL: https://issues.apache.org/jira/browse/GEODE-8041
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Patrick Johnsn
>Assignee: Patrick Johnsn
>Priority: Major
>
> Create a ManagementService interface. The ManagementService will configure 
> and start Geode (create a Cache given some configuration properties) after 
> the BootstrappingService has bootstrapped the environment and loaded the 
> relevant modules.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8233) add equals and hashCode implementations to RedisData classes

2020-06-10 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on GEODE-8233:


Commit 11e80c36116b4b3a3e4c7d6ad6a9dd4de63bddcf in geode's branch 
refs/heads/feature/GEODE-8067 from Darrel Schneider
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=11e80c3 ]

GEODE-8233: add equals and hashCode to RedisData classes (#5220)



> add equals and hashCode implementations to RedisData classes
> 
>
> Key: GEODE-8233
> URL: https://issues.apache.org/jira/browse/GEODE-8233
> Project: Geode
>  Issue Type: Improvement
>  Components: redis
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>Priority: Major
> Fix For: 1.14.0
>
>
> The classes that implement RedisData should override equals and hashCode to 
> have implementations that use the actual data.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8230) run benchmarks in parallel with other CI

2020-06-10 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on GEODE-8230:


Commit f65ea452443bcd2d0dac6ef1d2d958b0cb02936f in geode's branch 
refs/heads/feature/GEODE-8067 from Owen Nichols
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=f65ea45 ]

GEODE-8230: run benchmarks in parallel with other CI jobs (#5217)

* run benchmarks in parallel with other CI jobs
* eliminate JDK11 flavors for deterministic already-required-in-PR-pipeline 
jobs UnitTest and ApiChecker
* add Benchmarks tab

> run benchmarks in parallel with other CI
> 
>
> Key: GEODE-8230
> URL: https://issues.apache.org/jira/browse/GEODE-8230
> Project: Geode
>  Issue Type: Improvement
>  Components: ci
>Reporter: Owen Nichols
>Assignee: Owen Nichols
>Priority: Major
> Fix For: 1.12.1, 1.13.0, 1.14.0
>
>
> currently, we run Build, then all Test jobs in parallel (which takes ~5 
> hours), then all Benchmark jobs (which takes ~5 hours).
> Presumably the benchmarks were run after all tests, on the premise that 
> benchmarks are meaningless if the code is not correct.  However, required PR 
> checks now prevent incorrect code from getting into develop in the first 
> place, and the remaining occasional failures are flaky, so it's rather 
> arbitrary to gate benchmarks on a lottery.
> However, faster feedback has clear benefits, and cutting our CI pipeline from 
> 10 hours to 5 hours seems like low-hanging fruit.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8037) Create BootstrappingService Interface

2020-06-10 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on GEODE-8037:


Commit 986c5936b7b354e288d540d97c2a02dc5e049b98 in geode's branch 
refs/heads/feature/GEODE-8067 from Patrick Johnson
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=986c593 ]

GEODE-8037 - Create BootstrappingService interface. (#5046)



> Create BootstrappingService Interface
> -
>
> Key: GEODE-8037
> URL: https://issues.apache.org/jira/browse/GEODE-8037
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Patrick Johnsn
>Assignee: Patrick Johnsn
>Priority: Major
>
> Create a BootstrapingService interface. The BootstrappingService will use the 
> ModuleService to bootstrap Geode in a classloader-isolated way, i.e. loading 
> the necessary modules to run Geode.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8041) Create ManagementService Interface

2020-06-10 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on GEODE-8041:


Commit 202d7ac040696f19715b8c853580d4c1b2694007 in geode's branch 
refs/heads/feature/GEODE-8067 from Patrick Johnson
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=202d7ac ]

GEODE-8041 - Create ManagementService interface. (#5062)



> Create ManagementService Interface
> --
>
> Key: GEODE-8041
> URL: https://issues.apache.org/jira/browse/GEODE-8041
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Patrick Johnsn
>Assignee: Patrick Johnsn
>Priority: Major
>
> Create a ManagementService interface. The ManagementService will configure 
> and start Geode (create a Cache given some configuration properties) after 
> the BootstrappingService has bootstrapped the environment and loaded the 
> relevant modules.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8176) CI Failure: ClientServerMiscBCDUnitTest > testPingWrongServer[1]

2020-06-10 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on GEODE-8176:


Commit 6dabaeb519de64d53029d02541d69010d8c2f3f4 in geode's branch 
refs/heads/feature/GEODE-8067 from Alberto Bustamante Reyes
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=6dabaeb ]

GEODE-8176: Add more checks in the flaky ping test (#5176)



> CI Failure: ClientServerMiscBCDUnitTest > testPingWrongServer[1] 
> -
>
> Key: GEODE-8176
> URL: https://issues.apache.org/jira/browse/GEODE-8176
> Project: Geode
>  Issue Type: Bug
>Reporter: Donal Evans
>Assignee: Alberto Bustamante Reyes
>Priority: Major
>
> Failed in 
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/UpgradeTestOpenJDK8/builds/192#A
> {noformat}
> org.apache.geode.internal.cache.tier.sockets.ClientServerMiscBCDUnitTest > 
> testPingWrongServer[1] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.internal.cache.tier.sockets.ClientServerMiscDUnitTestBase$$Lambda$310/201549247.run
>  in VM 3 running on Host c0a964e32781 with 5 VMs
> Caused by:
> org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
> {noformat}
> I ran the test 200 times locally with no failure, so this is possibly just a 
> blip.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8232) Add better error message for know redis commands that are not implemented

2020-06-10 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on GEODE-8232:


Commit 20ed5a89246e465e8c79d3da61144e7911067d5b in geode's branch 
refs/heads/feature/GEODE-8067 from Darrel Schneider
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=20ed5a8 ]

GEODE-8232: add better error message for unimplemented redis commands (#5219)

* If a known redis command that is not implemented is executed then
it will fail with the message ' is not implemented'.
* An "info" level message will also be logged on the redis server.

> Add better error message for know redis commands that are not implemented
> -
>
> Key: GEODE-8232
> URL: https://issues.apache.org/jira/browse/GEODE-8232
> Project: Geode
>  Issue Type: Improvement
>  Components: redis
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>Priority: Major
> Fix For: 1.14.0
>
>
> Currently a known, unimplemented, redis command gives the same error message 
> as does executing a redis command that does not exist in any redis release.
> It would be helpful to users if they get a different error message for these 
> two classes of commands.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8037) Create BootstrappingService Interface

2020-06-10 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on GEODE-8037:


Commit 986c5936b7b354e288d540d97c2a02dc5e049b98 in geode's branch 
refs/heads/feature/GEODE-8067 from Patrick Johnson
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=986c593 ]

GEODE-8037 - Create BootstrappingService interface. (#5046)



> Create BootstrappingService Interface
> -
>
> Key: GEODE-8037
> URL: https://issues.apache.org/jira/browse/GEODE-8037
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Patrick Johnsn
>Assignee: Patrick Johnsn
>Priority: Major
>
> Create a BootstrapingService interface. The BootstrappingService will use the 
> ModuleService to bootstrap Geode in a classloader-isolated way, i.e. loading 
> the necessary modules to run Geode.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8148) Implement unloadModule in JBossModuleService

2020-06-10 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on GEODE-8148:


Commit 923735772bc7d46b84fe430170be875f43713a48 in geode's branch 
refs/heads/feature/GEODE-8067 from Patrick Johnson
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=9237357 ]

GEODE-8148 - Implement unloadModule. (#5151)



> Implement unloadModule in JBossModuleService
> 
>
> Key: GEODE-8148
> URL: https://issues.apache.org/jira/browse/GEODE-8148
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Patrick Johnsn
>Assignee: Patrick Johnsn
>Priority: Major
>
> unloadModule will unload JBoss modules previously loaded by loadModule. 
> unloadModule takes a String that represents the name of the module to find 
> and unload. It should return true when successfully unloading a module and 
> false if it cannot find or cannot unload the specified module.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8233) add equals and hashCode implementations to RedisData classes

2020-06-10 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on GEODE-8233:


Commit 11e80c36116b4b3a3e4c7d6ad6a9dd4de63bddcf in geode's branch 
refs/heads/feature/GEODE-8067 from Darrel Schneider
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=11e80c3 ]

GEODE-8233: add equals and hashCode to RedisData classes (#5220)



> add equals and hashCode implementations to RedisData classes
> 
>
> Key: GEODE-8233
> URL: https://issues.apache.org/jira/browse/GEODE-8233
> Project: Geode
>  Issue Type: Improvement
>  Components: redis
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>Priority: Major
> Fix For: 1.14.0
>
>
> The classes that implement RedisData should override equals and hashCode to 
> have implementations that use the actual data.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8043) Create JBoss-Modules ModuleService Implementation - loadModule

2020-06-10 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on GEODE-8043:


Commit 1b057c361ee06f5a0e39f05ad2ce1485c91f35fe in geode's branch 
refs/heads/feature/GEODE-8067 from Udo Kohlmeyer
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=1b057c3 ]

GEODE-8043 - Create JBossModuleService and implement loadModule. (#5081)


> Create JBoss-Modules ModuleService Implementation - loadModule
> --
>
> Key: GEODE-8043
> URL: https://issues.apache.org/jira/browse/GEODE-8043
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Patrick Johnsn
>Assignee: Patrick Johnsn
>Priority: Major
>
> Implement the loadModule method of the ModuleService interface using 
> JBoss-Modules.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8230) run benchmarks in parallel with other CI

2020-06-10 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on GEODE-8230:


Commit f65ea452443bcd2d0dac6ef1d2d958b0cb02936f in geode's branch 
refs/heads/feature/GEODE-8067 from Owen Nichols
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=f65ea45 ]

GEODE-8230: run benchmarks in parallel with other CI jobs (#5217)

* run benchmarks in parallel with other CI jobs
* eliminate JDK11 flavors for deterministic already-required-in-PR-pipeline 
jobs UnitTest and ApiChecker
* add Benchmarks tab

> run benchmarks in parallel with other CI
> 
>
> Key: GEODE-8230
> URL: https://issues.apache.org/jira/browse/GEODE-8230
> Project: Geode
>  Issue Type: Improvement
>  Components: ci
>Reporter: Owen Nichols
>Assignee: Owen Nichols
>Priority: Major
> Fix For: 1.12.1, 1.13.0, 1.14.0
>
>
> currently, we run Build, then all Test jobs in parallel (which takes ~5 
> hours), then all Benchmark jobs (which takes ~5 hours).
> Presumably the benchmarks were run after all tests, on the premise that 
> benchmarks are meaningless if the code is not correct.  However, required PR 
> checks now prevent incorrect code from getting into develop in the first 
> place, and the remaining occasional failures are flaky, so it's rather 
> arbitrary to gate benchmarks on a lottery.
> However, faster feedback has clear benefits, and cutting our CI pipeline from 
> 10 hours to 5 hours seems like low-hanging fruit.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8234) the internal redis functions should all implement InternalFunction

2020-06-10 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on GEODE-8234:


Commit 6e65b075351cf25f36c6023edc6b6608e48bf257 in geode's branch 
refs/heads/feature/GEODE-8067 from Darrel Schneider
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=6e65b07 ]

GEODE-8234: change redis functions to implement InternalFunction (#5229)



> the internal redis functions should all implement InternalFunction
> --
>
> Key: GEODE-8234
> URL: https://issues.apache.org/jira/browse/GEODE-8234
> Project: Geode
>  Issue Type: Bug
>  Components: redis
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>Priority: Major
> Fix For: 1.14.0
>
>
> The redis internal functions should all implement InternalFunction. This will 
> prevent users from directly executing them from a client.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8137) Implement loadService on JBossModuleService

2020-06-10 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on GEODE-8137:


Commit 5c1fbcd70ec25e94722d58109b67b5bdbd171ae3 in geode's branch 
refs/heads/feature/GEODE-8067 from Patrick Johnson
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=5c1fbcd ]

GEODE-8137 - Implement loadService. (#5136)



> Implement loadService on JBossModuleService
> ---
>
> Key: GEODE-8137
> URL: https://issues.apache.org/jira/browse/GEODE-8137
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Patrick Johnsn
>Assignee: Patrick Johnsn
>Priority: Major
>
> Implement loadService to load implementations of a given interface from JBoss 
> Modules.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8176) CI Failure: ClientServerMiscBCDUnitTest > testPingWrongServer[1]

2020-06-10 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on GEODE-8176:


Commit 6dabaeb519de64d53029d02541d69010d8c2f3f4 in geode's branch 
refs/heads/feature/GEODE-8067 from Alberto Bustamante Reyes
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=6dabaeb ]

GEODE-8176: Add more checks in the flaky ping test (#5176)



> CI Failure: ClientServerMiscBCDUnitTest > testPingWrongServer[1] 
> -
>
> Key: GEODE-8176
> URL: https://issues.apache.org/jira/browse/GEODE-8176
> Project: Geode
>  Issue Type: Bug
>Reporter: Donal Evans
>Assignee: Alberto Bustamante Reyes
>Priority: Major
>
> Failed in 
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/UpgradeTestOpenJDK8/builds/192#A
> {noformat}
> org.apache.geode.internal.cache.tier.sockets.ClientServerMiscBCDUnitTest > 
> testPingWrongServer[1] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.internal.cache.tier.sockets.ClientServerMiscDUnitTestBase$$Lambda$310/201549247.run
>  in VM 3 running on Host c0a964e32781 with 5 VMs
> Caused by:
> org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
> {noformat}
> I ran the test 200 times locally with no failure, so this is possibly just a 
> blip.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8230) run benchmarks in parallel with other CI

2020-06-10 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on GEODE-8230:


Commit f65ea452443bcd2d0dac6ef1d2d958b0cb02936f in geode's branch 
refs/heads/feature/GEODE-8067 from Owen Nichols
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=f65ea45 ]

GEODE-8230: run benchmarks in parallel with other CI jobs (#5217)

* run benchmarks in parallel with other CI jobs
* eliminate JDK11 flavors for deterministic already-required-in-PR-pipeline 
jobs UnitTest and ApiChecker
* add Benchmarks tab

> run benchmarks in parallel with other CI
> 
>
> Key: GEODE-8230
> URL: https://issues.apache.org/jira/browse/GEODE-8230
> Project: Geode
>  Issue Type: Improvement
>  Components: ci
>Reporter: Owen Nichols
>Assignee: Owen Nichols
>Priority: Major
> Fix For: 1.12.1, 1.13.0, 1.14.0
>
>
> currently, we run Build, then all Test jobs in parallel (which takes ~5 
> hours), then all Benchmark jobs (which takes ~5 hours).
> Presumably the benchmarks were run after all tests, on the premise that 
> benchmarks are meaningless if the code is not correct.  However, required PR 
> checks now prevent incorrect code from getting into develop in the first 
> place, and the remaining occasional failures are flaky, so it's rather 
> arbitrary to gate benchmarks on a lottery.
> However, faster feedback has clear benefits, and cutting our CI pipeline from 
> 10 hours to 5 hours seems like low-hanging fruit.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8041) Create ManagementService Interface

2020-06-10 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on GEODE-8041:


Commit 202d7ac040696f19715b8c853580d4c1b2694007 in geode's branch 
refs/heads/feature/GEODE-8067 from Patrick Johnson
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=202d7ac ]

GEODE-8041 - Create ManagementService interface. (#5062)



> Create ManagementService Interface
> --
>
> Key: GEODE-8041
> URL: https://issues.apache.org/jira/browse/GEODE-8041
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Patrick Johnsn
>Assignee: Patrick Johnsn
>Priority: Major
>
> Create a ManagementService interface. The ManagementService will configure 
> and start Geode (create a Cache given some configuration properties) after 
> the BootstrappingService has bootstrapped the environment and loaded the 
> relevant modules.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8148) Implement unloadModule in JBossModuleService

2020-06-10 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on GEODE-8148:


Commit 923735772bc7d46b84fe430170be875f43713a48 in geode's branch 
refs/heads/feature/GEODE-8067 from Patrick Johnson
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=9237357 ]

GEODE-8148 - Implement unloadModule. (#5151)



> Implement unloadModule in JBossModuleService
> 
>
> Key: GEODE-8148
> URL: https://issues.apache.org/jira/browse/GEODE-8148
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Patrick Johnsn
>Assignee: Patrick Johnsn
>Priority: Major
>
> unloadModule will unload JBoss modules previously loaded by loadModule. 
> unloadModule takes a String that represents the name of the module to find 
> and unload. It should return true when successfully unloading a module and 
> false if it cannot find or cannot unload the specified module.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8137) Implement loadService on JBossModuleService

2020-06-10 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on GEODE-8137:


Commit 5c1fbcd70ec25e94722d58109b67b5bdbd171ae3 in geode's branch 
refs/heads/feature/GEODE-8067 from Patrick Johnson
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=5c1fbcd ]

GEODE-8137 - Implement loadService. (#5136)



> Implement loadService on JBossModuleService
> ---
>
> Key: GEODE-8137
> URL: https://issues.apache.org/jira/browse/GEODE-8137
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Patrick Johnsn
>Assignee: Patrick Johnsn
>Priority: Major
>
> Implement loadService to load implementations of a given interface from JBoss 
> Modules.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8043) Create JBoss-Modules ModuleService Implementation - loadModule

2020-06-10 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on GEODE-8043:


Commit 1b057c361ee06f5a0e39f05ad2ce1485c91f35fe in geode's branch 
refs/heads/feature/GEODE-8067 from Udo Kohlmeyer
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=1b057c3 ]

GEODE-8043 - Create JBossModuleService and implement loadModule. (#5081)


> Create JBoss-Modules ModuleService Implementation - loadModule
> --
>
> Key: GEODE-8043
> URL: https://issues.apache.org/jira/browse/GEODE-8043
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Patrick Johnsn
>Assignee: Patrick Johnsn
>Priority: Major
>
> Implement the loadModule method of the ModuleService interface using 
> JBoss-Modules.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8232) Add better error message for know redis commands that are not implemented

2020-06-10 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on GEODE-8232:


Commit 20ed5a89246e465e8c79d3da61144e7911067d5b in geode's branch 
refs/heads/feature/GEODE-8067 from Darrel Schneider
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=20ed5a8 ]

GEODE-8232: add better error message for unimplemented redis commands (#5219)

* If a known redis command that is not implemented is executed then
it will fail with the message ' is not implemented'.
* An "info" level message will also be logged on the redis server.

> Add better error message for know redis commands that are not implemented
> -
>
> Key: GEODE-8232
> URL: https://issues.apache.org/jira/browse/GEODE-8232
> Project: Geode
>  Issue Type: Improvement
>  Components: redis
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>Priority: Major
> Fix For: 1.14.0
>
>
> Currently a known, unimplemented, redis command gives the same error message 
> as does executing a redis command that does not exist in any redis release.
> It would be helpful to users if they get a different error message for these 
> two classes of commands.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8234) the internal redis functions should all implement InternalFunction

2020-06-10 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on GEODE-8234:


Commit 6e65b075351cf25f36c6023edc6b6608e48bf257 in geode's branch 
refs/heads/feature/GEODE-8067 from Darrel Schneider
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=6e65b07 ]

GEODE-8234: change redis functions to implement InternalFunction (#5229)



> the internal redis functions should all implement InternalFunction
> --
>
> Key: GEODE-8234
> URL: https://issues.apache.org/jira/browse/GEODE-8234
> Project: Geode
>  Issue Type: Bug
>  Components: redis
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>Priority: Major
> Fix For: 1.14.0
>
>
> The redis internal functions should all implement InternalFunction. This will 
> prevent users from directly executing them from a client.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8233) add equals and hashCode implementations to RedisData classes

2020-06-10 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on GEODE-8233:


Commit 11e80c36116b4b3a3e4c7d6ad6a9dd4de63bddcf in geode's branch 
refs/heads/feature/GEODE-8067 from Darrel Schneider
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=11e80c3 ]

GEODE-8233: add equals and hashCode to RedisData classes (#5220)



> add equals and hashCode implementations to RedisData classes
> 
>
> Key: GEODE-8233
> URL: https://issues.apache.org/jira/browse/GEODE-8233
> Project: Geode
>  Issue Type: Improvement
>  Components: redis
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>Priority: Major
> Fix For: 1.14.0
>
>
> The classes that implement RedisData should override equals and hashCode to 
> have implementations that use the actual data.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8037) Create BootstrappingService Interface

2020-06-10 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on GEODE-8037:


Commit 986c5936b7b354e288d540d97c2a02dc5e049b98 in geode's branch 
refs/heads/feature/GEODE-8067 from Patrick Johnson
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=986c593 ]

GEODE-8037 - Create BootstrappingService interface. (#5046)



> Create BootstrappingService Interface
> -
>
> Key: GEODE-8037
> URL: https://issues.apache.org/jira/browse/GEODE-8037
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Patrick Johnsn
>Assignee: Patrick Johnsn
>Priority: Major
>
> Create a BootstrapingService interface. The BootstrappingService will use the 
> ModuleService to bootstrap Geode in a classloader-isolated way, i.e. loading 
> the necessary modules to run Geode.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8148) Implement unloadModule in JBossModuleService

2020-06-10 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on GEODE-8148:


Commit 923735772bc7d46b84fe430170be875f43713a48 in geode's branch 
refs/heads/feature/GEODE-8067 from Patrick Johnson
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=9237357 ]

GEODE-8148 - Implement unloadModule. (#5151)



> Implement unloadModule in JBossModuleService
> 
>
> Key: GEODE-8148
> URL: https://issues.apache.org/jira/browse/GEODE-8148
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Patrick Johnsn
>Assignee: Patrick Johnsn
>Priority: Major
>
> unloadModule will unload JBoss modules previously loaded by loadModule. 
> unloadModule takes a String that represents the name of the module to find 
> and unload. It should return true when successfully unloading a module and 
> false if it cannot find or cannot unload the specified module.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8233) add equals and hashCode implementations to RedisData classes

2020-06-10 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on GEODE-8233:


Commit 11e80c36116b4b3a3e4c7d6ad6a9dd4de63bddcf in geode's branch 
refs/heads/feature/GEODE-8067 from Darrel Schneider
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=11e80c3 ]

GEODE-8233: add equals and hashCode to RedisData classes (#5220)



> add equals and hashCode implementations to RedisData classes
> 
>
> Key: GEODE-8233
> URL: https://issues.apache.org/jira/browse/GEODE-8233
> Project: Geode
>  Issue Type: Improvement
>  Components: redis
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>Priority: Major
> Fix For: 1.14.0
>
>
> The classes that implement RedisData should override equals and hashCode to 
> have implementations that use the actual data.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8232) Add better error message for know redis commands that are not implemented

2020-06-10 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on GEODE-8232:


Commit 20ed5a89246e465e8c79d3da61144e7911067d5b in geode's branch 
refs/heads/feature/GEODE-8067 from Darrel Schneider
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=20ed5a8 ]

GEODE-8232: add better error message for unimplemented redis commands (#5219)

* If a known redis command that is not implemented is executed then
it will fail with the message ' is not implemented'.
* An "info" level message will also be logged on the redis server.

> Add better error message for know redis commands that are not implemented
> -
>
> Key: GEODE-8232
> URL: https://issues.apache.org/jira/browse/GEODE-8232
> Project: Geode
>  Issue Type: Improvement
>  Components: redis
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>Priority: Major
> Fix For: 1.14.0
>
>
> Currently a known, unimplemented, redis command gives the same error message 
> as does executing a redis command that does not exist in any redis release.
> It would be helpful to users if they get a different error message for these 
> two classes of commands.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8234) the internal redis functions should all implement InternalFunction

2020-06-10 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on GEODE-8234:


Commit 6e65b075351cf25f36c6023edc6b6608e48bf257 in geode's branch 
refs/heads/feature/GEODE-8067 from Darrel Schneider
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=6e65b07 ]

GEODE-8234: change redis functions to implement InternalFunction (#5229)



> the internal redis functions should all implement InternalFunction
> --
>
> Key: GEODE-8234
> URL: https://issues.apache.org/jira/browse/GEODE-8234
> Project: Geode
>  Issue Type: Bug
>  Components: redis
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>Priority: Major
> Fix For: 1.14.0
>
>
> The redis internal functions should all implement InternalFunction. This will 
> prevent users from directly executing them from a client.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8176) CI Failure: ClientServerMiscBCDUnitTest > testPingWrongServer[1]

2020-06-10 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on GEODE-8176:


Commit 6dabaeb519de64d53029d02541d69010d8c2f3f4 in geode's branch 
refs/heads/feature/GEODE-8067 from Alberto Bustamante Reyes
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=6dabaeb ]

GEODE-8176: Add more checks in the flaky ping test (#5176)



> CI Failure: ClientServerMiscBCDUnitTest > testPingWrongServer[1] 
> -
>
> Key: GEODE-8176
> URL: https://issues.apache.org/jira/browse/GEODE-8176
> Project: Geode
>  Issue Type: Bug
>Reporter: Donal Evans
>Assignee: Alberto Bustamante Reyes
>Priority: Major
>
> Failed in 
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/UpgradeTestOpenJDK8/builds/192#A
> {noformat}
> org.apache.geode.internal.cache.tier.sockets.ClientServerMiscBCDUnitTest > 
> testPingWrongServer[1] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.internal.cache.tier.sockets.ClientServerMiscDUnitTestBase$$Lambda$310/201549247.run
>  in VM 3 running on Host c0a964e32781 with 5 VMs
> Caused by:
> org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
> {noformat}
> I ran the test 200 times locally with no failure, so this is possibly just a 
> blip.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8230) run benchmarks in parallel with other CI

2020-06-10 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on GEODE-8230:


Commit f65ea452443bcd2d0dac6ef1d2d958b0cb02936f in geode's branch 
refs/heads/feature/GEODE-8067 from Owen Nichols
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=f65ea45 ]

GEODE-8230: run benchmarks in parallel with other CI jobs (#5217)

* run benchmarks in parallel with other CI jobs
* eliminate JDK11 flavors for deterministic already-required-in-PR-pipeline 
jobs UnitTest and ApiChecker
* add Benchmarks tab

> run benchmarks in parallel with other CI
> 
>
> Key: GEODE-8230
> URL: https://issues.apache.org/jira/browse/GEODE-8230
> Project: Geode
>  Issue Type: Improvement
>  Components: ci
>Reporter: Owen Nichols
>Assignee: Owen Nichols
>Priority: Major
> Fix For: 1.12.1, 1.13.0, 1.14.0
>
>
> currently, we run Build, then all Test jobs in parallel (which takes ~5 
> hours), then all Benchmark jobs (which takes ~5 hours).
> Presumably the benchmarks were run after all tests, on the premise that 
> benchmarks are meaningless if the code is not correct.  However, required PR 
> checks now prevent incorrect code from getting into develop in the first 
> place, and the remaining occasional failures are flaky, so it's rather 
> arbitrary to gate benchmarks on a lottery.
> However, faster feedback has clear benefits, and cutting our CI pipeline from 
> 10 hours to 5 hours seems like low-hanging fruit.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8037) Create BootstrappingService Interface

2020-06-10 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on GEODE-8037:


Commit 986c5936b7b354e288d540d97c2a02dc5e049b98 in geode's branch 
refs/heads/feature/GEODE-8067 from Patrick Johnson
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=986c593 ]

GEODE-8037 - Create BootstrappingService interface. (#5046)



> Create BootstrappingService Interface
> -
>
> Key: GEODE-8037
> URL: https://issues.apache.org/jira/browse/GEODE-8037
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Patrick Johnsn
>Assignee: Patrick Johnsn
>Priority: Major
>
> Create a BootstrapingService interface. The BootstrappingService will use the 
> ModuleService to bootstrap Geode in a classloader-isolated way, i.e. loading 
> the necessary modules to run Geode.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8137) Implement loadService on JBossModuleService

2020-06-10 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on GEODE-8137:


Commit 5c1fbcd70ec25e94722d58109b67b5bdbd171ae3 in geode's branch 
refs/heads/feature/GEODE-8067 from Patrick Johnson
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=5c1fbcd ]

GEODE-8137 - Implement loadService. (#5136)



> Implement loadService on JBossModuleService
> ---
>
> Key: GEODE-8137
> URL: https://issues.apache.org/jira/browse/GEODE-8137
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Patrick Johnsn
>Assignee: Patrick Johnsn
>Priority: Major
>
> Implement loadService to load implementations of a given interface from JBoss 
> Modules.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8041) Create ManagementService Interface

2020-06-10 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on GEODE-8041:


Commit 202d7ac040696f19715b8c853580d4c1b2694007 in geode's branch 
refs/heads/feature/GEODE-8067 from Patrick Johnson
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=202d7ac ]

GEODE-8041 - Create ManagementService interface. (#5062)



> Create ManagementService Interface
> --
>
> Key: GEODE-8041
> URL: https://issues.apache.org/jira/browse/GEODE-8041
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Patrick Johnsn
>Assignee: Patrick Johnsn
>Priority: Major
>
> Create a ManagementService interface. The ManagementService will configure 
> and start Geode (create a Cache given some configuration properties) after 
> the BootstrappingService has bootstrapped the environment and loaded the 
> relevant modules.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8043) Create JBoss-Modules ModuleService Implementation - loadModule

2020-06-10 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on GEODE-8043:


Commit 1b057c361ee06f5a0e39f05ad2ce1485c91f35fe in geode's branch 
refs/heads/feature/GEODE-8067 from Udo Kohlmeyer
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=1b057c3 ]

GEODE-8043 - Create JBossModuleService and implement loadModule. (#5081)


> Create JBoss-Modules ModuleService Implementation - loadModule
> --
>
> Key: GEODE-8043
> URL: https://issues.apache.org/jira/browse/GEODE-8043
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Patrick Johnsn
>Assignee: Patrick Johnsn
>Priority: Major
>
> Implement the loadModule method of the ModuleService interface using 
> JBoss-Modules.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8148) Implement unloadModule in JBossModuleService

2020-06-10 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on GEODE-8148:


Commit 923735772bc7d46b84fe430170be875f43713a48 in geode's branch 
refs/heads/feature/GEODE-8067 from Patrick Johnson
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=9237357 ]

GEODE-8148 - Implement unloadModule. (#5151)



> Implement unloadModule in JBossModuleService
> 
>
> Key: GEODE-8148
> URL: https://issues.apache.org/jira/browse/GEODE-8148
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Patrick Johnsn
>Assignee: Patrick Johnsn
>Priority: Major
>
> unloadModule will unload JBoss modules previously loaded by loadModule. 
> unloadModule takes a String that represents the name of the module to find 
> and unload. It should return true when successfully unloading a module and 
> false if it cannot find or cannot unload the specified module.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8043) Create JBoss-Modules ModuleService Implementation - loadModule

2020-06-10 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on GEODE-8043:


Commit 1b057c361ee06f5a0e39f05ad2ce1485c91f35fe in geode's branch 
refs/heads/feature/GEODE-8067 from Udo Kohlmeyer
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=1b057c3 ]

GEODE-8043 - Create JBossModuleService and implement loadModule. (#5081)


> Create JBoss-Modules ModuleService Implementation - loadModule
> --
>
> Key: GEODE-8043
> URL: https://issues.apache.org/jira/browse/GEODE-8043
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Patrick Johnsn
>Assignee: Patrick Johnsn
>Priority: Major
>
> Implement the loadModule method of the ModuleService interface using 
> JBoss-Modules.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8137) Implement loadService on JBossModuleService

2020-06-10 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on GEODE-8137:


Commit 5c1fbcd70ec25e94722d58109b67b5bdbd171ae3 in geode's branch 
refs/heads/feature/GEODE-8067 from Patrick Johnson
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=5c1fbcd ]

GEODE-8137 - Implement loadService. (#5136)



> Implement loadService on JBossModuleService
> ---
>
> Key: GEODE-8137
> URL: https://issues.apache.org/jira/browse/GEODE-8137
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Patrick Johnsn
>Assignee: Patrick Johnsn
>Priority: Major
>
> Implement loadService to load implementations of a given interface from JBoss 
> Modules.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8041) Create ManagementService Interface

2020-06-10 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on GEODE-8041:


Commit 202d7ac040696f19715b8c853580d4c1b2694007 in geode's branch 
refs/heads/feature/GEODE-8067 from Patrick Johnson
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=202d7ac ]

GEODE-8041 - Create ManagementService interface. (#5062)



> Create ManagementService Interface
> --
>
> Key: GEODE-8041
> URL: https://issues.apache.org/jira/browse/GEODE-8041
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Patrick Johnsn
>Assignee: Patrick Johnsn
>Priority: Major
>
> Create a ManagementService interface. The ManagementService will configure 
> and start Geode (create a Cache given some configuration properties) after 
> the BootstrappingService has bootstrapped the environment and loaded the 
> relevant modules.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8233) add equals and hashCode implementations to RedisData classes

2020-06-10 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on GEODE-8233:


Commit 11e80c36116b4b3a3e4c7d6ad6a9dd4de63bddcf in geode's branch 
refs/heads/feature/GEODE-8067 from Darrel Schneider
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=11e80c3 ]

GEODE-8233: add equals and hashCode to RedisData classes (#5220)



> add equals and hashCode implementations to RedisData classes
> 
>
> Key: GEODE-8233
> URL: https://issues.apache.org/jira/browse/GEODE-8233
> Project: Geode
>  Issue Type: Improvement
>  Components: redis
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>Priority: Major
> Fix For: 1.14.0
>
>
> The classes that implement RedisData should override equals and hashCode to 
> have implementations that use the actual data.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8037) Create BootstrappingService Interface

2020-06-10 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on GEODE-8037:


Commit 986c5936b7b354e288d540d97c2a02dc5e049b98 in geode's branch 
refs/heads/feature/GEODE-8067 from Patrick Johnson
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=986c593 ]

GEODE-8037 - Create BootstrappingService interface. (#5046)



> Create BootstrappingService Interface
> -
>
> Key: GEODE-8037
> URL: https://issues.apache.org/jira/browse/GEODE-8037
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Patrick Johnsn
>Assignee: Patrick Johnsn
>Priority: Major
>
> Create a BootstrapingService interface. The BootstrappingService will use the 
> ModuleService to bootstrap Geode in a classloader-isolated way, i.e. loading 
> the necessary modules to run Geode.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8230) run benchmarks in parallel with other CI

2020-06-10 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on GEODE-8230:


Commit f65ea452443bcd2d0dac6ef1d2d958b0cb02936f in geode's branch 
refs/heads/feature/GEODE-8067 from Owen Nichols
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=f65ea45 ]

GEODE-8230: run benchmarks in parallel with other CI jobs (#5217)

* run benchmarks in parallel with other CI jobs
* eliminate JDK11 flavors for deterministic already-required-in-PR-pipeline 
jobs UnitTest and ApiChecker
* add Benchmarks tab

> run benchmarks in parallel with other CI
> 
>
> Key: GEODE-8230
> URL: https://issues.apache.org/jira/browse/GEODE-8230
> Project: Geode
>  Issue Type: Improvement
>  Components: ci
>Reporter: Owen Nichols
>Assignee: Owen Nichols
>Priority: Major
> Fix For: 1.12.1, 1.13.0, 1.14.0
>
>
> currently, we run Build, then all Test jobs in parallel (which takes ~5 
> hours), then all Benchmark jobs (which takes ~5 hours).
> Presumably the benchmarks were run after all tests, on the premise that 
> benchmarks are meaningless if the code is not correct.  However, required PR 
> checks now prevent incorrect code from getting into develop in the first 
> place, and the remaining occasional failures are flaky, so it's rather 
> arbitrary to gate benchmarks on a lottery.
> However, faster feedback has clear benefits, and cutting our CI pipeline from 
> 10 hours to 5 hours seems like low-hanging fruit.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8176) CI Failure: ClientServerMiscBCDUnitTest > testPingWrongServer[1]

2020-06-10 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on GEODE-8176:


Commit 6dabaeb519de64d53029d02541d69010d8c2f3f4 in geode's branch 
refs/heads/feature/GEODE-8067 from Alberto Bustamante Reyes
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=6dabaeb ]

GEODE-8176: Add more checks in the flaky ping test (#5176)



> CI Failure: ClientServerMiscBCDUnitTest > testPingWrongServer[1] 
> -
>
> Key: GEODE-8176
> URL: https://issues.apache.org/jira/browse/GEODE-8176
> Project: Geode
>  Issue Type: Bug
>Reporter: Donal Evans
>Assignee: Alberto Bustamante Reyes
>Priority: Major
>
> Failed in 
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/UpgradeTestOpenJDK8/builds/192#A
> {noformat}
> org.apache.geode.internal.cache.tier.sockets.ClientServerMiscBCDUnitTest > 
> testPingWrongServer[1] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.internal.cache.tier.sockets.ClientServerMiscDUnitTestBase$$Lambda$310/201549247.run
>  in VM 3 running on Host c0a964e32781 with 5 VMs
> Caused by:
> org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
> {noformat}
> I ran the test 200 times locally with no failure, so this is possibly just a 
> blip.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8234) the internal redis functions should all implement InternalFunction

2020-06-10 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on GEODE-8234:


Commit 6e65b075351cf25f36c6023edc6b6608e48bf257 in geode's branch 
refs/heads/feature/GEODE-8067 from Darrel Schneider
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=6e65b07 ]

GEODE-8234: change redis functions to implement InternalFunction (#5229)



> the internal redis functions should all implement InternalFunction
> --
>
> Key: GEODE-8234
> URL: https://issues.apache.org/jira/browse/GEODE-8234
> Project: Geode
>  Issue Type: Bug
>  Components: redis
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>Priority: Major
> Fix For: 1.14.0
>
>
> The redis internal functions should all implement InternalFunction. This will 
> prevent users from directly executing them from a client.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8232) Add better error message for know redis commands that are not implemented

2020-06-10 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on GEODE-8232:


Commit 20ed5a89246e465e8c79d3da61144e7911067d5b in geode's branch 
refs/heads/feature/GEODE-8067 from Darrel Schneider
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=20ed5a8 ]

GEODE-8232: add better error message for unimplemented redis commands (#5219)

* If a known redis command that is not implemented is executed then
it will fail with the message ' is not implemented'.
* An "info" level message will also be logged on the redis server.

> Add better error message for know redis commands that are not implemented
> -
>
> Key: GEODE-8232
> URL: https://issues.apache.org/jira/browse/GEODE-8232
> Project: Geode
>  Issue Type: Improvement
>  Components: redis
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>Priority: Major
> Fix For: 1.14.0
>
>
> Currently a known, unimplemented, redis command gives the same error message 
> as does executing a redis command that does not exist in any redis release.
> It would be helpful to users if they get a different error message for these 
> two classes of commands.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8205) Feature flag unsupported Redis commands

2020-06-10 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on GEODE-8205:


Commit 1231db1c70632c3f822a63cbd6a4e662d542c961 in geode's branch 
refs/heads/develop from Sarah Abbey
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=1231db1 ]

GEODE-8205: add gfsh redis command (#5226)

Unsupported commands can now be enabled dynamically on running servers using 
'gfsh redis --enable-unsupported-commands'.

A warning is now logged if unsupported commands are enabled.
The error message has been improved.


> Feature flag unsupported Redis commands
> ---
>
> Key: GEODE-8205
> URL: https://issues.apache.org/jira/browse/GEODE-8205
> Project: Geode
>  Issue Type: Improvement
>  Components: redis
>Reporter: Jens Deppe
>Assignee: Darrel Schneider
>Priority: Major
> Fix For: 1.14.0
>
>
> Hide unsupported Redis commands behind system property 
> {{enable-unsupported-redis-commands}}.
> This will be removed once all commands are supported.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8238) message loss during shutdown in Shutdown Hook when JVM exits

2020-06-10 Thread ASF GitHub Bot (Jira)


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

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

bschuchardt opened a new pull request #5232:
URL: https://github.com/apache/geode/pull/5232


   Remove invocation of removeEndpoint when a shared/unordered connection
   shuts down.  Endpoint cleanup is already initiated by DistributionImpl
   during membership view installation, so it isn't needed here.
   
   Thank you for submitting a contribution to Apache Geode.
   
   In order to streamline the review of the contribution we ask you
   to ensure the following steps have been taken:
   
   ### For all changes:
   - [ ] Is there a JIRA ticket associated with this PR? Is it referenced in 
the commit message?
   
   - [ ] Has your PR been rebased against the latest commit within the target 
branch (typically `develop`)?
   
   - [ ] Is your initial contribution a single, squashed commit?
   
   - [ ] Does `gradlew build` run cleanly?
   
   - [ ] Have you written or updated unit tests to verify your changes?
   
   - [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)?
   
   ### Note:
   Please ensure that once the PR is submitted, check Concourse for build 
issues and
   submit an update to your PR as soon as possible. If you need help, please 
send an
   email to d...@geode.apache.org.
   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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


> message loss during shutdown in Shutdown Hook when JVM exits
> 
>
> Key: GEODE-8238
> URL: https://issues.apache.org/jira/browse/GEODE-8238
> Project: Geode
>  Issue Type: Bug
>  Components: membership, messaging
>Reporter: Bruce J Schuchardt
>Priority: Major
>
> In a test I was running a JVM was told to exit and Geode's Shutdown Hook 
> initiated cache shutdown.  This thread hung once in a while either waiting 
> for a reply to a release of a distributed lock or for a reply to a 
> region-destroy message.
> I traced this down by adding some logging to TCPConduit and DirectChannel and 
> it's due to the changes for GEODE-7727 ("modify sender thread to detect 
> relese of connection").  Those changes cause the P2P Handshake thread to stay 
> active reading from a shared Connection socket.  Unfortunately, when this 
> thread eventually exits it is invoking removeEndpoint, which closes all the 
> other connections to the other node.  This is causing messages to be lost.
> Here's an example:
> one node (19919) fails to form a connection and invokes removeEndpoint for 
> the other node (23898)
> {noformat}
> bridgegemfire1_19919/system.log: [info 2020/06/09 11:05:08.862 PDT  handshake reader@31e492f-45> tid=0x14f] BRUCE: asyncClose closing Connection, 
> uid=4 shared=true ordered=false 
> remoteAddr=rs-Awesome-14-1023a0i3xlarge-hydra-client-8(bridgegemfire4_host1_23898:23898):41005
>  isReceiver=true
> java.lang.Exception: stack trace
>   at 
> org.apache.geode.internal.tcp.Connection.asyncClose(Connection.java:833)
>   at org.apache.geode.internal.tcp.Connection.close(Connection.java:1338)
>   at 
> org.apache.geode.internal.tcp.Connection.closePartialConnect(Connection.java:1276)
>   at 
> org.apache.geode.internal.tcp.ConnectionTable.closeCon(ConnectionTable.java:612)
>   at 
> org.apache.geode.internal.tcp.ConnectionTable.closeCon(ConnectionTable.java:604)
>   at 
> org.apache.geode.internal.tcp.ConnectionTable.removeEndpoint(ConnectionTable.java:851)
>   at 
> org.apache.geode.internal.tcp.ConnectionTable.removeEndpoint(ConnectionTable.java:751)
>   at org.apache.geode.internal.tcp.Connection.close(Connection.java:1400)
>   at 
> org.apache.geode.internal.tcp.Connection.requestClose(Connection.java:1268)
>   at 
> org.apache.geode.internal.tcp.Connection.readMessages(Connection.java:1661)
>   at org.apache.geode.internal.tcp.Connection.run(Connection.java:1460)
>   at java.base/java.lang.Thread.run(Thread.java:834)
> {noformat}
> The other node's shared/unordered connection was unexpectedly terminated, 
> causing it to also invoke removeEndpoint():
> {noformat}
> bridgegemfire4_23898/system.log: [info 2020/06/09 11:05:08.862 PDT  handshake reader@2e1ef958-4> tid=0x36] BRUCE: asyncClose closing Connection, 
> uid=4 shared=true ordered=false 
> remoteAddr=rs-Awesome-14-1023a0i3xlarge-hydra-client-8(bridgegemfire1_host1_19919:19919):41002
>  

[jira] [Commented] (GEODE-8205) Feature flag unsupported Redis commands

2020-06-10 Thread ASF GitHub Bot (Jira)


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

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

dschneider-pivotal merged pull request #5226:
URL: https://github.com/apache/geode/pull/5226


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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


> Feature flag unsupported Redis commands
> ---
>
> Key: GEODE-8205
> URL: https://issues.apache.org/jira/browse/GEODE-8205
> Project: Geode
>  Issue Type: Improvement
>  Components: redis
>Reporter: Jens Deppe
>Assignee: Darrel Schneider
>Priority: Major
> Fix For: 1.14.0
>
>
> Hide unsupported Redis commands behind system property 
> {{enable-unsupported-redis-commands}}.
> This will be removed once all commands are supported.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (GEODE-8238) message loss during shutdown in Shutdown Hook when JVM exits

2020-06-10 Thread Bruce J Schuchardt (Jira)


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

Bruce J Schuchardt updated GEODE-8238:
--
Description: 
In a test I was running a JVM was told to exit and Geode's Shutdown Hook 
initiated cache shutdown.  This thread hung once in a while either waiting for 
a reply to a release of a distributed lock or for a reply to a region-destroy 
message.

I traced this down by adding some logging to TCPConduit and DirectChannel and 
it's due to the changes for GEODE-7727 ("modify sender thread to detect relese 
of connection").  Those changes cause the P2P Handshake thread to stay active 
reading from a shared Connection socket.  Unfortunately, when this thread 
eventually exits it is invoking removeEndpoint, which closes all the other 
connections to the other node.  This is causing messages to be lost.

Here's an example:

one node (19919) fails to form a connection and invokes removeEndpoint for the 
other node (23898)

{noformat}
bridgegemfire1_19919/system.log: [info 2020/06/09 11:05:08.862 PDT  tid=0x14f] BRUCE: asyncClose closing Connection, 
uid=4 shared=true ordered=false 
remoteAddr=rs-Awesome-14-1023a0i3xlarge-hydra-client-8(bridgegemfire4_host1_23898:23898):41005
 isReceiver=true
java.lang.Exception: stack trace
at 
org.apache.geode.internal.tcp.Connection.asyncClose(Connection.java:833)
at org.apache.geode.internal.tcp.Connection.close(Connection.java:1338)
at 
org.apache.geode.internal.tcp.Connection.closePartialConnect(Connection.java:1276)
at 
org.apache.geode.internal.tcp.ConnectionTable.closeCon(ConnectionTable.java:612)
at 
org.apache.geode.internal.tcp.ConnectionTable.closeCon(ConnectionTable.java:604)
at 
org.apache.geode.internal.tcp.ConnectionTable.removeEndpoint(ConnectionTable.java:851)
at 
org.apache.geode.internal.tcp.ConnectionTable.removeEndpoint(ConnectionTable.java:751)
at org.apache.geode.internal.tcp.Connection.close(Connection.java:1400)
at 
org.apache.geode.internal.tcp.Connection.requestClose(Connection.java:1268)
at 
org.apache.geode.internal.tcp.Connection.readMessages(Connection.java:1661)
at org.apache.geode.internal.tcp.Connection.run(Connection.java:1460)
at java.base/java.lang.Thread.run(Thread.java:834)
{noformat}

The other node's shared/unordered connection was unexpectedly terminated, 
causing it to also invoke removeEndpoint():

{noformat}
bridgegemfire4_23898/system.log: [info 2020/06/09 11:05:08.862 PDT  tid=0x36] BRUCE: asyncClose closing Connection, 
uid=4 shared=true ordered=false 
remoteAddr=rs-Awesome-14-1023a0i3xlarge-hydra-client-8(bridgegemfire1_host1_19919:19919):41002
 isReceiver=false
java.lang.Exception: stack trace
at 
org.apache.geode.internal.tcp.Connection.asyncClose(Connection.java:833)
at org.apache.geode.internal.tcp.Connection.close(Connection.java:1338)
at 
org.apache.geode.internal.tcp.Connection.requestClose(Connection.java:1268)
at 
org.apache.geode.internal.tcp.Connection.readMessages(Connection.java:1619)
at org.apache.geode.internal.tcp.Connection.run(Connection.java:1460)
at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)

bridgegemfire4_23898/system.log: [info 2020/06/09 11:05:08.862 PDT  tid=0x36] BRUCE: removeEndpoint invoked for 
rs-Awesome-14-1023a0i3xlarge-hydra-client-8(bridgegemfire1_host1_19919:19919):41002
 reason=SocketChannel.read returned EOF notifyDisconnect=true
java.lang.Exception: stack trace
at 
org.apache.geode.internal.tcp.ConnectionTable.removeEndpoint(ConnectionTable.java:758)
at 
org.apache.geode.internal.tcp.ConnectionTable.removeEndpoint(ConnectionTable.java:751)
at org.apache.geode.internal.tcp.Connection.close(Connection.java:1400)
at 
org.apache.geode.internal.tcp.Connection.requestClose(Connection.java:1268)
at 
org.apache.geode.internal.tcp.Connection.readMessages(Connection.java:1619)
at org.apache.geode.internal.tcp.Connection.run(Connection.java:1460)
at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)
{noformat}

An unordered message like a Reply can be lost in this case if it is written to 
the Connection's socket but one of these background threads then closes the 
socket.

Here the logs show a reply being sent on a Connection with a UID  (unique ID) 
of 69.  The message is never received because, as you can see, the other node 
closes the socket for Connection with UID 69.

{noformat}

[jira] [Updated] (GEODE-8238) message loss during shutdown in Shutdown Hook when JVM exits

2020-06-10 Thread Bruce J Schuchardt (Jira)


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

Bruce J Schuchardt updated GEODE-8238:
--
Component/s: membership

> message loss during shutdown in Shutdown Hook when JVM exits
> 
>
> Key: GEODE-8238
> URL: https://issues.apache.org/jira/browse/GEODE-8238
> Project: Geode
>  Issue Type: Bug
>  Components: membership, messaging
>Reporter: Bruce J Schuchardt
>Priority: Major
>
> In a test I was running a JVM was told to exit and Geode's Shutdown Hook 
> initiated cache shutdown.  This thread hung once in a while either waiting 
> for a reply to a release of a distributed lock or for a reply to a 
> region-destroy message.
> I traced this down by adding some logging to TCPConduit and DirectChannel and 
> it's due to the changes for GEODE-7727 ("modify sender thread to detect 
> relese of connection").  Those changes cause the P2P Handshake thread to stay 
> active reading from a shared Connection socket.  Unfortunately, when this 
> thread eventually exits it is invoking removeEndpoint, which closes all the 
> other connections to the other node.  This is causing messages to be lost.
> Here's an example:
> one node (19919) fails to form a connection and invokes removeEndpoint for 
> the other node (23898)
> {noformat}
> bridgegemfire1_19919/system.log: [info 2020/06/09 11:05:08.862 PDT  handshake reader@31e492f-45> tid=0x14f] BRUCE: asyncClose closing Connection, 
> uid=4 shared=true ordered=false 
> remoteAddr=rs-Awesome-14-1023a0i3xlarge-hydra-client-8(bridgegemfire4_host1_23898:23898):41005
>  isReceiver=true
> java.lang.Exception: stack trace
>   at 
> org.apache.geode.internal.tcp.Connection.asyncClose(Connection.java:833)
>   at org.apache.geode.internal.tcp.Connection.close(Connection.java:1338)
>   at 
> org.apache.geode.internal.tcp.Connection.closePartialConnect(Connection.java:1276)
>   at 
> org.apache.geode.internal.tcp.ConnectionTable.closeCon(ConnectionTable.java:612)
>   at 
> org.apache.geode.internal.tcp.ConnectionTable.closeCon(ConnectionTable.java:604)
>   at 
> org.apache.geode.internal.tcp.ConnectionTable.removeEndpoint(ConnectionTable.java:851)
>   at 
> org.apache.geode.internal.tcp.ConnectionTable.removeEndpoint(ConnectionTable.java:751)
>   at org.apache.geode.internal.tcp.Connection.close(Connection.java:1400)
>   at 
> org.apache.geode.internal.tcp.Connection.requestClose(Connection.java:1268)
>   at 
> org.apache.geode.internal.tcp.Connection.readMessages(Connection.java:1661)
>   at org.apache.geode.internal.tcp.Connection.run(Connection.java:1460)
>   at java.base/java.lang.Thread.run(Thread.java:834)
> {noformat}
> The other node's shared/unordered connection was unexpectedly terminated, 
> causing it to also invoke removeEndpoint():
> {noformat}
> bridgegemfire4_23898/system.log: [info 2020/06/09 11:05:08.862 PDT  handshake reader@2e1ef958-4> tid=0x36] BRUCE: asyncClose closing Connection, 
> uid=4 shared=true ordered=false 
> remoteAddr=rs-Awesome-14-1023a0i3xlarge-hydra-client-8(bridgegemfire1_host1_19919:19919):41002
>  isReceiver=false
> java.lang.Exception: stack trace
>   at 
> org.apache.geode.internal.tcp.Connection.asyncClose(Connection.java:833)
>   at org.apache.geode.internal.tcp.Connection.close(Connection.java:1338)
>   at 
> org.apache.geode.internal.tcp.Connection.requestClose(Connection.java:1268)
>   at 
> org.apache.geode.internal.tcp.Connection.readMessages(Connection.java:1619)
>   at org.apache.geode.internal.tcp.Connection.run(Connection.java:1460)
>   at 
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
>   at 
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
>   at java.base/java.lang.Thread.run(Thread.java:834)
> bridgegemfire4_23898/system.log: [info 2020/06/09 11:05:08.862 PDT  handshake reader@2e1ef958-4> tid=0x36] BRUCE: removeEndpoint invoked for 
> rs-Awesome-14-1023a0i3xlarge-hydra-client-8(bridgegemfire1_host1_19919:19919):41002
>  reason=SocketChannel.read returned EOF notifyDisconnect=true
> java.lang.Exception: stack trace
>   at 
> org.apache.geode.internal.tcp.ConnectionTable.removeEndpoint(ConnectionTable.java:758)
>   at 
> org.apache.geode.internal.tcp.ConnectionTable.removeEndpoint(ConnectionTable.java:751)
>   at org.apache.geode.internal.tcp.Connection.close(Connection.java:1400)
>   at 
> org.apache.geode.internal.tcp.Connection.requestClose(Connection.java:1268)
>   at 
> org.apache.geode.internal.tcp.Connection.readMessages(Connection.java:1619)
>   at org.apache.geode.internal.tcp.Connection.run(Connection.java:1460)
>   at 
> 

[jira] [Created] (GEODE-8238) message loss during shutdown in Shutdown Hook when JVM exits

2020-06-10 Thread Bruce J Schuchardt (Jira)
Bruce J Schuchardt created GEODE-8238:
-

 Summary: message loss during shutdown in Shutdown Hook when JVM 
exits
 Key: GEODE-8238
 URL: https://issues.apache.org/jira/browse/GEODE-8238
 Project: Geode
  Issue Type: Bug
  Components: messaging
Reporter: Bruce J Schuchardt


In a test I was running a JVM was told to exit and Geode's Shutdown Hook 
initiated cache shutdown.  This thread hung once in a while either waiting for 
a reply to a release of a distributed lock or for a reply to a region-destroy 
message.

I traced this down by adding some logging to TCPConduit and DirectChannel and 
it's due to the changes for GEODE-7727 ("modify sender thread to detect relese 
of connection").  Those changes cause the P2P Handshake thread to stay active 
reading from a shared Connection socket.  Unfortunately, when this thread 
eventually exits it is invoking removeEndpoint, which closes all the other 
connections to the other node.  This is causing messages to be lost.

Here's an example:

one node (19919) fails to form a connection and invokes removeEndpoint for the 
other node (23898)

{noformat}
bridgegemfire1_19919/system.log: [info 2020/06/09 11:05:08.862 PDT  tid=0x14f] BRUCE: asyncClose closing Connection, 
uid=4 shared=true ordered=false 
remoteAddr=rs-Awesome-14-1023a0i3xlarge-hydra-client-8(bridgegemfire4_host1_23898:23898):41005
 isReceiver=true
java.lang.Exception: stack trace
at 
org.apache.geode.internal.tcp.Connection.asyncClose(Connection.java:833)
at org.apache.geode.internal.tcp.Connection.close(Connection.java:1338)
at 
org.apache.geode.internal.tcp.Connection.closePartialConnect(Connection.java:1276)
at 
org.apache.geode.internal.tcp.ConnectionTable.closeCon(ConnectionTable.java:612)
at 
org.apache.geode.internal.tcp.ConnectionTable.closeCon(ConnectionTable.java:604)
at 
org.apache.geode.internal.tcp.ConnectionTable.removeEndpoint(ConnectionTable.java:851)
at 
org.apache.geode.internal.tcp.ConnectionTable.removeEndpoint(ConnectionTable.java:751)
at org.apache.geode.internal.tcp.Connection.close(Connection.java:1400)
at 
org.apache.geode.internal.tcp.Connection.requestClose(Connection.java:1268)
at 
org.apache.geode.internal.tcp.Connection.readMessages(Connection.java:1661)
at org.apache.geode.internal.tcp.Connection.run(Connection.java:1460)
at java.base/java.lang.Thread.run(Thread.java:834)
{noformat}

The other node's shared/unordered connection was unexpectedly terminated, 
causing it to also invoke removeEndpoint():

{noformat}
bridgegemfire4_23898/system.log: [info 2020/06/09 11:05:08.862 PDT  tid=0x36] BRUCE: asyncClose closing Connection, 
uid=4 shared=true ordered=false 
remoteAddr=rs-Awesome-14-1023a0i3xlarge-hydra-client-8(bridgegemfire1_host1_19919:19919):41002
 isReceiver=false
java.lang.Exception: stack trace
at 
org.apache.geode.internal.tcp.Connection.asyncClose(Connection.java:833)
at org.apache.geode.internal.tcp.Connection.close(Connection.java:1338)
at 
org.apache.geode.internal.tcp.Connection.requestClose(Connection.java:1268)
at 
org.apache.geode.internal.tcp.Connection.readMessages(Connection.java:1619)
at org.apache.geode.internal.tcp.Connection.run(Connection.java:1460)
at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)

bridgegemfire4_23898/system.log: [info 2020/06/09 11:05:08.862 PDT  tid=0x36] BRUCE: removeEndpoint invoked for 
rs-Awesome-14-1023a0i3xlarge-hydra-client-8(bridgegemfire1_host1_19919:19919):41002
 reason=SocketChannel.read returned EOF notifyDisconnect=true
java.lang.Exception: stack trace
at 
org.apache.geode.internal.tcp.ConnectionTable.removeEndpoint(ConnectionTable.java:758)
at 
org.apache.geode.internal.tcp.ConnectionTable.removeEndpoint(ConnectionTable.java:751)
at org.apache.geode.internal.tcp.Connection.close(Connection.java:1400)
at 
org.apache.geode.internal.tcp.Connection.requestClose(Connection.java:1268)
at 
org.apache.geode.internal.tcp.Connection.readMessages(Connection.java:1619)
at org.apache.geode.internal.tcp.Connection.run(Connection.java:1460)
at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)
{noformat}

An unordered message like a Reply can be lost in this case if it is written to 
the Connection's socket but one of these background threads then closes the 
socket.

I don't think Connection termination should be 

[jira] [Assigned] (GEODE-8176) CI Failure: ClientServerMiscBCDUnitTest > testPingWrongServer[1]

2020-06-10 Thread Bruce J Schuchardt (Jira)


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

Bruce J Schuchardt reassigned GEODE-8176:
-

Assignee: Alberto Bustamante Reyes

> CI Failure: ClientServerMiscBCDUnitTest > testPingWrongServer[1] 
> -
>
> Key: GEODE-8176
> URL: https://issues.apache.org/jira/browse/GEODE-8176
> Project: Geode
>  Issue Type: Bug
>Reporter: Donal Evans
>Assignee: Alberto Bustamante Reyes
>Priority: Major
>
> Failed in 
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/UpgradeTestOpenJDK8/builds/192#A
> {noformat}
> org.apache.geode.internal.cache.tier.sockets.ClientServerMiscBCDUnitTest > 
> testPingWrongServer[1] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.internal.cache.tier.sockets.ClientServerMiscDUnitTestBase$$Lambda$310/201549247.run
>  in VM 3 running on Host c0a964e32781 with 5 VMs
> Caused by:
> org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
> {noformat}
> I ran the test 200 times locally with no failure, so this is possibly just a 
> blip.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


  1   2   >