[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=17262056#comment-17262056 ] 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 > Labels: pull-request-available > -- 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=17262079#comment-17262079 ] 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] [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=17262078#comment-17262078 ] 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-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=17262073#comment-17262073
]
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.
##
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,
[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=17262053#comment-17262053 ] 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 > 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-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=17262071#comment-17262071 ] 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 > 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] [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=17262069#comment-17262069
]
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
> 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-8803) RedisStatsIntegrationTest.opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring fails intermittently
[
https://issues.apache.org/jira/browse/GEODE-8803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17262067#comment-17262067
]
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-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=17262065#comment-17262065
]
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
> 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
>
[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=17262064#comment-17262064
]
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-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=17262061#comment-17262061 ] 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 > 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-8782) Add getPrincipal method to FunctionContext interface
[
https://issues.apache.org/jira/browse/GEODE-8782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17262041#comment-17262041
]
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.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-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=17262052#comment-17262052 ] 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] [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=17262046#comment-17262046 ] 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-8782) Add getPrincipal method to FunctionContext interface
[
https://issues.apache.org/jira/browse/GEODE-8782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17262047#comment-17262047
]
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.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-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=17262045#comment-17262045
]
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
> 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-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=17262044#comment-17262044
]
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-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=17262036#comment-17262036
]
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
> 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-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=17262032#comment-17262032 ] 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-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=17262026#comment-17262026
]
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
> 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
>
[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=17262027#comment-17262027 ] 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] [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=17262023#comment-17262023
]
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
> 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] [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=17262021#comment-17262021
]
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
> 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
[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=17262020#comment-17262020 ] 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-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=17262010#comment-17262010 ] 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)
