[jira] [Created] (GEODE-10386) Document JDK 17 for 1.15 release
Dave Barnes created GEODE-10386: --- Summary: Document JDK 17 for 1.15 release Key: GEODE-10386 URL: https://issues.apache.org/jira/browse/GEODE-10386 Project: Geode Issue Type: Improvement Components: docs Affects Versions: 1.15.0 Reporter: Dave Barnes Document JDK 17 for 1.5 release -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (GEODE-10386) Document JDK 17 for 1.15 release
[ https://issues.apache.org/jira/browse/GEODE-10386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Barnes reassigned GEODE-10386: --- Assignee: Max Hufnagel > Document JDK 17 for 1.15 release > > > Key: GEODE-10386 > URL: https://issues.apache.org/jira/browse/GEODE-10386 > Project: Geode > Issue Type: Improvement > Components: docs >Affects Versions: 1.15.0 >Reporter: Dave Barnes >Assignee: Max Hufnagel >Priority: Major > > Document JDK 17 for 1.5 release -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (GEODE-10385) User Guide: Remove bad G1 tuning advice
[ https://issues.apache.org/jira/browse/GEODE-10385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Barnes reassigned GEODE-10385: --- Assignee: Dave Barnes > User Guide: Remove bad G1 tuning advice > --- > > Key: GEODE-10385 > URL: https://issues.apache.org/jira/browse/GEODE-10385 > Project: Geode > Issue Type: Improvement > Components: docs >Affects Versions: 1.14.4 >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > > The "Managing Heap Memory" page provides some G1 tuning advice that is > actually detrimental to performance. The whole section needs some work, but > this passage, in particular, is wrong: > If you find the Apache Geode Resource Manager does not detect crossing the > eviction or critical threshold quickly enough, it has been observed that its > responsiveness is increased by reducing the default value of > --J-XX:MaxGCPauseMillis=VALUE JVM parameter (which is 200). Be sure to take > into account that this change also increases the amount of time spent in > garbage collection. > Cause: This advice was originally intended only to maximize performance of a > specific test case. It is NOT good advice for production systems. > https://geode.apache.org/docs/guide/114/managing/heap_use/heap_management.html > Short-term solution: delete the passage. > Long-term solution: Come up with some better ideas. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (GEODE-10385) User Guide: Remove bad G1 tuning advice
Dave Barnes created GEODE-10385: --- Summary: User Guide: Remove bad G1 tuning advice Key: GEODE-10385 URL: https://issues.apache.org/jira/browse/GEODE-10385 Project: Geode Issue Type: Improvement Components: docs Affects Versions: 1.14.4 Reporter: Dave Barnes The "Managing Heap Memory" page provides some G1 tuning advice that is actually detrimental to performance. The whole section needs some work, but this passage, in particular, is wrong: If you find the Apache Geode Resource Manager does not detect crossing the eviction or critical threshold quickly enough, it has been observed that its responsiveness is increased by reducing the default value of --J-XX:MaxGCPauseMillis=VALUE JVM parameter (which is 200). Be sure to take into account that this change also increases the amount of time spent in garbage collection. Cause: This advice was originally intended only to maximize performance of a specific test case. It is NOT good advice for production systems. https://geode.apache.org/docs/guide/114/managing/heap_use/heap_management.html Short-term solution: delete the passage. Long-term solution: Come up with some better ideas. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-849) GMSJoinLeaveJUnitTest.testNetworkPartitionMessage
[
https://issues.apache.org/jira/browse/GEODE-849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17554821#comment-17554821
]
Geode Integration commented on GEODE-849:
-
Seen in [windows-integration-test-openjdk8
#397|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/windows-integration-test-openjdk8/builds/397]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.16.0-build.0342/test-results/integrationTest/1655330320/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.16.0-build.0342/test-artifacts/1655330320/windows-integrationtestfiles-openjdk8-1.16.0-build.0342.tgz].
> GMSJoinLeaveJUnitTest.testNetworkPartitionMessage
> -
>
> Key: GEODE-849
> URL: https://issues.apache.org/jira/browse/GEODE-849
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Xiaojian Zhou
>Priority: Major
> Labels: CI
> Fix For: 1.0.0-incubating.M2, 1.10.0
>
>
> Revision: df274cc0fe8323f307e718a688e96bd7ff14288b
> IntegrationTests build 1477
> {noformat}
> Argument(s) are different! Wanted:
> messenger.send(
>
> isA(com.gemstone.gemfire.distributed.internal.membership.gms.messages.NetworkPartitionMessage)
> );
> -> at
> com.gemstone.gemfire.distributed.internal.membership.gms.membership.GMSJoinLeaveJUnitTest.testNetworkPartionMessage(GMSJoinLeaveJUnitTest.java:949)
> Actual invocation has different arguments:
> messenger.send(
> ViewAckMessage(recipients: ALL; 0; preparing=false; altview=null)
> );
> -> at
> com.gemstone.gemfire.distributed.internal.membership.gms.membership.GMSJoinLeave.ackView(GMSJoinLeave.java:824)
> at sun.reflect.GeneratedConstructorAccessor11.newInstance(Unknown
> Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
> at
> com.gemstone.gemfire.distributed.internal.membership.gms.membership.GMSJoinLeaveJUnitTest.testNetworkPartionMessage(GMSJoinLeaveJUnitTest.java:949)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:105)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:64)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:50)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
> at
>
[jira] [Resolved] (GEODE-10384) Improve logging with stack trace for gateway senders
[
https://issues.apache.org/jira/browse/GEODE-10384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jianxia Chen resolved GEODE-10384.
--
Fix Version/s: 1.16.0
Resolution: Fixed
> Improve logging with stack trace for gateway senders
>
>
> Key: GEODE-10384
> URL: https://issues.apache.org/jira/browse/GEODE-10384
> Project: Geode
> Issue Type: Improvement
>Reporter: Jianxia Chen
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.16.0
>
>
> In ConcurrentSerialGatewaySenderEventProcessor.stopProcessing, the log does
> not print out the stack trace, making it hard figure out the root cause:
> {code:java}
> logger.warn("GatewaySender {} caught exception while stopping: {}",
> new Object[] {sender, e.getCause()}); {code}
> For example, the log would be something without stack trace:
> {code:java}
> [warning 2022/06/14 20:41:17.412 PDT peergemfire_2_2_host1_20886
> tid=0x1cc] GatewaySender
> SerialGatewaySender{id=sender_ds_2_to_ds_1,remoteDsId=1,isRunning
> =false,isPrimary =true} caught exception while stopping:
> java.lang.NullPointerException {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10384) Improve logging with stack trace for gateway senders
[
https://issues.apache.org/jira/browse/GEODE-10384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-10384:
---
Labels: pull-request-available (was: )
> Improve logging with stack trace for gateway senders
>
>
> Key: GEODE-10384
> URL: https://issues.apache.org/jira/browse/GEODE-10384
> Project: Geode
> Issue Type: Improvement
>Reporter: Jianxia Chen
>Priority: Major
> Labels: pull-request-available
>
> In ConcurrentSerialGatewaySenderEventProcessor.stopProcessing, the log does
> not print out the stack trace, making it hard figure out the root cause:
> {code:java}
> logger.warn("GatewaySender {} caught exception while stopping: {}",
> new Object[] {sender, e.getCause()}); {code}
> For example, the log would be something without stack trace:
> {code:java}
> [warning 2022/06/14 20:41:17.412 PDT peergemfire_2_2_host1_20886
> tid=0x1cc] GatewaySender
> SerialGatewaySender{id=sender_ds_2_to_ds_1,remoteDsId=1,isRunning
> =false,isPrimary =true} caught exception while stopping:
> java.lang.NullPointerException {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-10384) Improve logging with stack trace for gateway senders
[
https://issues.apache.org/jira/browse/GEODE-10384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17554818#comment-17554818
]
ASF subversion and git services commented on GEODE-10384:
-
Commit 1a3c817081bfd97243b24b8ea6957a1e9040ca25 in geode's branch
refs/heads/develop from Jianxia Chen
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=1a3c817081 ]
GEODE-10384: Add stack trace to logging (#7804)
> Improve logging with stack trace for gateway senders
>
>
> Key: GEODE-10384
> URL: https://issues.apache.org/jira/browse/GEODE-10384
> Project: Geode
> Issue Type: Improvement
>Reporter: Jianxia Chen
>Priority: Major
> Labels: pull-request-available
>
> In ConcurrentSerialGatewaySenderEventProcessor.stopProcessing, the log does
> not print out the stack trace, making it hard figure out the root cause:
> {code:java}
> logger.warn("GatewaySender {} caught exception while stopping: {}",
> new Object[] {sender, e.getCause()}); {code}
> For example, the log would be something without stack trace:
> {code:java}
> [warning 2022/06/14 20:41:17.412 PDT peergemfire_2_2_host1_20886
> tid=0x1cc] GatewaySender
> SerialGatewaySender{id=sender_ds_2_to_ds_1,remoteDsId=1,isRunning
> =false,isPrimary =true} caught exception while stopping:
> java.lang.NullPointerException {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-10089) release 1.15.0
[ https://issues.apache.org/jira/browse/GEODE-10089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17554817#comment-17554817 ] ASF subversion and git services commented on GEODE-10089: - Commit c5afabc1d98d0c0f1acae65e69bb73523a37 in geode-examples's branch refs/heads/support/1.15 from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode-examples.git;h=c5afab6 ] GEODE-10089: Bump version to 1.15.0 As part of the Geode Release Process, the geode-examples build number must be rolled forward as work begins on the next release > release 1.15.0 > -- > > Key: GEODE-10089 > URL: https://issues.apache.org/jira/browse/GEODE-10089 > Project: Geode > Issue Type: Task > Components: release >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > Labels: pull-request-available > > As per [Jan 25 dev list > discussion|https://lists.apache.org/thread/s9mpd207h40crcr76fpdfmohdchgdqog], > support/1.15 was cut with the intention of stabilizing and releasing a new > Geode minor. > UPDATE: As per [Mar 16 dev list > discussion|https://lists.apache.org/thread/twlwzcvmx2kqw15whpmxkh2h8bmrok21], > support/1.15 was retracted. Work will continue on develop with an eye toward > re-cutting support/1.15 in ~June > UPDATE: support/1.15 was re-cut on May 9 with an eye toward shipping in mid > to late June (2022). > Release status information is also updated in the Geode [Release > Schedule|https://cwiki.apache.org/confluence/display/GEODE/Release+Schedule]. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-10089) release 1.15.0
[ https://issues.apache.org/jira/browse/GEODE-10089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17554815#comment-17554815 ] ASF subversion and git services commented on GEODE-10089: - Commit a75d8099bb46d091fe177b45def076e4f50dd031 in geode-examples's branch refs/heads/support/1.15 from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode-examples.git;h=a75d809 ] GEODE-10089: Bump version to 1.15.0 As part of the Geode Release Process, the geode-examples build number must be rolled forward as work begins on the next release > release 1.15.0 > -- > > Key: GEODE-10089 > URL: https://issues.apache.org/jira/browse/GEODE-10089 > Project: Geode > Issue Type: Task > Components: release >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > Labels: pull-request-available > > As per [Jan 25 dev list > discussion|https://lists.apache.org/thread/s9mpd207h40crcr76fpdfmohdchgdqog], > support/1.15 was cut with the intention of stabilizing and releasing a new > Geode minor. > UPDATE: As per [Mar 16 dev list > discussion|https://lists.apache.org/thread/twlwzcvmx2kqw15whpmxkh2h8bmrok21], > support/1.15 was retracted. Work will continue on develop with an eye toward > re-cutting support/1.15 in ~June > UPDATE: support/1.15 was re-cut on May 9 with an eye toward shipping in mid > to late June (2022). > Release status information is also updated in the Geode [Release > Schedule|https://cwiki.apache.org/confluence/display/GEODE/Release+Schedule]. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-10089) release 1.15.0
[ https://issues.apache.org/jira/browse/GEODE-10089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17554816#comment-17554816 ] ASF subversion and git services commented on GEODE-10089: - Commit fef93101383522f1cf69508ec52ac6e8e0d24d80 in geode-examples's branch refs/heads/support/1.15 from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode-examples.git;h=fef9310 ] GEODE-10089: Set temporary staging repo This serves two purposes: it gives the RC pipeline a way to get the nexus staging repo id needed for various tests, and it gives the Jenkins server a valid configuration during the voting period. > release 1.15.0 > -- > > Key: GEODE-10089 > URL: https://issues.apache.org/jira/browse/GEODE-10089 > Project: Geode > Issue Type: Task > Components: release >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > Labels: pull-request-available > > As per [Jan 25 dev list > discussion|https://lists.apache.org/thread/s9mpd207h40crcr76fpdfmohdchgdqog], > support/1.15 was cut with the intention of stabilizing and releasing a new > Geode minor. > UPDATE: As per [Mar 16 dev list > discussion|https://lists.apache.org/thread/twlwzcvmx2kqw15whpmxkh2h8bmrok21], > support/1.15 was retracted. Work will continue on develop with an eye toward > re-cutting support/1.15 in ~June > UPDATE: support/1.15 was re-cut on May 9 with an eye toward shipping in mid > to late June (2022). > Release status information is also updated in the Geode [Release > Schedule|https://cwiki.apache.org/confluence/display/GEODE/Release+Schedule]. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10382) Windows build broken after image update
[ https://issues.apache.org/jira/browse/GEODE-10382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-10382: -- Labels: pull-request-available (was: needsTriage pull-request-available) > Windows build broken after image update > --- > > Key: GEODE-10382 > URL: https://issues.apache.org/jira/browse/GEODE-10382 > Project: Geode > Issue Type: Bug > Components: native client >Affects Versions: 1.16.0 >Reporter: Blake Bender >Priority: Major > Labels: pull-request-available > > The Windows 2019 build is broken in CI due to a new version of cmake not > liking one of our config parameters, and a couple of new build warnings being > flagged as errors after a compiler update. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (GEODE-10384) Improve logging with stack trace for gateway senders
Jianxia Chen created GEODE-10384:
Summary: Improve logging with stack trace for gateway senders
Key: GEODE-10384
URL: https://issues.apache.org/jira/browse/GEODE-10384
Project: Geode
Issue Type: Improvement
Reporter: Jianxia Chen
In ConcurrentSerialGatewaySenderEventProcessor.stopProcessing, the log does not
print out the stack trace, making it hard figure out the root cause:
{code:java}
logger.warn("GatewaySender {} caught exception while stopping: {}",
new Object[] {sender, e.getCause()}); {code}
For example, the log would be something without stack trace:
{code:java}
[warning 2022/06/14 20:41:17.412 PDT peergemfire_2_2_host1_20886
tid=0x1cc] GatewaySender
SerialGatewaySender{id=sender_ds_2_to_ds_1,remoteDsId=1,isRunning
=false,isPrimary =true} caught exception while stopping:
java.lang.NullPointerException {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-7017) CI failure: org.apache.geode.launchers.ServerStartupValueRecoveryNotificationTest > startupReportsOnlineOnlyAfterRedundancyRestored
[
https://issues.apache.org/jira/browse/GEODE-7017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17554785#comment-17554785
]
Geode Integration commented on GEODE-7017:
--
Seen on support/1.15 in [acceptance-test-openjdk11
#68|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-15-main/jobs/acceptance-test-openjdk11/builds/68]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-support-1-15-main/1.15.0-build.1329/test-results/acceptanceTest/1655325383/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-support-1-15-main/1.15.0-build.1329/test-artifacts/1655325383/acceptancetestfiles-openjdk11-1.15.0-build.1329.tgz].
> CI failure:
> org.apache.geode.launchers.ServerStartupValueRecoveryNotificationTest >
> startupReportsOnlineOnlyAfterRedundancyRestored
> ---
>
> Key: GEODE-7017
> URL: https://issues.apache.org/jira/browse/GEODE-7017
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Affects Versions: 1.10.0
>Reporter: Anilkumar Gingade
>Assignee: Mark Hanson
>Priority: Major
> Attachments: acceptancetestfiles-OpenJDK11-1.14.0-build.0628.tgz
>
>
> {noformat}
> org.apache.geode.launchers.ServerStartupValueRecoveryNotificationTest >
> startupReportsOnlineOnlyAfterRedundancyRestored FAILED
> org.junit.ComparisonFailure: expected:<[0]> but was:<[1]>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:125)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:125)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:112)
> at
> org.apache.geode.launchers.ServerStartupValueRecoveryNotificationTest.persistentRegionThatRequiresValueRecovery(ServerStartupValueRecoveryNotificationTest.java:120)
> {noformat}
> https://concourse.gemfire-ci.info/teams/main/pipelines/gemfire-develop-main/jobs/AcceptanceTestOpenJDK8/builds/797
> Test report artifacts from this job are available at:
> gs://gemfire-test-artifacts/builds/gemfire-develop-main/9.9.0-build.0258/test-artifacts/1564078711/acceptancetestfiles-OpenJDK8-9.9.0-build.0258.tgz
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Resolved] (GEODE-10381) CI Failure: SocketCreatorUpgradeTest.upgradingToNewGeodeAndNewJavaWithProtocolsTLSv1_2WithNewProperties[1.13.1] FAILED
[
https://issues.apache.org/jira/browse/GEODE-10381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob Barrett resolved GEODE-10381.
---
Resolution: Duplicate
> CI Failure:
> SocketCreatorUpgradeTest.upgradingToNewGeodeAndNewJavaWithProtocolsTLSv1_2WithNewProperties[1.13.1]
> FAILED
> --
>
> Key: GEODE-10381
> URL: https://issues.apache.org/jira/browse/GEODE-10381
> Project: Geode
> Issue Type: Bug
>Reporter: Eric Shu
>Priority: Major
> Labels: needsTriage
>
> {noformat}
> org.opentest4j.AssertionFailedError: [Exit value from process started by
> [c4f0c1c64be0eb32: gfsh -e start locator --connect=false
> --http-service-port=0 --name=locator1
> --bind-address=heavy-lifter-53ba3aed-9271-5896-9b10-672aaf4ea707.c.apachegeode-ci.internal
> --port=29435 --J=-Dgemfire.jmx-manager-port=29436
> --security-properties-file=/home/geode/geode/geode-core/build/upgradeTest/test-worker-59/SocketCreatorUpgradeTest/upgradingToNewGeodeAndNewJavaWithProtocolsTLSv1_2WithNewProperties[1.13.1]/newSecurity.properties
>
> --locators=heavy-lifter-53ba3aed-9271-5896-9b10-672aaf4ea707.c.apachegeode-ci.internal[29437]]]
>
> expected: 0
> but was: 1
> at
> jdk.internal.reflect.GeneratedConstructorAccessor23.newInstance(Unknown
> Source)
> at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:146)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshContext.doExecute(GfshContext.java:157)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshContext.execute(GfshContext.java:127)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshContext.execute(GfshContext.java:121)
> at
> org.apache.geode.internal.net.SocketCreatorUpgradeTest.upgradingToNewGeodeAndNewJavaWithProtocolsTLSv1_2WithNewProperties(SocketCreatorUpgradeTest.java:507)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule$1.evaluate(GfshRule.java:75)
> at
> org.apache.geode.test.junit.rules.FolderRule$1.evaluate(FolderRule.java:54)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at
> org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:42)
> at
>
[jira] [Updated] (GEODE-10383) lucene may log many warnings about BucketNotFound during normal operations
[
https://issues.apache.org/jira/browse/GEODE-10383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider updated GEODE-10383:
-
Summary: lucene may log many warnings about BucketNotFound during normal
operations (was: lucene may log many warnings about BucketNotFound during
normal opeartions)
> lucene may log many warnings about BucketNotFound during normal operations
> --
>
> Key: GEODE-10383
> URL: https://issues.apache.org/jira/browse/GEODE-10383
> Project: Geode
> Issue Type: Bug
> Components: lucene
>Reporter: Darrel Schneider
>Priority: Major
> Labels: needsTriage
>
> This seems much like GEODE-1557 but it may be this exception is coming from a
> different place. Once again it involves a test that has primaries moving
> around due to new servers starting up.
> I don't see any value in logging the stack trace in this case.
> If we are going to log about this should the message also include an
> explanation as to why it can happen during normal operations?
> Also should it really be a warning since it can occur during normal
> operations? It looks like the fix for GEODE-1557 made it "debug" level.
> I see a bunch of the following warnings logged:
> {noformat}
> .cache.lucene.internal.distributed.LuceneQueryFunction@14894ec8
> org.apache.geode.cache.execute.FunctionException:
> org.apache.geode.internal.cache.execute.InternalFunctionInvocationTargetException:
> org.apache.geode.internal.cache.BucketNotFo
> undException: Unable to find lucene index because no longer primary for
> bucket 326
> at
> org.apache.geode.internal.cache.partitioned.PRFunctionStreamingResultCollector.getResultInternal(PRFunctionStreamingResultCollector.java:126)
> at
> org.apache.geode.internal.cache.execute.ResultCollectorHolder.getResult(ResultCollectorHolder.java:53)
> at
> org.apache.geode.internal.cache.partitioned.PRFunctionStreamingResultCollector.getResult(PRFunctionStreamingResultCollector.java:87)
> at
> org.apache.geode.internal.cache.tier.sockets.command.ExecuteRegionFunctionGeode18.executeFunctionWithResult(ExecuteRegionFunctionGeode18.java:50)
> at
> org.apache.geode.internal.cache.tier.sockets.command.ExecuteRegionFunction66.cmdExecute(ExecuteRegionFunction66.java:203)
> at
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:187)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:880)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doOneMessage(ServerConnection.java:1074)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1356)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.lambda$initializeServerConnectionThreadPool$3(AcceptorImpl.java:690)
> at
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120)
> at java.base/java.lang.Thread.run(Thread.java:833)
> Caused by:
> org.apache.geode.internal.cache.execute.InternalFunctionInvocationTargetException:
> org.apache.geode.internal.cache.BucketNotFoundException: Unable to find
> lucene ind
> ex because no longer primary for bucket 326
> at
> org.apache.geode.internal.cache.partitioned.PRFunctionStreamingResultCollector.getResultInternal(PRFunctionStreamingResultCollector.java:125)
> ... 13 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10341) Add scope details to snapshot section in documentation
[ https://issues.apache.org/jira/browse/GEODE-10341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Hufnagel updated GEODE-10341: - Affects Version/s: 1.12.9 1.15.1 1.16.0 > Add scope details to snapshot section in documentation > -- > > Key: GEODE-10341 > URL: https://issues.apache.org/jira/browse/GEODE-10341 > Project: Geode > Issue Type: Improvement > Components: docs >Affects Versions: 1.12.9, 1.14.4, 1.15.1, 1.16.0 >Reporter: Max Hufnagel >Assignee: Max Hufnagel >Priority: Major > Labels: pull-request-available > > A customer was doing an upgrade with a complete cluster restart and the > documentation is not clear on this part. > The customer has a non-persistent region with overflow to disk and wanted to > know if they needed to do a combination of export/import and diskstore backup > to backup the region or if a snapshot would include both in-cache entries and > overflowed entries. > A test verified that all entries are included in the gfd file. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10383) lucene may log many warnings about BucketNotFound during normal opeartions
[
https://issues.apache.org/jira/browse/GEODE-10383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10383:
--
Labels: needsTriage (was: )
> lucene may log many warnings about BucketNotFound during normal opeartions
> --
>
> Key: GEODE-10383
> URL: https://issues.apache.org/jira/browse/GEODE-10383
> Project: Geode
> Issue Type: Bug
> Components: lucene
>Reporter: Darrel Schneider
>Priority: Major
> Labels: needsTriage
>
> This seems much like GEODE-1557 but it may be this exception is coming from a
> different place. Once again it involves a test that has primaries moving
> around due to new servers starting up.
> I don't see any value in logging the stack trace in this case.
> If we are going to log about this should the message also include an
> explanation as to why it can happen during normal operations?
> Also should it really be a warning since it can occur during normal
> operations? It looks like the fix for GEODE-1557 made it "debug" level.
> I see a bunch of the following warnings logged:
> {noformat}
> .cache.lucene.internal.distributed.LuceneQueryFunction@14894ec8
> org.apache.geode.cache.execute.FunctionException:
> org.apache.geode.internal.cache.execute.InternalFunctionInvocationTargetException:
> org.apache.geode.internal.cache.BucketNotFo
> undException: Unable to find lucene index because no longer primary for
> bucket 326
> at
> org.apache.geode.internal.cache.partitioned.PRFunctionStreamingResultCollector.getResultInternal(PRFunctionStreamingResultCollector.java:126)
> at
> org.apache.geode.internal.cache.execute.ResultCollectorHolder.getResult(ResultCollectorHolder.java:53)
> at
> org.apache.geode.internal.cache.partitioned.PRFunctionStreamingResultCollector.getResult(PRFunctionStreamingResultCollector.java:87)
> at
> org.apache.geode.internal.cache.tier.sockets.command.ExecuteRegionFunctionGeode18.executeFunctionWithResult(ExecuteRegionFunctionGeode18.java:50)
> at
> org.apache.geode.internal.cache.tier.sockets.command.ExecuteRegionFunction66.cmdExecute(ExecuteRegionFunction66.java:203)
> at
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:187)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:880)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doOneMessage(ServerConnection.java:1074)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1356)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.lambda$initializeServerConnectionThreadPool$3(AcceptorImpl.java:690)
> at
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120)
> at java.base/java.lang.Thread.run(Thread.java:833)
> Caused by:
> org.apache.geode.internal.cache.execute.InternalFunctionInvocationTargetException:
> org.apache.geode.internal.cache.BucketNotFoundException: Unable to find
> lucene ind
> ex because no longer primary for bucket 326
> at
> org.apache.geode.internal.cache.partitioned.PRFunctionStreamingResultCollector.getResultInternal(PRFunctionStreamingResultCollector.java:125)
> ... 13 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (GEODE-10383) lucene may log many warnings about BucketNotFound during normal opeartions
Darrel Schneider created GEODE-10383:
Summary: lucene may log many warnings about BucketNotFound during
normal opeartions
Key: GEODE-10383
URL: https://issues.apache.org/jira/browse/GEODE-10383
Project: Geode
Issue Type: Bug
Components: lucene
Reporter: Darrel Schneider
This seems much like GEODE-1557 but it may be this exception is coming from a
different place. Once again it involves a test that has primaries moving around
due to new servers starting up.
I don't see any value in logging the stack trace in this case.
If we are going to log about this should the message also include an
explanation as to why it can happen during normal operations?
Also should it really be a warning since it can occur during normal operations?
It looks like the fix for GEODE-1557 made it "debug" level.
I see a bunch of the following warnings logged:
{noformat}
.cache.lucene.internal.distributed.LuceneQueryFunction@14894ec8
org.apache.geode.cache.execute.FunctionException:
org.apache.geode.internal.cache.execute.InternalFunctionInvocationTargetException:
org.apache.geode.internal.cache.BucketNotFo
undException: Unable to find lucene index because no longer primary for bucket
326
at
org.apache.geode.internal.cache.partitioned.PRFunctionStreamingResultCollector.getResultInternal(PRFunctionStreamingResultCollector.java:126)
at
org.apache.geode.internal.cache.execute.ResultCollectorHolder.getResult(ResultCollectorHolder.java:53)
at
org.apache.geode.internal.cache.partitioned.PRFunctionStreamingResultCollector.getResult(PRFunctionStreamingResultCollector.java:87)
at
org.apache.geode.internal.cache.tier.sockets.command.ExecuteRegionFunctionGeode18.executeFunctionWithResult(ExecuteRegionFunctionGeode18.java:50)
at
org.apache.geode.internal.cache.tier.sockets.command.ExecuteRegionFunction66.cmdExecute(ExecuteRegionFunction66.java:203)
at
org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:187)
at
org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:880)
at
org.apache.geode.internal.cache.tier.sockets.ServerConnection.doOneMessage(ServerConnection.java:1074)
at
org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1356)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at
org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.lambda$initializeServerConnectionThreadPool$3(AcceptorImpl.java:690)
at
org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120)
at java.base/java.lang.Thread.run(Thread.java:833)
Caused by:
org.apache.geode.internal.cache.execute.InternalFunctionInvocationTargetException:
org.apache.geode.internal.cache.BucketNotFoundException: Unable to find lucene
ind
ex because no longer primary for bucket 326
at
org.apache.geode.internal.cache.partitioned.PRFunctionStreamingResultCollector.getResultInternal(PRFunctionStreamingResultCollector.java:125)
... 13 more
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-10381) CI Failure: SocketCreatorUpgradeTest.upgradingToNewGeodeAndNewJavaWithProtocolsTLSv1_2WithNewProperties[1.13.1] FAILED
[
https://issues.apache.org/jira/browse/GEODE-10381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17554751#comment-17554751
]
Geode Integration commented on GEODE-10381:
---
Seen in [upgrade-test-openjdk11
#405|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/upgrade-test-openjdk11/builds/405]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.16.0-build.0339/test-results/upgradeTest/1655265192/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.16.0-build.0339/test-artifacts/1655265192/upgradetestfiles-openjdk11-1.16.0-build.0339.tgz].
> CI Failure:
> SocketCreatorUpgradeTest.upgradingToNewGeodeAndNewJavaWithProtocolsTLSv1_2WithNewProperties[1.13.1]
> FAILED
> --
>
> Key: GEODE-10381
> URL: https://issues.apache.org/jira/browse/GEODE-10381
> Project: Geode
> Issue Type: Bug
>Reporter: Eric Shu
>Priority: Major
> Labels: needsTriage
>
> {noformat}
> org.opentest4j.AssertionFailedError: [Exit value from process started by
> [c4f0c1c64be0eb32: gfsh -e start locator --connect=false
> --http-service-port=0 --name=locator1
> --bind-address=heavy-lifter-53ba3aed-9271-5896-9b10-672aaf4ea707.c.apachegeode-ci.internal
> --port=29435 --J=-Dgemfire.jmx-manager-port=29436
> --security-properties-file=/home/geode/geode/geode-core/build/upgradeTest/test-worker-59/SocketCreatorUpgradeTest/upgradingToNewGeodeAndNewJavaWithProtocolsTLSv1_2WithNewProperties[1.13.1]/newSecurity.properties
>
> --locators=heavy-lifter-53ba3aed-9271-5896-9b10-672aaf4ea707.c.apachegeode-ci.internal[29437]]]
>
> expected: 0
> but was: 1
> at
> jdk.internal.reflect.GeneratedConstructorAccessor23.newInstance(Unknown
> Source)
> at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:146)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshContext.doExecute(GfshContext.java:157)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshContext.execute(GfshContext.java:127)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshContext.execute(GfshContext.java:121)
> at
> org.apache.geode.internal.net.SocketCreatorUpgradeTest.upgradingToNewGeodeAndNewJavaWithProtocolsTLSv1_2WithNewProperties(SocketCreatorUpgradeTest.java:507)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule$1.evaluate(GfshRule.java:75)
> at
> org.apache.geode.test.junit.rules.FolderRule$1.evaluate(FolderRule.java:54)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at
[jira] [Commented] (GEODE-9612) CI Hang in org.apache.geode.internal.offheap.FreeListOffHeapRegionJUnitTest.testPersistentCompressorChange
[
https://issues.apache.org/jira/browse/GEODE-9612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17554749#comment-17554749
]
Geode Integration commented on GEODE-9612:
--
Seen in [integration-test-openjdk8
#419|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/integration-test-openjdk8/builds/419]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.16.0-build.0339/test-results/integrationTest/1655257297/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.16.0-build.0339/test-artifacts/1655257297/integrationtestfiles-openjdk8-1.16.0-build.0339.tgz].
> CI Hang in
> org.apache.geode.internal.offheap.FreeListOffHeapRegionJUnitTest.testPersistentCompressorChange
> --
>
> Key: GEODE-9612
> URL: https://issues.apache.org/jira/browse/GEODE-9612
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Owen Nichols
>Priority: Major
>
> {noformat}
> progress -s started
> org.apache.geode.internal.offheap.FreeListOffHeapRegionJUnitTest.testPersistentCompressorChange
> Iteration: 1
> Start: 2021-09-20 17:58:36.099 +
> End: 0001-01-01 00:00:00.000 +
> Duration: 0s
> Status:started {noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-10382) Windows build broken after image update
[ https://issues.apache.org/jira/browse/GEODE-10382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17554747#comment-17554747 ] ASF GitHub Bot commented on GEODE-10382: pdxcodemonkey opened a new pull request, #975: URL: https://github.com/apache/geode-native/pull/975 Add echo command to cmake configuration step, for debugging > Windows build broken after image update > --- > > Key: GEODE-10382 > URL: https://issues.apache.org/jira/browse/GEODE-10382 > Project: Geode > Issue Type: Bug > Components: native client >Affects Versions: 1.16.0 >Reporter: Blake Bender >Priority: Major > Labels: needsTriage > > The Windows 2019 build is broken in CI due to a new version of cmake not > liking one of our config parameters, and a couple of new build warnings being > flagged as errors after a compiler update. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10382) Windows build broken after image update
[ https://issues.apache.org/jira/browse/GEODE-10382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-10382: --- Labels: needsTriage pull-request-available (was: needsTriage) > Windows build broken after image update > --- > > Key: GEODE-10382 > URL: https://issues.apache.org/jira/browse/GEODE-10382 > Project: Geode > Issue Type: Bug > Components: native client >Affects Versions: 1.16.0 >Reporter: Blake Bender >Priority: Major > Labels: needsTriage, pull-request-available > > The Windows 2019 build is broken in CI due to a new version of cmake not > liking one of our config parameters, and a couple of new build warnings being > flagged as errors after a compiler update. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10382) Windows build broken after image update
[ https://issues.apache.org/jira/browse/GEODE-10382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10382: -- Labels: needsTriage (was: ) > Windows build broken after image update > --- > > Key: GEODE-10382 > URL: https://issues.apache.org/jira/browse/GEODE-10382 > Project: Geode > Issue Type: Bug > Components: native client >Affects Versions: 1.16.0 >Reporter: Blake Bender >Priority: Major > Labels: needsTriage > > The Windows 2019 build is broken in CI due to a new version of cmake not > liking one of our config parameters, and a couple of new build warnings being > flagged as errors after a compiler update. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (GEODE-10382) Windows build broken after image update
Blake Bender created GEODE-10382: Summary: Windows build broken after image update Key: GEODE-10382 URL: https://issues.apache.org/jira/browse/GEODE-10382 Project: Geode Issue Type: Bug Components: native client Affects Versions: 1.16.0 Reporter: Blake Bender The Windows 2019 build is broken in CI due to a new version of cmake not liking one of our config parameters, and a couple of new build warnings being flagged as errors after a compiler update. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10380) When dispatcher socket buffer is full, the ReAuth won't get sent to the client causing a deadlock
[ https://issues.apache.org/jira/browse/GEODE-10380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-10380: - Fix Version/s: 1.16.0 > When dispatcher socket buffer is full, the ReAuth won't get sent to the > client causing a deadlock > - > > Key: GEODE-10380 > URL: https://issues.apache.org/jira/browse/GEODE-10380 > Project: Geode > Issue Type: Bug > Components: client/server >Affects Versions: 1.15.0 >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: needsTriage, pull-request-available > Fix For: 1.15.0, 1.16.0 > > Attachments: Screen Shot 2022-06-14 at 5.37.18 PM.png > > > # message dispatcher trying to send a reAuth message to the client, but not > able to because the socket buffer is full. > # client updater is blocked waiting for a regionEntry lock when doing a > remove operation. > # the regionEntry lock is held by a client operation doing destroy on that > same key > # the client operation is waiting for the re_auth op to finish. > # the re_auth command on the server is blocked by the #1 holding the lock -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-10381) CI Failure: SocketCreatorUpgradeTest.upgradingToNewGeodeAndNewJavaWithProtocolsTLSv1_2WithNewProperties[1.13.1] FAILED
[
https://issues.apache.org/jira/browse/GEODE-10381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17554744#comment-17554744
]
Geode Integration commented on GEODE-10381:
---
Seen in [upgrade-test-openjdk11
#405|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/upgrade-test-openjdk11/builds/405]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.16.0-build.0339/test-results/upgradeTest/1655265192/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.16.0-build.0339/test-artifacts/1655265192/upgradetestfiles-openjdk11-1.16.0-build.0339.tgz].
> CI Failure:
> SocketCreatorUpgradeTest.upgradingToNewGeodeAndNewJavaWithProtocolsTLSv1_2WithNewProperties[1.13.1]
> FAILED
> --
>
> Key: GEODE-10381
> URL: https://issues.apache.org/jira/browse/GEODE-10381
> Project: Geode
> Issue Type: Bug
>Reporter: Eric Shu
>Priority: Major
> Labels: needsTriage
>
> {noformat}
> org.opentest4j.AssertionFailedError: [Exit value from process started by
> [c4f0c1c64be0eb32: gfsh -e start locator --connect=false
> --http-service-port=0 --name=locator1
> --bind-address=heavy-lifter-53ba3aed-9271-5896-9b10-672aaf4ea707.c.apachegeode-ci.internal
> --port=29435 --J=-Dgemfire.jmx-manager-port=29436
> --security-properties-file=/home/geode/geode/geode-core/build/upgradeTest/test-worker-59/SocketCreatorUpgradeTest/upgradingToNewGeodeAndNewJavaWithProtocolsTLSv1_2WithNewProperties[1.13.1]/newSecurity.properties
>
> --locators=heavy-lifter-53ba3aed-9271-5896-9b10-672aaf4ea707.c.apachegeode-ci.internal[29437]]]
>
> expected: 0
> but was: 1
> at
> jdk.internal.reflect.GeneratedConstructorAccessor23.newInstance(Unknown
> Source)
> at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:146)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshContext.doExecute(GfshContext.java:157)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshContext.execute(GfshContext.java:127)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshContext.execute(GfshContext.java:121)
> at
> org.apache.geode.internal.net.SocketCreatorUpgradeTest.upgradingToNewGeodeAndNewJavaWithProtocolsTLSv1_2WithNewProperties(SocketCreatorUpgradeTest.java:507)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule$1.evaluate(GfshRule.java:75)
> at
> org.apache.geode.test.junit.rules.FolderRule$1.evaluate(FolderRule.java:54)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at
[jira] [Updated] (GEODE-10381) CI Failure: SocketCreatorUpgradeTest.upgradingToNewGeodeAndNewJavaWithProtocolsTLSv1_2WithNewProperties[1.13.1] FAILED
[
https://issues.apache.org/jira/browse/GEODE-10381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10381:
--
Labels: needsTriage (was: )
> CI Failure:
> SocketCreatorUpgradeTest.upgradingToNewGeodeAndNewJavaWithProtocolsTLSv1_2WithNewProperties[1.13.1]
> FAILED
> --
>
> Key: GEODE-10381
> URL: https://issues.apache.org/jira/browse/GEODE-10381
> Project: Geode
> Issue Type: Bug
>Reporter: Eric Shu
>Priority: Major
> Labels: needsTriage
>
> {noformat}
> org.opentest4j.AssertionFailedError: [Exit value from process started by
> [c4f0c1c64be0eb32: gfsh -e start locator --connect=false
> --http-service-port=0 --name=locator1
> --bind-address=heavy-lifter-53ba3aed-9271-5896-9b10-672aaf4ea707.c.apachegeode-ci.internal
> --port=29435 --J=-Dgemfire.jmx-manager-port=29436
> --security-properties-file=/home/geode/geode/geode-core/build/upgradeTest/test-worker-59/SocketCreatorUpgradeTest/upgradingToNewGeodeAndNewJavaWithProtocolsTLSv1_2WithNewProperties[1.13.1]/newSecurity.properties
>
> --locators=heavy-lifter-53ba3aed-9271-5896-9b10-672aaf4ea707.c.apachegeode-ci.internal[29437]]]
>
> expected: 0
> but was: 1
> at
> jdk.internal.reflect.GeneratedConstructorAccessor23.newInstance(Unknown
> Source)
> at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:146)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshContext.doExecute(GfshContext.java:157)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshContext.execute(GfshContext.java:127)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshContext.execute(GfshContext.java:121)
> at
> org.apache.geode.internal.net.SocketCreatorUpgradeTest.upgradingToNewGeodeAndNewJavaWithProtocolsTLSv1_2WithNewProperties(SocketCreatorUpgradeTest.java:507)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule$1.evaluate(GfshRule.java:75)
> at
> org.apache.geode.test.junit.rules.FolderRule$1.evaluate(FolderRule.java:54)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at
> org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:42)
> at
>
[jira] [Created] (GEODE-10381) CI Failure: SocketCreatorUpgradeTest.upgradingToNewGeodeAndNewJavaWithProtocolsTLSv1_2WithNewProperties[1.13.1] FAILED
Eric Shu created GEODE-10381:
Summary: CI Failure:
SocketCreatorUpgradeTest.upgradingToNewGeodeAndNewJavaWithProtocolsTLSv1_2WithNewProperties[1.13.1]
FAILED
Key: GEODE-10381
URL: https://issues.apache.org/jira/browse/GEODE-10381
Project: Geode
Issue Type: Bug
Reporter: Eric Shu
{noformat}
org.opentest4j.AssertionFailedError: [Exit value from process started by
[c4f0c1c64be0eb32: gfsh -e start locator --connect=false --http-service-port=0
--name=locator1
--bind-address=heavy-lifter-53ba3aed-9271-5896-9b10-672aaf4ea707.c.apachegeode-ci.internal
--port=29435 --J=-Dgemfire.jmx-manager-port=29436
--security-properties-file=/home/geode/geode/geode-core/build/upgradeTest/test-worker-59/SocketCreatorUpgradeTest/upgradingToNewGeodeAndNewJavaWithProtocolsTLSv1_2WithNewProperties[1.13.1]/newSecurity.properties
--locators=heavy-lifter-53ba3aed-9271-5896-9b10-672aaf4ea707.c.apachegeode-ci.internal[29437]]]
expected: 0
but was: 1
at
jdk.internal.reflect.GeneratedConstructorAccessor23.newInstance(Unknown Source)
at
jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at
org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:146)
at
org.apache.geode.test.junit.rules.gfsh.GfshContext.doExecute(GfshContext.java:157)
at
org.apache.geode.test.junit.rules.gfsh.GfshContext.execute(GfshContext.java:127)
at
org.apache.geode.test.junit.rules.gfsh.GfshContext.execute(GfshContext.java:121)
at
org.apache.geode.internal.net.SocketCreatorUpgradeTest.upgradingToNewGeodeAndNewJavaWithProtocolsTLSv1_2WithNewProperties(SocketCreatorUpgradeTest.java:507)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:566)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.apache.geode.test.junit.rules.gfsh.GfshRule$1.evaluate(GfshRule.java:75)
at
org.apache.geode.test.junit.rules.FolderRule$1.evaluate(FolderRule.java:54)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at
org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:27)
at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
at
org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:42)
at
org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:80)
at
org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:72)
at
org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:108)
at
org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:88)
[jira] [Commented] (GEODE-10380) When dispatcher socket buffer is full, the ReAuth won't get sent to the client causing a deadlock
[ https://issues.apache.org/jira/browse/GEODE-10380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17554736#comment-17554736 ] ASF subversion and git services commented on GEODE-10380: - Commit 1869f2c06681bb73de727d2080d76c6215db9fb9 in geode's branch refs/heads/support/1.15 from Jinmei Liao [ https://gitbox.apache.org/repos/asf?p=geode.git;h=1869f2c066 ] GEODE-10380: use waitingThreadPool to notify dispatcher at re_auth (#7801) (cherry picked from commit b3fef2a9989ecb5897325a7a84377a8ac7d30028) > When dispatcher socket buffer is full, the ReAuth won't get sent to the > client causing a deadlock > - > > Key: GEODE-10380 > URL: https://issues.apache.org/jira/browse/GEODE-10380 > Project: Geode > Issue Type: Bug > Components: client/server >Affects Versions: 1.15.0 >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: needsTriage, pull-request-available > Attachments: Screen Shot 2022-06-14 at 5.37.18 PM.png > > > # message dispatcher trying to send a reAuth message to the client, but not > able to because the socket buffer is full. > # client updater is blocked waiting for a regionEntry lock when doing a > remove operation. > # the regionEntry lock is held by a client operation doing destroy on that > same key > # the client operation is waiting for the re_auth op to finish. > # the re_auth command on the server is blocked by the #1 holding the lock -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-10380) When dispatcher socket buffer is full, the ReAuth won't get sent to the client causing a deadlock
[ https://issues.apache.org/jira/browse/GEODE-10380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao resolved GEODE-10380. - Fix Version/s: 1.15.0 Resolution: Fixed > When dispatcher socket buffer is full, the ReAuth won't get sent to the > client causing a deadlock > - > > Key: GEODE-10380 > URL: https://issues.apache.org/jira/browse/GEODE-10380 > Project: Geode > Issue Type: Bug > Components: client/server >Affects Versions: 1.15.0 >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: needsTriage, pull-request-available > Fix For: 1.15.0 > > Attachments: Screen Shot 2022-06-14 at 5.37.18 PM.png > > > # message dispatcher trying to send a reAuth message to the client, but not > able to because the socket buffer is full. > # client updater is blocked waiting for a regionEntry lock when doing a > remove operation. > # the regionEntry lock is held by a client operation doing destroy on that > same key > # the client operation is waiting for the re_auth op to finish. > # the re_auth command on the server is blocked by the #1 holding the lock -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-10380) When dispatcher socket buffer is full, the ReAuth won't get sent to the client causing a deadlock
[ https://issues.apache.org/jira/browse/GEODE-10380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17554735#comment-17554735 ] ASF subversion and git services commented on GEODE-10380: - Commit b3fef2a9989ecb5897325a7a84377a8ac7d30028 in geode's branch refs/heads/develop from Jinmei Liao [ https://gitbox.apache.org/repos/asf?p=geode.git;h=b3fef2a998 ] GEODE-10380: use waitingThreadPool to notify dispatcher at re_auth (#7801) > When dispatcher socket buffer is full, the ReAuth won't get sent to the > client causing a deadlock > - > > Key: GEODE-10380 > URL: https://issues.apache.org/jira/browse/GEODE-10380 > Project: Geode > Issue Type: Bug > Components: client/server >Affects Versions: 1.15.0 >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: needsTriage, pull-request-available > Attachments: Screen Shot 2022-06-14 at 5.37.18 PM.png > > > # message dispatcher trying to send a reAuth message to the client, but not > able to because the socket buffer is full. > # client updater is blocked waiting for a regionEntry lock when doing a > remove operation. > # the regionEntry lock is held by a client operation doing destroy on that > same key > # the client operation is waiting for the re_auth op to finish. > # the re_auth command on the server is blocked by the #1 holding the lock -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-3492) ServerLauncherRemoteFileIntegrationTest fails on Windows
[
https://issues.apache.org/jira/browse/GEODE-3492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17554732#comment-17554732
]
Geode Integration commented on GEODE-3492:
--
Seen in [windows-core-integration-test-openjdk11
#407|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/windows-core-integration-test-openjdk11/builds/407]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.16.0-build.0339/test-results/integrationTest/1655258442/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.16.0-build.0339/test-artifacts/1655258442/windows-coreintegrationtestfiles-openjdk11-1.16.0-build.0339.tgz].
> ServerLauncherRemoteFileIntegrationTest fails on Windows
>
>
> Key: GEODE-3492
> URL: https://issues.apache.org/jira/browse/GEODE-3492
> Project: Geode
> Issue Type: Sub-task
> Components: gfsh, tests
> Environment: Windows
>Reporter: Kirk Lund
>Priority: Major
> Labels: IntegrationTest, Windows
>
> {noformat}
> org.apache.geode.distributed.ServerLauncherRemoteFileIntegrationTest >
> stopWithPidReturnsStopped FAILED
> org.awaitility.core.ConditionTimeoutException: Condition defined as a
> lambda expression in
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase that
> uses org.apache.geode.distributed.ServerLauncher expected:<[online]> but
> was:<[not responding]> within 2 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:104)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:117)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:32)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:809)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:648)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.awaitStart(ServerLauncherRemoteIntegrationTestCase.java:198)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.awaitStart(ServerLauncherRemoteIntegrationTestCase.java:177)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.awaitStart(ServerLauncherRemoteIntegrationTestCase.java:188)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.givenRunningServer(ServerLauncherRemoteIntegrationTestCase.java:114)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.givenRunningServer(ServerLauncherRemoteIntegrationTestCase.java:110)
> at
> org.apache.geode.distributed.ServerLauncherRemoteFileIntegrationTest.stopWithPidReturnsStopped(ServerLauncherRemoteFileIntegrationTest.java:75)
> org.apache.geode.distributed.ServerLauncherRemoteFileIntegrationTest >
> stopWithPidDeletesPidFile FAILED
> org.awaitility.core.ConditionTimeoutException: Condition defined as a
> lambda expression in
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase that
> uses org.apache.geode.distributed.ServerLauncher expected:<[online]> but
> was:<[not responding]> within 2 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:104)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:117)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:32)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:809)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:648)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.awaitStart(ServerLauncherRemoteIntegrationTestCase.java:198)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.awaitStart(ServerLauncherRemoteIntegrationTestCase.java:177)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.awaitStart(ServerLauncherRemoteIntegrationTestCase.java:188)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.givenRunningServer(ServerLauncherRemoteIntegrationTestCase.java:114)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.givenRunningServer(ServerLauncherRemoteIntegrationTestCase.java:110)
> at
> org.apache.geode.distributed.ServerLauncherRemoteFileIntegrationTest.stopWithPidDeletesPidFile(ServerLauncherRemoteFileIntegrationTest.java:63)
> org.apache.geode.distributed.ServerLauncherRemoteFileIntegrationTest >
> stopWithPidStopsServerProcess FAILED
> org.awaitility.core.ConditionTimeoutException: Condition defined as a
> lambda expression in
>
[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=17554730#comment-17554730 ] Geode Integration commented on GEODE-6183: -- Seen in [windows-core-integration-test-openjdk8 #411|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/windows-core-integration-test-openjdk8/builds/411] ... see [test results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.16.0-build.0340/test-results/integrationTest/1655261096/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.16.0-build.0340/test-artifacts/1655261096/windows-coreintegrationtestfiles-openjdk8-1.16.0-build.0340.tgz]. > 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: build >Affects Versions: 1.14.0, 1.15.0 >Reporter: Eric Shu >Assignee: Kirk Lund >Priority: Major > Time Spent: 5h 50m > 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.20.7#820007)
[jira] [Commented] (GEODE-10323) OffHeapStorageJUnitTest testCreateOffHeapStorage fails with AssertionError: expected:<100> but was:<1048576>
[
https://issues.apache.org/jira/browse/GEODE-10323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17554729#comment-17554729
]
Geode Integration commented on GEODE-10323:
---
Seen in [windows-unit-test-openjdk11
#416|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/windows-unit-test-openjdk11/builds/416]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.16.0-build.0340/test-results/test/1655259449/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.16.0-build.0340/test-artifacts/1655259449/windows-unittestfiles-openjdk11-1.16.0-build.0340.tgz].
> OffHeapStorageJUnitTest testCreateOffHeapStorage fails with AssertionError:
> expected:<100> but was:<1048576>
>
>
> Key: GEODE-10323
> URL: https://issues.apache.org/jira/browse/GEODE-10323
> Project: Geode
> Issue Type: Bug
> Components: offheap
>Affects Versions: 1.16.0
>Reporter: Kirk Lund
>Assignee: Alberto Gomez
>Priority: Major
> Labels: pull-request-available
>
> [Please see 1st comment on this ticket below the description for
> recommendation on how to fix.]
> {{OffHeapStorageJUnitTest testCreateOffHeapStorage}} started failing
> intermittently due to commit a350ed2 which went in as
> "[GEODE-10087|https://issues.apache.org/jira/browse/GEODE-10087]: Enhance
> off-heap fragmentation visibility.
> ([#7407|https://github.com/apache/geode/pull/7407/commits/1640effc5c760afa8d9ec4c2743950bb1de0ef8f])".
> The failure stack looks like:
> {noformat}
> OffHeapStorageJUnitTest > testCreateOffHeapStorage FAILED
> java.lang.AssertionError: expected:<100> but was:<1048576>
> at org.junit.Assert.fail(Assert.java:89)
> at org.junit.Assert.failNotEquals(Assert.java:835)
> at org.junit.Assert.assertEquals(Assert.java:647)
> at org.junit.Assert.assertEquals(Assert.java:633)
> at
> org.apache.geode.internal.offheap.OffHeapStorageJUnitTest.testCreateOffHeapStorage(OffHeapStorageJUnitTest.java:220)
> {noformat}
> The cause is in {{MemoryAllocatorImpl}}. A new scheduled executor
> {{updateNonRealTimeStatsExecutor}} was added near the bottom of the
> constructor which immediately gets scheduled to invoke
> {{freeList::updateNonRealTimeStats}} repeatedly at the specified frequency of
> {{updateOffHeapStatsFrequencyMs}} whenever an instance of
> {{MemoryAllocatorImpl}} is created.
> {{freeList::updateNonRealTimeStats}} then updates {{setLargestFragment}} and
> {{setFreedChunks}}.
> Scheduling or starting any sort of threads from a constructor is considered a
> bad practice and should only be done via some sort of activation method such
> as {{start()}} which can be invoked from the static factory method for
> {{MemoryAllocatorImpl}}. The unit tests would then continue to construct
> instances via a constructor that does NOT invoke {{start()}}.
> {{OffHeapStorageJUnitTest testCreateOffHeapStorage}}, and possibly other
> tests, is written with the assumption that no other thread or component can
> or will be updating the {{OffHeapStats}}. Hence it is then safe for the test
> to setLargestFragment and then assert that it has the value passed in:
> {noformat}
> 219: stats.setLargestFragment(100);
> 220: assertEquals(100, stats.getLargestFragment());
> {noformat}
> Line 220 is the source of the assertion failure because
> {{updateNonRealTimeStatsExecutor}} is racing with the JUnit thread and
> changes the value of {{setLargestFragment}} immediately after the test sets
> the value to 100, but before the test invokes the assertion.
> Looking back at the [PR test
> results|https://cio.hdb.gemfire-ci.info/commits/pr/7407/junit?days=90] we can
> see that stress-new-test failed 5 times with this exact failure before being
> merged to develop:
> *
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7407/test-results/repeatTest/1646140652/
> *
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7407/test-results/repeatTest/1646154134/
> (x2)
> *
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7407/test-results/repeatTest/1646156997/
> *
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7407/test-results/repeatTest/1646170346/
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-3487) Launcher integration tests fail on Windows
[ https://issues.apache.org/jira/browse/GEODE-3487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17554728#comment-17554728 ] Geode Integration commented on GEODE-3487: -- Seen in [windows-core-integration-test-openjdk11 #407|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/windows-core-integration-test-openjdk11/builds/407] ... see [test results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.16.0-build.0339/test-results/integrationTest/1655258442/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.16.0-build.0339/test-artifacts/1655258442/windows-coreintegrationtestfiles-openjdk11-1.16.0-build.0339.tgz]. > Launcher integration tests fail on Windows > -- > > Key: GEODE-3487 > URL: https://issues.apache.org/jira/browse/GEODE-3487 > Project: Geode > Issue Type: Bug > Components: gfsh, tests > Environment: Windows >Reporter: Kirk Lund >Priority: Major > Labels: IntegrationTest, Windows > > Various LocatorLauncher and ServerLauncher integration tests are failing on > Windows. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-10323) OffHeapStorageJUnitTest testCreateOffHeapStorage fails with AssertionError: expected:<100> but was:<1048576>
[
https://issues.apache.org/jira/browse/GEODE-10323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17554720#comment-17554720
]
Geode Integration commented on GEODE-10323:
---
Seen in [unit-test-openjdk17
#87|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/unit-test-openjdk17/builds/87]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.16.0-build.0339/test-results/test/1655255575/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.16.0-build.0339/test-artifacts/1655255575/unittestfiles-openjdk17-1.16.0-build.0339.tgz].
> OffHeapStorageJUnitTest testCreateOffHeapStorage fails with AssertionError:
> expected:<100> but was:<1048576>
>
>
> Key: GEODE-10323
> URL: https://issues.apache.org/jira/browse/GEODE-10323
> Project: Geode
> Issue Type: Bug
> Components: offheap
>Affects Versions: 1.16.0
>Reporter: Kirk Lund
>Assignee: Alberto Gomez
>Priority: Major
> Labels: pull-request-available
>
> [Please see 1st comment on this ticket below the description for
> recommendation on how to fix.]
> {{OffHeapStorageJUnitTest testCreateOffHeapStorage}} started failing
> intermittently due to commit a350ed2 which went in as
> "[GEODE-10087|https://issues.apache.org/jira/browse/GEODE-10087]: Enhance
> off-heap fragmentation visibility.
> ([#7407|https://github.com/apache/geode/pull/7407/commits/1640effc5c760afa8d9ec4c2743950bb1de0ef8f])".
> The failure stack looks like:
> {noformat}
> OffHeapStorageJUnitTest > testCreateOffHeapStorage FAILED
> java.lang.AssertionError: expected:<100> but was:<1048576>
> at org.junit.Assert.fail(Assert.java:89)
> at org.junit.Assert.failNotEquals(Assert.java:835)
> at org.junit.Assert.assertEquals(Assert.java:647)
> at org.junit.Assert.assertEquals(Assert.java:633)
> at
> org.apache.geode.internal.offheap.OffHeapStorageJUnitTest.testCreateOffHeapStorage(OffHeapStorageJUnitTest.java:220)
> {noformat}
> The cause is in {{MemoryAllocatorImpl}}. A new scheduled executor
> {{updateNonRealTimeStatsExecutor}} was added near the bottom of the
> constructor which immediately gets scheduled to invoke
> {{freeList::updateNonRealTimeStats}} repeatedly at the specified frequency of
> {{updateOffHeapStatsFrequencyMs}} whenever an instance of
> {{MemoryAllocatorImpl}} is created.
> {{freeList::updateNonRealTimeStats}} then updates {{setLargestFragment}} and
> {{setFreedChunks}}.
> Scheduling or starting any sort of threads from a constructor is considered a
> bad practice and should only be done via some sort of activation method such
> as {{start()}} which can be invoked from the static factory method for
> {{MemoryAllocatorImpl}}. The unit tests would then continue to construct
> instances via a constructor that does NOT invoke {{start()}}.
> {{OffHeapStorageJUnitTest testCreateOffHeapStorage}}, and possibly other
> tests, is written with the assumption that no other thread or component can
> or will be updating the {{OffHeapStats}}. Hence it is then safe for the test
> to setLargestFragment and then assert that it has the value passed in:
> {noformat}
> 219: stats.setLargestFragment(100);
> 220: assertEquals(100, stats.getLargestFragment());
> {noformat}
> Line 220 is the source of the assertion failure because
> {{updateNonRealTimeStatsExecutor}} is racing with the JUnit thread and
> changes the value of {{setLargestFragment}} immediately after the test sets
> the value to 100, but before the test invokes the assertion.
> Looking back at the [PR test
> results|https://cio.hdb.gemfire-ci.info/commits/pr/7407/junit?days=90] we can
> see that stress-new-test failed 5 times with this exact failure before being
> merged to develop:
> *
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7407/test-results/repeatTest/1646140652/
> *
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7407/test-results/repeatTest/1646154134/
> (x2)
> *
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7407/test-results/repeatTest/1646156997/
> *
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7407/test-results/repeatTest/1646170346/
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10380) When dispatcher socket buffer is full, the ReAuth won't get sent to the client causing a deadlock
[ https://issues.apache.org/jira/browse/GEODE-10380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-10380: --- Labels: needsTriage pull-request-available (was: needsTriage) > When dispatcher socket buffer is full, the ReAuth won't get sent to the > client causing a deadlock > - > > Key: GEODE-10380 > URL: https://issues.apache.org/jira/browse/GEODE-10380 > Project: Geode > Issue Type: Bug > Components: client/server >Affects Versions: 1.15.0 >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: needsTriage, pull-request-available > Attachments: Screen Shot 2022-06-14 at 5.37.18 PM.png > > > # message dispatcher trying to send a reAuth message to the client, but not > able to because the socket buffer is full. > # client updater is blocked waiting for a regionEntry lock when doing a > remove operation. > # the regionEntry lock is held by a client operation doing destroy on that > same key > # the client operation is waiting for the re_auth op to finish. > # the re_auth command on the server is blocked by the #1 holding the lock -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10380) When dispatcher socket buffer is full, the ReAuth won't get sent to the client causing a deadlock
[ https://issues.apache.org/jira/browse/GEODE-10380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao updated GEODE-10380: Affects Version/s: 1.15.0 > When dispatcher socket buffer is full, the ReAuth won't get sent to the > client causing a deadlock > - > > Key: GEODE-10380 > URL: https://issues.apache.org/jira/browse/GEODE-10380 > Project: Geode > Issue Type: Bug > Components: client/server >Affects Versions: 1.15.0 >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: needsTriage > Attachments: Screen Shot 2022-06-14 at 5.37.18 PM.png > > > # message dispatcher trying to send a reAuth message to the client, but not > able to because the socket buffer is full. > # client updater is blocked waiting for a regionEntry lock when doing a > remove operation. > # the regionEntry lock is held by a client operation doing destroy on that > same key > # the client operation is waiting for the re_auth op to finish. > # the re_auth command on the server is blocked by the #1 holding the lock -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-10380) When dispatcher socket buffer is full, the ReAuth won't get sent to the client causing a deadlock
[ https://issues.apache.org/jira/browse/GEODE-10380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17554697#comment-17554697 ] Jinmei Liao commented on GEODE-10380: - PR: https://github.com/apache/geode/pull/7801 > When dispatcher socket buffer is full, the ReAuth won't get sent to the > client causing a deadlock > - > > Key: GEODE-10380 > URL: https://issues.apache.org/jira/browse/GEODE-10380 > Project: Geode > Issue Type: Bug > Components: client/server >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: needsTriage > Attachments: Screen Shot 2022-06-14 at 5.37.18 PM.png > > > # message dispatcher trying to send a reAuth message to the client, but not > able to because the socket buffer is full. > # client updater is blocked waiting for a regionEntry lock when doing a > remove operation. > # the regionEntry lock is held by a client operation doing destroy on that > same key > # the client operation is waiting for the re_auth op to finish. > # the re_auth command on the server is blocked by the #1 holding the lock -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-9711) Fix the typos in ConflationDUnitTestHelper
[ https://issues.apache.org/jira/browse/GEODE-9711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nabarun Nag resolved GEODE-9711. Fix Version/s: 1.16.0 Resolution: Fixed > Fix the typos in ConflationDUnitTestHelper > -- > > Key: GEODE-9711 > URL: https://issues.apache.org/jira/browse/GEODE-9711 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Nabarun Nag >Priority: Major > Labels: pull-request-available > Fix For: 1.16.0 > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-10068) Make WanCopyRegionFunctionService thread pool configurable through configuration or property
[ https://issues.apache.org/jira/browse/GEODE-10068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols resolved GEODE-10068. -- Fix Version/s: 1.16.0 Resolution: Fixed > Make WanCopyRegionFunctionService thread pool configurable through > configuration or property > > > Key: GEODE-10068 > URL: https://issues.apache.org/jira/browse/GEODE-10068 > Project: Geode > Issue Type: Improvement > Components: wan >Affects Versions: 1.15.0 >Reporter: Udo Kohlmeyer >Priority: Major > Labels: pull-request-available > Fix For: 1.16.0 > > > The current implementation of `WanCopyRegionFunctionService` creates a fixed > thread pool of size 10. This is possibly something that one would like to be > able to configure. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-10346) Correct batch-time-interval description in documentation
[ https://issues.apache.org/jira/browse/GEODE-10346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols resolved GEODE-10346. -- Fix Version/s: 1.16.0 Resolution: Fixed > Correct batch-time-interval description in documentation > > > Key: GEODE-10346 > URL: https://issues.apache.org/jira/browse/GEODE-10346 > Project: Geode > Issue Type: Bug > Components: docs, wan >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > Fix For: 1.16.0 > > > The description of the batch-time-interval parameter for the Gateway Sender > in the Geode documentation states the following: > "Maximum amount of time, in ms, that can elapse before a batch is delivered." > Nevertheless, that is not completely true. > The number of ms that can elapse before a batch is delivered could be longer > than what is configured in batch-time-interval in the case that the batch > being created has not yet reached the value of max-batch-size and there are > still events in the gateway sender's queue to be added to the batch. If that > is the case, new events will keep being added to the batch without taking > into account the value for batch-time-interval. > The batch-time-interval parameter is only used when the batch being filled > has not reached the max-batch-size but there are no events in the queue. In > that case, in order not to delay the delivery of the batch until there are > events in the queue, this value is used to determine if the batch must be > sent. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-10155) ServerConnection thread hangs when client function execution times-out
[ https://issues.apache.org/jira/browse/GEODE-10155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols resolved GEODE-10155. -- Fix Version/s: 1.16.0 Resolution: Fixed > ServerConnection thread hangs when client function execution times-out > -- > > Key: GEODE-10155 > URL: https://issues.apache.org/jira/browse/GEODE-10155 > Project: Geode > Issue Type: Bug > Components: core, functions >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > Fix For: 1.16.0 > > > If a Geode client executes a non-HA server function (isHA=false) with a > timeout > and > the function is handled in the Geode server by a "Function Execution > Processor" thread (for example by calling the function with onRegion() on a > partitioned region without a filter) > and > the function times-out before the server has answered back with all the > results > then > the ServerConnection thread that originally started to handle the function > execution will be stuck forever. > > If this happens several times and the max-threads parameters is set to a > value greater than 0, the server will eventually run out of ServerConnection > threads and will not be able to process more client requests. > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-10352) Update Dockerfile to use Ruby >= 2.6 in the tool to preview Geode documentation
[ https://issues.apache.org/jira/browse/GEODE-10352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols resolved GEODE-10352. -- Fix Version/s: 1.16.0 Resolution: Fixed > Update Dockerfile to use Ruby >= 2.6 in the tool to preview Geode > documentation > --- > > Key: GEODE-10352 > URL: https://issues.apache.org/jira/browse/GEODE-10352 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > Fix For: 1.16.0 > > > The script to preview the documentation of Geode (./preview-user-guide.sh) is > not working anymore. > The following error appears while running it (unless you have a previously > downloaded geodedocs/temp docker image in your local docker repo): > ERROR: Error installing elasticsearch: > The last version of faraday (>= 0) to support your Ruby & RubyGems was > 1.10.0. Try installing it with `gem install faraday -v 1.10.0` and then > running the current command again > faraday requires Ruby version >= 2.6. The current ruby version is > 2.5.9.229. > That error prevents the preview script to work. > It is needed to update the docker image used to preview the documentation to > use a Ruby version >= 2.6 -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-10348) Correct documentation about conflation
[ https://issues.apache.org/jira/browse/GEODE-10348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols resolved GEODE-10348. -- Fix Version/s: 1.16.0 Resolution: Fixed > Correct documentation about conflation > -- > > Key: GEODE-10348 > URL: https://issues.apache.org/jira/browse/GEODE-10348 > Project: Geode > Issue Type: Bug > Components: docs, wan >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > Fix For: 1.16.0 > > > The Geode documentation states on conflation: > "When an update is added to a queue that has conflation enabled, if there is > already an update message in the queue for the entry key, then the existing > message assumes the value of the new update and the new update is dropped, as > shown here for key A." > Nevertheless, that is not correct. The actual behavior is the following: > "When an update is added to a queue that has conflation enabled, if there is > already an update message in the queue for the entry key, then the existing > message is removed and the new update is added to the end of the queue, as > shown here for key A." -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10305) CI Failure: TomcatSessionBackwardsCompatibilityTomcat8WithOldModulesMixedWithCurrentCanDoPutFromOldModuleTest failed
[
https://issues.apache.org/jira/browse/GEODE-10305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols updated GEODE-10305:
-
Fix Version/s: 1.16.0
> CI Failure:
> TomcatSessionBackwardsCompatibilityTomcat8WithOldModulesMixedWithCurrentCanDoPutFromOldModuleTest
> failed
> -
>
> Key: GEODE-10305
> URL: https://issues.apache.org/jira/browse/GEODE-10305
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.16.0
>Reporter: Eric Shu
>Assignee: Jianxia Chen
>Priority: Major
> Labels: needsTriage, pull-request-available
> Fix For: 1.16.0
>
>
> {noformat}
> org.gradle.internal.exceptions.DefaultMultiCauseException: Multiple Failures
> (2 failures)
> org.opentest4j.AssertionFailedError: [The Cache Server process
> terminated unexpectedly with exit status 1. Please refer to the log file in
> /tmp/junit439159077415808630/server for full details.
> SLF4J: Class path contains multiple SLF4J bindings.
> SLF4J: Found binding in
> [jar:file:/tmp/geode_container_install8549633813411705254/cargo_containers/Tomcat8AndCurrentModules/tomcat-8.5.66/apache-tomcat-8.5.66/lib/slf4j-jdk14-1.7.32.jar!/org/slf4j/impl/StaticLoggerBinder.class]
> SLF4J: Found binding in
> [jar:file:/home/geode/geode/geode-assembly/build/install/apache-geode/lib/log4j-slf4j-impl-2.17.2.jar!/org/slf4j/impl/StaticLoggerBinder.class]
> SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an
> explanation.
> SLF4J: Actual binding is of type [org.slf4j.impl.JDK14LoggerFactory]
> {noformat}
> This is caused by ForcedDisconnectException during cache creation.
> {noformat}
> Exception in thread "main"
> org.apache.geode.distributed.DistributedSystemDisconnectedException:
> Distribution manager on
> heavy-lifter-e2fd6dd2-c530-54ef-ab7c-b95e0e8cca34(server:240126):41036
> started at Thu May 05 21:36:30 UTC 2022: Member isn't responding to heartbeat
> requests, caused by org.apache.geode.ForcedDisconnectException: Member isn't
> responding to heartbeat requests
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager$Stopper.generateCancelledException(ClusterDistributionManager.java:2899)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Stopper.generateCancelledException(InternalDistributedSystem.java:1183)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl$Stopper.generateCancelledException(GemFireCacheImpl.java:5201)
> at
> org.apache.geode.CancelCriterion.checkCancelInProgress(CancelCriterion.java:83)
> at
> org.apache.geode.cache.query.cq.internal.CqServiceImpl.(CqServiceImpl.java:166)
> at
> org.apache.geode.cache.query.cq.internal.CqServiceFactoryImpl.create(CqServiceFactoryImpl.java:59)
> at
> org.apache.geode.cache.query.internal.cq.CqServiceProvider.create(CqServiceProvider.java:63)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.(GemFireCacheImpl.java:1004)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.(GemFireCacheImpl.java:864)
> at
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:187)
> at
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:158)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:142)
> at
> org.apache.geode.distributed.internal.DefaultServerLauncherCacheProvider.createCache(DefaultServerLauncherCacheProvider.java:52)
> at
> org.apache.geode.distributed.ServerLauncher.createCache(ServerLauncher.java:913)
> at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:814)
> at
> org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:740)
> at
> org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:259)
> Caused by: org.apache.geode.ForcedDisconnectException: Member isn't
> responding to heartbeat requests
> at
> org.apache.geode.distributed.internal.DistributionImpl$LifecycleListenerImpl.forcedDisconnect(DistributionImpl.java:941)
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.lambda$uncleanShutdownDS$0(GMSMembership.java:1792)
> at java.lang.Thread.run(Thread.java:750)
> {noformat}
> Artifacts can be found here:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/upgrade-test-openjdk8/builds/331
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10308) CI Failure: Tomcat8SessionsClientServerDUnitTest.testSessionExpiration1 failed
[
https://issues.apache.org/jira/browse/GEODE-10308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols updated GEODE-10308:
-
Fix Version/s: 1.16.0
> CI Failure: Tomcat8SessionsClientServerDUnitTest.testSessionExpiration1 failed
> --
>
> Key: GEODE-10308
> URL: https://issues.apache.org/jira/browse/GEODE-10308
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.16.0
>Reporter: Eric Shu
>Assignee: Jianxia Chen
>Priority: Major
> Labels: needsTriage, pull-request-available
> Fix For: 1.16.0
>
>
> {noformat}
> org.apache.geode.cache.CacheClosedException: The cache is closed.
> at
> org.apache.geode.internal.cache.GemFireCacheImpl$Stopper.generateCancelledException(GemFireCacheImpl.java:5207)
> at
> org.apache.geode.internal.cache.LocalRegion$Stopper.generateCancelledException(LocalRegion.java:11342)
> at
> org.apache.geode.CancelCriterion.checkCancelInProgress(CancelCriterion.java:83)
> at
> org.apache.geode.CancelCriterion.checkCancelInProgress(CancelCriterion.java:87)
> at
> org.apache.geode.internal.cache.execute.InternalFunctionExecutionServiceImpl.onRegion(InternalFunctionExecutionServiceImpl.java:122)
> at
> org.apache.geode.cache.execute.FunctionService.onRegion(FunctionService.java:79)
> at
> org.apache.geode.modules.session.catalina.ClientServerSessionCache.getExecutionForFunctionOnRegionWithFilter(ClientServerSessionCache.java:283)
> at
> org.apache.geode.modules.session.catalina.ClientServerSessionCache.touchSessions(ClientServerSessionCache.java:101)
> at
> org.apache.geode.modules.session.catalina.DeltaSessionManager$1.run(DeltaSessionManager.java:534)
> at java.util.TimerThread.mainLoop(Timer.java:556)
> at java.util.TimerThread.run(Timer.java:506)
> {noformat}
> Artifacts can be found here:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/distributed-test-openjdk11/builds/334
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Resolved] (GEODE-10365) Add missing configuration properties to table
[ https://issues.apache.org/jira/browse/GEODE-10365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols resolved GEODE-10365. -- Fix Version/s: 1.12.10 1.14.5 1.15.0 1.16.0 Resolution: Fixed > Add missing configuration properties to table > - > > Key: GEODE-10365 > URL: https://issues.apache.org/jira/browse/GEODE-10365 > Project: Geode > Issue Type: Improvement > Components: docs >Affects Versions: 1.12.9, 1.14.5, 1.15.0 >Reporter: Max Hufnagel >Assignee: Max Hufnagel >Priority: Major > Labels: pull-request-available > Fix For: 1.12.10, 1.14.5, 1.15.0, 1.16.0 > > > Add ssl-keystore-type, ssl-truststore-type to appropriate table in > [https://geode.apache.org/docs/guide/112/managing/security/implementing_ssl.html] -- This message was sent by Atlassian Jira (v8.20.7#820007)
