[jira] [Updated] (GEODE-7242) Incorrect documentation for AVG and SUM aggregate functions
[ https://issues.apache.org/jira/browse/GEODE-7242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans updated GEODE-7242: --- Parent: GEODE-6969 Issue Type: Sub-task (was: Bug) > Incorrect documentation for AVG and SUM aggregate functions > --- > > Key: GEODE-7242 > URL: https://issues.apache.org/jira/browse/GEODE-7242 > Project: Geode > Issue Type: Sub-task > Components: docs, querying >Reporter: Donal Evans >Priority: Major > Labels: GeodeCommons > > The documentation for OQL Aggregate Functions states that AVG and SUM always > return either a Float or Double, but the actual return type can be any of > Integer, Long, Float or Double. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7242) Incorrect documentation for AVG and SUM aggregate functions
[ https://issues.apache.org/jira/browse/GEODE-7242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans updated GEODE-7242: --- Labels: GeodeCommons (was: ) > Incorrect documentation for AVG and SUM aggregate functions > --- > > Key: GEODE-7242 > URL: https://issues.apache.org/jira/browse/GEODE-7242 > Project: Geode > Issue Type: Bug > Components: docs, querying >Reporter: Donal Evans >Priority: Major > Labels: GeodeCommons > > The documentation for OQL Aggregate Functions states that AVG and SUM always > return either a Float or Double, but the actual return type can be any of > Integer, Long, Float or Double. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-7242) Incorrect documentation for AVG and SUM aggregate functions
Donal Evans created GEODE-7242: -- Summary: Incorrect documentation for AVG and SUM aggregate functions Key: GEODE-7242 URL: https://issues.apache.org/jira/browse/GEODE-7242 Project: Geode Issue Type: Bug Components: docs, querying Reporter: Donal Evans The documentation for OQL Aggregate Functions states that AVG and SUM always return either a Float or Double, but the actual return type can be any of Integer, Long, Float or Double. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-6183) CI Failure: LocatorLauncherRemoteFileIntegrationTest.startDeletesStaleControlFiles failed with ConditionTimeoutException
[ https://issues.apache.org/jira/browse/GEODE-6183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16937218#comment-16937218 ] Aaron Lindsey commented on GEODE-6183: -- Failed again: [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsCoreIntegrationTestOpenJDK11/builds/349] > CI Failure: > LocatorLauncherRemoteFileIntegrationTest.startDeletesStaleControlFiles failed > with ConditionTimeoutException > > > Key: GEODE-6183 > URL: https://issues.apache.org/jira/browse/GEODE-6183 > Project: Geode > Issue Type: Bug > Components: ci, gfsh >Reporter: Eric Shu >Assignee: Kirk Lund >Priority: Major > Fix For: 1.10.0 > > Time Spent: 5.5h > Remaining Estimate: 0h > > Test failed in > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/IntegrationTestOpenJDK8/builds/223 > org.apache.geode.distributed.LocatorLauncherRemoteFileIntegrationTest > > startDeletesStaleControlFiles FAILED > org.awaitility.core.ConditionTimeoutException: Assertion condition > defined as a lambda expression in > org.apache.geode.distributed.LocatorLauncherRemoteIntegrationTestCase that > uses org.apache.geode.distributed.LocatorLauncher expected:<[online]> but > was:<[not responding]> within 300 seconds. > Caused by: > org.junit.ComparisonFailure: expected:<[online]> but was:<[not > responding]> -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7026) LocatorLauncherRemoteFileIntegrationTest > startDeletesStaleControlFiles fails on Windows
[ https://issues.apache.org/jira/browse/GEODE-7026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16937214#comment-16937214 ] Aaron Lindsey commented on GEODE-7026: -- Failed again: [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsCoreIntegrationTestOpenJDK11/builds/349] > LocatorLauncherRemoteFileIntegrationTest > startDeletesStaleControlFiles > fails on Windows > - > > Key: GEODE-7026 > URL: https://issues.apache.org/jira/browse/GEODE-7026 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Donal Evans >Priority: Major > Labels: IntegrationTest, Windows, flaky > > org.apache.geode.distributed.LocatorLauncherRemoteFileIntegrationTest > > startDeletesStaleControlFiles FAILED > [ > |https://concourse.gemfire-ci.info/teams/main/pipelines/gemfire-develop-main/jobs/WindowsCoreIntegrationTestOpenJDK11/builds/159#L5d3266c7:1681] > org.awaitility.core.ConditionTimeoutException: Assertion condition defined > as a lambda expression in > org.apache.geode.distributed.LocatorLauncherRemoteIntegrationTestCase > expected:<[online]> but was:<[not responding]> within 300 seconds. > [ > |https://concourse.gemfire-ci.info/teams/main/pipelines/gemfire-develop-main/jobs/WindowsCoreIntegrationTestOpenJDK11/builds/159#L5d3266c7:1682] > > [ > |https://concourse.gemfire-ci.info/teams/main/pipelines/gemfire-develop-main/jobs/WindowsCoreIntegrationTestOpenJDK11/builds/159#L5d3266c7:1683] > Caused by: > [ > |https://concourse.gemfire-ci.info/teams/main/pipelines/gemfire-develop-main/jobs/WindowsCoreIntegrationTestOpenJDK11/builds/159#L5d3266c7:1684] > org.junit.ComparisonFailure: expected:<[online]> but was:<[not responding]> > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7050) Log4jAgent should avoid casting non-log4j loggers
[
https://issues.apache.org/jira/browse/GEODE-7050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16937213#comment-16937213
]
Kirk Lund commented on GEODE-7050:
--
It may be possible to work around this bug in previous versions if you exclude
{{log4j-core}} from the classpath and dependencies.
> Log4jAgent should avoid casting non-log4j loggers
> -
>
> Key: GEODE-7050
> URL: https://issues.apache.org/jira/browse/GEODE-7050
> Project: Geode
> Issue Type: Bug
> Components: logging
>Affects Versions: 1.9.0, 1.10.0
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Fix For: 1.9.1, 1.10.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Users should be able to use SLF4J API with Geode even when log4j-core is in
> the class path and the Geode log4j appenders are being used.
> Log4jAgent assumes that all Loggers are Log4J loggers. This can result in a
> ClassCastException when encountering an instance of SLF4JLogger.
> {noformat}
> Caused by: java.lang.ClassCastException: org.apache.logging.slf4j.SLF4JLogger
> cannot be cast to org.apache.logging.log4j.core.Logger
> at
> org.apache.geode.internal.logging.log4j.Log4jAgent.getRootLoggerContext(Log4jAgent.java:91)
> at
> org.apache.geode.internal.logging.log4j.Log4jAgent.getConfiguration(Log4jAgent.java:95)
> at
> org.apache.geode.internal.logging.log4j.Log4jAgent.isUsingGemFireDefaultConfig(Log4jAgent.java:80)
> at
> org.apache.geode.internal.logging.log4j.Log4jAgent.shouldUpdateLogLevels(Log4jAgent.java:129)
> at
> org.apache.geode.internal.logging.log4j.Log4jAgent.configure(Log4jAgent.java:107)
> at
> org.apache.geode.internal.logging.Configuration.configChanged(Configuration.java:152)
> at
> org.apache.geode.internal.logging.Configuration.initialize(Configuration.java:141)
> at
> org.apache.geode.internal.logging.LoggingSession.createSession(LoggingSession.java:65)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:762)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:446)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:432)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:257)
> at
> org.apache.geode.distributed.DistributedSystem.connect(DistributedSystem.java:164)
> at
> org.apache.geode.cache.client.ClientCacheFactory.basicCreate(ClientCacheFactory.java:243)
> at
> org.apache.geode.cache.client.ClientCacheFactory.create(ClientCacheFactory.java:214)
> at
> org.springframework.data.gemfire.client.ClientCacheFactoryBean.createCache(ClientCacheFactoryBean.java:391)
> at
> org.springframework.data.gemfire.CacheFactoryBean.resolveCache(CacheFactoryBean.java:325)
> at
> org.springframework.data.gemfire.CacheFactoryBean.init(CacheFactoryBean.java:269)
> ... 107 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7235) Disable new Clang warnings to fix build for now
[ https://issues.apache.org/jira/browse/GEODE-7235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16937201#comment-16937201 ] ASF subversion and git services commented on GEODE-7235: Commit 05710df47b886b831b4ee49b68faf971a1205a0e in geode-native's branch refs/heads/develop from Blake Bender [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=05710df ] GEODE-7235: Disable a couple of new Clang warnings temporarily (#527) * GEODE-7235: Disable a couple of new Clang warnings temporarily * GEODE-7235: Make disabled warnings platform-dependent - Got a new version of the compiler from Apple, this is breaking Mac builds - Turns out Travis CI also uses Clang, but an older version that doesn't recognize these warnings, so there you get a warning about unrecognized warnings Co-authored-by Michael Oleske > Disable new Clang warnings to fix build for now > --- > > Key: GEODE-7235 > URL: https://issues.apache.org/jira/browse/GEODE-7235 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Blake Bender >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > Apple pushed an XCode update a couple of days ago to version ` > Apple clang version 11.0.0 (clang-1100.0.33.8)`. This version flags some new > warnings in our code, and since we have warnings-as-errors turned on we blow > up. Fixing these warnings is non-trivial, so we need to disable them in the > top-level CMakeLists.txt and file another Jira issue to do the real fix. > * Steps to repro: > Sync up to the latest `develop` branch of Native Client on a Mac and build > * Expected Result: > Geode Native builds, and produces our libraries > * Actual Result: > Clang warns about "implicitly deleted copy/move ctors declared as default" in > a product header, gives a warning about UTF-8 string literals in test code, > then build fails. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7235) Disable new Clang warnings to fix build for now
[ https://issues.apache.org/jira/browse/GEODE-7235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16937202#comment-16937202 ] ASF subversion and git services commented on GEODE-7235: Commit 05710df47b886b831b4ee49b68faf971a1205a0e in geode-native's branch refs/heads/develop from Blake Bender [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=05710df ] GEODE-7235: Disable a couple of new Clang warnings temporarily (#527) * GEODE-7235: Disable a couple of new Clang warnings temporarily * GEODE-7235: Make disabled warnings platform-dependent - Got a new version of the compiler from Apple, this is breaking Mac builds - Turns out Travis CI also uses Clang, but an older version that doesn't recognize these warnings, so there you get a warning about unrecognized warnings Co-authored-by Michael Oleske > Disable new Clang warnings to fix build for now > --- > > Key: GEODE-7235 > URL: https://issues.apache.org/jira/browse/GEODE-7235 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Blake Bender >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > Apple pushed an XCode update a couple of days ago to version ` > Apple clang version 11.0.0 (clang-1100.0.33.8)`. This version flags some new > warnings in our code, and since we have warnings-as-errors turned on we blow > up. Fixing these warnings is non-trivial, so we need to disable them in the > top-level CMakeLists.txt and file another Jira issue to do the real fix. > * Steps to repro: > Sync up to the latest `develop` branch of Native Client on a Mac and build > * Expected Result: > Geode Native builds, and produces our libraries > * Actual Result: > Clang warns about "implicitly deleted copy/move ctors declared as default" in > a product header, gives a warning about UTF-8 string literals in test code, > then build fails. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7235) Disable new Clang warnings to fix build for now
[ https://issues.apache.org/jira/browse/GEODE-7235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16937200#comment-16937200 ] ASF subversion and git services commented on GEODE-7235: Commit 05710df47b886b831b4ee49b68faf971a1205a0e in geode-native's branch refs/heads/develop from Blake Bender [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=05710df ] GEODE-7235: Disable a couple of new Clang warnings temporarily (#527) * GEODE-7235: Disable a couple of new Clang warnings temporarily * GEODE-7235: Make disabled warnings platform-dependent - Got a new version of the compiler from Apple, this is breaking Mac builds - Turns out Travis CI also uses Clang, but an older version that doesn't recognize these warnings, so there you get a warning about unrecognized warnings Co-authored-by Michael Oleske > Disable new Clang warnings to fix build for now > --- > > Key: GEODE-7235 > URL: https://issues.apache.org/jira/browse/GEODE-7235 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Blake Bender >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > Apple pushed an XCode update a couple of days ago to version ` > Apple clang version 11.0.0 (clang-1100.0.33.8)`. This version flags some new > warnings in our code, and since we have warnings-as-errors turned on we blow > up. Fixing these warnings is non-trivial, so we need to disable them in the > top-level CMakeLists.txt and file another Jira issue to do the real fix. > * Steps to repro: > Sync up to the latest `develop` branch of Native Client on a Mac and build > * Expected Result: > Geode Native builds, and produces our libraries > * Actual Result: > Clang warns about "implicitly deleted copy/move ctors declared as default" in > a product header, gives a warning about UTF-8 string literals in test code, > then build fails. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7241) Artifacts for geode-web and geode-web-api are jars instead of wars in maven central
[ https://issues.apache.org/jira/browse/GEODE-7241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer updated GEODE-7241: - Fix Version/s: (was: 1.11.0) > Artifacts for geode-web and geode-web-api are jars instead of wars in maven > central > --- > > Key: GEODE-7241 > URL: https://issues.apache.org/jira/browse/GEODE-7241 > Project: Geode > Issue Type: Bug > Components: build >Affects Versions: 1.8.0, 1.9.0, 1.9.1, 1.10.0 >Reporter: Udo Kohlmeyer >Assignee: Robert Houghton >Priority: Major > > In maven central the artifact for `geode-web` and `geode-web-api` are jars > instead of the expected wars. > This seems to be problem with the build/publish script that seems to have > changed in 1.8. > As this problem started in 1.8 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7241) Artifacts for geode-web and geode-web-api are jars instead of wars in maven central
[ https://issues.apache.org/jira/browse/GEODE-7241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer updated GEODE-7241: - Affects Version/s: 1.10.0 > Artifacts for geode-web and geode-web-api are jars instead of wars in maven > central > --- > > Key: GEODE-7241 > URL: https://issues.apache.org/jira/browse/GEODE-7241 > Project: Geode > Issue Type: Bug > Components: build >Affects Versions: 1.8.0, 1.9.0, 1.9.1, 1.10.0 >Reporter: Udo Kohlmeyer >Assignee: Robert Houghton >Priority: Major > Fix For: 1.11.0 > > > In maven central the artifact for `geode-web` and `geode-web-api` are jars > instead of the expected wars. > This seems to be problem with the build/publish script that seems to have > changed in 1.8. > As this problem started in 1.8 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7241) Artifacts for geode-web and geode-web-api are jars instead of wars in maven central
[ https://issues.apache.org/jira/browse/GEODE-7241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer updated GEODE-7241: - Affects Version/s: 1.8.0 1.9.0 1.9.1 > Artifacts for geode-web and geode-web-api are jars instead of wars in maven > central > --- > > Key: GEODE-7241 > URL: https://issues.apache.org/jira/browse/GEODE-7241 > Project: Geode > Issue Type: Bug > Components: build >Affects Versions: 1.8.0, 1.9.0, 1.9.1 >Reporter: Udo Kohlmeyer >Priority: Major > Fix For: 1.11.0 > > > In maven central the artifact for `geode-web` and `geode-web-api` are jars > instead of the expected wars. > This seems to be problem with the build/publish script that seems to have > changed in 1.8. > As this problem started in 1.8 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-7241) Artifacts for geode-web and geode-web-api are jars instead of wars in maven central
[ https://issues.apache.org/jira/browse/GEODE-7241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer reassigned GEODE-7241: Assignee: Robert Houghton > Artifacts for geode-web and geode-web-api are jars instead of wars in maven > central > --- > > Key: GEODE-7241 > URL: https://issues.apache.org/jira/browse/GEODE-7241 > Project: Geode > Issue Type: Bug > Components: build >Affects Versions: 1.8.0, 1.9.0, 1.9.1 >Reporter: Udo Kohlmeyer >Assignee: Robert Houghton >Priority: Major > Fix For: 1.11.0 > > > In maven central the artifact for `geode-web` and `geode-web-api` are jars > instead of the expected wars. > This seems to be problem with the build/publish script that seems to have > changed in 1.8. > As this problem started in 1.8 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-7241) Artifacts for geode-web and geode-web-api are jars instead of wars in maven central
Udo Kohlmeyer created GEODE-7241: Summary: Artifacts for geode-web and geode-web-api are jars instead of wars in maven central Key: GEODE-7241 URL: https://issues.apache.org/jira/browse/GEODE-7241 Project: Geode Issue Type: Bug Components: build Reporter: Udo Kohlmeyer Fix For: 1.11.0 In maven central the artifact for `geode-web` and `geode-web-api` are jars instead of the expected wars. This seems to be problem with the build/publish script that seems to have changed in 1.8. As this problem started in 1.8 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7240) Prevent Usage of Aggregates within WHERE clause
[
https://issues.apache.org/jira/browse/GEODE-7240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella updated GEODE-7240:
Labels: GeodeCommons (was: )
> Prevent Usage of Aggregates within WHERE clause
> ---
>
> Key: GEODE-7240
> URL: https://issues.apache.org/jira/browse/GEODE-7240
> Project: Geode
> Issue Type: Bug
> Components: querying
>Reporter: Juan José Ramos Cassella
>Priority: Major
> Labels: GeodeCommons
>
> Aggregate functions shouldn't be allowed as part of the {{WHERE}} clause.
> Currently, instead of rejecting the query, we throw a {{ClassCastException}}
> while trying to evaluate the condition:
> {noformat}
> org.apache.geode.cache.query.TypeMismatchException: Unable to use a
> relational comparison operator to compare an instance of class '
> org.apache.geode.cache.query.internal.aggregate.XXX ' with an instance of '
> java.lang.XXX '
> at
> org.apache.geode.cache.query.internal.types.TypeUtils$ComparisonStrategy.get(TypeUtils.java:144)
> at
> org.apache.geode.cache.query.internal.types.TypeUtils.compare(TypeUtils.java:499)
> at
> org.apache.geode.cache.query.internal.CompiledComparison.evaluate(CompiledComparison.java:137)
> at
> org.apache.geode.cache.query.internal.CompiledSelect.evaluate(CompiledSelect.java:438)
> at
> org.apache.geode.cache.query.internal.CompiledSelect.evaluate(CompiledSelect.java:53)
> at
> org.apache.geode.cache.query.internal.DefaultQuery.executeUsingContext(DefaultQuery.java:432)
> at
> org.apache.geode.cache.query.internal.DefaultQuery.execute(DefaultQuery.java:267)
> at
> org.apache.geode.cache.query.internal.DefaultQuery.execute(DefaultQuery.java:199)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-7240) Prevent Usage of Aggregates within WHERE clause
Juan José Ramos Cassella created GEODE-7240:
---
Summary: Prevent Usage of Aggregates within WHERE clause
Key: GEODE-7240
URL: https://issues.apache.org/jira/browse/GEODE-7240
Project: Geode
Issue Type: Bug
Components: querying
Reporter: Juan José Ramos Cassella
Aggregate functions shouldn't be allowed as part of the {{WHERE}} clause.
Currently, instead of rejecting the query, we throw a {{ClassCastException}}
while trying to evaluate the condition:
{noformat}
org.apache.geode.cache.query.TypeMismatchException: Unable to use a relational
comparison operator to compare an instance of class '
org.apache.geode.cache.query.internal.aggregate.XXX ' with an instance of '
java.lang.XXX '
at
org.apache.geode.cache.query.internal.types.TypeUtils$ComparisonStrategy.get(TypeUtils.java:144)
at
org.apache.geode.cache.query.internal.types.TypeUtils.compare(TypeUtils.java:499)
at
org.apache.geode.cache.query.internal.CompiledComparison.evaluate(CompiledComparison.java:137)
at
org.apache.geode.cache.query.internal.CompiledSelect.evaluate(CompiledSelect.java:438)
at
org.apache.geode.cache.query.internal.CompiledSelect.evaluate(CompiledSelect.java:53)
at
org.apache.geode.cache.query.internal.DefaultQuery.executeUsingContext(DefaultQuery.java:432)
at
org.apache.geode.cache.query.internal.DefaultQuery.execute(DefaultQuery.java:267)
at
org.apache.geode.cache.query.internal.DefaultQuery.execute(DefaultQuery.java:199)
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-7239) geode-core unit tests should not use log4j-core
[
https://issues.apache.org/jira/browse/GEODE-7239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-7239:
-
Component/s: tests
> geode-core unit tests should not use log4j-core
> ---
>
> Key: GEODE-7239
> URL: https://issues.apache.org/jira/browse/GEODE-7239
> Project: Geode
> Issue Type: Wish
> Components: tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
>
> The following classes in geode-core src/test should be rewritten to not use
> log4j-core:
> * ColocationHelperTest
> * GfshInitFileJUnitTest
> * ShowMissingDiskStoresFunctionJUnitTest
> {noformat}
> > Task :geode-core:compileTestJava
> /Users/klund/dev/gemfire/geode/geode-core/src/test/java/org/apache/geode/internal/cache/ColocationHelperTest.java:26:
> error: package org.apache.logging.log4j.core does not exist
> import org.apache.logging.log4j.core.Appender;
> ^
> /Users/klund/dev/gemfire/geode/geode-core/src/test/java/org/apache/geode/internal/cache/ColocationHelperTest.java:27:
> error: package org.apache.logging.log4j.core does not exist
> import org.apache.logging.log4j.core.LogEvent;
> ^
> /Users/klund/dev/gemfire/geode/geode-core/src/test/java/org/apache/geode/internal/cache/ColocationHelperTest.java:28:
> error: package org.apache.logging.log4j.core does not exist
> import org.apache.logging.log4j.core.Logger;
> ^
> /Users/klund/dev/gemfire/geode/geode-core/src/test/java/org/apache/geode/internal/cache/ColocationHelperTest.java:50:
> error: cannot find symbol
> private Logger logger;
> ^
> symbol: class Logger
> location: class ColocationHelperTest
> /Users/klund/dev/gemfire/geode/geode-core/src/test/java/org/apache/geode/internal/cache/ColocationHelperTest.java:51:
> error: cannot find symbol
> private Appender mockAppender;
> ^
> symbol: class Appender
> location: class ColocationHelperTest
> /Users/klund/dev/gemfire/geode/geode-core/src/test/java/org/apache/geode/internal/cache/ColocationHelperTest.java:52:
> error: cannot find symbol
> private ArgumentCaptor loggingEventCaptor;
> ^
> symbol: class LogEvent
> location: class ColocationHelperTest
> /Users/klund/dev/gemfire/geode/geode-core/src/test/java/org/apache/geode/management/internal/cli/shell/GfshInitFileJUnitTest.java:33:
> error: package org.apache.logging.log4j.core does not exist
> import org.apache.logging.log4j.core.LoggerContext;
> ^
> /Users/klund/dev/gemfire/geode/geode-core/src/test/java/org/apache/geode/management/internal/cli/shell/GfshInitFileJUnitTest.java:34:
> error: package org.apache.logging.log4j.core.config does not exist
> import org.apache.logging.log4j.core.config.ConfigurationFactory;
>^
> /Users/klund/dev/gemfire/geode/geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/ShowMissingDiskStoresFunctionJUnitTest.java:36:
> error: package org.apache.logging.log4j.core does not exist
> import org.apache.logging.log4j.core.Appender;
> ^
> /Users/klund/dev/gemfire/geode/geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/ShowMissingDiskStoresFunctionJUnitTest.java:37:
> error: package org.apache.logging.log4j.core does not exist
> import org.apache.logging.log4j.core.LogEvent;
> ^
> /Users/klund/dev/gemfire/geode/geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/ShowMissingDiskStoresFunctionJUnitTest.java:38:
> error: package org.apache.logging.log4j.core does not exist
> import org.apache.logging.log4j.core.Logger;
> ^
> /Users/klund/dev/gemfire/geode/geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/ShowMissingDiskStoresFunctionJUnitTest.java:71:
> error: cannot find symbol
> private Logger logger;
> ^
> symbol: class Logger
> location: class ShowMissingDiskStoresFunctionJUnitTest
> /Users/klund/dev/gemfire/geode/geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/ShowMissingDiskStoresFunctionJUnitTest.java:72:
> error: cannot find symbol
> private Appender mockAppender;
> ^
> symbol: class Appender
> location: class ShowMissingDiskStoresFunctionJUnitTest
> /Users/klund/dev/gemfire/geode/geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/ShowMissingDiskStoresFunctionJUnitTest.java:73:
> error: cannot find symbol
> private ArgumentCaptor loggingEventCaptor;
> ^
> symbol: class LogEvent
> location: class
[jira] [Assigned] (GEODE-7239) geode-core unit tests should not use log4j-core
[
https://issues.apache.org/jira/browse/GEODE-7239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund reassigned GEODE-7239:
Assignee: Kirk Lund
> geode-core unit tests should not use log4j-core
> ---
>
> Key: GEODE-7239
> URL: https://issues.apache.org/jira/browse/GEODE-7239
> Project: Geode
> Issue Type: Wish
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
>
> The following classes in geode-core src/test should be rewritten to not use
> log4j-core:
> * ColocationHelperTest
> * GfshInitFileJUnitTest
> * ShowMissingDiskStoresFunctionJUnitTest
> {noformat}
> > Task :geode-core:compileTestJava
> /Users/klund/dev/gemfire/geode/geode-core/src/test/java/org/apache/geode/internal/cache/ColocationHelperTest.java:26:
> error: package org.apache.logging.log4j.core does not exist
> import org.apache.logging.log4j.core.Appender;
> ^
> /Users/klund/dev/gemfire/geode/geode-core/src/test/java/org/apache/geode/internal/cache/ColocationHelperTest.java:27:
> error: package org.apache.logging.log4j.core does not exist
> import org.apache.logging.log4j.core.LogEvent;
> ^
> /Users/klund/dev/gemfire/geode/geode-core/src/test/java/org/apache/geode/internal/cache/ColocationHelperTest.java:28:
> error: package org.apache.logging.log4j.core does not exist
> import org.apache.logging.log4j.core.Logger;
> ^
> /Users/klund/dev/gemfire/geode/geode-core/src/test/java/org/apache/geode/internal/cache/ColocationHelperTest.java:50:
> error: cannot find symbol
> private Logger logger;
> ^
> symbol: class Logger
> location: class ColocationHelperTest
> /Users/klund/dev/gemfire/geode/geode-core/src/test/java/org/apache/geode/internal/cache/ColocationHelperTest.java:51:
> error: cannot find symbol
> private Appender mockAppender;
> ^
> symbol: class Appender
> location: class ColocationHelperTest
> /Users/klund/dev/gemfire/geode/geode-core/src/test/java/org/apache/geode/internal/cache/ColocationHelperTest.java:52:
> error: cannot find symbol
> private ArgumentCaptor loggingEventCaptor;
> ^
> symbol: class LogEvent
> location: class ColocationHelperTest
> /Users/klund/dev/gemfire/geode/geode-core/src/test/java/org/apache/geode/management/internal/cli/shell/GfshInitFileJUnitTest.java:33:
> error: package org.apache.logging.log4j.core does not exist
> import org.apache.logging.log4j.core.LoggerContext;
> ^
> /Users/klund/dev/gemfire/geode/geode-core/src/test/java/org/apache/geode/management/internal/cli/shell/GfshInitFileJUnitTest.java:34:
> error: package org.apache.logging.log4j.core.config does not exist
> import org.apache.logging.log4j.core.config.ConfigurationFactory;
>^
> /Users/klund/dev/gemfire/geode/geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/ShowMissingDiskStoresFunctionJUnitTest.java:36:
> error: package org.apache.logging.log4j.core does not exist
> import org.apache.logging.log4j.core.Appender;
> ^
> /Users/klund/dev/gemfire/geode/geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/ShowMissingDiskStoresFunctionJUnitTest.java:37:
> error: package org.apache.logging.log4j.core does not exist
> import org.apache.logging.log4j.core.LogEvent;
> ^
> /Users/klund/dev/gemfire/geode/geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/ShowMissingDiskStoresFunctionJUnitTest.java:38:
> error: package org.apache.logging.log4j.core does not exist
> import org.apache.logging.log4j.core.Logger;
> ^
> /Users/klund/dev/gemfire/geode/geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/ShowMissingDiskStoresFunctionJUnitTest.java:71:
> error: cannot find symbol
> private Logger logger;
> ^
> symbol: class Logger
> location: class ShowMissingDiskStoresFunctionJUnitTest
> /Users/klund/dev/gemfire/geode/geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/ShowMissingDiskStoresFunctionJUnitTest.java:72:
> error: cannot find symbol
> private Appender mockAppender;
> ^
> symbol: class Appender
> location: class ShowMissingDiskStoresFunctionJUnitTest
> /Users/klund/dev/gemfire/geode/geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/ShowMissingDiskStoresFunctionJUnitTest.java:73:
> error: cannot find symbol
> private ArgumentCaptor loggingEventCaptor;
> ^
> symbol: class LogEvent
> location: class ShowMissingDiskStoresFunctionJUnitTest
> 14 errors
>
[jira] [Created] (GEODE-7239) geode-core unit tests should not use log4j-core
Kirk Lund created GEODE-7239:
Summary: geode-core unit tests should not use log4j-core
Key: GEODE-7239
URL: https://issues.apache.org/jira/browse/GEODE-7239
Project: Geode
Issue Type: Wish
Reporter: Kirk Lund
The following classes in geode-core src/test should be rewritten to not use
log4j-core:
* ColocationHelperTest
* GfshInitFileJUnitTest
* ShowMissingDiskStoresFunctionJUnitTest
{noformat}
> Task :geode-core:compileTestJava
/Users/klund/dev/gemfire/geode/geode-core/src/test/java/org/apache/geode/internal/cache/ColocationHelperTest.java:26:
error: package org.apache.logging.log4j.core does not exist
import org.apache.logging.log4j.core.Appender;
^
/Users/klund/dev/gemfire/geode/geode-core/src/test/java/org/apache/geode/internal/cache/ColocationHelperTest.java:27:
error: package org.apache.logging.log4j.core does not exist
import org.apache.logging.log4j.core.LogEvent;
^
/Users/klund/dev/gemfire/geode/geode-core/src/test/java/org/apache/geode/internal/cache/ColocationHelperTest.java:28:
error: package org.apache.logging.log4j.core does not exist
import org.apache.logging.log4j.core.Logger;
^
/Users/klund/dev/gemfire/geode/geode-core/src/test/java/org/apache/geode/internal/cache/ColocationHelperTest.java:50:
error: cannot find symbol
private Logger logger;
^
symbol: class Logger
location: class ColocationHelperTest
/Users/klund/dev/gemfire/geode/geode-core/src/test/java/org/apache/geode/internal/cache/ColocationHelperTest.java:51:
error: cannot find symbol
private Appender mockAppender;
^
symbol: class Appender
location: class ColocationHelperTest
/Users/klund/dev/gemfire/geode/geode-core/src/test/java/org/apache/geode/internal/cache/ColocationHelperTest.java:52:
error: cannot find symbol
private ArgumentCaptor loggingEventCaptor;
^
symbol: class LogEvent
location: class ColocationHelperTest
/Users/klund/dev/gemfire/geode/geode-core/src/test/java/org/apache/geode/management/internal/cli/shell/GfshInitFileJUnitTest.java:33:
error: package org.apache.logging.log4j.core does not exist
import org.apache.logging.log4j.core.LoggerContext;
^
/Users/klund/dev/gemfire/geode/geode-core/src/test/java/org/apache/geode/management/internal/cli/shell/GfshInitFileJUnitTest.java:34:
error: package org.apache.logging.log4j.core.config does not exist
import org.apache.logging.log4j.core.config.ConfigurationFactory;
^
/Users/klund/dev/gemfire/geode/geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/ShowMissingDiskStoresFunctionJUnitTest.java:36:
error: package org.apache.logging.log4j.core does not exist
import org.apache.logging.log4j.core.Appender;
^
/Users/klund/dev/gemfire/geode/geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/ShowMissingDiskStoresFunctionJUnitTest.java:37:
error: package org.apache.logging.log4j.core does not exist
import org.apache.logging.log4j.core.LogEvent;
^
/Users/klund/dev/gemfire/geode/geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/ShowMissingDiskStoresFunctionJUnitTest.java:38:
error: package org.apache.logging.log4j.core does not exist
import org.apache.logging.log4j.core.Logger;
^
/Users/klund/dev/gemfire/geode/geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/ShowMissingDiskStoresFunctionJUnitTest.java:71:
error: cannot find symbol
private Logger logger;
^
symbol: class Logger
location: class ShowMissingDiskStoresFunctionJUnitTest
/Users/klund/dev/gemfire/geode/geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/ShowMissingDiskStoresFunctionJUnitTest.java:72:
error: cannot find symbol
private Appender mockAppender;
^
symbol: class Appender
location: class ShowMissingDiskStoresFunctionJUnitTest
/Users/klund/dev/gemfire/geode/geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/ShowMissingDiskStoresFunctionJUnitTest.java:73:
error: cannot find symbol
private ArgumentCaptor loggingEventCaptor;
^
symbol: class LogEvent
location: class ShowMissingDiskStoresFunctionJUnitTest
14 errors
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7237) CI failure: ConnectCommandAcceptanceTest.invalidHostname
[
https://issues.apache.org/jira/browse/GEODE-7237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16937165#comment-16937165
]
Kirk Lund commented on GEODE-7237:
--
This is caused by a race condition in the implementation of GfshRule. After
forking the process, ProcessLogger is created to read the output from that
process. ProcessLogger uses log4j-core to reconfigure logging. Meanwhile, the
process may have already started printing output which has been missed which
causes the assertion in this bug to fail.
I cannot find any good reason for ProcessLogger to actually need to use
log4j-core to reconfigure logging. If I change it to just grab a logger without
reconfiguring log4j, the test runs must faster and passes consistently.
> CI failure: ConnectCommandAcceptanceTest.invalidHostname
>
>
> Key: GEODE-7237
> URL: https://issues.apache.org/jira/browse/GEODE-7237
> Project: Geode
> Issue Type: Bug
> Components: ci, tests
>Reporter: Aaron Lindsey
>Assignee: Kirk Lund
>Priority: Major
>
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/AcceptanceTestOpenJDK8/builds/1101]
> {code:java}
> org.apache.geode.management.internal.cli.commands.ConnectCommandAcceptanceTest
> > invalidHostname FAILED
> java.lang.AssertionError:
> Expecting:
> <"">
> to contain:
> <"can't be reached. Hostname or IP address could not be found.">
> at
> org.apache.geode.management.internal.cli.commands.ConnectCommandAcceptanceTest.invalidHostname(ConnectCommandAcceptanceTest.java:59)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-6601) CI Failure: Timeout in LuceneIndexDestroyDUnitTest verifyDestroyAllIndexesWhileDoingPuts(PARTITION_OVERFLOW_TO_DISK)
[ https://issues.apache.org/jira/browse/GEODE-6601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey reassigned GEODE-6601: Assignee: (was: xiaojian zhou) > CI Failure: Timeout in LuceneIndexDestroyDUnitTest > verifyDestroyAllIndexesWhileDoingPuts(PARTITION_OVERFLOW_TO_DISK) > > > Key: GEODE-6601 > URL: https://issues.apache.org/jira/browse/GEODE-6601 > Project: Geode > Issue Type: Bug >Reporter: Helena Bales >Priority: Major > > DistributedTestJDK11 failed due to timeout with a hang in > org.apache.geode.cache.lucene.LuceneIndexDestroyDUnitTest > verifyDestroyAllIndexesWhileDoingPuts(PARTITION_OVERFLOW_TO_DISK). > CI Failure here: > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/579 > Test results here: > http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0137/test-results/distributedTest/1554409876/ > Test artifacts here: > http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0137/test-artifacts/1554409876/distributedtestfiles-OpenJDK11-1.10.0-SNAPSHOT.0137.tgz -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-6601) CI Failure: Timeout in LuceneIndexDestroyDUnitTest verifyDestroyAllIndexesWhileDoingPuts(PARTITION_OVERFLOW_TO_DISK)
[ https://issues.apache.org/jira/browse/GEODE-6601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16937143#comment-16937143 ] Aaron Lindsey commented on GEODE-6601: -- I saw tests in LuceneIndexDestroyDUnitTest fail again today due to OOM errors. The SHA was dffcb9446aef09c7bf6e626121f4d2ec5c74586f. > CI Failure: Timeout in LuceneIndexDestroyDUnitTest > verifyDestroyAllIndexesWhileDoingPuts(PARTITION_OVERFLOW_TO_DISK) > > > Key: GEODE-6601 > URL: https://issues.apache.org/jira/browse/GEODE-6601 > Project: Geode > Issue Type: Bug >Reporter: Helena Bales >Assignee: xiaojian zhou >Priority: Major > > DistributedTestJDK11 failed due to timeout with a hang in > org.apache.geode.cache.lucene.LuceneIndexDestroyDUnitTest > verifyDestroyAllIndexesWhileDoingPuts(PARTITION_OVERFLOW_TO_DISK). > CI Failure here: > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/579 > Test results here: > http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0137/test-results/distributedTest/1554409876/ > Test artifacts here: > http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0137/test-artifacts/1554409876/distributedtestfiles-OpenJDK11-1.10.0-SNAPSHOT.0137.tgz -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-5407) CI failure: JMXMBeanReconnectDUnitTest.testRemoteBeanKnowledge_MaintainServerAndCrashLocator and testLocalBeans_MaintainServerAndCrashLocator
[ https://issues.apache.org/jira/browse/GEODE-5407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16937136#comment-16937136 ] Aaron Lindsey commented on GEODE-5407: -- Failed again: [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/1121] > CI failure: > JMXMBeanReconnectDUnitTest.testRemoteBeanKnowledge_MaintainServerAndCrashLocator > and testLocalBeans_MaintainServerAndCrashLocator > - > > Key: GEODE-5407 > URL: https://issues.apache.org/jira/browse/GEODE-5407 > Project: Geode > Issue Type: Bug >Reporter: Jinmei Liao >Priority: Major > Labels: flaky, pull-request-available, swat > Attachments: Test results - Class > org.apache.geode.management.JMXMBeanReconnectDUnitTest.html > > Time Spent: 2h 20m > Remaining Estimate: 0h > > org.apache.geode.management.JMXMBeanReconnectDUnitTest > > testRemoteBeanKnowledge_MaintainServerAndCrashLocator FAILED > [ > |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/103#L5b401925:249] > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.test.dunit.rules.MemberVM$$Lambda$73/2140274979.run in VM 0 > running on Host 640ab3da6905 with 4 VMs > [ > |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/103#L5b401925:250] > at org.apache.geode.test.dunit.VM.invoke(VM.java:436) > [ > |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/103#L5b401925:251] > at org.apache.geode.test.dunit.VM.invoke(VM.java:405) > [ > |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/103#L5b401925:252] > at org.apache.geode.test.dunit.VM.invoke(VM.java:348) > [ > |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/103#L5b401925:253] > at > org.apache.geode.test.dunit.rules.MemberVM.waitTilLocatorFullyReconnected(MemberVM.java:113) > [ > |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/103#L5b401925:254] > at > org.apache.geode.management.JMXMBeanReconnectDUnitTest.testRemoteBeanKnowledge_MaintainServerAndCrashLocator(JMXMBeanReconnectDUnitTest.java:161) > [ > |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/103#L5b401925:255] > > [ > |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/103#L5b401925:256] > Caused by: > [ > |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/103#L5b401925:257] > org.awaitility.core.ConditionTimeoutException: Condition with > org.apache.geode.test.dunit.rules.MemberVM was not fulfilled within 30 > seconds. > > org.apache.geode.management.JMXMBeanReconnectDUnitTest > > testLocalBeans_MaintainServerAndCrashLocator FAILED > [ > |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/103#L5b401925:260] > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.test.dunit.rules.MemberVM$$Lambda$73/2140274979.run in VM 0 > running on Host 640ab3da6905 with 4 VMs > [ > |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/103#L5b401925:261] > at org.apache.geode.test.dunit.VM.invoke(VM.java:436) > [ > |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/103#L5b401925:262] > at org.apache.geode.test.dunit.VM.invoke(VM.java:405) > [ > |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/103#L5b401925:263] > at org.apache.geode.test.dunit.VM.invoke(VM.java:348) > [ > |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/103#L5b401925:264] > at > org.apache.geode.test.dunit.rules.MemberVM.waitTilLocatorFullyReconnected(MemberVM.java:113) > [ > |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/103#L5b401925:265] > at > org.apache.geode.management.JMXMBeanReconnectDUnitTest.testLocalBeans_MaintainServerAndCrashLocator(JMXMBeanReconnectDUnitTest.java:112) > > Caused by: > [ > |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/103#L5b401925:268] > org.awaitility.core.ConditionTimeoutException: Condition with > org.apache.geode.test.dunit.rules.MemberVM was not fulfilled within 30 > seconds. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-6897) Create a REST v2 endpoint to do rebanlance
[ https://issues.apache.org/jira/browse/GEODE-6897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16937128#comment-16937128 ] ASF subversion and git services commented on GEODE-6897: Commit ee3049be9745324f2f643b54e54a515df0888db2 in geode's branch refs/heads/develop from Jinmei Liao [ https://gitbox.apache.org/repos/asf?p=geode.git;h=ee3049b ] GEODE-6897: revert accidental change of apidoc's link for dev rest api. (#4083) > Create a REST v2 endpoint to do rebanlance > -- > > Key: GEODE-6897 > URL: https://issues.apache.org/jira/browse/GEODE-6897 > Project: Geode > Issue Type: New Feature > Components: management >Reporter: Jinmei Liao >Assignee: Owen Nichols >Priority: Major > Fix For: 1.10.0 > > Time Spent: 35h > Remaining Estimate: 0h > > For the first iteration, we are: > 1. make it an async request > 2. have an endpoint to check status of this request > 3. keep the rebalance operation status in memory only > 4. Can do one rebalance at a time, ignore the concurrent rebalance request > 5. do not implement cancel operation yet. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-7238) Upgrade Lucene from 6.6.2 to 8.2.0 in Apache Geode 1.9.0
Ajay Vasudevan created GEODE-7238:
-
Summary: Upgrade Lucene from 6.6.2 to 8.2.0 in Apache Geode 1.9.0
Key: GEODE-7238
URL: https://issues.apache.org/jira/browse/GEODE-7238
Project: Geode
Issue Type: Improvement
Components: lucene
Reporter: Ajay Vasudevan
Fix For: 1.9.0
Lucene version in Apache geode 1.9.0 is locked down to 6.6.2 and hence I am not
able to create a LatLonPoint type lucene document. LatLongPoint lucene document
can be created on lucene version 7.5.0 and above. Upgrading lucene core version
to 8.2.0 throws AbstractMethodError. Please find stackoverflow query :
{color:#0747a6}https://stackoverflow.com/questions/58049566/upgrade-lucene-from-6-6-2-to-8-2-0-in-apache-geode-1-9-0{color}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-7237) CI failure: ConnectCommandAcceptanceTest.invalidHostname
[
https://issues.apache.org/jira/browse/GEODE-7237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Lindsey reassigned GEODE-7237:
Assignee: Kirk Lund (was: Aaron Lindsey)
> CI failure: ConnectCommandAcceptanceTest.invalidHostname
>
>
> Key: GEODE-7237
> URL: https://issues.apache.org/jira/browse/GEODE-7237
> Project: Geode
> Issue Type: Bug
> Components: ci, tests
>Reporter: Aaron Lindsey
>Assignee: Kirk Lund
>Priority: Major
>
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/AcceptanceTestOpenJDK8/builds/1101]
> {code:java}
> org.apache.geode.management.internal.cli.commands.ConnectCommandAcceptanceTest
> > invalidHostname FAILED
> java.lang.AssertionError:
> Expecting:
> <"">
> to contain:
> <"can't be reached. Hostname or IP address could not be found.">
> at
> org.apache.geode.management.internal.cli.commands.ConnectCommandAcceptanceTest.invalidHostname(ConnectCommandAcceptanceTest.java:59)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-7237) CI failure: ConnectCommandAcceptanceTest.invalidHostname
[
https://issues.apache.org/jira/browse/GEODE-7237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Lindsey reassigned GEODE-7237:
Assignee: Aaron Lindsey
> CI failure: ConnectCommandAcceptanceTest.invalidHostname
>
>
> Key: GEODE-7237
> URL: https://issues.apache.org/jira/browse/GEODE-7237
> Project: Geode
> Issue Type: Bug
> Components: ci, tests
>Reporter: Aaron Lindsey
>Assignee: Aaron Lindsey
>Priority: Major
>
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/AcceptanceTestOpenJDK8/builds/1101]
> {code:java}
> org.apache.geode.management.internal.cli.commands.ConnectCommandAcceptanceTest
> > invalidHostname FAILED
> java.lang.AssertionError:
> Expecting:
> <"">
> to contain:
> <"can't be reached. Hostname or IP address could not be found.">
> at
> org.apache.geode.management.internal.cli.commands.ConnectCommandAcceptanceTest.invalidHostname(ConnectCommandAcceptanceTest.java:59)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-7237) CI failure: ConnectCommandAcceptanceTest.invalidHostname
Aaron Lindsey created GEODE-7237:
Summary: CI failure: ConnectCommandAcceptanceTest.invalidHostname
Key: GEODE-7237
URL: https://issues.apache.org/jira/browse/GEODE-7237
Project: Geode
Issue Type: Bug
Components: ci, tests
Reporter: Aaron Lindsey
[https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/AcceptanceTestOpenJDK8/builds/1101]
{code:java}
org.apache.geode.management.internal.cli.commands.ConnectCommandAcceptanceTest
> invalidHostname FAILED
java.lang.AssertionError:
Expecting:
<"">
to contain:
<"can't be reached. Hostname or IP address could not be found.">
at
org.apache.geode.management.internal.cli.commands.ConnectCommandAcceptanceTest.invalidHostname(ConnectCommandAcceptanceTest.java:59)
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-7152) AlertAppender recursion causes ForcedDisconnect to hang
[
https://issues.apache.org/jira/browse/GEODE-7152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund resolved GEODE-7152.
--
Fix Version/s: 1.11.0
Resolution: Fixed
Geode now uses a background ExecutorService to send Alerts in response to
AlertAppender events. This moves the responsibility for detecting and
preventing recursion back to Geode instead of Log4j.
> AlertAppender recursion causes ForcedDisconnect to hang
> ---
>
> Key: GEODE-7152
> URL: https://issues.apache.org/jira/browse/GEODE-7152
> Project: Geode
> Issue Type: Bug
> Components: management
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Fix For: 1.11.0
>
>
> AlertAppender uses a ThreadLocal to prevent recursive calls from actually
> doing anything. However, a recent upgrade to our log4j dependencies seems to
> have changed the behavior such that log4j refuses to invoke {{doAppend}} if
> the thread is currently handling a {{sendAlert}} initiated from {{doAppend}}.
> To fix this bug, we will need to change {{sendAlert}} to be asynchronous.
> In this run we are expecting ForcedDisconnects, but they don't occur until
> after the hang is declared.
> The appearance of these "Recursive call to appender" messages is new:
> {noformat}
> wan_bridgeNetworkPartition1-0812-213411/bgexec15919_14066.log: 2019-08-12
> 21:37:47,554 Geode Failure Detection thread 6 ERROR Recursive call to
> appender ALERT
> {noformat}
> \*** Test is dropping the network
> {noformat}
> wan_bridgeNetworkPartition1-0812-213411/vm_9_locator_1_2_host2_13435.log:
> [info 2019/08/12 21:37:46.265 PDT
> tid=0x94] Dropping network connection from
> rs-FullRegression13040513a0i3large-hydra-client-46 to
> rs-FullRegression13040513a0i3large-hydra-client-1 and from
> rs-FullRegression13040513a0i3large-hydra-client-1 to
> rs-FullRegression13040513a0i3large-hydra-client-46
> {noformat}
> \*** Here are the appender messages
> {noformat}
> wan_bridgeNetworkPartition1-0812-213411/bgexec15919_14066.log: 2019-08-12
> 21:37:47,554 Geode Failure Detection thread 6 ERROR Recursive call to
> appender ALERT
> wan_bridgeNetworkPartition1-0812-213411/bgexec15919_14066.log: 2019-08-12
> 21:37:47,554 Geode Failure Detection thread 4 ERROR Recursive call to
> appender ALERT
> wan_bridgeNetworkPartition1-0812-213411/bgexec15919_14066.log: 2019-08-12
> 21:37:47,554 Geode Failure Detection thread 5 ERROR Recursive call to
> appender ALERT
> wan_bridgeNetworkPartition1-0812-213411/bgexec15919_14066.log: 2019-08-12
> 21:37:47,556 Geode Failure Detection thread 5 ERROR Recursive call to
> appender ALERT
> wan_bridgeNetworkPartition1-0812-213411/bgexec15919_14066.log: 2019-08-12
> 21:37:47,558 Geode Failure Detection thread 4 ERROR Recursive call to
> appender ALERT
> wan_bridgeNetworkPartition1-0812-213411/bgexec15919_14066.log: 2019-08-12
> 21:37:47,559 Geode Failure Detection thread 4 ERROR Recursive call to
> appender ALERT
> {noformat}
> \*** network is dropped
> {noformat}
> wan_bridgeNetworkPartition1-0812-213411/vm_9_locator_1_2_host2_13435.log:
> [info 2019/08/12 21:37:47.136 PDT
> tid=0x94] Dropped network connection from
> rs-FullRegression13040513a0i3large-hydra-client-46 to
> rs-FullRegression13040513a0i3large-hydra-client-1 and from
> rs-FullRegression13040513a0i3large-hydra-client-1 to
> rs-FullRegression13040513a0i3large-hydra-client-46
> {noformat}
> \*** hang is declared
> {noformat}
> wan_bridgeNetworkPartition1-0812-213411/taskmaster_15326.log: [severe
> 2019/08/12 21:40:44.626 PDT tid=0x1] Result for
> vm_12_thr_16_wan1Lose_host1_14084: TASK[0]
> splitBrain.NetworkPartitionTest.HydraTask_doEntryOperations: HANG a client
> exceeded max result wait sec: 180
> {noformat}
> \*** now we see ForcedDisconnects
> {noformat}
> [fatal 2019/08/12 21:40:57.826 PDT receiver,rs-FullRegression13040513a0i3large-hydra-client-46-43284> tid=0x24]
> Membership service failure: Membership coordinator
> 10.32.110.145(gemfire3_host1_14066:14066:locator):41000 has declared
> that a network partition has occurred
> org.apache.geode.ForcedDisconnectException: Membership coordinator
> 10.32.110.145(gemfire3_host1_14066:14066:locator):41000 has declared
> that a network partition has occurred
> at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.forceDisconnect(GMSMembershipManager.java:2506)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.forceDisconnect(GMSJoinLeave.java:1106)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.processMessage(GMSJoinLeave.java:1481)
> at
>
[jira] [Resolved] (GEODE-6964) Log4j configuration can be altered by adding geode-core to the classpath
[
https://issues.apache.org/jira/browse/GEODE-6964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund resolved GEODE-6964.
--
Fix Version/s: 1.11.0
Resolution: Fixed
All classes that use *log4j-core* have now moved to the new module
*geode-log4j* on develop. The default log4j2.xml configuration file for Geode
Locators and Servers has also moved to geode-log4j.
The first Geode release expected to include this change is 1.11.0.
The geode-log4j module is included in geode-dependencies.jar so that Locators
and Servers will continue to use the code and configuration in geode-log4j by
default. It is also included in the classpath of most _*integrationTest*_ and
_*distributedTest*_ targets to facilitate non-unit test debugging, support
_dunit grep for suspect strings_, and also to avoid moving or changing tests
that involve or require Geode Alerting or Logging functionality.
Precheckin was {color:#57D9A3}GREEN{color} before merging to develop, so all
Geode tests should be unaffected.
*A. The effects of not having geode-log4j on the classpath
(client/server/locator) are:*
1) Log4j will not be configurable by Geode
2) Log4j will print out an error message if not configured by User or Geode
This is printed out by Apache Log4j (not by Geode):
{noformat}
ERROR StatusLogger No Log4j 2 configuration file found. Using default
configuration (logging only errors to the console), or user programmatically
provided configurations. Set system property 'log4j2.debug' to show Log4j 2
internal initialization logging. See
https://logging.apache.org/log4j/2.x/manual/configuration.html for instructions
on how to configure Log4j 2
{noformat}
3) Geode will not create a log file by default (when starting a server or
locator using GFSH)
4) Logging configuration properties do nothing
Logging configuration properties include:
* log-disk-space-limit
* log-file
* log-file-size-limit
* log-level
5) Geode Alerts will never be generated
Geode Alerts are exposed primarily exposed via:
* DistributedSystemMXBean JMX Notifications
* Viewable in Pulse (via DistributedSystemMXBean)
* (Deprecated) Admin API support for Alert Listening
6) GFSH commands or options involving Logging and Alerting do nothing
GFSH commands or options involving Logging and Alerting:
* alter runtime (log-disk-space-limit, log-file, log-file-size-limit, log-level)
* export logs
* show log
* start locator (log-level, redirect-output)
* start server (log-level, redirect-output)
*B. The primary reasons a user might not include geode-log4j in their
classpath:*
a) User wants to use Logback or other backend instead of log4j-core (especially
true for users of Spring Boot)
b) User wants greater control over logging, especially in a client or embedded
application
Since Geode uses log4j-api Loggers for its internal logging, swapping out
log4j-core for logback as the backend imposes a significant performance
penalty. Although, the logging APIs and backends are interchangeable, using the
intended backend with its matching API provides the best performance for both
log4j-api/log4j-core and slf4j/logback.
C. Impact on IDE usage
IntelliJ projects for Geode should automatically pull in geode-log4j when it
re-imports from gradle. Note that may see warnings about _*"No Log4j 2
configuration file found."*_ if you're running a test that doesn't have
geode-log4j on its classpath.
For more advanced projects in IntelliJ with additional non-Geode modules, you
might benefit from using *-Dclasspath* (or other proprietary/environment
options) in *Gradle VM options*.
The commit on develop:
{noformat}
commit efc2362d2bae0877a427ce2c29beae94118d6567
Author: Kirk Lund
Date: Thu Aug 8 15:17:54 2019 -0700
GEODE-6964: Move geode log4j core classes to geode-log4j
Introduce new Logging and Alerting SPIs. Extract all log4j-core code to
geode-log4j module.
The geode-core module no longer contains log4j2.xml and no longer has a
dependency on log4j-core.
All code that uses log4j-core has moved to the new module geode-log4j.
The log4j2.xml for Geode now lives in geode-log4j as well. These
changes ensure that users have better control over logging including
which backend to use. This should improve user experience when using
Spring Boot.
Co-authored-by: Mark Hanson
{noformat}
Let me know if there are any questions or if anyone runs into anything
interesting because of these changes.
> Log4j configuration can be altered by adding geode-core to the classpath
>
>
> Key: GEODE-6964
> URL: https://issues.apache.org/jira/browse/GEODE-6964
> Project: Geode
> Issue Type: Bug
> Components: logging
>Affects Versions: 1.0.0-incubating, 1.1.0, 1.1.1, 1.2.0, 1.3.0, 1.2.1,
> 1.4.0, 1.5.0, 1.6.0,
[jira] [Commented] (GEODE-6903) CI Failure: GemFireTransactionDataSourceIntegrationTest.testExceptionHandlingGetConnection failed with Assertion
[
https://issues.apache.org/jira/browse/GEODE-6903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16937014#comment-16937014
]
Aaron Lindsey commented on GEODE-6903:
--
Failed again today with SHA 802687154131af16d350bf39d152feb4685ba7e6
{code:java}
org.apache.geode.internal.datasource.GemFireTransactionDataSourceIntegrationTest
> testExceptionHandlingGetConnection FAILED
org.junit.ComparisonFailure: expected:<[0]> but was:<[2]>
at sun.reflect.GeneratedConstructorAccessor26.newInstance(Unknown Source)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at
org.apache.geode.internal.datasource.GemFireTransactionDataSourceIntegrationTest.testExceptionHandlingGetConnection(GemFireTransactionDataSourceIntegrationTest.java:149){code}
> CI Failure:
> GemFireTransactionDataSourceIntegrationTest.testExceptionHandlingGetConnection
> failed with Assertion
>
>
> Key: GEODE-6903
> URL: https://issues.apache.org/jira/browse/GEODE-6903
> Project: Geode
> Issue Type: Bug
> Components: transactions
>Reporter: Eric Shu
>Assignee: Mark Hanson
>Priority: Major
>
> org.apache.geode.internal.datasource.GemFireTransactionDataSourceIntegrationTest
> > testExceptionHandlingGetConnection FAILED
> org.junit.ComparisonFailure: expected:<[0]> but was:<[2]>
> at sun.reflect.GeneratedConstructorAccessor26.newInstance(Unknown
> Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.datasource.GemFireTransactionDataSourceIntegrationTest.testExceptionHandlingGetConnection(GemFireTransactionDataSourceIntegrationTest.java:141)
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0399/test-results/integrationTest/1561170841/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0399/test-artifacts/1561170841/integrationtestfiles-OpenJDK8-1.10.0-SNAPSHOT.0399.tgz
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7049) Add timeout parameter to Java client Execution::execute() methods
[
https://issues.apache.org/jira/browse/GEODE-7049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16936999#comment-16936999
]
ASF subversion and git services commented on GEODE-7049:
Commit b8b67694f19f0055f4cda226e5cf2e69860821ac in geode's branch
refs/heads/develop from Alberto Gomez
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=b8b6769 ]
Merge branch 'develop' into feature/GEODE-7049
> Add timeout parameter to Java client Execution::execute() methods
> --
>
> Key: GEODE-7049
> URL: https://issues.apache.org/jira/browse/GEODE-7049
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Alberto Gomez
>Assignee: Alberto Gomez
>Priority: Major
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> The Java client only allows to set a timeout to functions by means of a
> system property (gemfire.CLIENT_FUNCTION_TIMEOUT) while the C++ and C# native
> clients allow to pass a timeout parameter on a function execution basis.
> It will be good to have the same functionality on the Java client by means of
> having the following methods on the Execution interface:
>
> {code:java}
> ResultCollector execute(Function function, int timeoutMs) throws
> FunctionException;
> ResultCollector execute(String functionId, int timeoutMs) throws
> FunctionException;
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7049) Add timeout parameter to Java client Execution::execute() methods
[
https://issues.apache.org/jira/browse/GEODE-7049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16937002#comment-16937002
]
ASF subversion and git services commented on GEODE-7049:
Commit 2c512a701cd1a75f850146689fc447be03688c50 in geode's branch
refs/heads/develop from Dan Smith
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=2c512a7 ]
Merge pull request #3888 from Nordix/feature/GEODE-7049
GEODE-7049: Add timeout to Java client Execute::execute() methods
> Add timeout parameter to Java client Execution::execute() methods
> --
>
> Key: GEODE-7049
> URL: https://issues.apache.org/jira/browse/GEODE-7049
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Alberto Gomez
>Assignee: Alberto Gomez
>Priority: Major
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> The Java client only allows to set a timeout to functions by means of a
> system property (gemfire.CLIENT_FUNCTION_TIMEOUT) while the C++ and C# native
> clients allow to pass a timeout parameter on a function execution basis.
> It will be good to have the same functionality on the Java client by means of
> having the following methods on the Execution interface:
>
> {code:java}
> ResultCollector execute(Function function, int timeoutMs) throws
> FunctionException;
> ResultCollector execute(String functionId, int timeoutMs) throws
> FunctionException;
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7049) Add timeout parameter to Java client Execution::execute() methods
[
https://issues.apache.org/jira/browse/GEODE-7049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16937000#comment-16937000
]
ASF subversion and git services commented on GEODE-7049:
Commit 1b7edf0f0bab959dca225fdc9841c07bf1af34e3 in geode's branch
refs/heads/develop from Alberto Gomez
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=1b7edf0 ]
Merge branch 'GEODE-7049-new' into feature/GEODE-7049
> Add timeout parameter to Java client Execution::execute() methods
> --
>
> Key: GEODE-7049
> URL: https://issues.apache.org/jira/browse/GEODE-7049
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Alberto Gomez
>Assignee: Alberto Gomez
>Priority: Major
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> The Java client only allows to set a timeout to functions by means of a
> system property (gemfire.CLIENT_FUNCTION_TIMEOUT) while the C++ and C# native
> clients allow to pass a timeout parameter on a function execution basis.
> It will be good to have the same functionality on the Java client by means of
> having the following methods on the Execution interface:
>
> {code:java}
> ResultCollector execute(Function function, int timeoutMs) throws
> FunctionException;
> ResultCollector execute(String functionId, int timeoutMs) throws
> FunctionException;
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7049) Add timeout parameter to Java client Execution::execute() methods
[
https://issues.apache.org/jira/browse/GEODE-7049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16937001#comment-16937001
]
ASF subversion and git services commented on GEODE-7049:
Commit 1b7edf0f0bab959dca225fdc9841c07bf1af34e3 in geode's branch
refs/heads/develop from Alberto Gomez
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=1b7edf0 ]
Merge branch 'GEODE-7049-new' into feature/GEODE-7049
> Add timeout parameter to Java client Execution::execute() methods
> --
>
> Key: GEODE-7049
> URL: https://issues.apache.org/jira/browse/GEODE-7049
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Alberto Gomez
>Assignee: Alberto Gomez
>Priority: Major
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> The Java client only allows to set a timeout to functions by means of a
> system property (gemfire.CLIENT_FUNCTION_TIMEOUT) while the C++ and C# native
> clients allow to pass a timeout parameter on a function execution basis.
> It will be good to have the same functionality on the Java client by means of
> having the following methods on the Execution interface:
>
> {code:java}
> ResultCollector execute(Function function, int timeoutMs) throws
> FunctionException;
> ResultCollector execute(String functionId, int timeoutMs) throws
> FunctionException;
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7049) Add timeout parameter to Java client Execution::execute() methods
[
https://issues.apache.org/jira/browse/GEODE-7049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16936995#comment-16936995
]
ASF subversion and git services commented on GEODE-7049:
Commit 66e327cc37bfbccde5204d6cc486d4f4e8043e6f in geode's branch
refs/heads/develop from Alberto Gomez
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=66e327c ]
GEODE-7049: add TimeUnit param to executeFunction methods and handle smaller
than 1ms values and greater than Integer.MAX_VALUE ms
> Add timeout parameter to Java client Execution::execute() methods
> --
>
> Key: GEODE-7049
> URL: https://issues.apache.org/jira/browse/GEODE-7049
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Alberto Gomez
>Assignee: Alberto Gomez
>Priority: Major
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> The Java client only allows to set a timeout to functions by means of a
> system property (gemfire.CLIENT_FUNCTION_TIMEOUT) while the C++ and C# native
> clients allow to pass a timeout parameter on a function execution basis.
> It will be good to have the same functionality on the Java client by means of
> having the following methods on the Execution interface:
>
> {code:java}
> ResultCollector execute(Function function, int timeoutMs) throws
> FunctionException;
> ResultCollector execute(String functionId, int timeoutMs) throws
> FunctionException;
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7049) Add timeout parameter to Java client Execution::execute() methods
[
https://issues.apache.org/jira/browse/GEODE-7049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16937003#comment-16937003
]
ASF subversion and git services commented on GEODE-7049:
Commit 2c512a701cd1a75f850146689fc447be03688c50 in geode's branch
refs/heads/develop from Dan Smith
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=2c512a7 ]
Merge pull request #3888 from Nordix/feature/GEODE-7049
GEODE-7049: Add timeout to Java client Execute::execute() methods
> Add timeout parameter to Java client Execution::execute() methods
> --
>
> Key: GEODE-7049
> URL: https://issues.apache.org/jira/browse/GEODE-7049
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Alberto Gomez
>Assignee: Alberto Gomez
>Priority: Major
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> The Java client only allows to set a timeout to functions by means of a
> system property (gemfire.CLIENT_FUNCTION_TIMEOUT) while the C++ and C# native
> clients allow to pass a timeout parameter on a function execution basis.
> It will be good to have the same functionality on the Java client by means of
> having the following methods on the Execution interface:
>
> {code:java}
> ResultCollector execute(Function function, int timeoutMs) throws
> FunctionException;
> ResultCollector execute(String functionId, int timeoutMs) throws
> FunctionException;
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7049) Add timeout parameter to Java client Execution::execute() methods
[
https://issues.apache.org/jira/browse/GEODE-7049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16936997#comment-16936997
]
ASF subversion and git services commented on GEODE-7049:
Commit 8f1cfd6c90e6882b7ff22470f82d0322c1f89cd6 in geode's branch
refs/heads/develop from Alberto Gomez
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=8f1cfd6 ]
GEODE-7049: Change signature of execute with timeout methods to use a TimeUnit
param
> Add timeout parameter to Java client Execution::execute() methods
> --
>
> Key: GEODE-7049
> URL: https://issues.apache.org/jira/browse/GEODE-7049
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Alberto Gomez
>Assignee: Alberto Gomez
>Priority: Major
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> The Java client only allows to set a timeout to functions by means of a
> system property (gemfire.CLIENT_FUNCTION_TIMEOUT) while the C++ and C# native
> clients allow to pass a timeout parameter on a function execution basis.
> It will be good to have the same functionality on the Java client by means of
> having the following methods on the Execution interface:
>
> {code:java}
> ResultCollector execute(Function function, int timeoutMs) throws
> FunctionException;
> ResultCollector execute(String functionId, int timeoutMs) throws
> FunctionException;
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7049) Add timeout parameter to Java client Execution::execute() methods
[
https://issues.apache.org/jira/browse/GEODE-7049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16936998#comment-16936998
]
ASF subversion and git services commented on GEODE-7049:
Commit cd869a0395d22d98c3b3731b92679d311df913bf in geode's branch
refs/heads/develop from Alberto Gomez
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=cd869a0 ]
GEODE-7049: add TimeUnit param to executeFunction methods and handle smaller
than 1ms values and greater than Integer.MAX_VALUE ms
> Add timeout parameter to Java client Execution::execute() methods
> --
>
> Key: GEODE-7049
> URL: https://issues.apache.org/jira/browse/GEODE-7049
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Alberto Gomez
>Assignee: Alberto Gomez
>Priority: Major
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> The Java client only allows to set a timeout to functions by means of a
> system property (gemfire.CLIENT_FUNCTION_TIMEOUT) while the C++ and C# native
> clients allow to pass a timeout parameter on a function execution basis.
> It will be good to have the same functionality on the Java client by means of
> having the following methods on the Execution interface:
>
> {code:java}
> ResultCollector execute(Function function, int timeoutMs) throws
> FunctionException;
> ResultCollector execute(String functionId, int timeoutMs) throws
> FunctionException;
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7049) Add timeout parameter to Java client Execution::execute() methods
[
https://issues.apache.org/jira/browse/GEODE-7049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16936996#comment-16936996
]
ASF subversion and git services commented on GEODE-7049:
Commit 940fe4f232c99cbd04c3850a29e75270b0dd04bf in geode's branch
refs/heads/develop from Alberto Gomez
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=940fe4f ]
GEODE-7049: Add timeout to Java native client Execute::execute() methods
> Add timeout parameter to Java client Execution::execute() methods
> --
>
> Key: GEODE-7049
> URL: https://issues.apache.org/jira/browse/GEODE-7049
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Alberto Gomez
>Assignee: Alberto Gomez
>Priority: Major
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> The Java client only allows to set a timeout to functions by means of a
> system property (gemfire.CLIENT_FUNCTION_TIMEOUT) while the C++ and C# native
> clients allow to pass a timeout parameter on a function execution basis.
> It will be good to have the same functionality on the Java client by means of
> having the following methods on the Execution interface:
>
> {code:java}
> ResultCollector execute(Function function, int timeoutMs) throws
> FunctionException;
> ResultCollector execute(String functionId, int timeoutMs) throws
> FunctionException;
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-6964) Log4j configuration can be altered by adding geode-core to the classpath
[
https://issues.apache.org/jira/browse/GEODE-6964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16936960#comment-16936960
]
ASF subversion and git services commented on GEODE-6964:
Commit efc2362d2bae0877a427ce2c29beae94118d6567 in geode's branch
refs/heads/develop from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=efc2362 ]
GEODE-6964: Move geode log4j core classes to geode-log4j
Introduce new Logging and Alerting SPIs. Extract all log4j-core code to
geode-log4j module.
The geode-core module no longer contains log4j2.xml and no longer has a
dependency on log4j-core.
All code that uses log4j-core has moved to the new module geode-log4j.
The log4j2.xml for Geode now lives in geode-log4j as well. These
changes ensure that users have better control over logging including
which backend to use. This should improve user experience when using
Spring Boot.
Co-authored-by: Mark Hanson
> Log4j configuration can be altered by adding geode-core to the classpath
>
>
> Key: GEODE-6964
> URL: https://issues.apache.org/jira/browse/GEODE-6964
> Project: Geode
> Issue Type: Bug
> Components: logging
>Affects Versions: 1.0.0-incubating, 1.1.0, 1.1.1, 1.2.0, 1.3.0, 1.2.1,
> 1.4.0, 1.5.0, 1.6.0, 1.7.0, 1.8.0, 1.9.0, 1.9.1, 1.10.0
>Reporter: Stephane Nicoll
>Assignee: Kirk Lund
>Priority: Major
> Time Spent: 20h
> Remaining Estimate: 0h
>
> {{geode-core}} ships with a {{log4j2.xml}} at the standard location which
> means that it is a candidate for bootstraping the logging infrastructure of
> any app using that library. See also #GEODE-189
> This is a problem when embedding this library in application that relies on
> the absence of such a file to derive a sensible default configuration
> (typically a Spring Boot app).
> In general, the hard dependency on log4j is a bit annoying for the embedded
> use case. There is more context available here:
> https://github.com/spring-projects/spring-boot-data-geode/issues/42
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7152) AlertAppender recursion causes ForcedDisconnect to hang
[
https://issues.apache.org/jira/browse/GEODE-7152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16936961#comment-16936961
]
ASF subversion and git services commented on GEODE-7152:
Commit dffcb9446aef09c7bf6e626121f4d2ec5c74586f in geode's branch
refs/heads/develop from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=dffcb94 ]
GEODE-7152: Send alert messages using executor
AlertAppender uses a ThreadLocal to prevent recursive calls from
actually doing anything. However, a recent upgrade to our log4j
dependencies seems to have changed the behavior such that log4j refuses
to invoke doAppend if the thread is currently handling a sendAlert
initiated from doAppend. To fix this bug, sendAlert must be async.
> AlertAppender recursion causes ForcedDisconnect to hang
> ---
>
> Key: GEODE-7152
> URL: https://issues.apache.org/jira/browse/GEODE-7152
> Project: Geode
> Issue Type: Bug
> Components: management
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
>
> AlertAppender uses a ThreadLocal to prevent recursive calls from actually
> doing anything. However, a recent upgrade to our log4j dependencies seems to
> have changed the behavior such that log4j refuses to invoke {{doAppend}} if
> the thread is currently handling a {{sendAlert}} initiated from {{doAppend}}.
> To fix this bug, we will need to change {{sendAlert}} to be asynchronous.
> In this run we are expecting ForcedDisconnects, but they don't occur until
> after the hang is declared.
> The appearance of these "Recursive call to appender" messages is new:
> {noformat}
> wan_bridgeNetworkPartition1-0812-213411/bgexec15919_14066.log: 2019-08-12
> 21:37:47,554 Geode Failure Detection thread 6 ERROR Recursive call to
> appender ALERT
> {noformat}
> \*** Test is dropping the network
> {noformat}
> wan_bridgeNetworkPartition1-0812-213411/vm_9_locator_1_2_host2_13435.log:
> [info 2019/08/12 21:37:46.265 PDT
> tid=0x94] Dropping network connection from
> rs-FullRegression13040513a0i3large-hydra-client-46 to
> rs-FullRegression13040513a0i3large-hydra-client-1 and from
> rs-FullRegression13040513a0i3large-hydra-client-1 to
> rs-FullRegression13040513a0i3large-hydra-client-46
> {noformat}
> \*** Here are the appender messages
> {noformat}
> wan_bridgeNetworkPartition1-0812-213411/bgexec15919_14066.log: 2019-08-12
> 21:37:47,554 Geode Failure Detection thread 6 ERROR Recursive call to
> appender ALERT
> wan_bridgeNetworkPartition1-0812-213411/bgexec15919_14066.log: 2019-08-12
> 21:37:47,554 Geode Failure Detection thread 4 ERROR Recursive call to
> appender ALERT
> wan_bridgeNetworkPartition1-0812-213411/bgexec15919_14066.log: 2019-08-12
> 21:37:47,554 Geode Failure Detection thread 5 ERROR Recursive call to
> appender ALERT
> wan_bridgeNetworkPartition1-0812-213411/bgexec15919_14066.log: 2019-08-12
> 21:37:47,556 Geode Failure Detection thread 5 ERROR Recursive call to
> appender ALERT
> wan_bridgeNetworkPartition1-0812-213411/bgexec15919_14066.log: 2019-08-12
> 21:37:47,558 Geode Failure Detection thread 4 ERROR Recursive call to
> appender ALERT
> wan_bridgeNetworkPartition1-0812-213411/bgexec15919_14066.log: 2019-08-12
> 21:37:47,559 Geode Failure Detection thread 4 ERROR Recursive call to
> appender ALERT
> {noformat}
> \*** network is dropped
> {noformat}
> wan_bridgeNetworkPartition1-0812-213411/vm_9_locator_1_2_host2_13435.log:
> [info 2019/08/12 21:37:47.136 PDT
> tid=0x94] Dropped network connection from
> rs-FullRegression13040513a0i3large-hydra-client-46 to
> rs-FullRegression13040513a0i3large-hydra-client-1 and from
> rs-FullRegression13040513a0i3large-hydra-client-1 to
> rs-FullRegression13040513a0i3large-hydra-client-46
> {noformat}
> \*** hang is declared
> {noformat}
> wan_bridgeNetworkPartition1-0812-213411/taskmaster_15326.log: [severe
> 2019/08/12 21:40:44.626 PDT tid=0x1] Result for
> vm_12_thr_16_wan1Lose_host1_14084: TASK[0]
> splitBrain.NetworkPartitionTest.HydraTask_doEntryOperations: HANG a client
> exceeded max result wait sec: 180
> {noformat}
> \*** now we see ForcedDisconnects
> {noformat}
> [fatal 2019/08/12 21:40:57.826 PDT receiver,rs-FullRegression13040513a0i3large-hydra-client-46-43284> tid=0x24]
> Membership service failure: Membership coordinator
> 10.32.110.145(gemfire3_host1_14066:14066:locator):41000 has declared
> that a network partition has occurred
> org.apache.geode.ForcedDisconnectException: Membership coordinator
> 10.32.110.145(gemfire3_host1_14066:14066:locator):41000 has declared
> that a network partition has occurred
> at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.forceDisconnect(GMSMembershipManager.java:2506)
> at
>
[jira] [Commented] (GEODE-7165) GatewayReceiverImplTest may fail if a port in the test is in use
[
https://issues.apache.org/jira/browse/GEODE-7165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16936958#comment-16936958
]
ASF subversion and git services commented on GEODE-7165:
Commit 802687154131af16d350bf39d152feb4685ba7e6 in geode's branch
refs/heads/develop from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=8026871 ]
GEODE-7165: Remove networking dependency from GatewayReceiverImplTest (#4071)
The test was failing on machines with ports 2000 or 2001 in use.
This change replaces GatewayReceiverImpl's dependency on AvailablePort
with functions that are now injected by the unit tests.
> GatewayReceiverImplTest may fail if a port in the test is in use
>
>
> Key: GEODE-7165
> URL: https://issues.apache.org/jira/browse/GEODE-7165
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Time Spent: 2h
> Remaining Estimate: 0h
>
> GatewayReceiverImplTest may fail with a call stack like:
> {noformat}
> org.apache.geode.internal.cache.wan.GatewayReceiverImplTest >
> startShouldTryAllPortsInPortRangeIfIOExceptionIsThrown FAILED
> org.mockito.exceptions.verification.TooLittleActualInvocations:
> internalCacheServer.start();
> Wanted 101 times:
> -> at
> org.apache.geode.internal.cache.wan.GatewayReceiverImplTest.startShouldTryAllPortsInPortRangeIfIOExceptionIsThrown(GatewayReceiverImplTest.java:167)
> But was 100 times:
> -> at
> org.apache.geode.internal.cache.wan.GatewayReceiverImpl.tryToStart(GatewayReceiverImpl.java:157)
> -> at
> org.apache.geode.internal.cache.wan.GatewayReceiverImpl.tryToStart(GatewayReceiverImpl.java:157)
> -> at
> org.apache.geode.internal.cache.wan.GatewayReceiverImpl.tryToStart(GatewayReceiverImpl.java:157)
> -> at
> org.apache.geode.internal.cache.wan.GatewayReceiverImpl.tryToStart(GatewayReceiverImpl.java:157)
> -> at
> org.apache.geode.internal.cache.wan.GatewayReceiverImpl.tryToStart(GatewayReceiverImpl.java:157)
> {noformat}
> The test is assuming that only the underlying CacheServer will try the ports
> in the start-end port range. However, I just found this line of code in
> GatewayReceiverImpl:
> {noformat}
> private boolean tryToStart(int port) {
> if (!AvailablePort.isPortAvailable(port, SOCKET, getAddress(SOCKET))) {
> return false;
> }
> {noformat}
> The above early-out will test the availability of the port and exit without
> interacting with the mock CacheServer provided by the test. Thus, if any of
> the ports in the range are actually in use on the machine running the test,
> it will fail.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-7236) Fix Clang 'defaulted-function-deleted' and 'c++2a-compat' warnings
[ https://issues.apache.org/jira/browse/GEODE-7236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Bender updated GEODE-7236: Description: Repro steps: * Sync up to geode native `develop` branch on a Mac with latest Clang `Apple clang version 11.0.0 (clang-1100.0.33.8)` * Check top-level CMakeLists.txt and make sure these warnings are enabled, i.e. not turned off in `target_compile_options(_WarningsAsError INTERFACE` * Configure and build Geode Native Expected Result: * Geode Native builds to completion Actual Result: * Clang warns about these things, and the build fails due to WarningsAsError. These warnings have been disabled (GEODE-7325) to get the build back off the floor, but we need to provide the actual code fix and re-enable the warnings. was: Repro steps: * Sync up to geode native `develop` branch on a Mac with latest Clang `Apple clang version 11.0.0 (clang-1100.0.33.8)` * Check top-level CMakeLists.txt and make sure these warnings are enabled, i.e. not turned off in `target_compile_options(_WarningsAsError INTERFACE` * Configure and build Geode Native Expected Result: * Geode Native builds to completion Actual Result: * Clang warns about these things, and the build fails due to WarningsAsError. These warnings have been disabled to get the build back off the floor, but we need to provide the actual code fix and re-enable the warnings. > Fix Clang 'defaulted-function-deleted' and 'c++2a-compat' warnings > -- > > Key: GEODE-7236 > URL: https://issues.apache.org/jira/browse/GEODE-7236 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Blake Bender >Priority: Major > > Repro steps: > * Sync up to geode native `develop` branch on a Mac with latest Clang `Apple > clang version 11.0.0 (clang-1100.0.33.8)` > * Check top-level CMakeLists.txt and make sure these warnings are enabled, > i.e. not turned off in `target_compile_options(_WarningsAsError INTERFACE` > * Configure and build Geode Native > Expected Result: > * Geode Native builds to completion > Actual Result: > * Clang warns about these things, and the build fails due to WarningsAsError. > These warnings have been disabled (GEODE-7325) to get the build back off the > floor, but we need to provide the actual code fix and re-enable the warnings. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-7236) Fix Clang 'defaulted-function-deleted' and 'c++2a-compat' warnings
Blake Bender created GEODE-7236: --- Summary: Fix Clang 'defaulted-function-deleted' and 'c++2a-compat' warnings Key: GEODE-7236 URL: https://issues.apache.org/jira/browse/GEODE-7236 Project: Geode Issue Type: Bug Components: native client Reporter: Blake Bender Repro steps: * Sync up to geode native `develop` branch on a Mac with latest Clang `Apple clang version 11.0.0 (clang-1100.0.33.8)` * Check top-level CMakeLists.txt and make sure these warnings are enabled, i.e. not turned off in `target_compile_options(_WarningsAsError INTERFACE` * Configure and build Geode Native Expected Result: * Geode Native builds to completion Actual Result: * Clang warns about these things, and the build fails due to WarningsAsError. These warnings have been disabled to get the build back off the floor, but we need to provide the actual code fix and re-enable the warnings. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7234) Improve concourse task-image caching
[ https://issues.apache.org/jira/browse/GEODE-7234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16936944#comment-16936944 ] ASF subversion and git services commented on GEODE-7234: Commit 757b32958c6bc50461504056a54f85e8a48fe379 in geode's branch refs/heads/develop from Robert Houghton [ https://gitbox.apache.org/repos/asf?p=geode.git;h=757b329 ] GEODE-7234 Pull tools image into its own resource for better Concourse caching. Authored-by: Robert Houghton > Improve concourse task-image caching > > > Key: GEODE-7234 > URL: https://issues.apache.org/jira/browse/GEODE-7234 > Project: Geode > Issue Type: Improvement > Components: ci >Reporter: Robert Houghton >Priority: Major > Fix For: 1.11.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Using a Concourse resource to cache images used by tasks is more efficient > than using *image-resource* in the task definition itself. Do this wherever > possible to keep from downloading the same Docker image over and over again > in the same job. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7234) Improve concourse task-image caching
[ https://issues.apache.org/jira/browse/GEODE-7234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Houghton resolved GEODE-7234. Resolution: Fixed > Improve concourse task-image caching > > > Key: GEODE-7234 > URL: https://issues.apache.org/jira/browse/GEODE-7234 > Project: Geode > Issue Type: Improvement > Components: ci >Reporter: Robert Houghton >Priority: Major > Fix For: 1.11.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Using a Concourse resource to cache images used by tasks is more efficient > than using *image-resource* in the task definition itself. Do this wherever > possible to keep from downloading the same Docker image over and over again > in the same job. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-7235) Disable new Clang warnings to fix build for now
Blake Bender created GEODE-7235: --- Summary: Disable new Clang warnings to fix build for now Key: GEODE-7235 URL: https://issues.apache.org/jira/browse/GEODE-7235 Project: Geode Issue Type: Bug Components: native client Reporter: Blake Bender Apple pushed an XCode update a couple of days ago to version ` Apple clang version 11.0.0 (clang-1100.0.33.8)`. This version flags some new warnings in our code, and since we have warnings-as-errors turned on we blow up. Fixing these warnings is non-trivial, so we need to disable them in the top-level CMakeLists.txt and file another Jira issue to do the real fix. * Steps to repro: Sync up to the latest `develop` branch of Native Client on a Mac and build * Expected Result: Geode Native builds, and produces our libraries * Actual Result: Clang warns about "implicitly deleted copy/move ctors declared as default" in a product header, gives a warning about UTF-8 string literals in test code, then build fails. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-7234) Improve concourse task-image caching
Robert Houghton created GEODE-7234: -- Summary: Improve concourse task-image caching Key: GEODE-7234 URL: https://issues.apache.org/jira/browse/GEODE-7234 Project: Geode Issue Type: Improvement Components: ci Reporter: Robert Houghton Fix For: 1.11.0 Using a Concourse resource to cache images used by tasks is more efficient than using *image-resource* in the task definition itself. Do this wherever possible to keep from downloading the same Docker image over and over again in the same job. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7225) Update OpenSSL download URL in Windows Packer script
[ https://issues.apache.org/jira/browse/GEODE-7225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Bender resolved GEODE-7225. - Resolution: Fixed > Update OpenSSL download URL in Windows Packer script > > > Key: GEODE-7225 > URL: https://issues.apache.org/jira/browse/GEODE-7225 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Blake Bender >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > The Windows build of OpenSSL has bumped from 1.1c to 1.1d, and our download > script for Windows is now failing with 404 errors. Just need to change one > character in the URL and we're good to go. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-7225) Update OpenSSL download URL in Windows Packer script
[ https://issues.apache.org/jira/browse/GEODE-7225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Bender closed GEODE-7225. --- > Update OpenSSL download URL in Windows Packer script > > > Key: GEODE-7225 > URL: https://issues.apache.org/jira/browse/GEODE-7225 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Blake Bender >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > The Windows build of OpenSSL has bumped from 1.1c to 1.1d, and our download > script for Windows is now failing with 404 errors. Just need to change one > character in the URL and we're good to go. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-6766) Add reaper job for benchmark instances
[ https://issues.apache.org/jira/browse/GEODE-6766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Houghton resolved GEODE-6766. Resolution: Fixed > Add reaper job for benchmark instances > -- > > Key: GEODE-6766 > URL: https://issues.apache.org/jira/browse/GEODE-6766 > Project: Geode > Issue Type: Improvement > Components: ci >Reporter: Sean Goller >Priority: Major > Fix For: 1.10.0 > > Time Spent: 50m > Remaining Estimate: 0h > > Add a job that runs four times a day, which checks for free-roaming benchmark > clusters and destroys them. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-5380) Add PR pipeline to Geode
[ https://issues.apache.org/jira/browse/GEODE-5380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Houghton resolved GEODE-5380. Fix Version/s: 1.9.0 Resolution: Fixed > Add PR pipeline to Geode > > > Key: GEODE-5380 > URL: https://issues.apache.org/jira/browse/GEODE-5380 > Project: Geode > Issue Type: Improvement > Components: ci >Reporter: Sean Goller >Priority: Major > Labels: pull-request-available > Fix For: 1.9.0 > > Time Spent: 1.5h > Remaining Estimate: 0h > > Add PR pipeline to Geode that integrates with GitHub pull requests. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-5449) Create google cloud image suitable for running jobs
[ https://issues.apache.org/jira/browse/GEODE-5449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Houghton resolved GEODE-5449. Fix Version/s: 1.10.0 Resolution: Fixed > Create google cloud image suitable for running jobs > --- > > Key: GEODE-5449 > URL: https://issues.apache.org/jira/browse/GEODE-5449 > Project: Geode > Issue Type: Task > Components: ci >Reporter: Sean Goller >Priority: Major > Labels: pull-request-available > Fix For: 1.10.0 > > Time Spent: 50m > Remaining Estimate: 0h > > In order to run more complex jobs via concourse, we need a google cloud > instance image that can build geode and run tests. Establish the image and a > pipeline for building it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-5584) Switch concourse template generation from spruce to jinja
[ https://issues.apache.org/jira/browse/GEODE-5584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Houghton resolved GEODE-5584. Fix Version/s: 1.11.0 Resolution: Fixed > Switch concourse template generation from spruce to jinja > - > > Key: GEODE-5584 > URL: https://issues.apache.org/jira/browse/GEODE-5584 > Project: Geode > Issue Type: Task >Reporter: Finn Southerland >Priority: Major > Labels: pull-request-available > Fix For: 1.11.0 > > Time Spent: 20m > Remaining Estimate: 0h > > The meta scripts currently use spruce to assemble the other pipeline > templates. They should use jinja, because it is more readable and will be > easier to extend. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-7216) The ExportStackTraceCommand should include a timestamp similar to jstack
[
https://issues.apache.org/jira/browse/GEODE-7216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Kevo reassigned GEODE-7216:
-
Assignee: Mario Kevo
> The ExportStackTraceCommand should include a timestamp similar to jstack
>
>
> Key: GEODE-7216
> URL: https://issues.apache.org/jira/browse/GEODE-7216
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Barry Oglesby
>Assignee: Mario Kevo
>Priority: Major
>
> Currently the ExportStackTraceCommand dumps stack traces with a head for each
> member like:
> {noformat}
> *** Stack-trace for member server3 ***
> {noformat}
> It would be nice for support purposes if it included a timestamp like:
> {noformat}
> *** Stack-trace for member server3 at 2019-09-16 10:39:57 ***
> {noformat}
> That'll help correlate stack traces with logs and stats.
> Something like:
> {noformat}
> ps.append(STACK_TRACE_FOR_MEMBER).append(entry.getKey()).append(" at ")
> .append(new SimpleDateFormat("-MM-dd HH:mm:ss").format(new
> Date())).append(" ***")
> .append(System.lineSeparator());
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
