[jira] [Updated] (GEODE-8782) Add getPrincipal method to FunctionContext interface
[
https://issues.apache.org/jira/browse/GEODE-8782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols updated GEODE-8782:
Fix Version/s: 1.12.1
> Add getPrincipal method to FunctionContext interface
>
>
> Key: GEODE-8782
> URL: https://issues.apache.org/jira/browse/GEODE-8782
> Project: Geode
> Issue Type: New Feature
> Components: core
>Reporter: Jens Deppe
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.12.1, 1.14.0
>
>
> In some cases it would be very helpful to have access to the {{Principal}}
> when executing a function.
> It may seem obvious that if one has a reference to the {{cache}} that you
> could get to the {{SecurityManager}} and extract the {{Subject}} and thus the
> {{Principal}} from there. However, in some cases, Geode will seamlessly proxy
> a function call from one server to the other. This will typically happen with
> {{onRegion}} calls and partitioned regions. In such cases, the security
> context is lost and thus the principal is not accessible.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8815) Cache could close with uncaught exception
[
https://issues.apache.org/jira/browse/GEODE-8815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17261726#comment-17261726
]
ASF subversion and git services commented on GEODE-8815:
Commit 84f43e1ed75e670de4fe8663e4da7dfa952ffa87 in geode's branch
refs/heads/develop from Jianxia Chen
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=84f43e1 ]
GEODE-8815: Cache could close with uncaught exception (#5882)
* Catch and log all possible throwables before closing the cache
* Add a unit test
> Cache could close with uncaught exception
> -
>
> Key: GEODE-8815
> URL: https://issues.apache.org/jira/browse/GEODE-8815
> Project: Geode
> Issue Type: Bug
>Reporter: Jianxia Chen
>Assignee: Jianxia Chen
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> In GemFireCacheImpl.initialize(), it is possible that an uncaught exception
> is not logged and close the cache.
> {code:java}
> try {
> if (!isClient) {
> applyJarAndXmlFromClusterConfig();
> }
> initializeDeclarativeCache();
> completedCacheXml = true;
> } catch (RuntimeException e) {
> logger.error("Cache initialization for " + this.toString() + " failed
> because:", e);
> throw e;
> } finally {
> if (!completedCacheXml) {
> // so initializeDeclarativeCache threw an exception
> try {
> close();
> } catch (Throwable ignore) {
> // I don't want init to throw an exception that came from the close.
> // I want it to throw the original exception that came from
> initializeDeclarativeCache.
> }
> configurationResponse = null;
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-8815) Cache could close with uncaught exception
[
https://issues.apache.org/jira/browse/GEODE-8815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jianxia Chen resolved GEODE-8815.
-
Fix Version/s: 1.14.0
Resolution: Fixed
> Cache could close with uncaught exception
> -
>
> Key: GEODE-8815
> URL: https://issues.apache.org/jira/browse/GEODE-8815
> Project: Geode
> Issue Type: Bug
>Reporter: Jianxia Chen
>Assignee: Jianxia Chen
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> In GemFireCacheImpl.initialize(), it is possible that an uncaught exception
> is not logged and close the cache.
> {code:java}
> try {
> if (!isClient) {
> applyJarAndXmlFromClusterConfig();
> }
> initializeDeclarativeCache();
> completedCacheXml = true;
> } catch (RuntimeException e) {
> logger.error("Cache initialization for " + this.toString() + " failed
> because:", e);
> throw e;
> } finally {
> if (!completedCacheXml) {
> // so initializeDeclarativeCache threw an exception
> try {
> close();
> } catch (Throwable ignore) {
> // I don't want init to throw an exception that came from the close.
> // I want it to throw the original exception that came from
> initializeDeclarativeCache.
> }
> configurationResponse = null;
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8815) Cache could close with uncaught exception
[
https://issues.apache.org/jira/browse/GEODE-8815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17261725#comment-17261725
]
ASF GitHub Bot commented on GEODE-8815:
---
jchen21 merged pull request #5882:
URL: https://github.com/apache/geode/pull/5882
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
> Cache could close with uncaught exception
> -
>
> Key: GEODE-8815
> URL: https://issues.apache.org/jira/browse/GEODE-8815
> Project: Geode
> Issue Type: Bug
>Reporter: Jianxia Chen
>Assignee: Jianxia Chen
>Priority: Major
> Labels: pull-request-available
>
> In GemFireCacheImpl.initialize(), it is possible that an uncaught exception
> is not logged and close the cache.
> {code:java}
> try {
> if (!isClient) {
> applyJarAndXmlFromClusterConfig();
> }
> initializeDeclarativeCache();
> completedCacheXml = true;
> } catch (RuntimeException e) {
> logger.error("Cache initialization for " + this.toString() + " failed
> because:", e);
> throw e;
> } finally {
> if (!completedCacheXml) {
> // so initializeDeclarativeCache threw an exception
> try {
> close();
> } catch (Throwable ignore) {
> // I don't want init to throw an exception that came from the close.
> // I want it to throw the original exception that came from
> initializeDeclarativeCache.
> }
> configurationResponse = null;
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8626) Omitting field-mapping tag of cache.xml when using Simple JDBC Connector
[
https://issues.apache.org/jira/browse/GEODE-8626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17261720#comment-17261720
]
ASF GitHub Bot commented on GEODE-8626:
---
jchen21 commented on pull request #5637:
URL: https://github.com/apache/geode/pull/5637#issuecomment-757076684
@masaki-yamakawa I have reviewed your code again. Please see the comments in
the code.
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
> Omitting field-mapping tag of cache.xml when using Simple JDBC Connector
>
>
> Key: GEODE-8626
> URL: https://issues.apache.org/jira/browse/GEODE-8626
> Project: Geode
> Issue Type: Improvement
> Components: jdbc
>Reporter: Masaki Yamakawa
>Priority: Minor
> Labels: pull-request-available
>
> When configuring Simple JDBC Connector with gfsh, I don't need to create
> field-mapping, the default field-mapping will be created from pdx and table
> meta data.
> On the other hand, when using cache.xml(cluster.xml), pdx and table meta data
> cannot be used, and field-mapping must be described in cache.xml.
> I would like to create field-mapping defaults based on pdx and table meta
> data when using cache.xml.
> If field-mapping is specified in cache.xml, the xml setting has priority, and
> only if there are no field-mapping tags.
> cache.xml will be as follows:
> {code:java}
>
> data-source="TestDataSource"
> table="employees"
> pdx-name="org.apache.geode.connectors.jdbc.Employee"
> ids="id">
>
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8626) Omitting field-mapping tag of cache.xml when using Simple JDBC Connector
[
https://issues.apache.org/jira/browse/GEODE-8626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17261716#comment-17261716
]
ASF GitHub Bot commented on GEODE-8626:
---
jchen21 commented on a change in pull request #5637:
URL: https://github.com/apache/geode/pull/5637#discussion_r554273414
##
File path:
geode-connectors/src/acceptanceTest/java/org/apache/geode/connectors/jdbc/GfshJdbcMappingIntegrationTest.java
##
@@ -0,0 +1,208 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
contributor license
+ * agreements. See the NOTICE file distributed with this work for additional
information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express
+ * or implied. See the License for the specific language governing permissions
and limitations under
+ * the License.
+ */
+package org.apache.geode.connectors.jdbc;
+
+import java.lang.reflect.Constructor;
+import java.util.ArrayList;
+import java.util.Collections;
+import java.util.List;
+import java.util.Set;
+
+import org.apache.geode.cache.CacheFactory;
+import org.apache.geode.cache.configuration.JndiBindingsType;
+import org.apache.geode.cache.configuration.RegionConfig;
+import org.apache.geode.cache.execute.Function;
+import org.apache.geode.cache.execute.ResultCollector;
+import org.apache.geode.connectors.jdbc.internal.cli.CreateMappingFunction;
+import
org.apache.geode.connectors.jdbc.internal.cli.CreateMappingPreconditionCheckFunction;
+import org.apache.geode.connectors.jdbc.internal.configuration.FieldMapping;
+import org.apache.geode.connectors.jdbc.internal.configuration.RegionMapping;
+import org.apache.geode.distributed.DistributedMember;
+import org.apache.geode.internal.cache.InternalCache;
+import org.apache.geode.management.configuration.RegionType;
+import
org.apache.geode.management.internal.cli.commands.CreateJndiBindingCommand;
+import
org.apache.geode.management.internal.cli.functions.CreateJndiBindingFunction;
+import
org.apache.geode.management.internal.cli.functions.CreateRegionFunctionArgs;
+import org.apache.geode.management.internal.cli.functions.RegionCreateFunction;
+import
org.apache.geode.management.internal.configuration.converters.RegionConverter;
+import org.apache.geode.management.internal.functions.CliFunctionResult;
+import org.apache.geode.management.internal.util.ManagementUtils;
+
+public class GfshJdbcMappingIntegrationTest extends JdbcMappingIntegrationTest
{
+
+ @Override
+ protected InternalCache createCacheAndCreateJdbcMapping(String
cacheXmlTestName)
+ throws Exception {
+InternalCache cache =
+(InternalCache) new CacheFactory().set("locators",
"").set("mcast-port", "0").create();
+Set targetMembers = findMembers(cache, null, null);
+
+CliFunctionResult createRegionFuncResult =
executeCreateRegionFunction(targetMembers);
Review comment:
If you want to use `gfsh` and verify the field mapping,
`CreateMappingCommandDUnitTest` has some good examples which use
`GfshCommandRule` (not `GfshRule` though). You can see if you would like add
some more tests there. Typically, a DUnit is used for testing that involves
`gfsh` commands. In the DUnit, you create a cluster with locator and server(s)
and execute the `gfsh` commands.
Using the functions that implement a specific `gfsh` command in integration
tests is discouraged. That is not what an integration test should do.
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
> Omitting field-mapping tag of cache.xml when using Simple JDBC Connector
>
>
> Key: GEODE-8626
> URL: https://issues.apache.org/jira/browse/GEODE-8626
> Project: Geode
> Issue Type: Improvement
> Components: jdbc
>Reporter: Masaki Yamakawa
>Priority: Minor
> Labels: pull-request-available
>
> When configuring Simple JDBC Connector with gfsh, I don't need to create
> field-mapping, the default field-mapping will be created from pdx and table
> meta data.
> On the other hand, when using cache.xml(cluster.xml), pdx and table meta data
> cannot be used, and
[jira] [Commented] (GEODE-7739) JMX managers may fail to federate mbeans for other members
[ https://issues.apache.org/jira/browse/GEODE-7739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17261710#comment-17261710 ] ASF GitHub Bot commented on GEODE-7739: --- lgtm-com[bot] commented on pull request #5890: URL: https://github.com/apache/geode/pull/5890#issuecomment-757074267 This pull request **introduces 1 alert** when merging 95c54771d1bd9e2692871ac18c216ade35240fab into a52745c98559b0403a20a5bcfdf48202db2326b9 - [view on LGTM.com](https://lgtm.com/projects/g/apache/geode/rev/pr-8dd8fc89bb885a1a23ff9ec4bf3299443a48ea98) **new alerts:** * 1 for Missing space in string literal 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 > JMX managers may fail to federate mbeans for other members > -- > > Key: GEODE-7739 > URL: https://issues.apache.org/jira/browse/GEODE-7739 > Project: Geode > Issue Type: Bug > Components: jmx >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > JMX Manager may fail to federate one or more MXBeans for other members > because of a race condition during startup. When ManagementCacheListener is > first constructed, it is in a state that will ignore all callbacks because > the field readyForEvents is false. > > Debugging with JMXMBeanReconnectDUnitTest revealed this bug. > The test starts two locators with jmx manager configured and started. > Locator1 always has all of locator2's mbeans, but locator2 is intermittently > missing the personal mbeans of locator1. > I think this is caused by some sort of race condition in the code that > creates the monitoring regions for other members in locator2. > It's possible that the jmx manager that hits this bug might fail to have > mbeans for servers as well as other locators but I haven't seen a test case > for this scenario. > The exposure of this bug means that a user running more than one locator > might have a locator that is missing one or more mbeans for the cluster. > > Studying the JMX code also reveals the existence of *GEODE-8012*. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8626) Omitting field-mapping tag of cache.xml when using Simple JDBC Connector
[
https://issues.apache.org/jira/browse/GEODE-8626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17261705#comment-17261705
]
ASF GitHub Bot commented on GEODE-8626:
---
jchen21 commented on a change in pull request #5637:
URL: https://github.com/apache/geode/pull/5637#discussion_r554270893
##
File path:
geode-connectors/src/distributedTest/java/org/apache/geode/connectors/jdbc/internal/cli/CreateMappingCommandDUnitTest.java
##
@@ -1142,7 +1142,7 @@ public void createMappingWithExistingQueueFails() {
+ " must not already exist.");
}
- private static class Employee implements PdxSerializable {
+ public static class Employee implements PdxSerializable {
Review comment:
On the surface, it seems a trivial change from `private` to `public`, in
order to fix the exception. However, under the hood, it is doing unnecessary
serialization and deserialization of the `Employee` class. Because
`getPdxTypeForClass()`, `generatePdxTypeForClass() ` and `createInstance()` are
moved from `CreateMappingPreconditionCheckFunction` to
`JdbcConnectorServiceImpl`, which is probably because you want to use these
methods in `RegionMappingConfiguration`.
I would recommend keeping `getPdxTypeForClass()`, `generatePdxTypeForClass()
` and `createInstance()` in `CreateMappingPreconditionCheckFunction`. And in
`RegionMappingConfiguration`, implement similar methods. Though it looks like
duplicating the code, it does avoid unnecessary serialization and
deserialization of user defined classes like `Employee`, which is more
important.
And I don't think adding more methods to `JdbcConnectorService` is
necessary. e.g. `createDefaultFieldMapping()` is something you want to
automatically achieve for the users, so it is not necessary be exposed as an
API. Just put it as a private method in `RegionMappingConfiguration` should be
good. The same reason applies for `getTableMetaDataView()` and
`getPdxTypeForClass`. Basically, keep `JdbcConnectorService` unchanged.
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
> Omitting field-mapping tag of cache.xml when using Simple JDBC Connector
>
>
> Key: GEODE-8626
> URL: https://issues.apache.org/jira/browse/GEODE-8626
> Project: Geode
> Issue Type: Improvement
> Components: jdbc
>Reporter: Masaki Yamakawa
>Priority: Minor
> Labels: pull-request-available
>
> When configuring Simple JDBC Connector with gfsh, I don't need to create
> field-mapping, the default field-mapping will be created from pdx and table
> meta data.
> On the other hand, when using cache.xml(cluster.xml), pdx and table meta data
> cannot be used, and field-mapping must be described in cache.xml.
> I would like to create field-mapping defaults based on pdx and table meta
> data when using cache.xml.
> If field-mapping is specified in cache.xml, the xml setting has priority, and
> only if there are no field-mapping tags.
> cache.xml will be as follows:
> {code:java}
>
> data-source="TestDataSource"
> table="employees"
> pdx-name="org.apache.geode.connectors.jdbc.Employee"
> ids="id">
>
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7739) JMX managers may fail to federate mbeans for other members
[ https://issues.apache.org/jira/browse/GEODE-7739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17261696#comment-17261696 ] ASF GitHub Bot commented on GEODE-7739: --- kirklund opened a new pull request #5890: URL: https://github.com/apache/geode/pull/5890 Based on #5778. 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 > JMX managers may fail to federate mbeans for other members > -- > > Key: GEODE-7739 > URL: https://issues.apache.org/jira/browse/GEODE-7739 > Project: Geode > Issue Type: Bug > Components: jmx >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > JMX Manager may fail to federate one or more MXBeans for other members > because of a race condition during startup. When ManagementCacheListener is > first constructed, it is in a state that will ignore all callbacks because > the field readyForEvents is false. > > Debugging with JMXMBeanReconnectDUnitTest revealed this bug. > The test starts two locators with jmx manager configured and started. > Locator1 always has all of locator2's mbeans, but locator2 is intermittently > missing the personal mbeans of locator1. > I think this is caused by some sort of race condition in the code that > creates the monitoring regions for other members in locator2. > It's possible that the jmx manager that hits this bug might fail to have > mbeans for servers as well as other locators but I haven't seen a test case > for this scenario. > The exposure of this bug means that a user running more than one locator > might have a locator that is missing one or more mbeans for the cluster. > > Studying the JMX code also reveals the existence of *GEODE-8012*. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8719) CI Failure: org.apache.geode.redis.internal.executor.CrashAndNoRepeatDUnitTest > givenServerCrashesDuringAPPEND_thenDataIsNotLost
[
https://issues.apache.org/jira/browse/GEODE-8719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17261685#comment-17261685
]
Geode Integration commented on GEODE-8719:
--
Seen in [DistributedTestOpenJDK11
#698|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/698]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0596/test-results/distributedTest/1610149379/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0596/test-artifacts/1610149379/distributedtestfiles-OpenJDK11-1.14.0-build.0596.tgz].
> CI Failure:
> org.apache.geode.redis.internal.executor.CrashAndNoRepeatDUnitTest >
> givenServerCrashesDuringAPPEND_thenDataIsNotLost
> -
>
> Key: GEODE-8719
> URL: https://issues.apache.org/jira/browse/GEODE-8719
> Project: Geode
> Issue Type: Bug
> Components: redis
>Reporter: Sarah Abbey
>Assignee: John Hutchison
>Priority: Minor
>
> CI failure: https://concourse.apachegeode-ci.info/builds/207449
> {code:java}
> org.apache.geode.redis.internal.executor.CrashAndNoRepeatDUnitTest >
> givenServerCrashesDuringAPPEND_thenDataIsNotLost FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.internal.IdentifiableCallable.call in VM 2
> running on Host e0e2f6af9445 with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:623)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:460)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.startServerVM(ClusterStartupRule.java:268)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.startServerVM(ClusterStartupRule.java:261)
> at
> org.apache.geode.redis.internal.executor.CrashAndNoRepeatDUnitTest.startRedisVM(CrashAndNoRepeatDUnitTest.java:131)
> at
> org.apache.geode.redis.internal.executor.CrashAndNoRepeatDUnitTest.givenServerCrashesDuringAPPEND_thenDataIsNotLost(CrashAndNoRepeatDUnitTest.java:164)
> Caused by:
> org.apache.geode.management.ManagementException: Could not start
> Redis Server using bind address: localhost/127.0.0.1 and port: 44579. Please
> make sure nothing else is running on this address/port combination.
> Caused by:
> java.net.BindException: Address already in use
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Reopened] (GEODE-8719) CI Failure: org.apache.geode.redis.internal.executor.CrashAndNoRepeatDUnitTest > givenServerCrashesDuringAPPEND_thenDataIsNotLost
[
https://issues.apache.org/jira/browse/GEODE-8719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider reopened GEODE-8719:
-
This reproduced here:
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/698
{noformat}
org.apache.geode.redis.internal.executor.CrashAndNoRepeatDUnitTest >
givenServerCrashesDuringAPPEND_thenDataIsNotLost FAILED
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.test.dunit.internal.IdentifiableCallable.call in VM 3 running
on Host 56886cab3c85 with 4 VMs
at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:623)
at org.apache.geode.test.dunit.VM.invoke(VM.java:460)
at
org.apache.geode.test.dunit.rules.ClusterStartupRule.startServerVM(ClusterStartupRule.java:268)
at
org.apache.geode.test.dunit.rules.ClusterStartupRule.startServerVM(ClusterStartupRule.java:261)
at
org.apache.geode.redis.internal.executor.CrashAndNoRepeatDUnitTest.startRedisVM(CrashAndNoRepeatDUnitTest.java:131)
at
org.apache.geode.redis.internal.executor.CrashAndNoRepeatDUnitTest.givenServerCrashesDuringAPPEND_thenDataIsNotLost(CrashAndNoRepeatDUnitTest.java:160)
Caused by:
org.apache.geode.management.ManagementException: Could not start Redis
Server using bind address: localhost/127.0.0.1 and port: 42809. Please make
sure nothing else is running on this address/port combination.
Caused by:
java.net.BindException: Address already in use
org.apache.geode.redis.internal.executor.CrashAndNoRepeatDUnitTest >
classMethod FAILED
java.lang.AssertionError: Suspicious strings were written to the log during
this run.
Fix the strings or use IgnoredException.addIgnoredException to ignore.
---
Found suspect string in 'dunit_suspect-vm3.log' at line 6657
[error 2021/01/08 21:34:13.724 GMT
tid=35] org.apache.geode.management.ManagementException: Could not start Redis
Server using bind address: localhost/127.0.0.1 and port: 42809. Please make
sure nothing else is running on this address/port combination.
{noformat}
> CI Failure:
> org.apache.geode.redis.internal.executor.CrashAndNoRepeatDUnitTest >
> givenServerCrashesDuringAPPEND_thenDataIsNotLost
> -
>
> Key: GEODE-8719
> URL: https://issues.apache.org/jira/browse/GEODE-8719
> Project: Geode
> Issue Type: Bug
> Components: redis
>Reporter: Sarah Abbey
>Assignee: John Hutchison
>Priority: Minor
>
> CI failure: https://concourse.apachegeode-ci.info/builds/207449
> {code:java}
> org.apache.geode.redis.internal.executor.CrashAndNoRepeatDUnitTest >
> givenServerCrashesDuringAPPEND_thenDataIsNotLost FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.internal.IdentifiableCallable.call in VM 2
> running on Host e0e2f6af9445 with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:623)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:460)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.startServerVM(ClusterStartupRule.java:268)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.startServerVM(ClusterStartupRule.java:261)
> at
> org.apache.geode.redis.internal.executor.CrashAndNoRepeatDUnitTest.startRedisVM(CrashAndNoRepeatDUnitTest.java:131)
> at
> org.apache.geode.redis.internal.executor.CrashAndNoRepeatDUnitTest.givenServerCrashesDuringAPPEND_thenDataIsNotLost(CrashAndNoRepeatDUnitTest.java:164)
> Caused by:
> org.apache.geode.management.ManagementException: Could not start
> Redis Server using bind address: localhost/127.0.0.1 and port: 44579. Please
> make sure nothing else is running on this address/port combination.
> Caused by:
> java.net.BindException: Address already in use
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-8696) Startup of JMX Manager may hang during crash of other members
[
https://issues.apache.org/jira/browse/GEODE-8696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund resolved GEODE-8696.
--
Fix Version/s: 1.14.0
Resolution: Fixed
Fix was merged to develop in PR #5728.
> Startup of JMX Manager may hang during crash of other members
> -
>
> Key: GEODE-8696
> URL: https://issues.apache.org/jira/browse/GEODE-8696
> Project: Geode
> Issue Type: Bug
> Components: jmx, management
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
> Fix For: 1.14.0
>
>
> The fix for GEODE-7400 removed final from the executorService field to
> introduce a Supplier. I think this hang was caused by adding
> synchronized to FederatingManager.executeTask instead of making
> executorService a volatile field.
> _vm_3_thr_3_client2_host2_21145_ hung while synchronized on
> *0xf6316520*:
> {noformat}
> "vm_3_thr_3_client2_host2_21145" #56 daemon prio=5 os_prio=0
> tid=0x7f1854002000 nid=0x5326 waiting on condition [0x7f18520e2000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xf6364030> (a
> java.util.concurrent.FutureTask)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:429)
> at java.util.concurrent.FutureTask.get(FutureTask.java:191)
> at
> java.util.concurrent.AbstractExecutorService.invokeAll(AbstractExecutorService.java:244)
> at
> org.apache.geode.management.internal.FederatingManager.startManagingActivity(FederatingManager.java:256)
> at
> org.apache.geode.management.internal.FederatingManager.startManager(FederatingManager.java:121)
> - locked <0xf6316520> (a
> org.apache.geode.management.internal.FederatingManager)
> at
> org.apache.geode.management.internal.SystemManagementService.startManager(SystemManagementService.java:373)
> - locked <0xfed91a70> (a java.util.HashMap)
> at
> org.apache.geode.management.internal.beans.ManagementAdapter.handleCacheCreation(ManagementAdapter.java:197)
> at
> org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:127)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2089)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:643)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1363)
> at
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:191)
> - locked <0xe11065f0> (a java.lang.Class for
> org.apache.geode.internal.cache.GemFireCacheImpl)
> - locked <0xe1101220> (a java.lang.Class for
> org.apache.geode.internal.cache.InternalCacheBuilder)
> at
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:158)
> - locked <0xe1101220> (a java.lang.Class for
> org.apache.geode.internal.cache.InternalCacheBuilder)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:142)
> at
> hydra.CacheVersionHelper.configureAndCreateCache(CacheVersionHelper.java:51)
> at hydra.CacheHelper.createCacheWithHttpService(CacheHelper.java:127)
> - locked <0xfecab060> (a java.lang.Class for
> hydra.CacheHelper)
> at hydra.CacheHelper.createCache(CacheHelper.java:87)
> at
> splitBrain.NetworkPartitionTest.initialize(NetworkPartitionTest.java:293)
> at
> splitBrain.NetworkPartitionTest.initializeInstance(NetworkPartitionTest.java:228)
> - locked <0xe14a2db0> (a java.lang.Class for
> splitBrain.NetworkPartitionTest)
> at
> splitBrain.NetworkPartitionTest.HydraTask_initialize(NetworkPartitionTest.java:203)
> - locked <0xe14a2db0> (a java.lang.Class for
> splitBrain.NetworkPartitionTest)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at hydra.MethExecutor.execute(MethExecutor.java:173)
> at hydra.MethExecutor.execute(MethExecutor.java:141)
> at hydra.TestTask.execute(TestTask.java:197)
> at hydra.RemoteTestModule$1.run(RemoteTestModule.java:213)
[jira] [Resolved] (GEODE-8798) export logs command with --start-time or --end-time arguments needs improvement
[ https://issues.apache.org/jira/browse/GEODE-8798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans resolved GEODE-8798. Fix Version/s: 1.14.0 Resolution: Fixed > export logs command with --start-time or --end-time arguments needs > improvement > --- > > Key: GEODE-8798 > URL: https://issues.apache.org/jira/browse/GEODE-8798 > Project: Geode > Issue Type: Improvement > Components: docs, gfsh >Affects Versions: 1.12.0, 1.14.0, 1.13.1 >Reporter: Donal Evans >Assignee: Donal Evans >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > If an invalid or improperly formatted argument for --start-time or --end-time > is provided to the export logs gfsh command, the actual time cutoffs used to > determine which logs to export may be inconsistent or unexpected, but no > indication is given to the user that anything is wrong. > In addition to this, the documentation for the command could be made clearer > to better allow users to understand the correct use of the arguments. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8808) CQListener onEvent() not invoked when conserve-sockets = false
[
https://issues.apache.org/jira/browse/GEODE-8808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans updated GEODE-8808:
---
Summary: CQListener onEvent() not invoked when conserve-sockets = false
(was: Missing CQ events for puts)
> CQListener onEvent() not invoked when conserve-sockets = false
> --
>
> Key: GEODE-8808
> URL: https://issues.apache.org/jira/browse/GEODE-8808
> Project: Geode
> Issue Type: Bug
> Components: cq
>Reporter: Nabarun Nag
>Assignee: Donal Evans
>Priority: Major
> Labels: blocks-1.14.0
>
> When {{conserve-sockets}} is false, the CQListener {{onEvent()}} is not
> invoked for some reason.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8278) Gateway sender queues using heap memory way above configured value after server restart
[ https://issues.apache.org/jira/browse/GEODE-8278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17261676#comment-17261676 ] ASF subversion and git services commented on GEODE-8278: Commit 2d4b1653e70f7edcb1ed1b1125cd52c63d698f1a in geode's branch refs/heads/feature/GEODE-8278 from Barry Oglesby [ https://gitbox.apache.org/repos/asf?p=geode.git;h=2d4b165 ] GEODE-8278: Modified initialImagePut to invoke callback methods > Gateway sender queues using heap memory way above configured value after > server restart > --- > > Key: GEODE-8278 > URL: https://issues.apache.org/jira/browse/GEODE-8278 > Project: Geode > Issue Type: Bug > Components: eviction >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > > In a Geode system with the following characteristics: > * WAN replication > * partition redundant regions > * overflow configured for the gateway senders queues by means of persistence > and maximum queue memory set. > * gateway receivers stopped in one site (B) > * Operations sent to the site that does not have the gateway receivers > stopped (A) > When operations are sent to site A, the gateway sender queues start to grow > as expected and the heap memory consumed by the queues does not grow > indefinitely given that there is overflow to disk when the limit is reached. > But, if a server is restarted, the restarted server will show a much higher > heap memory used than the memory used by this server before it was restarted > or by the other servers. > This can even provoke that the server cannot be restarted if the heap memory > it requires is above the limit configured. > According to the memory analyzer the entries taking up the memory are > subclasses of ```VMThinDiskLRURegionEntryHeap```. > The number of instances of this type are the same in the restarted server > than in the not restarted servers but on the restarted server they take much > more memory. The reason seems to be that the ```value``` member attribute of > the instances, in the case of the restarted server contains > ```VMCachedDeserializable``` objects while in the case of the not restarted > server the attribute contains either ```null``` or > ```GatewaySenderEventImpl``` objects that use much less memory than the > ```VMCachedDeserializable``` ones. > If redundancy is not configured for the region then the problem is not > manifested, i.e. the heap memory used by the restarted server is similar to > the one prior to the restart. > If the node not restarted is restarted then the previously restarted node > seems to release the extra memory (my guess is that it is processing the > other process queue). > Also, if traffic is sent again to the Geode cluster, then it seems eviction > kicks in and after some short time, the memory of the restarted server goes > down to the level it had before it had been restarted. > As a summary, the problem seems to be that if a server does GII > (getInitialImage) from another server, eviction does not occur for gateway > sender queue entries. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8728) Configure Gradle to run parallel tests in isolation without Docker [PERMANENT]
[ https://issues.apache.org/jira/browse/GEODE-8728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17261674#comment-17261674 ] ASF GitHub Bot commented on GEODE-8728: --- lgtm-com[bot] commented on pull request #5848: URL: https://github.com/apache/geode/pull/5848#issuecomment-757048986 This pull request **fixes 1 alert** when merging 4f6108e7e252ead1c2653c1b7691502706092441 into 86693d5170bb7ea85dabe15bf67c32ba875abef9 - [view on LGTM.com](https://lgtm.com/projects/g/apache/geode/rev/pr-ac1a83f1357d5476239aa6bcb9ffa6267fbc2e2f) **fixed alerts:** * 1 for Dereferenced variable may be null 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 > Configure Gradle to run parallel tests in isolation without Docker [PERMANENT] > -- > > Key: GEODE-8728 > URL: https://issues.apache.org/jira/browse/GEODE-8728 > Project: Geode > Issue Type: Test > Components: tests >Affects Versions: 1.14.0 >Reporter: Dale Emery >Assignee: Dale Emery >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > For tests to behave well when run in parallel, each must refrain from using > ports and test files that are in use by other tests. > Geode's Gradle build isolates concurrently executing tests by running each > test class in a Docker container. To do this, the build applies an open > source "Gradle Dockerized Test" plugin that is obsolete and appears to be > unmaintained. > This ticket removes the obsolete plugin and replaces it with a small amount > of custom Gradle code and a few minor changes to Geode: > - Configure Gradle to assign each concurrently executing test JVM a unique > working directory and a distinct range of ports. > - Change Geode's "available port" feature to allocate ports only from the > ranges assigned by Gradle. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8808) Missing CQ events for puts
[
https://issues.apache.org/jira/browse/GEODE-8808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans updated GEODE-8808:
---
Description: When {{conserve-sockets}} is false, the CQListener
{{onEvent()}} is not invoked for some reason. (was: After a certain number of
puts, CQ are missing afterCreate. There is a mismatch between number of CQ
events and puts)
> Missing CQ events for puts
> --
>
> Key: GEODE-8808
> URL: https://issues.apache.org/jira/browse/GEODE-8808
> Project: Geode
> Issue Type: Bug
> Components: cq
>Reporter: Nabarun Nag
>Assignee: Donal Evans
>Priority: Major
> Labels: blocks-1.14.0
>
> When {{conserve-sockets}} is false, the CQListener {{onEvent()}} is not
> invoked for some reason.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-8799) Increase default OperationExecutors#MAX_THREADS and MAX_PR_THREADS
[
https://issues.apache.org/jira/browse/GEODE-8799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans resolved GEODE-8799.
Fix Version/s: 1.14.0
Resolution: Fixed
> Increase default OperationExecutors#MAX_THREADS and MAX_PR_THREADS
> --
>
> Key: GEODE-8799
> URL: https://issues.apache.org/jira/browse/GEODE-8799
> Project: Geode
> Issue Type: Improvement
>Affects Versions: 1.14.0
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> Similar to GEODE-8780, the default maximum number of pooled message processor
> and partitioned region message processor threads are low enough that they can
> cause performance degradation and should be increased.
> The current default value for {{MAX_THREADS}} is 100, and the current default
> value for {{MAX_PR_THREADS}} is
> {{Math.max(Runtime.getRuntime().availableProcessors() * 4, 16)}}
> The proposed new values are 1000 and
> {{Math.max(Runtime.getRuntime().availableProcessors() * 32, 200)}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8798) export logs command with --start-time or --end-time arguments needs improvement
[ https://issues.apache.org/jira/browse/GEODE-8798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17261661#comment-17261661 ] ASF subversion and git services commented on GEODE-8798: Commit 94c3aea4821eed49ab2420333cd2544d81b0094f in geode's branch refs/heads/develop from Donal Evans [ https://gitbox.apache.org/repos/asf?p=geode.git;h=94c3aea ] GEODE-8798: Improve output from export logs command (#5863) - Validate the format of the --start-time and --end-time arguments - Validate that the --start-time and --end-time arguments can be correctly parsed - Output the values for --start-time and --end-time as used by the function to allow users to check that they're as expected when specified - Update documentation to reflect the new output and better explain the behaviour when the arguments are provided Authored-by: Donal Evans > export logs command with --start-time or --end-time arguments needs > improvement > --- > > Key: GEODE-8798 > URL: https://issues.apache.org/jira/browse/GEODE-8798 > Project: Geode > Issue Type: Improvement > Components: docs, gfsh >Affects Versions: 1.12.0, 1.14.0, 1.13.1 >Reporter: Donal Evans >Assignee: Donal Evans >Priority: Major > Labels: pull-request-available > > If an invalid or improperly formatted argument for --start-time or --end-time > is provided to the export logs gfsh command, the actual time cutoffs used to > determine which logs to export may be inconsistent or unexpected, but no > indication is given to the user that anything is wrong. > In addition to this, the documentation for the command could be made clearer > to better allow users to understand the correct use of the arguments. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8798) export logs command with --start-time or --end-time arguments needs improvement
[ https://issues.apache.org/jira/browse/GEODE-8798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17261659#comment-17261659 ] ASF GitHub Bot commented on GEODE-8798: --- DonalEvans merged pull request #5863: URL: https://github.com/apache/geode/pull/5863 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 > export logs command with --start-time or --end-time arguments needs > improvement > --- > > Key: GEODE-8798 > URL: https://issues.apache.org/jira/browse/GEODE-8798 > Project: Geode > Issue Type: Improvement > Components: docs, gfsh >Affects Versions: 1.12.0, 1.14.0, 1.13.1 >Reporter: Donal Evans >Assignee: Donal Evans >Priority: Major > Labels: pull-request-available > > If an invalid or improperly formatted argument for --start-time or --end-time > is provided to the export logs gfsh command, the actual time cutoffs used to > determine which logs to export may be inconsistent or unexpected, but no > indication is given to the user that anything is wrong. > In addition to this, the documentation for the command could be made clearer > to better allow users to understand the correct use of the arguments. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8798) export logs command with --start-time or --end-time arguments needs improvement
[
https://issues.apache.org/jira/browse/GEODE-8798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17261658#comment-17261658
]
ASF GitHub Bot commented on GEODE-8798:
---
DonalEvans commented on a change in pull request #5863:
URL: https://github.com/apache/geode/pull/5863#discussion_r554241132
##
File path:
geode-gfsh/src/main/java/org/apache/geode/management/internal/cli/commands/ExportLogsInterceptor.java
##
@@ -106,8 +159,78 @@ public ResultModel postExecution(GfshParseResult
parseResult, ResultModel comman
}
// if there is no downloaded file. File is saved on the locator/manager.
-return ResultModel.createInfo(
-"Logs exported to the connected member's file system: "
-+ commandResult.getFileToDownload().toString());
+output.append("Logs exported to the connected member's file system: ")
+.append(commandResult.getFileToDownload().toString());
+return ResultModel.createInfo(output.toString());
+ }
+
+ private ResultModel checkStartAndEndFormat(String start, String end) {
+StringBuilder formatErrorMessage = new StringBuilder();
+boolean formatError = false;
+if (start != null && !DATE_AND_TIME_PATTERN.matcher(start).matches()
+&& !DATE_ONLY_PATTERN.matcher(start).matches()) {
+ formatErrorMessage.append(EXPORT_LOGS__STARTTIME);
+ formatError = true;
+}
+
+if (end != null && !DATE_AND_TIME_PATTERN.matcher(end).matches()
+&& !DATE_ONLY_PATTERN.matcher(end).matches()) {
+ if (formatError) {
+formatErrorMessage.append(" and ");
+ }
+ formatErrorMessage.append(EXPORT_LOGS__ENDTIME);
+ formatError = true;
+}
+
+if (formatError) {
+ formatErrorMessage.append(" had incorrect format. Valid formats are ")
+ .append(ONLY_DATE_FORMAT).append(" and ").append(FORMAT);
+ return ResultModel.createError(formatErrorMessage.toString());
+}
+return null;
+ }
+
+ private ResultModel checkStartAndEndParsing(String start, String end) {
+StringBuilder parseErrorMessage = new StringBuilder();
+boolean parseError = false;
+
+SimpleDateFormat dateAndTimeFormat = new SimpleDateFormat(FORMAT);
+SimpleDateFormat dateOnlyFormat = new SimpleDateFormat(ONLY_DATE_FORMAT);
+if (start != null) {
+ try {
+// If the input is intended to be parsed as date and time, use the
date and time format
+if (start.length() > 10) {
+ dateAndTimeFormat.parse(start);
+} else {
+ dateOnlyFormat.parse(start);
+}
+ } catch (ParseException e) {
Review comment:
The error message from the ParseException is simply "Unparseable date: "
followed by the user input, so it doesn't add any useful information here.
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
> export logs command with --start-time or --end-time arguments needs
> improvement
> ---
>
> Key: GEODE-8798
> URL: https://issues.apache.org/jira/browse/GEODE-8798
> Project: Geode
> Issue Type: Improvement
> Components: docs, gfsh
>Affects Versions: 1.12.0, 1.14.0, 1.13.1
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
> Labels: pull-request-available
>
> If an invalid or improperly formatted argument for --start-time or --end-time
> is provided to the export logs gfsh command, the actual time cutoffs used to
> determine which logs to export may be inconsistent or unexpected, but no
> indication is given to the user that anything is wrong.
> In addition to this, the documentation for the command could be made clearer
> to better allow users to understand the correct use of the arguments.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8795) Lucene queries should utilize post-processing if enabled
[ https://issues.apache.org/jira/browse/GEODE-8795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17261649#comment-17261649 ] ASF GitHub Bot commented on GEODE-8795: --- lgtm-com[bot] commented on pull request #5887: URL: https://github.com/apache/geode/pull/5887#issuecomment-757039495 This pull request **introduces 1 alert** when merging 732f37900cfee8b02f1073b2d2ecf90f88a10de6 into 0ab677199d189527be354fd1427ce29b91ed6b31 - [view on LGTM.com](https://lgtm.com/projects/g/apache/geode/rev/pr-9bb0a53016934eed6c5fd31e5f95d598cb8226f2) **new alerts:** * 1 for Uncontrolled data used in path expression 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 > Lucene queries should utilize post-processing if enabled > > > Key: GEODE-8795 > URL: https://issues.apache.org/jira/browse/GEODE-8795 > Project: Geode > Issue Type: Bug > Components: lucene >Reporter: Jens Deppe >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > Currently the entries returned by lucene queries are not able to be > post-processed as other retrieval mechanisms can (gets, regular OQL queries, > CQs). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7861) Improve error reporting when a member is unable to contact a locator
[
https://issues.apache.org/jira/browse/GEODE-7861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kamilla Aslami resolved GEODE-7861.
---
Fix Version/s: 1.14.0
Resolution: Fixed
> Improve error reporting when a member is unable to contact a locator
>
>
> Key: GEODE-7861
> URL: https://issues.apache.org/jira/browse/GEODE-7861
> Project: Geode
> Issue Type: Improvement
> Components: membership
>Reporter: Dan Smith
>Assignee: Kamilla Aslami
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> When a member is unable to contact a join the system due to a failure to
> contact a locator, we could be a lot more specific, which would help users
> debug issues in their environment. We currently print out
> {noformat}
> Unable to join the distributed system. Operation either timed out, was
> stopped or Locator does not exist.
> {noformat}
> We should include the underlying exception from the last locator we tried to
> contact as a cause, so that users can see why it failed (DNS error, ???).
> Perhaps also the list of locators we tried to contact.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8798) export logs command with --start-time or --end-time arguments needs improvement
[
https://issues.apache.org/jira/browse/GEODE-8798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17261648#comment-17261648
]
ASF GitHub Bot commented on GEODE-8798:
---
pivotal-eshu commented on a change in pull request #5863:
URL: https://github.com/apache/geode/pull/5863#discussion_r554237191
##
File path:
geode-gfsh/src/main/java/org/apache/geode/management/internal/cli/commands/ExportLogsInterceptor.java
##
@@ -106,8 +159,78 @@ public ResultModel postExecution(GfshParseResult
parseResult, ResultModel comman
}
// if there is no downloaded file. File is saved on the locator/manager.
-return ResultModel.createInfo(
-"Logs exported to the connected member's file system: "
-+ commandResult.getFileToDownload().toString());
+output.append("Logs exported to the connected member's file system: ")
+.append(commandResult.getFileToDownload().toString());
+return ResultModel.createInfo(output.toString());
+ }
+
+ private ResultModel checkStartAndEndFormat(String start, String end) {
+StringBuilder formatErrorMessage = new StringBuilder();
+boolean formatError = false;
+if (start != null && !DATE_AND_TIME_PATTERN.matcher(start).matches()
+&& !DATE_ONLY_PATTERN.matcher(start).matches()) {
+ formatErrorMessage.append(EXPORT_LOGS__STARTTIME);
+ formatError = true;
+}
+
+if (end != null && !DATE_AND_TIME_PATTERN.matcher(end).matches()
+&& !DATE_ONLY_PATTERN.matcher(end).matches()) {
+ if (formatError) {
+formatErrorMessage.append(" and ");
+ }
+ formatErrorMessage.append(EXPORT_LOGS__ENDTIME);
+ formatError = true;
+}
+
+if (formatError) {
+ formatErrorMessage.append(" had incorrect format. Valid formats are ")
+ .append(ONLY_DATE_FORMAT).append(" and ").append(FORMAT);
+ return ResultModel.createError(formatErrorMessage.toString());
+}
+return null;
+ }
+
+ private ResultModel checkStartAndEndParsing(String start, String end) {
+StringBuilder parseErrorMessage = new StringBuilder();
+boolean parseError = false;
+
+SimpleDateFormat dateAndTimeFormat = new SimpleDateFormat(FORMAT);
+SimpleDateFormat dateOnlyFormat = new SimpleDateFormat(ONLY_DATE_FORMAT);
+if (start != null) {
+ try {
+// If the input is intended to be parsed as date and time, use the
date and time format
+if (start.length() > 10) {
+ dateAndTimeFormat.parse(start);
+} else {
+ dateOnlyFormat.parse(start);
+}
+ } catch (ParseException e) {
Review comment:
Might be a nitpick. Is it possible to append the ParseException error
message as well?
##
File path:
geode-gfsh/src/main/java/org/apache/geode/management/internal/cli/commands/ExportLogsInterceptor.java
##
@@ -106,8 +159,78 @@ public ResultModel postExecution(GfshParseResult
parseResult, ResultModel comman
}
// if there is no downloaded file. File is saved on the locator/manager.
-return ResultModel.createInfo(
-"Logs exported to the connected member's file system: "
-+ commandResult.getFileToDownload().toString());
+output.append("Logs exported to the connected member's file system: ")
+.append(commandResult.getFileToDownload().toString());
+return ResultModel.createInfo(output.toString());
+ }
+
+ private ResultModel checkStartAndEndFormat(String start, String end) {
+StringBuilder formatErrorMessage = new StringBuilder();
+boolean formatError = false;
+if (start != null && !DATE_AND_TIME_PATTERN.matcher(start).matches()
+&& !DATE_ONLY_PATTERN.matcher(start).matches()) {
+ formatErrorMessage.append(EXPORT_LOGS__STARTTIME);
+ formatError = true;
+}
+
+if (end != null && !DATE_AND_TIME_PATTERN.matcher(end).matches()
+&& !DATE_ONLY_PATTERN.matcher(end).matches()) {
+ if (formatError) {
+formatErrorMessage.append(" and ");
+ }
+ formatErrorMessage.append(EXPORT_LOGS__ENDTIME);
+ formatError = true;
+}
+
+if (formatError) {
+ formatErrorMessage.append(" had incorrect format. Valid formats are ")
+ .append(ONLY_DATE_FORMAT).append(" and ").append(FORMAT);
+ return ResultModel.createError(formatErrorMessage.toString());
+}
+return null;
+ }
+
+ private ResultModel checkStartAndEndParsing(String start, String end) {
+StringBuilder parseErrorMessage = new StringBuilder();
+boolean parseError = false;
+
+SimpleDateFormat dateAndTimeFormat = new SimpleDateFormat(FORMAT);
+SimpleDateFormat dateOnlyFormat = new SimpleDateFormat(ONLY_DATE_FORMAT);
+if (start != null) {
+ try {
+// If the input is intended to be parsed as date and time, use the
date and time format
+if (start.length() > 10) {
+ dateAndTimeFormat.parse(start);
+} else {
[jira] [Commented] (GEODE-7861) Improve error reporting when a member is unable to contact a locator
[
https://issues.apache.org/jira/browse/GEODE-7861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17261645#comment-17261645
]
ASF subversion and git services commented on GEODE-7861:
Commit 089c1ba7e20606f8201a4cd8f7221f6adc60ba5c in geode's branch
refs/heads/develop from Kamilla Aslami
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=089c1ba ]
GEODE-7861: Improve error reporting in GMSJoinLeave.join() (#5839)
* GEODE-7861: Improve error reporting in GMSJoinLeave.join()
* Fix LocatorDUnitTest.testNoLocator
* Changes after the code review
* Fix typo
> Improve error reporting when a member is unable to contact a locator
>
>
> Key: GEODE-7861
> URL: https://issues.apache.org/jira/browse/GEODE-7861
> Project: Geode
> Issue Type: Improvement
> Components: membership
>Reporter: Dan Smith
>Assignee: Kamilla Aslami
>Priority: Major
> Labels: pull-request-available
>
> When a member is unable to contact a join the system due to a failure to
> contact a locator, we could be a lot more specific, which would help users
> debug issues in their environment. We currently print out
> {noformat}
> Unable to join the distributed system. Operation either timed out, was
> stopped or Locator does not exist.
> {noformat}
> We should include the underlying exception from the last locator we tried to
> contact as a cause, so that users can see why it failed (DNS error, ???).
> Perhaps also the list of locators we tried to contact.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7861) Improve error reporting when a member is unable to contact a locator
[
https://issues.apache.org/jira/browse/GEODE-7861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17261646#comment-17261646
]
ASF subversion and git services commented on GEODE-7861:
Commit 089c1ba7e20606f8201a4cd8f7221f6adc60ba5c in geode's branch
refs/heads/develop from Kamilla Aslami
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=089c1ba ]
GEODE-7861: Improve error reporting in GMSJoinLeave.join() (#5839)
* GEODE-7861: Improve error reporting in GMSJoinLeave.join()
* Fix LocatorDUnitTest.testNoLocator
* Changes after the code review
* Fix typo
> Improve error reporting when a member is unable to contact a locator
>
>
> Key: GEODE-7861
> URL: https://issues.apache.org/jira/browse/GEODE-7861
> Project: Geode
> Issue Type: Improvement
> Components: membership
>Reporter: Dan Smith
>Assignee: Kamilla Aslami
>Priority: Major
> Labels: pull-request-available
>
> When a member is unable to contact a join the system due to a failure to
> contact a locator, we could be a lot more specific, which would help users
> debug issues in their environment. We currently print out
> {noformat}
> Unable to join the distributed system. Operation either timed out, was
> stopped or Locator does not exist.
> {noformat}
> We should include the underlying exception from the last locator we tried to
> contact as a cause, so that users can see why it failed (DNS error, ???).
> Perhaps also the list of locators we tried to contact.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7861) Improve error reporting when a member is unable to contact a locator
[
https://issues.apache.org/jira/browse/GEODE-7861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17261643#comment-17261643
]
ASF GitHub Bot commented on GEODE-7861:
---
bschuchardt merged pull request #5839:
URL: https://github.com/apache/geode/pull/5839
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
> Improve error reporting when a member is unable to contact a locator
>
>
> Key: GEODE-7861
> URL: https://issues.apache.org/jira/browse/GEODE-7861
> Project: Geode
> Issue Type: Improvement
> Components: membership
>Reporter: Dan Smith
>Assignee: Kamilla Aslami
>Priority: Major
> Labels: pull-request-available
>
> When a member is unable to contact a join the system due to a failure to
> contact a locator, we could be a lot more specific, which would help users
> debug issues in their environment. We currently print out
> {noformat}
> Unable to join the distributed system. Operation either timed out, was
> stopped or Locator does not exist.
> {noformat}
> We should include the underlying exception from the last locator we tried to
> contact as a cause, so that users can see why it failed (DNS error, ???).
> Perhaps also the list of locators we tried to contact.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8822) Faulty statistics for parallel GW senders when using cleanQueues
[ https://issues.apache.org/jira/browse/GEODE-8822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17261615#comment-17261615 ] ASF GitHub Bot commented on GEODE-8822: --- mivanac opened a new pull request #5889: URL: https://github.com/apache/geode/pull/5889 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 > Faulty statistics for parallel GW senders when using cleanQueues > > > Key: GEODE-8822 > URL: https://issues.apache.org/jira/browse/GEODE-8822 > Project: Geode > Issue Type: Bug > Components: statistics, wan >Reporter: Mario Ivanac >Assignee: Mario Ivanac >Priority: Major > > After parallel GW sender with events in queue is restarted with option > --clean-queues, statistics is not cleared. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8822) Faulty statistics for parallel GW senders when using cleanQueues
[ https://issues.apache.org/jira/browse/GEODE-8822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-8822: -- Labels: pull-request-available (was: ) > Faulty statistics for parallel GW senders when using cleanQueues > > > Key: GEODE-8822 > URL: https://issues.apache.org/jira/browse/GEODE-8822 > Project: Geode > Issue Type: Bug > Components: statistics, wan >Reporter: Mario Ivanac >Assignee: Mario Ivanac >Priority: Major > Labels: pull-request-available > > After parallel GW sender with events in queue is restarted with option > --clean-queues, statistics is not cleared. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8818) Make docs of copy-on-read more visible to readers
[ https://issues.apache.org/jira/browse/GEODE-8818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17261611#comment-17261611 ] ASF GitHub Bot commented on GEODE-8818: --- karensmolermiller opened a new pull request #5888: URL: https://github.com/apache/geode/pull/5888 This PR includes updating all links to this subsection. And, I changed the title of the section. 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 docs of copy-on-read more visible to readers > - > > Key: GEODE-8818 > URL: https://issues.apache.org/jira/browse/GEODE-8818 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Karen Smoler Miller >Assignee: Karen Smoler Miller >Priority: Major > > Our users need more visibility of the copy-on-read region attribute. Promote > the subsection from within Basic Configuration and Programming, Data Entries, > Managing Data Entries to its own section within Data Entries. Update all > links within the manual to point to the new section. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8818) Make docs of copy-on-read more visible to readers
[ https://issues.apache.org/jira/browse/GEODE-8818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-8818: -- Labels: pull-request-available (was: ) > Make docs of copy-on-read more visible to readers > - > > Key: GEODE-8818 > URL: https://issues.apache.org/jira/browse/GEODE-8818 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Karen Smoler Miller >Assignee: Karen Smoler Miller >Priority: Major > Labels: pull-request-available > > Our users need more visibility of the copy-on-read region attribute. Promote > the subsection from within Basic Configuration and Programming, Data Entries, > Managing Data Entries to its own section within Data Entries. Update all > links within the manual to point to the new section. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8795) Lucene queries should utilize post-processing if enabled
[ https://issues.apache.org/jira/browse/GEODE-8795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17261608#comment-17261608 ] ASF GitHub Bot commented on GEODE-8795: --- jdeppe-pivotal opened a new pull request #5887: URL: https://github.com/apache/geode/pull/5887 - Some adjustments to the initial implementation - This now relies on the principal being available in the FunctionContext. - PDX objects are passed directly to the post-processor thus avoiding any possible serialization issues. Co-authored-by: Nabarun Nag (cherry picked from commit 8785b84efcabf9a74691ae65d7c1015a9c698893) 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 > Lucene queries should utilize post-processing if enabled > > > Key: GEODE-8795 > URL: https://issues.apache.org/jira/browse/GEODE-8795 > Project: Geode > Issue Type: Bug > Components: lucene >Reporter: Jens Deppe >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > Currently the entries returned by lucene queries are not able to be > post-processed as other retrieval mechanisms can (gets, regular OQL queries, > CQs). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8782) Add getPrincipal method to FunctionContext interface
[
https://issues.apache.org/jira/browse/GEODE-8782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17261603#comment-17261603
]
ASF subversion and git services commented on GEODE-8782:
Commit 0ab677199d189527be354fd1427ce29b91ed6b31 in geode's branch
refs/heads/support/1.12 from Jens Deppe
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=0ab6771 ]
GEODE-8782: Add getPrincipal method to FunctionContext interface (#5840) (#5880)
- Add the ability to retrieve the Principal from the FunctionContext
when a SecurityManager is enabled.
(cherry picked from commit a42f89ab48aaca9aac96a34e80a9b3b2d46bcddd)
> Add getPrincipal method to FunctionContext interface
>
>
> Key: GEODE-8782
> URL: https://issues.apache.org/jira/browse/GEODE-8782
> Project: Geode
> Issue Type: New Feature
> Components: core
>Reporter: Jens Deppe
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> In some cases it would be very helpful to have access to the {{Principal}}
> when executing a function.
> It may seem obvious that if one has a reference to the {{cache}} that you
> could get to the {{SecurityManager}} and extract the {{Subject}} and thus the
> {{Principal}} from there. However, in some cases, Geode will seamlessly proxy
> a function call from one server to the other. This will typically happen with
> {{onRegion}} calls and partitioned regions. In such cases, the security
> context is lost and thus the principal is not accessible.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8782) Add getPrincipal method to FunctionContext interface
[
https://issues.apache.org/jira/browse/GEODE-8782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17261602#comment-17261602
]
ASF GitHub Bot commented on GEODE-8782:
---
jdeppe-pivotal merged pull request #5880:
URL: https://github.com/apache/geode/pull/5880
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
> Add getPrincipal method to FunctionContext interface
>
>
> Key: GEODE-8782
> URL: https://issues.apache.org/jira/browse/GEODE-8782
> Project: Geode
> Issue Type: New Feature
> Components: core
>Reporter: Jens Deppe
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> In some cases it would be very helpful to have access to the {{Principal}}
> when executing a function.
> It may seem obvious that if one has a reference to the {{cache}} that you
> could get to the {{SecurityManager}} and extract the {{Subject}} and thus the
> {{Principal}} from there. However, in some cases, Geode will seamlessly proxy
> a function call from one server to the other. This will typically happen with
> {{onRegion}} calls and partitioned regions. In such cases, the security
> context is lost and thus the principal is not accessible.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8782) Add getPrincipal method to FunctionContext interface
[
https://issues.apache.org/jira/browse/GEODE-8782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17261601#comment-17261601
]
ASF GitHub Bot commented on GEODE-8782:
---
jdeppe-pivotal commented on pull request #5880:
URL: https://github.com/apache/geode/pull/5880#issuecomment-757009606
> Historically we have never changed serialization version between patches
releases. Gfsh used to rely on this but now I think will be fine, but we still
may encounter some surprises. Also GEODE_1_12_1 (and this entire change) will
need to be added to support/1.13 and develop if hasn't been already.
Yes, that's correct, but I don't think we can actually do that yet until we
have an actual `1.12.1` release to point to. Correct me if that's not right.
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
> Add getPrincipal method to FunctionContext interface
>
>
> Key: GEODE-8782
> URL: https://issues.apache.org/jira/browse/GEODE-8782
> Project: Geode
> Issue Type: New Feature
> Components: core
>Reporter: Jens Deppe
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> In some cases it would be very helpful to have access to the {{Principal}}
> when executing a function.
> It may seem obvious that if one has a reference to the {{cache}} that you
> could get to the {{SecurityManager}} and extract the {{Subject}} and thus the
> {{Principal}} from there. However, in some cases, Geode will seamlessly proxy
> a function call from one server to the other. This will typically happen with
> {{onRegion}} calls and partitioned regions. In such cases, the security
> context is lost and thus the principal is not accessible.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8799) Increase default OperationExecutors#MAX_THREADS and MAX_PR_THREADS
[
https://issues.apache.org/jira/browse/GEODE-8799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17261594#comment-17261594
]
ASF subversion and git services commented on GEODE-8799:
Commit 86693d5170bb7ea85dabe15bf67c32ba875abef9 in geode's branch
refs/heads/develop from Donal Evans
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=86693d5 ]
GEODE-8799: Increase defaults for MAX_THREADS and MAX_PR_THREADS (#5862)
- MAX_THREADS new default is 1000
- MAX_PR_THREADS new default is
Math.max(Runtime.getRuntime().availableProcessors() * 32, 200))
- Removed unit test case for setting system property, since it cannot be
cleared afterwards without unloading the class
- Correct default values in properties.html
Authored-by: Donal Evans
> Increase default OperationExecutors#MAX_THREADS and MAX_PR_THREADS
> --
>
> Key: GEODE-8799
> URL: https://issues.apache.org/jira/browse/GEODE-8799
> Project: Geode
> Issue Type: Improvement
>Affects Versions: 1.14.0
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
> Labels: pull-request-available
>
> Similar to GEODE-8780, the default maximum number of pooled message processor
> and partitioned region message processor threads are low enough that they can
> cause performance degradation and should be increased.
> The current default value for {{MAX_THREADS}} is 100, and the current default
> value for {{MAX_PR_THREADS}} is
> {{Math.max(Runtime.getRuntime().availableProcessors() * 4, 16)}}
> The proposed new values are 1000 and
> {{Math.max(Runtime.getRuntime().availableProcessors() * 32, 200)}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8799) Increase default OperationExecutors#MAX_THREADS and MAX_PR_THREADS
[
https://issues.apache.org/jira/browse/GEODE-8799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17261593#comment-17261593
]
ASF GitHub Bot commented on GEODE-8799:
---
DonalEvans merged pull request #5862:
URL: https://github.com/apache/geode/pull/5862
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
> Increase default OperationExecutors#MAX_THREADS and MAX_PR_THREADS
> --
>
> Key: GEODE-8799
> URL: https://issues.apache.org/jira/browse/GEODE-8799
> Project: Geode
> Issue Type: Improvement
>Affects Versions: 1.14.0
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
> Labels: pull-request-available
>
> Similar to GEODE-8780, the default maximum number of pooled message processor
> and partitioned region message processor threads are low enough that they can
> cause performance degradation and should be increased.
> The current default value for {{MAX_THREADS}} is 100, and the current default
> value for {{MAX_PR_THREADS}} is
> {{Math.max(Runtime.getRuntime().availableProcessors() * 4, 16)}}
> The proposed new values are 1000 and
> {{Math.max(Runtime.getRuntime().availableProcessors() * 32, 200)}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8696) Startup of JMX Manager may hang during crash of other members
[
https://issues.apache.org/jira/browse/GEODE-8696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17261592#comment-17261592
]
ASF subversion and git services commented on GEODE-8696:
Commit 42726bd99c9ebb57ec5d3e987d47ecae9f4ea3a7 in geode's branch
refs/heads/develop from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=42726bd ]
GEODE-8696: Fix synchronization in FederatingManager (#5728)
Prevent hang while protecting against removal of member artifacts
during startup of manager.
> Startup of JMX Manager may hang during crash of other members
> -
>
> Key: GEODE-8696
> URL: https://issues.apache.org/jira/browse/GEODE-8696
> Project: Geode
> Issue Type: Bug
> Components: jmx, management
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> The fix for GEODE-7400 removed final from the executorService field to
> introduce a Supplier. I think this hang was caused by adding
> synchronized to FederatingManager.executeTask instead of making
> executorService a volatile field.
> _vm_3_thr_3_client2_host2_21145_ hung while synchronized on
> *0xf6316520*:
> {noformat}
> "vm_3_thr_3_client2_host2_21145" #56 daemon prio=5 os_prio=0
> tid=0x7f1854002000 nid=0x5326 waiting on condition [0x7f18520e2000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xf6364030> (a
> java.util.concurrent.FutureTask)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:429)
> at java.util.concurrent.FutureTask.get(FutureTask.java:191)
> at
> java.util.concurrent.AbstractExecutorService.invokeAll(AbstractExecutorService.java:244)
> at
> org.apache.geode.management.internal.FederatingManager.startManagingActivity(FederatingManager.java:256)
> at
> org.apache.geode.management.internal.FederatingManager.startManager(FederatingManager.java:121)
> - locked <0xf6316520> (a
> org.apache.geode.management.internal.FederatingManager)
> at
> org.apache.geode.management.internal.SystemManagementService.startManager(SystemManagementService.java:373)
> - locked <0xfed91a70> (a java.util.HashMap)
> at
> org.apache.geode.management.internal.beans.ManagementAdapter.handleCacheCreation(ManagementAdapter.java:197)
> at
> org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:127)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2089)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:643)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1363)
> at
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:191)
> - locked <0xe11065f0> (a java.lang.Class for
> org.apache.geode.internal.cache.GemFireCacheImpl)
> - locked <0xe1101220> (a java.lang.Class for
> org.apache.geode.internal.cache.InternalCacheBuilder)
> at
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:158)
> - locked <0xe1101220> (a java.lang.Class for
> org.apache.geode.internal.cache.InternalCacheBuilder)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:142)
> at
> hydra.CacheVersionHelper.configureAndCreateCache(CacheVersionHelper.java:51)
> at hydra.CacheHelper.createCacheWithHttpService(CacheHelper.java:127)
> - locked <0xfecab060> (a java.lang.Class for
> hydra.CacheHelper)
> at hydra.CacheHelper.createCache(CacheHelper.java:87)
> at
> splitBrain.NetworkPartitionTest.initialize(NetworkPartitionTest.java:293)
> at
> splitBrain.NetworkPartitionTest.initializeInstance(NetworkPartitionTest.java:228)
> - locked <0xe14a2db0> (a java.lang.Class for
> splitBrain.NetworkPartitionTest)
> at
> splitBrain.NetworkPartitionTest.HydraTask_initialize(NetworkPartitionTest.java:203)
> - locked <0xe14a2db0> (a java.lang.Class for
> splitBrain.NetworkPartitionTest)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
[jira] [Commented] (GEODE-8696) Startup of JMX Manager may hang during crash of other members
[
https://issues.apache.org/jira/browse/GEODE-8696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17261591#comment-17261591
]
ASF GitHub Bot commented on GEODE-8696:
---
kirklund merged pull request #5728:
URL: https://github.com/apache/geode/pull/5728
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
> Startup of JMX Manager may hang during crash of other members
> -
>
> Key: GEODE-8696
> URL: https://issues.apache.org/jira/browse/GEODE-8696
> Project: Geode
> Issue Type: Bug
> Components: jmx, management
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> The fix for GEODE-7400 removed final from the executorService field to
> introduce a Supplier. I think this hang was caused by adding
> synchronized to FederatingManager.executeTask instead of making
> executorService a volatile field.
> _vm_3_thr_3_client2_host2_21145_ hung while synchronized on
> *0xf6316520*:
> {noformat}
> "vm_3_thr_3_client2_host2_21145" #56 daemon prio=5 os_prio=0
> tid=0x7f1854002000 nid=0x5326 waiting on condition [0x7f18520e2000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xf6364030> (a
> java.util.concurrent.FutureTask)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:429)
> at java.util.concurrent.FutureTask.get(FutureTask.java:191)
> at
> java.util.concurrent.AbstractExecutorService.invokeAll(AbstractExecutorService.java:244)
> at
> org.apache.geode.management.internal.FederatingManager.startManagingActivity(FederatingManager.java:256)
> at
> org.apache.geode.management.internal.FederatingManager.startManager(FederatingManager.java:121)
> - locked <0xf6316520> (a
> org.apache.geode.management.internal.FederatingManager)
> at
> org.apache.geode.management.internal.SystemManagementService.startManager(SystemManagementService.java:373)
> - locked <0xfed91a70> (a java.util.HashMap)
> at
> org.apache.geode.management.internal.beans.ManagementAdapter.handleCacheCreation(ManagementAdapter.java:197)
> at
> org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:127)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2089)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:643)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1363)
> at
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:191)
> - locked <0xe11065f0> (a java.lang.Class for
> org.apache.geode.internal.cache.GemFireCacheImpl)
> - locked <0xe1101220> (a java.lang.Class for
> org.apache.geode.internal.cache.InternalCacheBuilder)
> at
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:158)
> - locked <0xe1101220> (a java.lang.Class for
> org.apache.geode.internal.cache.InternalCacheBuilder)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:142)
> at
> hydra.CacheVersionHelper.configureAndCreateCache(CacheVersionHelper.java:51)
> at hydra.CacheHelper.createCacheWithHttpService(CacheHelper.java:127)
> - locked <0xfecab060> (a java.lang.Class for
> hydra.CacheHelper)
> at hydra.CacheHelper.createCache(CacheHelper.java:87)
> at
> splitBrain.NetworkPartitionTest.initialize(NetworkPartitionTest.java:293)
> at
> splitBrain.NetworkPartitionTest.initializeInstance(NetworkPartitionTest.java:228)
> - locked <0xe14a2db0> (a java.lang.Class for
> splitBrain.NetworkPartitionTest)
> at
> splitBrain.NetworkPartitionTest.HydraTask_initialize(NetworkPartitionTest.java:203)
> - locked <0xe14a2db0> (a java.lang.Class for
> splitBrain.NetworkPartitionTest)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
>
[jira] [Commented] (GEODE-8821) Add tests to validate Geode redis stats
[ https://issues.apache.org/jira/browse/GEODE-8821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17261584#comment-17261584 ] ASF subversion and git services commented on GEODE-8821: Commit 88bafbb622426e684fe2f8c58be18f49b19abfee in geode's branch refs/heads/develop from Jens Deppe [ https://gitbox.apache.org/repos/asf?p=geode.git;h=88bafbb ] GEODE-8821: Add tests to validate Geode redis stats (#5886) > Add tests to validate Geode redis stats > --- > > Key: GEODE-8821 > URL: https://issues.apache.org/jira/browse/GEODE-8821 > Project: Geode > Issue Type: Test > Components: redis >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8821) Add tests to validate Geode redis stats
[ https://issues.apache.org/jira/browse/GEODE-8821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17261582#comment-17261582 ] ASF GitHub Bot commented on GEODE-8821: --- jdeppe-pivotal merged pull request #5886: URL: https://github.com/apache/geode/pull/5886 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 > Add tests to validate Geode redis stats > --- > > Key: GEODE-8821 > URL: https://issues.apache.org/jira/browse/GEODE-8821 > Project: Geode > Issue Type: Test > Components: redis >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-8822) Faulty statistics for parallel GW senders when using cleanQueues
[ https://issues.apache.org/jira/browse/GEODE-8822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Ivanac reassigned GEODE-8822: --- Assignee: Mario Ivanac > Faulty statistics for parallel GW senders when using cleanQueues > > > Key: GEODE-8822 > URL: https://issues.apache.org/jira/browse/GEODE-8822 > Project: Geode > Issue Type: Bug > Components: statistics, wan >Reporter: Mario Ivanac >Assignee: Mario Ivanac >Priority: Major > > After parallel GW sender with events in queue is restarted with option > --clean-queues, statistics is not cleared. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8823) Refactor RedisStats IntegrationTest
John Hutchison created GEODE-8823: - Summary: Refactor RedisStats IntegrationTest Key: GEODE-8823 URL: https://issues.apache.org/jira/browse/GEODE-8823 Project: Geode Issue Type: Improvement Components: redis Reporter: John Hutchison -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8696) Startup of JMX Manager may hang during crash of other members
[
https://issues.apache.org/jira/browse/GEODE-8696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17261519#comment-17261519
]
ASF GitHub Bot commented on GEODE-8696:
---
kirklund commented on a change in pull request #5728:
URL: https://github.com/apache/geode/pull/5728#discussion_r554126172
##
File path:
geode-core/src/main/java/org/apache/geode/management/internal/FederatingManager.java
##
@@ -108,31 +114,60 @@
@Override
public synchronized void startManager() {
try {
- if (logger.isDebugEnabled()) {
-logger.debug("Starting the Federating Manager ");
+ lifecycleLock.lock();
+ try {
+if (starting || running) {
+ return;
+}
+if (logger.isDebugEnabled()) {
+ logger.debug("Starting the Federating Manager ");
+}
+starting = true;
+executorService.set(executorServiceSupplier.get());
+running = true;
+ } finally {
+lifecycleLock.unlock();
}
- executorService = executorServiceSupplier.get();
-
- running = true;
startManagingActivity();
+
+ lifecycleLock.lock();
+ try {
+for (Runnable task : pendingTasks) {
+ executeTask(task);
+}
+ } finally {
+pendingTasks.clear();
+starting = false;
+lifecycleLock.unlock();
+ }
+
messenger.broadcastManagerInfo();
+
} catch (Exception e) {
+ pendingTasks.clear();
Review comment:
Yeah, I'm not sure if it's necessary but it would be more consistent.
I'll try making that change and try to write a new test or two in which startup
fails.
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
> Startup of JMX Manager may hang during crash of other members
> -
>
> Key: GEODE-8696
> URL: https://issues.apache.org/jira/browse/GEODE-8696
> Project: Geode
> Issue Type: Bug
> Components: jmx, management
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> The fix for GEODE-7400 removed final from the executorService field to
> introduce a Supplier. I think this hang was caused by adding
> synchronized to FederatingManager.executeTask instead of making
> executorService a volatile field.
> _vm_3_thr_3_client2_host2_21145_ hung while synchronized on
> *0xf6316520*:
> {noformat}
> "vm_3_thr_3_client2_host2_21145" #56 daemon prio=5 os_prio=0
> tid=0x7f1854002000 nid=0x5326 waiting on condition [0x7f18520e2000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xf6364030> (a
> java.util.concurrent.FutureTask)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:429)
> at java.util.concurrent.FutureTask.get(FutureTask.java:191)
> at
> java.util.concurrent.AbstractExecutorService.invokeAll(AbstractExecutorService.java:244)
> at
> org.apache.geode.management.internal.FederatingManager.startManagingActivity(FederatingManager.java:256)
> at
> org.apache.geode.management.internal.FederatingManager.startManager(FederatingManager.java:121)
> - locked <0xf6316520> (a
> org.apache.geode.management.internal.FederatingManager)
> at
> org.apache.geode.management.internal.SystemManagementService.startManager(SystemManagementService.java:373)
> - locked <0xfed91a70> (a java.util.HashMap)
> at
> org.apache.geode.management.internal.beans.ManagementAdapter.handleCacheCreation(ManagementAdapter.java:197)
> at
> org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:127)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2089)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:643)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1363)
> at
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:191)
> - locked <0xe11065f0> (a java.lang.Class for
> org.apache.geode.internal.cache.GemFireCacheImpl)
> - locked <0xe1101220> (a java.lang.Class for
>
[jira] [Commented] (GEODE-8696) Startup of JMX Manager may hang during crash of other members
[
https://issues.apache.org/jira/browse/GEODE-8696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17261514#comment-17261514
]
ASF GitHub Bot commented on GEODE-8696:
---
dschneider-pivotal commented on a change in pull request #5728:
URL: https://github.com/apache/geode/pull/5728#discussion_r554117743
##
File path:
geode-core/src/main/java/org/apache/geode/management/internal/FederatingManager.java
##
@@ -108,31 +114,60 @@
@Override
public synchronized void startManager() {
try {
- if (logger.isDebugEnabled()) {
-logger.debug("Starting the Federating Manager ");
+ lifecycleLock.lock();
+ try {
+if (starting || running) {
+ return;
+}
+if (logger.isDebugEnabled()) {
+ logger.debug("Starting the Federating Manager ");
+}
+starting = true;
+executorService.set(executorServiceSupplier.get());
+running = true;
+ } finally {
+lifecycleLock.unlock();
}
- executorService = executorServiceSupplier.get();
-
- running = true;
startManagingActivity();
+
+ lifecycleLock.lock();
+ try {
+for (Runnable task : pendingTasks) {
+ executeTask(task);
+}
+ } finally {
+pendingTasks.clear();
+starting = false;
+lifecycleLock.unlock();
+ }
+
messenger.broadcastManagerInfo();
+
} catch (Exception e) {
+ pendingTasks.clear();
Review comment:
Should this clear and setting running and starting also be protected by
a lifecycleLock.lock/unlock?
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
> Startup of JMX Manager may hang during crash of other members
> -
>
> Key: GEODE-8696
> URL: https://issues.apache.org/jira/browse/GEODE-8696
> Project: Geode
> Issue Type: Bug
> Components: jmx, management
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> The fix for GEODE-7400 removed final from the executorService field to
> introduce a Supplier. I think this hang was caused by adding
> synchronized to FederatingManager.executeTask instead of making
> executorService a volatile field.
> _vm_3_thr_3_client2_host2_21145_ hung while synchronized on
> *0xf6316520*:
> {noformat}
> "vm_3_thr_3_client2_host2_21145" #56 daemon prio=5 os_prio=0
> tid=0x7f1854002000 nid=0x5326 waiting on condition [0x7f18520e2000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xf6364030> (a
> java.util.concurrent.FutureTask)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:429)
> at java.util.concurrent.FutureTask.get(FutureTask.java:191)
> at
> java.util.concurrent.AbstractExecutorService.invokeAll(AbstractExecutorService.java:244)
> at
> org.apache.geode.management.internal.FederatingManager.startManagingActivity(FederatingManager.java:256)
> at
> org.apache.geode.management.internal.FederatingManager.startManager(FederatingManager.java:121)
> - locked <0xf6316520> (a
> org.apache.geode.management.internal.FederatingManager)
> at
> org.apache.geode.management.internal.SystemManagementService.startManager(SystemManagementService.java:373)
> - locked <0xfed91a70> (a java.util.HashMap)
> at
> org.apache.geode.management.internal.beans.ManagementAdapter.handleCacheCreation(ManagementAdapter.java:197)
> at
> org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:127)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2089)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:643)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1363)
> at
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:191)
> - locked <0xe11065f0> (a java.lang.Class for
> org.apache.geode.internal.cache.GemFireCacheImpl)
> - locked <0xe1101220> (a java.lang.Class for
> org.apache.geode.internal.cache.InternalCacheBuilder)
>
[jira] [Created] (GEODE-8822) Faulty statistics for parallel GW senders when using cleanQueues
Mario Ivanac created GEODE-8822: --- Summary: Faulty statistics for parallel GW senders when using cleanQueues Key: GEODE-8822 URL: https://issues.apache.org/jira/browse/GEODE-8822 Project: Geode Issue Type: Bug Components: statistics, wan Reporter: Mario Ivanac After parallel GW sender with events in queue is restarted with option --clean-queues, statistics is not cleared. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-6504) CI: RegionExpirationIntegrationTest > increaseRegionTtl[EMPTY] FAILED
[
https://issues.apache.org/jira/browse/GEODE-6504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17261462#comment-17261462
]
Geode Integration commented on GEODE-6504:
--
Seen in [WindowsCoreIntegrationTestOpenJDK11
#658|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsCoreIntegrationTestOpenJDK11/builds/658]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0591/test-results/integrationTest/1610076192/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0591/test-artifacts/1610076192/windows-coreintegrationtestfiles-OpenJDK11-1.14.0-build.0591.tgz].
> CI: RegionExpirationIntegrationTest > increaseRegionTtl[EMPTY] FAILED
> -
>
> Key: GEODE-6504
> URL: https://issues.apache.org/jira/browse/GEODE-6504
> Project: Geode
> Issue Type: Bug
> Components: expiration
>Reporter: Mark Hanson
>Priority: Major
> Labels: GeodeOperationAPI
> Attachments: RegionExpirationIntegrationTest.log
>
>
> CI failure: see attached log.
>
> Failed on WindowsIntegrationTestOpenJDK11
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsIntegrationTestOpenJDK11/builds/272]
> {noformat}
> org.apache.geode.cache.RegionExpirationIntegrationTest >
> increaseRegionTtl[EMPTY] FAILED
> java.lang.AssertionError:
> Expecting:
> <7L>
> to be greater than or equal to:
> <8L>
> at
> org.apache.geode.cache.RegionExpirationIntegrationTest.increaseRegionTtl(RegionExpirationIntegrationTest.java:88)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-6504) CI: RegionExpirationIntegrationTest > increaseRegionTtl[EMPTY] FAILED
[
https://issues.apache.org/jira/browse/GEODE-6504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17261461#comment-17261461
]
Darrel Schneider commented on GEODE-6504:
-
again:
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsCoreIntegrationTestOpenJDK11/builds/658
> CI: RegionExpirationIntegrationTest > increaseRegionTtl[EMPTY] FAILED
> -
>
> Key: GEODE-6504
> URL: https://issues.apache.org/jira/browse/GEODE-6504
> Project: Geode
> Issue Type: Bug
> Components: expiration
>Reporter: Mark Hanson
>Priority: Major
> Labels: GeodeOperationAPI
> Attachments: RegionExpirationIntegrationTest.log
>
>
> CI failure: see attached log.
>
> Failed on WindowsIntegrationTestOpenJDK11
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsIntegrationTestOpenJDK11/builds/272]
> {noformat}
> org.apache.geode.cache.RegionExpirationIntegrationTest >
> increaseRegionTtl[EMPTY] FAILED
> java.lang.AssertionError:
> Expecting:
> <7L>
> to be greater than or equal to:
> <8L>
> at
> org.apache.geode.cache.RegionExpirationIntegrationTest.increaseRegionTtl(RegionExpirationIntegrationTest.java:88)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8803) RedisStatsIntegrationTest.opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring fails intermittently
[
https://issues.apache.org/jira/browse/GEODE-8803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17261453#comment-17261453
]
Geode Integration commented on GEODE-8803:
--
Seen in [IntegrationTestOpenJDK8
#660|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/IntegrationTestOpenJDK8/builds/660]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0593/test-results/integrationTest/1610075291/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0593/test-artifacts/1610075291/integrationtestfiles-OpenJDK8-1.14.0-build.0593.tgz].
> RedisStatsIntegrationTest.opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring
> fails intermittently
> ---
>
> Key: GEODE-8803
> URL: https://issues.apache.org/jira/browse/GEODE-8803
> Project: Geode
> Issue Type: Bug
> Components: redis
>Reporter: Kirk Lund
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available
>
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0578/test-results/integrationTest/1609804101/
> {noformat}
> java.lang.AssertionError:
> Expecting:
> <19.0>
> to be close to:
> <17.0>
> by less than <1.0> but difference was <2.0>.
> (a difference of exactly <1.0> being considered valid)
> at
> org.apache.geode.redis.internal.RedisStatsIntegrationTest.opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring(RedisStatsIntegrationTest.java:430)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:38)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
> at
> org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
>
[jira] [Commented] (GEODE-8803) RedisStatsIntegrationTest.opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring fails intermittently
[
https://issues.apache.org/jira/browse/GEODE-8803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17261454#comment-17261454
]
Geode Integration commented on GEODE-8803:
--
Seen in [IntegrationTestOpenJDK8
#661|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/IntegrationTestOpenJDK8/builds/661]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0593/test-results/integrationTest/1610077322/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0593/test-artifacts/1610077322/integrationtestfiles-OpenJDK8-1.14.0-build.0593.tgz].
> RedisStatsIntegrationTest.opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring
> fails intermittently
> ---
>
> Key: GEODE-8803
> URL: https://issues.apache.org/jira/browse/GEODE-8803
> Project: Geode
> Issue Type: Bug
> Components: redis
>Reporter: Kirk Lund
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available
>
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0578/test-results/integrationTest/1609804101/
> {noformat}
> java.lang.AssertionError:
> Expecting:
> <19.0>
> to be close to:
> <17.0>
> by less than <1.0> but difference was <2.0>.
> (a difference of exactly <1.0> being considered valid)
> at
> org.apache.geode.redis.internal.RedisStatsIntegrationTest.opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring(RedisStatsIntegrationTest.java:430)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:38)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
> at
> org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
>
[jira] [Commented] (GEODE-8821) Add tests to validate Geode redis stats
[ https://issues.apache.org/jira/browse/GEODE-8821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17261427#comment-17261427 ] ASF GitHub Bot commented on GEODE-8821: --- jdeppe-pivotal opened a new pull request #5886: URL: https://github.com/apache/geode/pull/5886 Co-authored-by: Ray Ingles 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 > Add tests to validate Geode redis stats > --- > > Key: GEODE-8821 > URL: https://issues.apache.org/jira/browse/GEODE-8821 > Project: Geode > Issue Type: Test > Components: redis >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8821) Add tests to validate Geode redis stats
[ https://issues.apache.org/jira/browse/GEODE-8821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-8821: -- Labels: pull-request-available (was: ) > Add tests to validate Geode redis stats > --- > > Key: GEODE-8821 > URL: https://issues.apache.org/jira/browse/GEODE-8821 > Project: Geode > Issue Type: Test > Components: redis >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8821) Add tests to validate Geode redis stats
Jens Deppe created GEODE-8821: - Summary: Add tests to validate Geode redis stats Key: GEODE-8821 URL: https://issues.apache.org/jira/browse/GEODE-8821 Project: Geode Issue Type: Test Components: redis Reporter: Jens Deppe -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-8821) Add tests to validate Geode redis stats
[ https://issues.apache.org/jira/browse/GEODE-8821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe reassigned GEODE-8821: - Assignee: Jens Deppe > Add tests to validate Geode redis stats > --- > > Key: GEODE-8821 > URL: https://issues.apache.org/jira/browse/GEODE-8821 > Project: Geode > Issue Type: Test > Components: redis >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8820) Fix ACE 6.5.12 build break on Windows
[ https://issues.apache.org/jira/browse/GEODE-8820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17261392#comment-17261392 ] ASF GitHub Bot commented on GEODE-8820: --- pivotal-jbarrett merged pull request #717: URL: https://github.com/apache/geode-native/pull/717 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 > Fix ACE 6.5.12 build break on Windows > - > > Key: GEODE-8820 > URL: https://issues.apache.org/jira/browse/GEODE-8820 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Michael Martell >Priority: Major > Labels: pull-request-available > > The recent upgrade to ACE version 6.5.12 has broken our CI build on Windows. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8820) Fix ACE 6.5.12 build break on Windows
[ https://issues.apache.org/jira/browse/GEODE-8820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17261391#comment-17261391 ] ASF subversion and git services commented on GEODE-8820: Commit c1886061ff94e328d4675206b34c3a4868510600 in geode-native's branch refs/heads/develop from Michael Martell [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=c188606 ] GEODE-8820: Fix Windows build for latest ACE (#717) Co-authored-by: Jacob Barrett > Fix ACE 6.5.12 build break on Windows > - > > Key: GEODE-8820 > URL: https://issues.apache.org/jira/browse/GEODE-8820 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Michael Martell >Priority: Major > Labels: pull-request-available > > The recent upgrade to ACE version 6.5.12 has broken our CI build on Windows. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8266) StatForNotQueuedConflated not incremented in time
[
https://issues.apache.org/jira/browse/GEODE-8266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17261387#comment-17261387
]
Geode Integration commented on GEODE-8266:
--
Seen in [WindowsUnitTestOpenJDK8
#654|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsUnitTestOpenJDK8/builds/654]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0592/test-results/test/1610073270/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0592/test-artifacts/1610073270/windows-unittestfiles-OpenJDK8-1.14.0-build.0592.tgz].
> StatForNotQueuedConflated not incremented in time
> -
>
> Key: GEODE-8266
> URL: https://issues.apache.org/jira/browse/GEODE-8266
> Project: Geode
> Issue Type: Bug
> Components: wan
>Reporter: Bill Burcham
>Priority: Major
>
> Failed here:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsUnitTestOpenJDK11/builds/259#A
> {code}
> org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueueJUnitTest
> >
> whenNullPeekedEventFromBucketRegionQueueTheStatForNotQueuedConflatedShouldBeIncremented
> FAILED
> java.lang.AssertionError: expected:<1> but was:<0>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.junit.Assert.assertEquals(Assert.java:631)
> at
> org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueueJUnitTest.whenNullPeekedEventFromBucketRegionQueueTheStatForNotQueuedConflatedShouldBeIncremented(ParallelGatewaySenderQueueJUnitTest.java:146)
> {code}
> It appears we are waiting 100ms for the statistic to be incremented. Perhaps
> we need to wait longer. Or maybe there is product bug here?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8803) RedisStatsIntegrationTest.opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring fails intermittently
[
https://issues.apache.org/jira/browse/GEODE-8803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17261383#comment-17261383
]
ASF subversion and git services commented on GEODE-8803:
Commit 762db7e86d3969205e2729e4900ff997ca659b74 in geode's branch
refs/heads/develop from John Hutchison
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=762db7e ]
GEODE-8803:increase offset of flakey test (#5876)
-change offset to be a percentage of total commands
Co-authored-by: john Hutchison
> RedisStatsIntegrationTest.opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring
> fails intermittently
> ---
>
> Key: GEODE-8803
> URL: https://issues.apache.org/jira/browse/GEODE-8803
> Project: Geode
> Issue Type: Bug
> Components: redis
>Reporter: Kirk Lund
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available
>
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0578/test-results/integrationTest/1609804101/
> {noformat}
> java.lang.AssertionError:
> Expecting:
> <19.0>
> to be close to:
> <17.0>
> by less than <1.0> but difference was <2.0>.
> (a difference of exactly <1.0> being considered valid)
> at
> org.apache.geode.redis.internal.RedisStatsIntegrationTest.opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring(RedisStatsIntegrationTest.java:430)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:38)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
> at
> org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
>
[jira] [Commented] (GEODE-8803) RedisStatsIntegrationTest.opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring fails intermittently
[
https://issues.apache.org/jira/browse/GEODE-8803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17261380#comment-17261380
]
ASF GitHub Bot commented on GEODE-8803:
---
jdeppe-pivotal merged pull request #5876:
URL: https://github.com/apache/geode/pull/5876
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
> RedisStatsIntegrationTest.opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring
> fails intermittently
> ---
>
> Key: GEODE-8803
> URL: https://issues.apache.org/jira/browse/GEODE-8803
> Project: Geode
> Issue Type: Bug
> Components: redis
>Reporter: Kirk Lund
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available
>
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0578/test-results/integrationTest/1609804101/
> {noformat}
> java.lang.AssertionError:
> Expecting:
> <19.0>
> to be close to:
> <17.0>
> by less than <1.0> but difference was <2.0>.
> (a difference of exactly <1.0> being considered valid)
> at
> org.apache.geode.redis.internal.RedisStatsIntegrationTest.opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring(RedisStatsIntegrationTest.java:430)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:38)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
> at
> org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
>
[jira] [Commented] (GEODE-8466) Create a ClassLoaderService to abstract away dealing with the default ClassLoader directly
[ https://issues.apache.org/jira/browse/GEODE-8466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17261313#comment-17261313 ] ASF GitHub Bot commented on GEODE-8466: --- yozaner1324 closed pull request #5658: URL: https://github.com/apache/geode/pull/5658 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 a ClassLoaderService to abstract away dealing with the default > ClassLoader directly > -- > > Key: GEODE-8466 > URL: https://issues.apache.org/jira/browse/GEODE-8466 > Project: Geode > Issue Type: New Feature > Components: core >Reporter: Udo Kohlmeyer >Assignee: Udo Kohlmeyer >Priority: Major > Labels: pull-request-available > > With the addition of ClassLoader isolation using JBoss Modules GEODE-8067, > the manner in which we interact with the ClassLoader needs to change. > An abstraction is required around the default functions like > `findResourceAsStream`, `loadClass` and `loadService`. > As these features will behave differently between different ClassLoader > implementations, it is best to have a single service that will expose that > functionality in a transparent manner. -- This message was sent by Atlassian Jira (v8.3.4#803005)
