[jira] [Commented] (GEODE-9531) CI Failure: TxCommitMessageBCClientToServerTxPartitionTest fails with ForcedDisconnectException
[
https://issues.apache.org/jira/browse/GEODE-9531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17434502#comment-17434502
]
Dale Emery commented on GEODE-9531:
---
I was curious about the warnings from the stat sampling thread, so I checked a
bunch of runs with failures. Eight of those failure runs had swarms of those
warnings. By "swarm" I mean that multiple tests issued that warning at about
the same time (within a second or two). In all eight of those runs, the
following tests were executing at the time of the first warning:
# org.apache.geode.security.ClientAuthorizationCQDUnitTest
testAllOpsWithFailover2
# org.apache.geode.management.GfshRebalanceCommandCompatibilityTest
whenCurrentVersionLocatorsExecuteRebalanceOnOldServersThenItMustSucceed
# org.apache.geode.management.ConfigurationCompatibilityTest
whenConfigurationIsExchangedBetweenMixedVersionLocatorsThenItShouldNotThrowExceptions
#
org.apache.geode.cache.wan.WANRollingUpgradeSecondaryEventsNotReprocessedAfterOldSiteMemberFailover
testSecondaryEventsNotReprocessedAfterOldSiteMemberFailover
#
org.apache.geode.cache.wan.WANRollingUpgradeSecondaryEventsNotReprocessedAfterCurrentSiteMemberFailoverWithOldClient
testSecondaryEventsNotReprocessedAfterCurrentSiteMemberFailoverWithOldClient
#
org.apache.geode.cache.wan.WANRollingUpgradeEventProcessingOldSiteOneCurrentSiteTwo
testEventProcessingOldSiteOneCurrentSiteTwo
#
org.apache.geode.cache.wan.WANRollingUpgradeEventProcessingMixedSiteOneOldSiteTwo
EventProcessingMixedSiteOneOldSiteTwo
#
org.apache.geode.cache.wan.WANRollingUpgradeEventProcessingMixedSiteOneCurrentSiteTwo
EventProcessingMixedSiteOneCurrentSiteTwo
#
org.apache.geode.cache.wan.WANRollingUpgradeCreateGatewaySenderMixedSiteOneCurrentSiteTwo
CreateGatewaySenderMixedSiteOneCurrentSiteTwo
#
org.apache.geode.cache.lucene.RollingUpgradeReindexShouldBeSuccessfulWhenAllServersRollToCurrentVersion
luceneReindexShouldBeSuccessfulWhenAllServersRollToCurrentVersion
#
org.apache.geode.cache.lucene.RollingUpgradeQueryReturnsCorrectResultsAfterServersRollOverOnPersistentPartitionRegion
luceneQueryReturnsCorrectResultsAfterServersRollOverOnPersistentPartitionRegion
#
org.apache.geode.cache.lucene.RollingUpgradeQueryReturnsCorrectResultsAfterServersRollOverOnPartitionRegion
luceneQueryReturnsCorrectResultsAfterServersRollOverOnPartitionRegion
#
org.apache.geode.cache.lucene.RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOverAllBucketsCreated
#
org.apache.geode.cache.lucene.RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOver
luceneQueryReturnsCorrectResultsAfterClientAndServersAreRolledOver
#
org.apache.geode.cache.lucene.RollingUpgradeQueryReturnsCorrectResultAfterTwoLocatorsWithTwoServersAreRolled
luceneQueryReturnsCorrectResultAfterTwoLocatorsWithTwoServersAreRolled
Perhaps one of these tests is doing something unusually CPU intensive.
Given that mosts tests succeeded even after emitting the warning, I may be able
to prune this list of tests by analyzing "green" jobs that have those warnings.
> CI Failure: TxCommitMessageBCClientToServerTxPartitionTest fails with
> ForcedDisconnectException
> ---
>
> Key: GEODE-9531
> URL: https://issues.apache.org/jira/browse/GEODE-9531
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.14.0
>Reporter: Donal Evans
>Assignee: Eric Shu
>Priority: Major
> Labels: GeodeOperationAPI
>
> {noformat}
> org.apache.geode.internal.cache.TxCommitMessageBCClientToServerTxPartitionTest
> > test[11] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.TxCommitMessageBCTestBase$$Lambda$55/2050040059.run
> in VM 2 running on Host 1797ac7f43c4 with 5 VMs
> Caused by:
> org.apache.geode.distributed.DistributedSystemDisconnectedException:
> membership shutdown, caused by org.apache.geode.ForcedDisconnectException:
> Member isn't responding to heartbeat requests
> Caused by:
> org.apache.geode.ForcedDisconnectException: Member isn't
> responding to heartbeat requests
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in 'dunit_suspect-vm2.log' at line 993
> [fatal 2021/05/25 16:58:13.700 GMT
> tid=1349] Membership service failure: Member isn't responding to heartbeat
> requests
>
> org.apache.geode.distributed.internal.membership.api.MemberDisconnectedException:
> Member isn't responding to heartbeat requests
> at
> org.apache.
[jira] [Created] (GEODE-9791) Upgrade Mockito dependency to 4.0.0
Dale Emery created GEODE-9791: - Summary: Upgrade Mockito dependency to 4.0.0 Key: GEODE-9791 URL: https://issues.apache.org/jira/browse/GEODE-9791 Project: Geode Issue Type: Improvement Components: tests Affects Versions: 1.15.0 Reporter: Dale Emery Upgrade Mockito dependency from version 3.12.4 to 4.0.0 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9791) Upgrade Mockito dependency to 4.0.0
[ https://issues.apache.org/jira/browse/GEODE-9791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale Emery reassigned GEODE-9791: - Assignee: Dale Emery > Upgrade Mockito dependency to 4.0.0 > --- > > Key: GEODE-9791 > URL: https://issues.apache.org/jira/browse/GEODE-9791 > Project: Geode > Issue Type: Improvement > Components: tests >Affects Versions: 1.15.0 >Reporter: Dale Emery >Assignee: Dale Emery >Priority: Major > Labels: pull-request-available > > Upgrade Mockito dependency from version 3.12.4 to 4.0.0 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9791) Upgrade Mockito dependency to 4.0.0
[ https://issues.apache.org/jira/browse/GEODE-9791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale Emery updated GEODE-9791: -- Labels: GeodeOperationAPI pull-request-available (was: pull-request-available) > Upgrade Mockito dependency to 4.0.0 > --- > > Key: GEODE-9791 > URL: https://issues.apache.org/jira/browse/GEODE-9791 > Project: Geode > Issue Type: Improvement > Components: tests >Affects Versions: 1.15.0 >Reporter: Dale Emery >Assignee: Dale Emery >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > Upgrade Mockito dependency from version 3.12.4 to 4.0.0 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-9791) Upgrade Mockito dependency to 4.0.0
[ https://issues.apache.org/jira/browse/GEODE-9791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale Emery closed GEODE-9791. - > Upgrade Mockito dependency to 4.0.0 > --- > > Key: GEODE-9791 > URL: https://issues.apache.org/jira/browse/GEODE-9791 > Project: Geode > Issue Type: Improvement > Components: tests >Affects Versions: 1.15.0 >Reporter: Dale Emery >Assignee: Dale Emery >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > Upgrade Mockito dependency from version 3.12.4 to 4.0.0 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-9791) Upgrade Mockito dependency to 4.0.0
[ https://issues.apache.org/jira/browse/GEODE-9791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale Emery resolved GEODE-9791. --- Resolution: Fixed > Upgrade Mockito dependency to 4.0.0 > --- > > Key: GEODE-9791 > URL: https://issues.apache.org/jira/browse/GEODE-9791 > Project: Geode > Issue Type: Improvement > Components: tests >Affects Versions: 1.15.0 >Reporter: Dale Emery >Assignee: Dale Emery >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > Upgrade Mockito dependency from version 3.12.4 to 4.0.0 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-9824) AvailablePortHelper configures itself poorly in a test JVM
[ https://issues.apache.org/jira/browse/GEODE-9824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale Emery reassigned GEODE-9824: - Assignee: Dale Emery > AvailablePortHelper configures itself poorly in a test JVM > -- > > Key: GEODE-9824 > URL: https://issues.apache.org/jira/browse/GEODE-9824 > Project: Geode > Issue Type: Bug > Components: tests >Affects Versions: 1.15.0 >Reporter: Dale Emery >Assignee: Dale Emery >Priority: Major > > In the test JVM, `AvailablePortHelper` initializes its "next port to check" > to a randomly selected port. That randomly selected port might be one of the > ones that a child VM will check early. > # Here's a problematic sequence of events: > In the test JVM, `AvailablePortHelper` learns that the range of ports > available to it is (say) 23750–24166. It randomly selects one of those as its > "next port to check." Let's suppose it randomly picks 23854 as its starting > port. > # The test starts vm0. In vm0 `AvailablePortHelper` initializes its "next > port to check" by computing it based on its VM number. For the given > available port range (23750–24166), vm0 will *always* start at 23854. > # At this point, both the test JVM and child vm0 have the exact same "next > port to check." Trouble is looming. > # The test requests a port in the test JVM, and gets the randomly selected > one: 23854. It doesn't bind to this port yet. Later it will try to start a > server on this port in vm1. Trouble is fast approaching. > # The test invokes `AvailablePortHelper` in vm0, and gets vm0's starting > port: 23854. The test then starts a server, which binds to that port. > # At this point, the test JVM thinks it has reserved the port, but vm0 has > bound to it. Trouble is imminent. > # The test tries to start a server in vm1, using the port it believes it > reserved. Trouble has arrived. The operation fails because the port is > already in use. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-9824) AvailablePortHelper configures itself poorly in a test JVM
Dale Emery created GEODE-9824: - Summary: AvailablePortHelper configures itself poorly in a test JVM Key: GEODE-9824 URL: https://issues.apache.org/jira/browse/GEODE-9824 Project: Geode Issue Type: Bug Components: tests Affects Versions: 1.15.0 Reporter: Dale Emery In the test JVM, `AvailablePortHelper` initializes its "next port to check" to a randomly selected port. That randomly selected port might be one of the ones that a child VM will check early. # Here's a problematic sequence of events: In the test JVM, `AvailablePortHelper` learns that the range of ports available to it is (say) 23750–24166. It randomly selects one of those as its "next port to check." Let's suppose it randomly picks 23854 as its starting port. # The test starts vm0. In vm0 `AvailablePortHelper` initializes its "next port to check" by computing it based on its VM number. For the given available port range (23750–24166), vm0 will *always* start at 23854. # At this point, both the test JVM and child vm0 have the exact same "next port to check." Trouble is looming. # The test requests a port in the test JVM, and gets the randomly selected one: 23854. It doesn't bind to this port yet. Later it will try to start a server on this port in vm1. Trouble is fast approaching. # The test invokes `AvailablePortHelper` in vm0, and gets vm0's starting port: 23854. The test then starts a server, which binds to that port. # At this point, the test JVM thinks it has reserved the port, but vm0 has bound to it. Trouble is imminent. # The test tries to start a server in vm1, using the port it believes it reserved. Trouble has arrived. The operation fails because the port is already in use. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9824) AvailablePortHelper configures itself poorly in a test JVM
[ https://issues.apache.org/jira/browse/GEODE-9824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale Emery updated GEODE-9824: -- Description: In the test JVM, `AvailablePortHelper` initializes its "next port to check" to a randomly selected port. That randomly selected port might be one of the ones that a child VM will check early. Here's a problematic sequence of events: # In the test JVM, `AvailablePortHelper` learns that the range of ports available to it is (say) 23750–24166. It randomly selects one of those as its "next port to check." Let's suppose it randomly picks 23854 as its starting port. # The test starts vm0. In vm0 `AvailablePortHelper` initializes its "next port to check" by computing it based on its VM number. For the given available port range (23750–24166), vm0 will *always* start at 23854. # At this point, both the test JVM and child vm0 have the exact same "next port to check." Trouble is looming. # The test requests a port in the test JVM, and gets the randomly selected one: 23854. It doesn't bind to this port yet. Later it will try to start a server on this port in vm1. Trouble is fast approaching. # The test invokes `AvailablePortHelper` in vm0, and gets vm0's starting port: 23854. The test then starts a server, which binds to that port. # At this point, the test JVM thinks it has reserved the port, but vm0 has bound to it. Trouble is imminent. # The test tries to start a server in vm1, using the port it believes it reserved. Trouble has arrived. The operation fails because the port is already in use. was: In the test JVM, `AvailablePortHelper` initializes its "next port to check" to a randomly selected port. That randomly selected port might be one of the ones that a child VM will check early. # Here's a problematic sequence of events: In the test JVM, `AvailablePortHelper` learns that the range of ports available to it is (say) 23750–24166. It randomly selects one of those as its "next port to check." Let's suppose it randomly picks 23854 as its starting port. # The test starts vm0. In vm0 `AvailablePortHelper` initializes its "next port to check" by computing it based on its VM number. For the given available port range (23750–24166), vm0 will *always* start at 23854. # At this point, both the test JVM and child vm0 have the exact same "next port to check." Trouble is looming. # The test requests a port in the test JVM, and gets the randomly selected one: 23854. It doesn't bind to this port yet. Later it will try to start a server on this port in vm1. Trouble is fast approaching. # The test invokes `AvailablePortHelper` in vm0, and gets vm0's starting port: 23854. The test then starts a server, which binds to that port. # At this point, the test JVM thinks it has reserved the port, but vm0 has bound to it. Trouble is imminent. # The test tries to start a server in vm1, using the port it believes it reserved. Trouble has arrived. The operation fails because the port is already in use. > AvailablePortHelper configures itself poorly in a test JVM > -- > > Key: GEODE-9824 > URL: https://issues.apache.org/jira/browse/GEODE-9824 > Project: Geode > Issue Type: Bug > Components: tests >Affects Versions: 1.15.0 >Reporter: Dale Emery >Assignee: Dale Emery >Priority: Major > > In the test JVM, `AvailablePortHelper` initializes its "next port to check" > to a randomly selected port. That randomly selected port might be one of the > ones that a child VM will check early. > Here's a problematic sequence of events: > # In the test JVM, `AvailablePortHelper` learns that the range of ports > available to it is (say) 23750–24166. It randomly selects one of those as its > "next port to check." Let's suppose it randomly picks 23854 as its starting > port. > # The test starts vm0. In vm0 `AvailablePortHelper` initializes its "next > port to check" by computing it based on its VM number. For the given > available port range (23750–24166), vm0 will *always* start at 23854. > # At this point, both the test JVM and child vm0 have the exact same "next > port to check." Trouble is looming. > # The test requests a port in the test JVM, and gets the randomly selected > one: 23854. It doesn't bind to this port yet. Later it will try to start a > server on this port in vm1. Trouble is fast approaching. > # The test invokes `AvailablePortHelper` in vm0, and gets vm0's starting > port: 23854. The test then starts a server, which binds to that port. > # At this point, the test JVM thinks it has reserved the port, but vm0 has > bound to it. Trouble is imminent. > # The test tries to start a server in vm1, using the port it believes it > reserved. Trouble has arrived. The operation fails because the port is > already in use.
[jira] [Updated] (GEODE-9824) AvailablePortHelper configures itself poorly in a test JVM
[ https://issues.apache.org/jira/browse/GEODE-9824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale Emery updated GEODE-9824: -- Labels: GeodeOperationAPI (was: ) > AvailablePortHelper configures itself poorly in a test JVM > -- > > Key: GEODE-9824 > URL: https://issues.apache.org/jira/browse/GEODE-9824 > Project: Geode > Issue Type: Bug > Components: tests >Affects Versions: 1.15.0 >Reporter: Dale Emery >Assignee: Dale Emery >Priority: Major > Labels: GeodeOperationAPI > > In the test JVM, `AvailablePortHelper` initializes its "next port to check" > to a randomly selected port. That randomly selected port might be one of the > ones that a child VM will check early. > Here's a problematic sequence of events: > # In the test JVM, `AvailablePortHelper` learns that the range of ports > available to it is (say) 23750–24166. It randomly selects one of those as its > "next port to check." Let's suppose it randomly picks 23854 as its starting > port. > # The test starts vm0. In vm0 `AvailablePortHelper` initializes its "next > port to check" by computing it based on its VM number. For the given > available port range (23750–24166), vm0 will *always* start at 23854. > # At this point, both the test JVM and child vm0 have the exact same "next > port to check." Trouble is looming. > # The test requests a port in the test JVM, and gets the randomly selected > one: 23854. It doesn't bind to this port yet. Later it will try to start a > server on this port in vm1. Trouble is fast approaching. > # The test invokes `AvailablePortHelper` in vm0, and gets vm0's starting > port: 23854. The test then starts a server, which binds to that port. > # At this point, the test JVM thinks it has reserved the port, but vm0 has > bound to it. Trouble is imminent. > # The test tries to start a server in vm1, using the port it believes it > reserved. Trouble has arrived. The operation fails because the port is > already in use. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-9536) Run all Windows distributed tests in CI, in parallel
[ https://issues.apache.org/jira/browse/GEODE-9536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale Emery reassigned GEODE-9536: - Assignee: (was: Dale Emery) > Run all Windows distributed tests in CI, in parallel > > > Key: GEODE-9536 > URL: https://issues.apache.org/jira/browse/GEODE-9536 > Project: Geode > Issue Type: Test > Components: ci, tests >Affects Versions: 1.15.0 >Reporter: Dale Emery >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > Currently CI runs only a subset of distributed tests on Windows, and it runs > them sequentially. > Change CI to run all distributed tests in Windows, and to run them in > parallel. > This requires changing a small number tests to allow them to run on Windows. > It may require additional changes to allow them to run in parallel on Windows. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9638) CI failure: DeployedJarTest getDeployedFileName failed on Windows intermittently
[ https://issues.apache.org/jira/browse/GEODE-9638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17446674#comment-17446674 ] Dale Emery commented on GEODE-9638: --- This test uses our custom Java compiler class to create jars. When the compiler finishes compiling, it deletes the temporary files it created. To delete the temporary files, it calls Apache commons `FileUtils.deleteDirectory(dir)`. On Windows, `FileUtils` sometimes throws `DirectoryNotEmptyException` even though it has recursively removed all of `dir`'s contents before attempting to delete `dir`. I don't know the specific cause of this. I suspect that `dir` or one of its files remains locked for a short time after `dir` is cleaned. Windows is known to refuse to delete a locked file. I have submitted a PR to change our custom Java compiler to create its temporary files in memory, rather than on the file system. That way there are no file system files to delete. > CI failure: DeployedJarTest getDeployedFileName failed on Windows > intermittently > - > > Key: GEODE-9638 > URL: https://issues.apache.org/jira/browse/GEODE-9638 > Project: Geode > Issue Type: Bug > Components: core >Affects Versions: 1.15.0 >Reporter: Darrel Schneider >Assignee: Dale Emery >Priority: Major > Labels: GeodeOperationAPI, flaky, needsTriage, > pull-request-available > > org.apache.geode.deployment.internal.DeployedJarTest > getDeployedFileName > FAILED > java.nio.file.DirectoryNotEmptyException: > C:\Users\geode\AppData\Local\Temp\javaCompiler2976436474406314797\classes > at > sun.nio.fs.WindowsFileSystemProvider.implDelete(WindowsFileSystemProvider.java:266) > at > sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:103) > at java.nio.file.Files.delete(Files.java:1126) > at org.apache.commons.io.FileUtils.delete(FileUtils.java:1175) > at > org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:1194) > at > org.apache.geode.test.compiler.JavaCompiler.compile(JavaCompiler.java:91) > at > org.apache.geode.test.compiler.JarBuilder.buildJarFromClassNames(JarBuilder.java:83) > at > org.apache.geode.deployment.internal.DeployedJarTest.createJarFile(DeployedJarTest.java:82) > at > org.apache.geode.deployment.internal.DeployedJarTest.getDeployedFileName(DeployedJarTest.java:65) > see: > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/windows-unit-test-openjdk8/builds/206 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (GEODE-9791) Upgrade Mockito dependency to 4.0.0
[ https://issues.apache.org/jira/browse/GEODE-9791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale Emery closed GEODE-9791. - > Upgrade Mockito dependency to 4.0.0 > --- > > Key: GEODE-9791 > URL: https://issues.apache.org/jira/browse/GEODE-9791 > Project: Geode > Issue Type: Improvement > Components: tests >Affects Versions: 1.15.0 >Reporter: Dale Emery >Assignee: Dale Emery >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.15.0 > > > Upgrade Mockito dependency from version 3.12.4 to 4.0.0 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-9638) CI failure: DeployedJarTest getDeployedFileName failed on Windows intermittently
[ https://issues.apache.org/jira/browse/GEODE-9638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale Emery resolved GEODE-9638. --- Resolution: Fixed > CI failure: DeployedJarTest getDeployedFileName failed on Windows > intermittently > - > > Key: GEODE-9638 > URL: https://issues.apache.org/jira/browse/GEODE-9638 > Project: Geode > Issue Type: Bug > Components: core >Affects Versions: 1.15.0 >Reporter: Darrel Schneider >Assignee: Dale Emery >Priority: Major > Labels: GeodeOperationAPI, flaky, pull-request-available > > org.apache.geode.deployment.internal.DeployedJarTest > getDeployedFileName > FAILED > java.nio.file.DirectoryNotEmptyException: > C:\Users\geode\AppData\Local\Temp\javaCompiler2976436474406314797\classes > at > sun.nio.fs.WindowsFileSystemProvider.implDelete(WindowsFileSystemProvider.java:266) > at > sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:103) > at java.nio.file.Files.delete(Files.java:1126) > at org.apache.commons.io.FileUtils.delete(FileUtils.java:1175) > at > org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:1194) > at > org.apache.geode.test.compiler.JavaCompiler.compile(JavaCompiler.java:91) > at > org.apache.geode.test.compiler.JarBuilder.buildJarFromClassNames(JarBuilder.java:83) > at > org.apache.geode.deployment.internal.DeployedJarTest.createJarFile(DeployedJarTest.java:82) > at > org.apache.geode.deployment.internal.DeployedJarTest.getDeployedFileName(DeployedJarTest.java:65) > see: > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/windows-unit-test-openjdk8/builds/206 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (GEODE-9638) CI failure: DeployedJarTest getDeployedFileName failed on Windows intermittently
[ https://issues.apache.org/jira/browse/GEODE-9638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale Emery closed GEODE-9638. - > CI failure: DeployedJarTest getDeployedFileName failed on Windows > intermittently > - > > Key: GEODE-9638 > URL: https://issues.apache.org/jira/browse/GEODE-9638 > Project: Geode > Issue Type: Bug > Components: core >Affects Versions: 1.15.0 >Reporter: Darrel Schneider >Assignee: Dale Emery >Priority: Major > Labels: GeodeOperationAPI, flaky, pull-request-available > > org.apache.geode.deployment.internal.DeployedJarTest > getDeployedFileName > FAILED > java.nio.file.DirectoryNotEmptyException: > C:\Users\geode\AppData\Local\Temp\javaCompiler2976436474406314797\classes > at > sun.nio.fs.WindowsFileSystemProvider.implDelete(WindowsFileSystemProvider.java:266) > at > sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:103) > at java.nio.file.Files.delete(Files.java:1126) > at org.apache.commons.io.FileUtils.delete(FileUtils.java:1175) > at > org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:1194) > at > org.apache.geode.test.compiler.JavaCompiler.compile(JavaCompiler.java:91) > at > org.apache.geode.test.compiler.JarBuilder.buildJarFromClassNames(JarBuilder.java:83) > at > org.apache.geode.deployment.internal.DeployedJarTest.createJarFile(DeployedJarTest.java:82) > at > org.apache.geode.deployment.internal.DeployedJarTest.getDeployedFileName(DeployedJarTest.java:65) > see: > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/windows-unit-test-openjdk8/builds/206 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9638) CI failure: DeployedJarTest getDeployedFileName failed on Windows intermittently
[ https://issues.apache.org/jira/browse/GEODE-9638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale Emery updated GEODE-9638: -- Fix Version/s: 1.15.0 > CI failure: DeployedJarTest getDeployedFileName failed on Windows > intermittently > - > > Key: GEODE-9638 > URL: https://issues.apache.org/jira/browse/GEODE-9638 > Project: Geode > Issue Type: Bug > Components: core >Affects Versions: 1.15.0 >Reporter: Darrel Schneider >Assignee: Dale Emery >Priority: Major > Labels: GeodeOperationAPI, flaky, pull-request-available > Fix For: 1.15.0 > > > org.apache.geode.deployment.internal.DeployedJarTest > getDeployedFileName > FAILED > java.nio.file.DirectoryNotEmptyException: > C:\Users\geode\AppData\Local\Temp\javaCompiler2976436474406314797\classes > at > sun.nio.fs.WindowsFileSystemProvider.implDelete(WindowsFileSystemProvider.java:266) > at > sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:103) > at java.nio.file.Files.delete(Files.java:1126) > at org.apache.commons.io.FileUtils.delete(FileUtils.java:1175) > at > org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:1194) > at > org.apache.geode.test.compiler.JavaCompiler.compile(JavaCompiler.java:91) > at > org.apache.geode.test.compiler.JarBuilder.buildJarFromClassNames(JarBuilder.java:83) > at > org.apache.geode.deployment.internal.DeployedJarTest.createJarFile(DeployedJarTest.java:82) > at > org.apache.geode.deployment.internal.DeployedJarTest.getDeployedFileName(DeployedJarTest.java:65) > see: > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/windows-unit-test-openjdk8/builds/206 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (GEODE-9824) AvailablePortHelper configures itself poorly in a test JVM
[ https://issues.apache.org/jira/browse/GEODE-9824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale Emery closed GEODE-9824. - > AvailablePortHelper configures itself poorly in a test JVM > -- > > Key: GEODE-9824 > URL: https://issues.apache.org/jira/browse/GEODE-9824 > Project: Geode > Issue Type: Bug > Components: tests >Affects Versions: 1.15.0 >Reporter: Dale Emery >Assignee: Dale Emery >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.15.0 > > > In the test JVM, `AvailablePortHelper` initializes its "next port to check" > to a randomly selected port. That randomly selected port might be one of the > ones that a child VM will check early. > Here's a problematic sequence of events: > # In the test JVM, `AvailablePortHelper` learns that the range of ports > available to it is (say) 23750–24166. It randomly selects one of those as its > "next port to check." Let's suppose it randomly picks 23854 as its starting > port. > # The test starts vm0. In vm0 `AvailablePortHelper` initializes its "next > port to check" by computing it based on its VM number. For the given > available port range (23750–24166), vm0 will *always* start at 23854. > # At this point, both the test JVM and child vm0 have the exact same "next > port to check." Trouble is looming. > # The test requests a port in the test JVM, and gets the randomly selected > one: 23854. It doesn't bind to this port yet. Later it will try to start a > server on this port in vm1. Trouble is fast approaching. > # The test invokes `AvailablePortHelper` in vm0, and gets vm0's starting > port: 23854. The test then starts a server, which binds to that port. > # At this point, the test JVM thinks it has reserved the port, but vm0 has > bound to it. Trouble is imminent. > # The test tries to start a server in vm1, using the port it believes it > reserved. Trouble has arrived. The operation fails because the port is > already in use. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-9824) AvailablePortHelper configures itself poorly in a test JVM
[ https://issues.apache.org/jira/browse/GEODE-9824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale Emery resolved GEODE-9824. --- Fix Version/s: 1.15.0 Resolution: Fixed > AvailablePortHelper configures itself poorly in a test JVM > -- > > Key: GEODE-9824 > URL: https://issues.apache.org/jira/browse/GEODE-9824 > Project: Geode > Issue Type: Bug > Components: tests >Affects Versions: 1.15.0 >Reporter: Dale Emery >Assignee: Dale Emery >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.15.0 > > > In the test JVM, `AvailablePortHelper` initializes its "next port to check" > to a randomly selected port. That randomly selected port might be one of the > ones that a child VM will check early. > Here's a problematic sequence of events: > # In the test JVM, `AvailablePortHelper` learns that the range of ports > available to it is (say) 23750–24166. It randomly selects one of those as its > "next port to check." Let's suppose it randomly picks 23854 as its starting > port. > # The test starts vm0. In vm0 `AvailablePortHelper` initializes its "next > port to check" by computing it based on its VM number. For the given > available port range (23750–24166), vm0 will *always* start at 23854. > # At this point, both the test JVM and child vm0 have the exact same "next > port to check." Trouble is looming. > # The test requests a port in the test JVM, and gets the randomly selected > one: 23854. It doesn't bind to this port yet. Later it will try to start a > server on this port in vm1. Trouble is fast approaching. > # The test invokes `AvailablePortHelper` in vm0, and gets vm0's starting > port: 23854. The test then starts a server, which binds to that port. > # At this point, the test JVM thinks it has reserved the port, but vm0 has > bound to it. Trouble is imminent. > # The test tries to start a server in vm1, using the port it believes it > reserved. Trouble has arrived. The operation fails because the port is > already in use. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-9872) DistTXPersistentDebugDUnitTest tests fail because "cluster configuration service not available"
[
https://issues.apache.org/jira/browse/GEODE-9872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery reassigned GEODE-9872:
-
Assignee: Dale Emery
> DistTXPersistentDebugDUnitTest tests fail because "cluster configuration
> service not available"
> ---
>
> Key: GEODE-9872
> URL: https://issues.apache.org/jira/browse/GEODE-9872
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Bill Burcham
>Assignee: Dale Emery
>Priority: Major
>
> I suspect this failure is due to something in the test framework, or perhaps
> one or more tests failing to manage ports correctly, allowing two or more
> tests to interfere with one another.
> In this distributed test:
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/388]
> we see two failures. Here's the first full stack trace:
>
>
> {code:java}
> [error 2021/12/04 20:40:53.796 UTC
> tid=33] org.apache.geode.GemFireConfigException: cluster configuration
> service not available
> at
> org.junit.vintage.engine.execution.TestRun.getStoredResultOrSuccessful(TestRun.java:196)
> at
> org.junit.vintage.engine.execution.RunListenerAdapter.fireExecutionFinished(RunListenerAdapter.java:226)
> at
> org.junit.vintage.engine.execution.RunListenerAdapter.testFinished(RunListenerAdapter.java:192)
> at
> org.junit.vintage.engine.execution.RunListenerAdapter.testFinished(RunListenerAdapter.java:79)
> at
> org.junit.runner.notification.SynchronizedRunListener.testFinished(SynchronizedRunListener.java:87)
> at
> org.junit.runner.notification.RunNotifier$9.notifyListener(RunNotifier.java:225)
> at
> org.junit.runner.notification.RunNotifier$SafeNotifier.run(RunNotifier.java:72)
> at
> org.junit.runner.notification.RunNotifier.fireTestFinished(RunNotifier.java:222)
> at
> org.junit.internal.runners.model.EachTestNotifier.fireTestFinished(EachTestNotifier.java:38)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:372)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.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:43)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> at
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> at
> java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> at
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
> at
> java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
> at
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:485)
> at
> org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:82)
> at
> org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:73)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:108)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:88)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.lambda$execute$0(EngineExecutionOrchestrator.java:54)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.withInterceptedStreams(EngineExecutionOrchestrator.java:67)
>
[jira] [Updated] (GEODE-9872) DistTXPersistentDebugDUnitTest tests fail because "cluster configuration service not available"
[
https://issues.apache.org/jira/browse/GEODE-9872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery updated GEODE-9872:
--
Labels: GeodeOperationAPI (was: )
> DistTXPersistentDebugDUnitTest tests fail because "cluster configuration
> service not available"
> ---
>
> Key: GEODE-9872
> URL: https://issues.apache.org/jira/browse/GEODE-9872
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Bill Burcham
>Assignee: Dale Emery
>Priority: Major
> Labels: GeodeOperationAPI
>
> I suspect this failure is due to something in the test framework, or perhaps
> one or more tests failing to manage ports correctly, allowing two or more
> tests to interfere with one another.
> In this distributed test:
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/388]
> we see two failures. Here's the first full stack trace:
>
>
> {code:java}
> [error 2021/12/04 20:40:53.796 UTC
> tid=33] org.apache.geode.GemFireConfigException: cluster configuration
> service not available
> at
> org.junit.vintage.engine.execution.TestRun.getStoredResultOrSuccessful(TestRun.java:196)
> at
> org.junit.vintage.engine.execution.RunListenerAdapter.fireExecutionFinished(RunListenerAdapter.java:226)
> at
> org.junit.vintage.engine.execution.RunListenerAdapter.testFinished(RunListenerAdapter.java:192)
> at
> org.junit.vintage.engine.execution.RunListenerAdapter.testFinished(RunListenerAdapter.java:79)
> at
> org.junit.runner.notification.SynchronizedRunListener.testFinished(SynchronizedRunListener.java:87)
> at
> org.junit.runner.notification.RunNotifier$9.notifyListener(RunNotifier.java:225)
> at
> org.junit.runner.notification.RunNotifier$SafeNotifier.run(RunNotifier.java:72)
> at
> org.junit.runner.notification.RunNotifier.fireTestFinished(RunNotifier.java:222)
> at
> org.junit.internal.runners.model.EachTestNotifier.fireTestFinished(EachTestNotifier.java:38)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:372)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.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:43)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> at
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> at
> java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> at
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
> at
> java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
> at
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:485)
> at
> org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:82)
> at
> org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:73)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:108)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:88)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.lambda$execute$0(EngineExecutionOrchestrator.java:54)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.withInterceptedStrea
[jira] [Commented] (GEODE-9877) GeodeRedisServerStartupDUnitTest. startupFailsGivenPortAlreadyInUse failed
[
https://issues.apache.org/jira/browse/GEODE-9877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17455896#comment-17455896
]
Dale Emery commented on GEODE-9877:
---
The test tries to demonstrate that Geode gives the right exception when asked
to start Redis on a port already in use. But the test (not Geode) fails to put
the port into use… because the port is already in use.
The sequence of events:
# Get an available port from AvailablePortHelper.
# Instruct the child VM to ignore the imminent exception.
# Bind to the port so that it is unavailable for the Redis service.
# Start a server, configuring Redis to use that already-in-use port.
The test failed in CI on step 3. The test could not bind to the port on step 3,
even though on step 1 AvailablePortHelper said the port was available.
My tentative hypothesis is that step 2 somehow put that port into use.
> GeodeRedisServerStartupDUnitTest. startupFailsGivenPortAlreadyInUse failed
> --
>
> Key: GEODE-9877
> URL: https://issues.apache.org/jira/browse/GEODE-9877
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Mark Hanson
>Priority: Major
>
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/acceptance-test-openjdk8/builds/43]
> failed with
> GeodeRedisServerStartupDUnitTest. startupFailsGivenPortAlreadyInUse
> {noformat}
> java.net.BindException: Address already in use (Bind failed)
> at java.net.PlainSocketImpl.socketBind(Native Method)
> at
> java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:387)
> at java.net.Socket.bind(Socket.java:662)
> at
> org.apache.geode.redis.GeodeRedisServerStartupDUnitTest.startupFailsGivenPortAlreadyInUse(GeodeRedisServerStartupDUnitTest.java:115)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule$1.evaluate(ClusterStartupRule.java:138)
> 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.apache.geode.test.junit.rules.DescribedExternalResource$1.evaluate(DescribedExternalResource.java:40)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.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:43)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> at
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> at
> java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
> at
> java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
> at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
[jira] [Commented] (GEODE-9872) DistTXPersistentDebugDUnitTest tests fail because "cluster configuration service not available"
[
https://issues.apache.org/jira/browse/GEODE-9872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17456005#comment-17456005
]
Dale Emery commented on GEODE-9872:
---
DistTXPersistentDebugDUnitTest became entangled with
ClusterConfigLocatorRestartDUnitTest through misuse of ephemeral ports.
ClusterConfigLocatorRestartDUnitTest launched a locator on an ephemeral port,
stopped the locator, and attempted to restart it on the same port. While the
locator was stopped, DistTXPersistentDebugDUnitTest started a locator on an
ephemeral port, and got the same port number. As a result, the two tests began
sharing a locator and confused each other.
After fixing several tests that attempt to reuse ephemeral ports, I've
concluded that the problem is not the test's reuse of the port, but the
framework's decision to issue an ephemeral port. It is reasonable for a test to
assume that, if the framework chooses a port, then the test enjoys exclusive
use of the port for as long as the test wants it. Framework code that issues
ephemeral ports violates this reasonable assumption.
The PR changes DUnitLauncher and ClusterStarterRule to assign ports via
AvailablePortHelper rather than starting locators on ephemeral ports by default.
> DistTXPersistentDebugDUnitTest tests fail because "cluster configuration
> service not available"
> ---
>
> Key: GEODE-9872
> URL: https://issues.apache.org/jira/browse/GEODE-9872
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Bill Burcham
>Assignee: Dale Emery
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> I suspect this failure is due to something in the test framework, or perhaps
> one or more tests failing to manage ports correctly, allowing two or more
> tests to interfere with one another.
> In this distributed test:
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/388]
> we see two failures. Here's the first full stack trace:
>
>
> {code:java}
> [error 2021/12/04 20:40:53.796 UTC
> tid=33] org.apache.geode.GemFireConfigException: cluster configuration
> service not available
> at
> org.junit.vintage.engine.execution.TestRun.getStoredResultOrSuccessful(TestRun.java:196)
> at
> org.junit.vintage.engine.execution.RunListenerAdapter.fireExecutionFinished(RunListenerAdapter.java:226)
> at
> org.junit.vintage.engine.execution.RunListenerAdapter.testFinished(RunListenerAdapter.java:192)
> at
> org.junit.vintage.engine.execution.RunListenerAdapter.testFinished(RunListenerAdapter.java:79)
> at
> org.junit.runner.notification.SynchronizedRunListener.testFinished(SynchronizedRunListener.java:87)
> at
> org.junit.runner.notification.RunNotifier$9.notifyListener(RunNotifier.java:225)
> at
> org.junit.runner.notification.RunNotifier$SafeNotifier.run(RunNotifier.java:72)
> at
> org.junit.runner.notification.RunNotifier.fireTestFinished(RunNotifier.java:222)
> at
> org.junit.internal.runners.model.EachTestNotifier.fireTestFinished(EachTestNotifier.java:38)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:372)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.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:43)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> at
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> at
> java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> at
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
> at
[jira] [Comment Edited] (GEODE-9872) DistTXPersistentDebugDUnitTest tests fail because "cluster configuration service not available"
[
https://issues.apache.org/jira/browse/GEODE-9872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17456005#comment-17456005
]
Dale Emery edited comment on GEODE-9872 at 12/8/21, 9:41 PM:
-
DistTXPersistentDebugDUnitTest became entangled with
ClusterConfigLocatorRestartDUnitTest through misuse of ephemeral ports.
ClusterConfigLocatorRestartDUnitTest launched a locator on an ephemeral port,
stopped the locator, and attempted to restart it on the same port. While the
locator was stopped, DistTXPersistentDebugDUnitTest started a locator on an
ephemeral port, and got the same port number. As a result, the two tests began
sharing a locator and confused each other.
After fixing several tests that attempt to reuse ephemeral ports, I've
concluded that the problem is not the test's reuse of the port, but {*}the
framework's decision to issue an ephemeral port in the first place{*}. It is
reasonable for a test to assume that, if the framework chooses a port, then the
test enjoys exclusive use of the port for as long as the test wants it.
Framework code that issues ephemeral ports violates this reasonable assumption.
The PR changes DUnitLauncher and ClusterStarterRule to assign ports via
AvailablePortHelper rather than starting locators on ephemeral ports by default.
was (Author: demery):
DistTXPersistentDebugDUnitTest became entangled with
ClusterConfigLocatorRestartDUnitTest through misuse of ephemeral ports.
ClusterConfigLocatorRestartDUnitTest launched a locator on an ephemeral port,
stopped the locator, and attempted to restart it on the same port. While the
locator was stopped, DistTXPersistentDebugDUnitTest started a locator on an
ephemeral port, and got the same port number. As a result, the two tests began
sharing a locator and confused each other.
After fixing several tests that attempt to reuse ephemeral ports, I've
concluded that the problem is not the test's reuse of the port, but the
framework's decision to issue an ephemeral port. It is reasonable for a test to
assume that, if the framework chooses a port, then the test enjoys exclusive
use of the port for as long as the test wants it. Framework code that issues
ephemeral ports violates this reasonable assumption.
The PR changes DUnitLauncher and ClusterStarterRule to assign ports via
AvailablePortHelper rather than starting locators on ephemeral ports by default.
> DistTXPersistentDebugDUnitTest tests fail because "cluster configuration
> service not available"
> ---
>
> Key: GEODE-9872
> URL: https://issues.apache.org/jira/browse/GEODE-9872
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Bill Burcham
>Assignee: Dale Emery
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> I suspect this failure is due to something in the test framework, or perhaps
> one or more tests failing to manage ports correctly, allowing two or more
> tests to interfere with one another.
> In this distributed test:
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/388]
> we see two failures. Here's the first full stack trace:
>
>
> {code:java}
> [error 2021/12/04 20:40:53.796 UTC
> tid=33] org.apache.geode.GemFireConfigException: cluster configuration
> service not available
> at
> org.junit.vintage.engine.execution.TestRun.getStoredResultOrSuccessful(TestRun.java:196)
> at
> org.junit.vintage.engine.execution.RunListenerAdapter.fireExecutionFinished(RunListenerAdapter.java:226)
> at
> org.junit.vintage.engine.execution.RunListenerAdapter.testFinished(RunListenerAdapter.java:192)
> at
> org.junit.vintage.engine.execution.RunListenerAdapter.testFinished(RunListenerAdapter.java:79)
> at
> org.junit.runner.notification.SynchronizedRunListener.testFinished(SynchronizedRunListener.java:87)
> at
> org.junit.runner.notification.RunNotifier$9.notifyListener(RunNotifier.java:225)
> at
> org.junit.runner.notification.RunNotifier$SafeNotifier.run(RunNotifier.java:72)
> at
> org.junit.runner.notification.RunNotifier.fireTestFinished(RunNotifier.java:222)
> at
> org.junit.internal.runners.model.EachTestNotifier.fireTestFinished(EachTestNotifier.java:38)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:372)
> 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.sched
[jira] [Comment Edited] (GEODE-9872) DistTXPersistentDebugDUnitTest tests fail because "cluster configuration service not available"
[
https://issues.apache.org/jira/browse/GEODE-9872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17456005#comment-17456005
]
Dale Emery edited comment on GEODE-9872 at 12/8/21, 9:41 PM:
-
DistTXPersistentDebugDUnitTest became entangled with
ClusterConfigLocatorRestartDUnitTest through misuse of ephemeral ports.
ClusterConfigLocatorRestartDUnitTest launched a locator on an ephemeral port,
stopped the locator, and attempted to restart it on the same port. While the
locator was stopped, DistTXPersistentDebugDUnitTest started a locator on an
ephemeral port, and got the same port number. As a result, the two tests began
sharing a locator and confused each other.
After fixing several tests that attempt to reuse ephemeral ports, I've
concluded that the problem is not the test's reuse of the port, but {*}the
framework's decision to issue an ephemeral port in the first place{*}. It is
reasonable for a test to assume that, if the framework chooses a port on behalf
of a test, then the test enjoys exclusive use of the port for as long as the
test wants it. Framework code that issues ephemeral ports violates this
reasonable assumption.
The PR changes DUnitLauncher and ClusterStarterRule to assign ports via
AvailablePortHelper rather than starting locators on ephemeral ports by default.
was (Author: demery):
DistTXPersistentDebugDUnitTest became entangled with
ClusterConfigLocatorRestartDUnitTest through misuse of ephemeral ports.
ClusterConfigLocatorRestartDUnitTest launched a locator on an ephemeral port,
stopped the locator, and attempted to restart it on the same port. While the
locator was stopped, DistTXPersistentDebugDUnitTest started a locator on an
ephemeral port, and got the same port number. As a result, the two tests began
sharing a locator and confused each other.
After fixing several tests that attempt to reuse ephemeral ports, I've
concluded that the problem is not the test's reuse of the port, but {*}the
framework's decision to issue an ephemeral port in the first place{*}. It is
reasonable for a test to assume that, if the framework chooses a port, then the
test enjoys exclusive use of the port for as long as the test wants it.
Framework code that issues ephemeral ports violates this reasonable assumption.
The PR changes DUnitLauncher and ClusterStarterRule to assign ports via
AvailablePortHelper rather than starting locators on ephemeral ports by default.
> DistTXPersistentDebugDUnitTest tests fail because "cluster configuration
> service not available"
> ---
>
> Key: GEODE-9872
> URL: https://issues.apache.org/jira/browse/GEODE-9872
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Bill Burcham
>Assignee: Dale Emery
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> I suspect this failure is due to something in the test framework, or perhaps
> one or more tests failing to manage ports correctly, allowing two or more
> tests to interfere with one another.
> In this distributed test:
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/388]
> we see two failures. Here's the first full stack trace:
>
>
> {code:java}
> [error 2021/12/04 20:40:53.796 UTC
> tid=33] org.apache.geode.GemFireConfigException: cluster configuration
> service not available
> at
> org.junit.vintage.engine.execution.TestRun.getStoredResultOrSuccessful(TestRun.java:196)
> at
> org.junit.vintage.engine.execution.RunListenerAdapter.fireExecutionFinished(RunListenerAdapter.java:226)
> at
> org.junit.vintage.engine.execution.RunListenerAdapter.testFinished(RunListenerAdapter.java:192)
> at
> org.junit.vintage.engine.execution.RunListenerAdapter.testFinished(RunListenerAdapter.java:79)
> at
> org.junit.runner.notification.SynchronizedRunListener.testFinished(SynchronizedRunListener.java:87)
> at
> org.junit.runner.notification.RunNotifier$9.notifyListener(RunNotifier.java:225)
> at
> org.junit.runner.notification.RunNotifier$SafeNotifier.run(RunNotifier.java:72)
> at
> org.junit.runner.notification.RunNotifier.fireTestFinished(RunNotifier.java:222)
> at
> org.junit.internal.runners.model.EachTestNotifier.fireTestFinished(EachTestNotifier.java:38)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:372)
> 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)
>
[jira] [Commented] (GEODE-9622) CI Failure: ClientServerTransactionFailoverWithMixedVersionServersDistributedTest fails with BindException
[
https://issues.apache.org/jira/browse/GEODE-9622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17456062#comment-17456062
]
Dale Emery commented on GEODE-9622:
---
In this test class, the `startLocator()` method has this code:
{noformat}
Locator locator = Locator.startLocatorAndDS(locatorPort, locatorLog,
bindAddress, config);
return locator.getPort();
{noformat}
{{locatorPort}} is a static variable. The first time this method is called in a
VM, it starts a locator on an ephemeral port.
Some tests in this class later stop the locator, then attempt to restart it the
same port. But because it's an ephemeral port, the OS can give it to some other
process while the locator is stopped.
This test class should be edited to call {{AvailablePortHelper}} to get a port
for the locator, rather than using an ephemeral port. And because some tests
invoke older JVMs, the call to {{AvailablePortHelper}} must be made in the test
JVM, not in child VMs.
> CI Failure:
> ClientServerTransactionFailoverWithMixedVersionServersDistributedTest fails
> with BindException
> --
>
> Key: GEODE-9622
> URL: https://issues.apache.org/jira/browse/GEODE-9622
> Project: Geode
> Issue Type: Bug
> Components: client/server, tests
>Reporter: Kirk Lund
>Priority: Major
>
> {noformat}
> org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest
> > clientTransactionOperationsAreNotLostIfTransactionIsOnRolledServer FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest$$Lambda$68/194483270.call
> in VM 5 running on Host
> heavy-lifter-2b8702f1-fe32-5895-9b14-832b7049b607.c.apachegeode-ci.internal
> with 6 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:473)
> at
> org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.rollLocatorToCurrent(ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.java:216)
> at
> org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.setupPartiallyRolledVersion(ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.java:171)
> at
> org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.clientTransactionOperationsAreNotLostIfTransactionIsOnRolledServer(ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.java:127)
> Caused by:
> java.net.BindException: Failed to create server socket on
> heavy-lifter-2b8702f1-fe32-5895-9b14-832b7049b607.c.apachegeode-ci.internal/10.0.0.60[43535]
> at
> org.apache.geode.distributed.internal.tcpserver.ClusterSocketCreatorImpl.createServerSocket(ClusterSocketCreatorImpl.java:75)
> at
> org.apache.geode.internal.net.SCClusterSocketCreator.createServerSocket(SCClusterSocketCreator.java:55)
> at
> org.apache.geode.distributed.internal.tcpserver.ClusterSocketCreatorImpl.createServerSocket(ClusterSocketCreatorImpl.java:54)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.initializeServerSocket(TcpServer.java:196)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.startServerThread(TcpServer.java:183)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.start(TcpServer.java:178)
> at
> org.apache.geode.distributed.internal.membership.gms.locator.MembershipLocatorImpl.start(MembershipLocatorImpl.java:112)
> at
> org.apache.geode.distributed.internal.InternalLocator.startPeerLocation(InternalLocator.java:653)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:394)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:345)
> at
> org.apache.geode.distributed.Locator.startLocator(Locator.java:261)
> at
> org.apache.geode.distributed.Locator.startLocatorAndDS(Locator.java:207)
> at
> org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.startLocator(ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.java:180)
> at
> org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.lambda$rollLocatorToCurrent$92d5d92a$1(ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.java:216)
> Caused by:
>
[jira] [Comment Edited] (GEODE-9622) CI Failure: ClientServerTransactionFailoverWithMixedVersionServersDistributedTest fails with BindException
[
https://issues.apache.org/jira/browse/GEODE-9622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17456062#comment-17456062
]
Dale Emery edited comment on GEODE-9622 at 12/9/21, 12:19 AM:
--
In this test class, the `startLocator()` method has this code:
{noformat}
Locator locator = Locator.startLocatorAndDS(locatorPort, locatorLog,
bindAddress, config);
return locator.getPort();
{noformat}
{{locatorPort}} is a static variable. The first time this method is called in a
VM, {{locatorPort}} has not been explicitly assigned a value, so its value is
0. This starts a locator on an ephemeral port.
Some tests in this class later stop the locator, then attempt to restart it the
same port. But because it's an ephemeral port, the OS can give it to some other
process while the locator is stopped.
This test class should be edited to call {{AvailablePortHelper}} to get a port
for the locator, rather than using an ephemeral port. And because some tests
invoke older JVMs, the call to {{AvailablePortHelper}} must be made in the test
JVM, not in child VMs.
was (Author: demery):
In this test class, the `startLocator()` method has this code:
{noformat}
Locator locator = Locator.startLocatorAndDS(locatorPort, locatorLog,
bindAddress, config);
return locator.getPort();
{noformat}
{{locatorPort}} is a static variable. The first time this method is called in a
VM, it starts a locator on an ephemeral port.
Some tests in this class later stop the locator, then attempt to restart it the
same port. But because it's an ephemeral port, the OS can give it to some other
process while the locator is stopped.
This test class should be edited to call {{AvailablePortHelper}} to get a port
for the locator, rather than using an ephemeral port. And because some tests
invoke older JVMs, the call to {{AvailablePortHelper}} must be made in the test
JVM, not in child VMs.
> CI Failure:
> ClientServerTransactionFailoverWithMixedVersionServersDistributedTest fails
> with BindException
> --
>
> Key: GEODE-9622
> URL: https://issues.apache.org/jira/browse/GEODE-9622
> Project: Geode
> Issue Type: Bug
> Components: client/server, tests
>Reporter: Kirk Lund
>Priority: Major
>
> {noformat}
> org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest
> > clientTransactionOperationsAreNotLostIfTransactionIsOnRolledServer FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest$$Lambda$68/194483270.call
> in VM 5 running on Host
> heavy-lifter-2b8702f1-fe32-5895-9b14-832b7049b607.c.apachegeode-ci.internal
> with 6 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:473)
> at
> org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.rollLocatorToCurrent(ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.java:216)
> at
> org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.setupPartiallyRolledVersion(ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.java:171)
> at
> org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.clientTransactionOperationsAreNotLostIfTransactionIsOnRolledServer(ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.java:127)
> Caused by:
> java.net.BindException: Failed to create server socket on
> heavy-lifter-2b8702f1-fe32-5895-9b14-832b7049b607.c.apachegeode-ci.internal/10.0.0.60[43535]
> at
> org.apache.geode.distributed.internal.tcpserver.ClusterSocketCreatorImpl.createServerSocket(ClusterSocketCreatorImpl.java:75)
> at
> org.apache.geode.internal.net.SCClusterSocketCreator.createServerSocket(SCClusterSocketCreator.java:55)
> at
> org.apache.geode.distributed.internal.tcpserver.ClusterSocketCreatorImpl.createServerSocket(ClusterSocketCreatorImpl.java:54)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.initializeServerSocket(TcpServer.java:196)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.startServerThread(TcpServer.java:183)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.start(TcpServer.java:178)
> at
> org.apache.geode.distributed.internal.membership.gms.locator.MembershipLocatorImpl.start(MembershipLocatorImpl.java:112)
> at
> org.apache.geode.distributed.internal.Inte
[jira] [Comment Edited] (GEODE-9622) CI Failure: ClientServerTransactionFailoverWithMixedVersionServersDistributedTest fails with BindException
[
https://issues.apache.org/jira/browse/GEODE-9622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17456062#comment-17456062
]
Dale Emery edited comment on GEODE-9622 at 12/9/21, 12:20 AM:
--
In this test class, the `startLocator()` method has this code:
{noformat}
Locator locator = Locator.startLocatorAndDS(locatorPort, locatorLog,
bindAddress, config);
return locator.getPort();
{noformat}
{{locatorPort}} is a static variable. The first time this method is called in a
VM, {{locatorPort}} has not been explicitly assigned a value, so its value is
0. This starts a locator on an ephemeral port.
Some tests in this class later stop the locator, then attempt to restart it on
the same port. But because it's an ephemeral port, the OS can give it to some
other process while the locator is stopped.
This test class should be edited to call {{AvailablePortHelper}} to get a port
for the locator, rather than using an ephemeral port. And because some tests
invoke older JVMs, the call to {{AvailablePortHelper}} must be made in the test
JVM, not in child VMs.
was (Author: demery):
In this test class, the `startLocator()` method has this code:
{noformat}
Locator locator = Locator.startLocatorAndDS(locatorPort, locatorLog,
bindAddress, config);
return locator.getPort();
{noformat}
{{locatorPort}} is a static variable. The first time this method is called in a
VM, {{locatorPort}} has not been explicitly assigned a value, so its value is
0. This starts a locator on an ephemeral port.
Some tests in this class later stop the locator, then attempt to restart it the
same port. But because it's an ephemeral port, the OS can give it to some other
process while the locator is stopped.
This test class should be edited to call {{AvailablePortHelper}} to get a port
for the locator, rather than using an ephemeral port. And because some tests
invoke older JVMs, the call to {{AvailablePortHelper}} must be made in the test
JVM, not in child VMs.
> CI Failure:
> ClientServerTransactionFailoverWithMixedVersionServersDistributedTest fails
> with BindException
> --
>
> Key: GEODE-9622
> URL: https://issues.apache.org/jira/browse/GEODE-9622
> Project: Geode
> Issue Type: Bug
> Components: client/server, tests
>Reporter: Kirk Lund
>Priority: Major
>
> {noformat}
> org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest
> > clientTransactionOperationsAreNotLostIfTransactionIsOnRolledServer FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest$$Lambda$68/194483270.call
> in VM 5 running on Host
> heavy-lifter-2b8702f1-fe32-5895-9b14-832b7049b607.c.apachegeode-ci.internal
> with 6 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:473)
> at
> org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.rollLocatorToCurrent(ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.java:216)
> at
> org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.setupPartiallyRolledVersion(ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.java:171)
> at
> org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.clientTransactionOperationsAreNotLostIfTransactionIsOnRolledServer(ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.java:127)
> Caused by:
> java.net.BindException: Failed to create server socket on
> heavy-lifter-2b8702f1-fe32-5895-9b14-832b7049b607.c.apachegeode-ci.internal/10.0.0.60[43535]
> at
> org.apache.geode.distributed.internal.tcpserver.ClusterSocketCreatorImpl.createServerSocket(ClusterSocketCreatorImpl.java:75)
> at
> org.apache.geode.internal.net.SCClusterSocketCreator.createServerSocket(SCClusterSocketCreator.java:55)
> at
> org.apache.geode.distributed.internal.tcpserver.ClusterSocketCreatorImpl.createServerSocket(ClusterSocketCreatorImpl.java:54)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.initializeServerSocket(TcpServer.java:196)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.startServerThread(TcpServer.java:183)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.start(TcpServer.java:178)
> at
> org.apache.geode.distributed.internal.membership.gms.locator.MembershipLocatorImpl.start(MembershipL
[jira] [Comment Edited] (GEODE-9622) CI Failure: ClientServerTransactionFailoverWithMixedVersionServersDistributedTest fails with BindException
[
https://issues.apache.org/jira/browse/GEODE-9622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17456062#comment-17456062
]
Dale Emery edited comment on GEODE-9622 at 12/9/21, 12:22 AM:
--
In this test class, the `startLocator()` method has this code:
{noformat}
Locator locator = Locator.startLocatorAndDS(locatorPort, locatorLog,
bindAddress, config);
return locator.getPort();
{noformat}
The first time this method is called in a VM, {{locatorPort}} has not been
explicitly assigned a value, so its value is 0. This starts a locator on an
ephemeral port.
Some tests in this class later stop the locator, then attempt to restart it on
the same port. But because it's an ephemeral port, the OS can give it to some
other process while the locator is stopped.
This test class should be edited to call {{AvailablePortHelper}} to get a port
for the locator, rather than using an ephemeral port. And because some tests
invoke older JVMs, the call to {{AvailablePortHelper}} must be made in the test
JVM, not in child VMs.
was (Author: demery):
In this test class, the `startLocator()` method has this code:
{noformat}
Locator locator = Locator.startLocatorAndDS(locatorPort, locatorLog,
bindAddress, config);
return locator.getPort();
{noformat}
{{locatorPort}} is a static variable. The first time this method is called in a
VM, {{locatorPort}} has not been explicitly assigned a value, so its value is
0. This starts a locator on an ephemeral port.
Some tests in this class later stop the locator, then attempt to restart it on
the same port. But because it's an ephemeral port, the OS can give it to some
other process while the locator is stopped.
This test class should be edited to call {{AvailablePortHelper}} to get a port
for the locator, rather than using an ephemeral port. And because some tests
invoke older JVMs, the call to {{AvailablePortHelper}} must be made in the test
JVM, not in child VMs.
> CI Failure:
> ClientServerTransactionFailoverWithMixedVersionServersDistributedTest fails
> with BindException
> --
>
> Key: GEODE-9622
> URL: https://issues.apache.org/jira/browse/GEODE-9622
> Project: Geode
> Issue Type: Bug
> Components: client/server, tests
>Reporter: Kirk Lund
>Priority: Major
>
> {noformat}
> org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest
> > clientTransactionOperationsAreNotLostIfTransactionIsOnRolledServer FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest$$Lambda$68/194483270.call
> in VM 5 running on Host
> heavy-lifter-2b8702f1-fe32-5895-9b14-832b7049b607.c.apachegeode-ci.internal
> with 6 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:473)
> at
> org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.rollLocatorToCurrent(ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.java:216)
> at
> org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.setupPartiallyRolledVersion(ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.java:171)
> at
> org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.clientTransactionOperationsAreNotLostIfTransactionIsOnRolledServer(ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.java:127)
> Caused by:
> java.net.BindException: Failed to create server socket on
> heavy-lifter-2b8702f1-fe32-5895-9b14-832b7049b607.c.apachegeode-ci.internal/10.0.0.60[43535]
> at
> org.apache.geode.distributed.internal.tcpserver.ClusterSocketCreatorImpl.createServerSocket(ClusterSocketCreatorImpl.java:75)
> at
> org.apache.geode.internal.net.SCClusterSocketCreator.createServerSocket(SCClusterSocketCreator.java:55)
> at
> org.apache.geode.distributed.internal.tcpserver.ClusterSocketCreatorImpl.createServerSocket(ClusterSocketCreatorImpl.java:54)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.initializeServerSocket(TcpServer.java:196)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.startServerThread(TcpServer.java:183)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.start(TcpServer.java:178)
> at
> org.apache.geode.distributed.internal.membership.gms.locator.MembershipLocatorImpl.start(MembershipLocatorImpl.java:112)
>
[jira] [Assigned] (GEODE-9622) CI Failure: ClientServerTransactionFailoverWithMixedVersionServersDistributedTest fails with BindException
[
https://issues.apache.org/jira/browse/GEODE-9622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery reassigned GEODE-9622:
-
Assignee: Dale Emery
> CI Failure:
> ClientServerTransactionFailoverWithMixedVersionServersDistributedTest fails
> with BindException
> --
>
> Key: GEODE-9622
> URL: https://issues.apache.org/jira/browse/GEODE-9622
> Project: Geode
> Issue Type: Bug
> Components: client/server, tests
>Reporter: Kirk Lund
>Assignee: Dale Emery
>Priority: Major
>
> {noformat}
> org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest
> > clientTransactionOperationsAreNotLostIfTransactionIsOnRolledServer FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest$$Lambda$68/194483270.call
> in VM 5 running on Host
> heavy-lifter-2b8702f1-fe32-5895-9b14-832b7049b607.c.apachegeode-ci.internal
> with 6 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:473)
> at
> org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.rollLocatorToCurrent(ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.java:216)
> at
> org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.setupPartiallyRolledVersion(ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.java:171)
> at
> org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.clientTransactionOperationsAreNotLostIfTransactionIsOnRolledServer(ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.java:127)
> Caused by:
> java.net.BindException: Failed to create server socket on
> heavy-lifter-2b8702f1-fe32-5895-9b14-832b7049b607.c.apachegeode-ci.internal/10.0.0.60[43535]
> at
> org.apache.geode.distributed.internal.tcpserver.ClusterSocketCreatorImpl.createServerSocket(ClusterSocketCreatorImpl.java:75)
> at
> org.apache.geode.internal.net.SCClusterSocketCreator.createServerSocket(SCClusterSocketCreator.java:55)
> at
> org.apache.geode.distributed.internal.tcpserver.ClusterSocketCreatorImpl.createServerSocket(ClusterSocketCreatorImpl.java:54)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.initializeServerSocket(TcpServer.java:196)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.startServerThread(TcpServer.java:183)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.start(TcpServer.java:178)
> at
> org.apache.geode.distributed.internal.membership.gms.locator.MembershipLocatorImpl.start(MembershipLocatorImpl.java:112)
> at
> org.apache.geode.distributed.internal.InternalLocator.startPeerLocation(InternalLocator.java:653)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:394)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:345)
> at
> org.apache.geode.distributed.Locator.startLocator(Locator.java:261)
> at
> org.apache.geode.distributed.Locator.startLocatorAndDS(Locator.java:207)
> at
> org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.startLocator(ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.java:180)
> at
> org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.lambda$rollLocatorToCurrent$92d5d92a$1(ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.java:216)
> Caused by:
> java.net.BindException: Address already in use (Bind failed)
> at java.net.PlainSocketImpl.socketBind(Native Method)
> at
> java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:387)
> at java.net.ServerSocket.bind(ServerSocket.java:390)
> at
> org.apache.geode.distributed.internal.tcpserver.ClusterSocketCreatorImpl.createServerSocket(ClusterSocketCreatorImpl.java:72)
> ... 13 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9622) CI Failure: ClientServerTransactionFailoverWithMixedVersionServersDistributedTest fails with BindException
[
https://issues.apache.org/jira/browse/GEODE-9622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery updated GEODE-9622:
--
Labels: GeodeOperationAPI pull-request-available (was:
pull-request-available)
> CI Failure:
> ClientServerTransactionFailoverWithMixedVersionServersDistributedTest fails
> with BindException
> --
>
> Key: GEODE-9622
> URL: https://issues.apache.org/jira/browse/GEODE-9622
> Project: Geode
> Issue Type: Bug
> Components: client/server, tests
>Reporter: Kirk Lund
>Assignee: Dale Emery
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> {noformat}
> org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest
> > clientTransactionOperationsAreNotLostIfTransactionIsOnRolledServer FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest$$Lambda$68/194483270.call
> in VM 5 running on Host
> heavy-lifter-2b8702f1-fe32-5895-9b14-832b7049b607.c.apachegeode-ci.internal
> with 6 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:473)
> at
> org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.rollLocatorToCurrent(ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.java:216)
> at
> org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.setupPartiallyRolledVersion(ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.java:171)
> at
> org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.clientTransactionOperationsAreNotLostIfTransactionIsOnRolledServer(ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.java:127)
> Caused by:
> java.net.BindException: Failed to create server socket on
> heavy-lifter-2b8702f1-fe32-5895-9b14-832b7049b607.c.apachegeode-ci.internal/10.0.0.60[43535]
> at
> org.apache.geode.distributed.internal.tcpserver.ClusterSocketCreatorImpl.createServerSocket(ClusterSocketCreatorImpl.java:75)
> at
> org.apache.geode.internal.net.SCClusterSocketCreator.createServerSocket(SCClusterSocketCreator.java:55)
> at
> org.apache.geode.distributed.internal.tcpserver.ClusterSocketCreatorImpl.createServerSocket(ClusterSocketCreatorImpl.java:54)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.initializeServerSocket(TcpServer.java:196)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.startServerThread(TcpServer.java:183)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.start(TcpServer.java:178)
> at
> org.apache.geode.distributed.internal.membership.gms.locator.MembershipLocatorImpl.start(MembershipLocatorImpl.java:112)
> at
> org.apache.geode.distributed.internal.InternalLocator.startPeerLocation(InternalLocator.java:653)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:394)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:345)
> at
> org.apache.geode.distributed.Locator.startLocator(Locator.java:261)
> at
> org.apache.geode.distributed.Locator.startLocatorAndDS(Locator.java:207)
> at
> org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.startLocator(ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.java:180)
> at
> org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.lambda$rollLocatorToCurrent$92d5d92a$1(ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.java:216)
> Caused by:
> java.net.BindException: Address already in use (Bind failed)
> at java.net.PlainSocketImpl.socketBind(Native Method)
> at
> java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:387)
> at java.net.ServerSocket.bind(ServerSocket.java:390)
> at
> org.apache.geode.distributed.internal.tcpserver.ClusterSocketCreatorImpl.createServerSocket(ClusterSocketCreatorImpl.java:72)
> ... 13 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-5895) Rolling upgrade tests can fail with port conflicts with dunit debugger ports
[
https://issues.apache.org/jira/browse/GEODE-5895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17456071#comment-17456071
]
Dale Emery commented on GEODE-5895:
---
The problem is that instead of picking an available port, we used an ephemeral
port. I'm marking this as a dupilicate of
https://issues.apache.org/jira/browse/GEODE-9622, where I've submitted a PR.
> Rolling upgrade tests can fail with port conflicts with dunit debugger ports
>
>
> Key: GEODE-5895
> URL: https://issues.apache.org/jira/browse/GEODE-5895
> Project: Geode
> Issue Type: Improvement
>Reporter: Dan Smith
>Priority: Major
> Labels: swat
>
> We recently had a rolling upgrade test fail with an address already in use
> failure. Tracking this down, it looks like the issue is that the we picked an
> available port, and then bounced a dunit VM. When the VM restarted it picked
> that same port to listener for debugging connections.
> Failure:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.8.0-build.9/test-results/distributedTest/1539810558/
> {noformat}
> Bouncing VM5 from version 160 to 000
> Old process for vm_5 has exited
> Executing [/usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java, -classpath,
> /home/geode/geode/geode-core/build/classes/java/distributedTest:/home/geode/geode/geode-core/build/resources/distributedTest:/home/geode/geode/geode-dunit/build/libs/geode-dunit-1.8.0-SNAPSHOT.jar:/home/geode/geode/geode-core/build/classes/java/integrationTest:/home/geode/geode/geode-core/build/resources/integrationTest:/home/geode/geode/geode-core/build/libs/geode-core-1.8.0-SNAPSHOT.jar:/home/geode/.gradle/caches/modules-2/files-2.1/antlr/antlr/2.7.7/83cd2cd674a217ade95a4bb83a8a14f351f48bd0/antlr-2.7.7.jar:/home/geode/.gradle/caches/modules-2/files-2.1/com.github.stephenc.findbugs/findbugs-annotations/1.3.9-1/a6b11447635d80757d64b355bed3c00786d86801/findbugs-annotations-1.3.9-1.jar:/home/geode/.gradle/caches/modules-2/files-2.1/org.jgroups/jgroups/3.6.14.Final/ee11e0645462b6937625f56f42bf5e853673168/jgroups-3.6.14.Final.jar:/home/geode/.gradle/caches/modules-2/files-2.1/com.fasterxml.jackson.core/jackson-databind/2.9.6/cfa4f316351a91bfd95cb0644c6a2c95f52db1fc/jackson-databind-2.9.6.jar:/home/geode/.gradle/caches/modules-2/files-2.1/com.fasterxml.jackson.core/jackson-annotations/2.9.6/6a0f0f154edaba00067772ce02e24f8c0973d84c/jackson-annotations-2.9.6.jar:/home/geode/geode/geode-junit/build/libs/geode-junit-1.8.0-SNAPSHOT.jar:/home/geode/.gradle/caches/modules-2/files-2.1/org.springframework.shell/spring-shell/1.2.0.RELEASE/d94047721f292bd5334b5654e8600cef4b845049/spring-shell-1.2.0.RELEASE.jar:/home/geode/.gradle/caches/modules-2/files-2.1/commons-io/commons-io/2.6/815893df5f31da2ece4040fe0a12fd44b577afaf/commons-io-2.6.jar:/home/geode/.gradle/caches/modules-2/files-2.1/commons-validator/commons-validator/1.6/e989d1e87cdd60575df0765ed5bac65c905d7908/commons-validator-1.6.jar:/home/geode/.gradle/caches/modules-2/files-2.1/commons-digester/commons-digester/2.1/73a8001e7a54a255eef0f03521ec1805dc738ca0/commons-digester-2.1.jar:/home/geode/.gradle/caches/modules-2/files-2.1/javax.mail/javax.mail-api/1.6.1/8cababdc2a9caae6e1641aae6671c24394227651/javax.mail-api-1.6.1.jar:/home/geode/.gradle/caches/modules-2/files-2.1/javax.activation/activation/1.1.1/485de3a253e23f645037828c07f1d7f1af40763a/activation-1.1.1.jar:/home/geode/.gradle/caches/modules-2/files-2.1/javax.xml.bind/jaxb-api/2.2.11/32274d4244967ff43e7a5d967743d94ed3d2aea7/jaxb-api-2.2.11.jar:/home/geode/.gradle/caches/modules-2/files-2.1/com.sun.xml.bind/jaxb-core/2.2.11/c3f87d654f8d5943cd08592f3f758856544d279a/jaxb-core-2.2.11.jar:/home/geode/.gradle/caches/modules-2/files-2.1/com.sun.xml.bind/jaxb-impl/2.2.11/a49ce57aee680f9435f49ba6ef427d38c93247a6/jaxb-impl-2.2.11.jar:/home/geode/.gradle/caches/modules-2/files-2.1/commons-lang/commons-lang/2.6/ce1edb914c94ebc388f086c6827e8bdeec71ac2/commons-lang-2.6.jar:/home/geode/.gradle/caches/modules-2/files-2.1/commons-modeler/commons-modeler/2.0.1/7ac36e7db0bb1230a901852ff618d3a3a873e9de/commons-modeler-2.0.1.jar:/home/geode/.gradle/caches/modules-2/files-2.1/io.netty/netty-all/4.1.27.Final/abcefabf95f3b21b3e31019fd89fd8687563076d/netty-all-4.1.27.Final.jar:/home/geode/.gradle/caches/modules-2/files-2.1/it.unimi.dsi/fastutil/8.2.1/5ad88f325e424f8dbc2be5459e21ea5cab3864e9/fastutil-8.2.1.jar:/home/geode/.gradle/caches/modules-2/files-2.1/javax.resource/javax.resource-api/1.7/ae40e0864eb1e92c48bf82a2a3399cbbf523fb79/javax.resource-api-1.7.jar:/home/geode/.gradle/caches/modules-2/files-2.1/mx4j/mx4j/3.0.2/47bf147f11b4a026263e1c96a1ea0e029f9e5ab6/mx4j-3.0.2.jar:/home/geode/.gradle/caches/modules-2/files-2.1/mx4j/mx4j-remote/3.0.2/35234324298454ee19efecb86f86b947269c9509/mx4j-remote-3.0.
[jira] [Resolved] (GEODE-5895) Rolling upgrade tests can fail with port conflicts with dunit debugger ports
[
https://issues.apache.org/jira/browse/GEODE-5895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery resolved GEODE-5895.
---
Resolution: Duplicate
> Rolling upgrade tests can fail with port conflicts with dunit debugger ports
>
>
> Key: GEODE-5895
> URL: https://issues.apache.org/jira/browse/GEODE-5895
> Project: Geode
> Issue Type: Improvement
>Reporter: Dan Smith
>Priority: Major
> Labels: swat
>
> We recently had a rolling upgrade test fail with an address already in use
> failure. Tracking this down, it looks like the issue is that the we picked an
> available port, and then bounced a dunit VM. When the VM restarted it picked
> that same port to listener for debugging connections.
> Failure:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.8.0-build.9/test-results/distributedTest/1539810558/
> {noformat}
> Bouncing VM5 from version 160 to 000
> Old process for vm_5 has exited
> Executing [/usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java, -classpath,
> /home/geode/geode/geode-core/build/classes/java/distributedTest:/home/geode/geode/geode-core/build/resources/distributedTest:/home/geode/geode/geode-dunit/build/libs/geode-dunit-1.8.0-SNAPSHOT.jar:/home/geode/geode/geode-core/build/classes/java/integrationTest:/home/geode/geode/geode-core/build/resources/integrationTest:/home/geode/geode/geode-core/build/libs/geode-core-1.8.0-SNAPSHOT.jar:/home/geode/.gradle/caches/modules-2/files-2.1/antlr/antlr/2.7.7/83cd2cd674a217ade95a4bb83a8a14f351f48bd0/antlr-2.7.7.jar:/home/geode/.gradle/caches/modules-2/files-2.1/com.github.stephenc.findbugs/findbugs-annotations/1.3.9-1/a6b11447635d80757d64b355bed3c00786d86801/findbugs-annotations-1.3.9-1.jar:/home/geode/.gradle/caches/modules-2/files-2.1/org.jgroups/jgroups/3.6.14.Final/ee11e0645462b6937625f56f42bf5e853673168/jgroups-3.6.14.Final.jar:/home/geode/.gradle/caches/modules-2/files-2.1/com.fasterxml.jackson.core/jackson-databind/2.9.6/cfa4f316351a91bfd95cb0644c6a2c95f52db1fc/jackson-databind-2.9.6.jar:/home/geode/.gradle/caches/modules-2/files-2.1/com.fasterxml.jackson.core/jackson-annotations/2.9.6/6a0f0f154edaba00067772ce02e24f8c0973d84c/jackson-annotations-2.9.6.jar:/home/geode/geode/geode-junit/build/libs/geode-junit-1.8.0-SNAPSHOT.jar:/home/geode/.gradle/caches/modules-2/files-2.1/org.springframework.shell/spring-shell/1.2.0.RELEASE/d94047721f292bd5334b5654e8600cef4b845049/spring-shell-1.2.0.RELEASE.jar:/home/geode/.gradle/caches/modules-2/files-2.1/commons-io/commons-io/2.6/815893df5f31da2ece4040fe0a12fd44b577afaf/commons-io-2.6.jar:/home/geode/.gradle/caches/modules-2/files-2.1/commons-validator/commons-validator/1.6/e989d1e87cdd60575df0765ed5bac65c905d7908/commons-validator-1.6.jar:/home/geode/.gradle/caches/modules-2/files-2.1/commons-digester/commons-digester/2.1/73a8001e7a54a255eef0f03521ec1805dc738ca0/commons-digester-2.1.jar:/home/geode/.gradle/caches/modules-2/files-2.1/javax.mail/javax.mail-api/1.6.1/8cababdc2a9caae6e1641aae6671c24394227651/javax.mail-api-1.6.1.jar:/home/geode/.gradle/caches/modules-2/files-2.1/javax.activation/activation/1.1.1/485de3a253e23f645037828c07f1d7f1af40763a/activation-1.1.1.jar:/home/geode/.gradle/caches/modules-2/files-2.1/javax.xml.bind/jaxb-api/2.2.11/32274d4244967ff43e7a5d967743d94ed3d2aea7/jaxb-api-2.2.11.jar:/home/geode/.gradle/caches/modules-2/files-2.1/com.sun.xml.bind/jaxb-core/2.2.11/c3f87d654f8d5943cd08592f3f758856544d279a/jaxb-core-2.2.11.jar:/home/geode/.gradle/caches/modules-2/files-2.1/com.sun.xml.bind/jaxb-impl/2.2.11/a49ce57aee680f9435f49ba6ef427d38c93247a6/jaxb-impl-2.2.11.jar:/home/geode/.gradle/caches/modules-2/files-2.1/commons-lang/commons-lang/2.6/ce1edb914c94ebc388f086c6827e8bdeec71ac2/commons-lang-2.6.jar:/home/geode/.gradle/caches/modules-2/files-2.1/commons-modeler/commons-modeler/2.0.1/7ac36e7db0bb1230a901852ff618d3a3a873e9de/commons-modeler-2.0.1.jar:/home/geode/.gradle/caches/modules-2/files-2.1/io.netty/netty-all/4.1.27.Final/abcefabf95f3b21b3e31019fd89fd8687563076d/netty-all-4.1.27.Final.jar:/home/geode/.gradle/caches/modules-2/files-2.1/it.unimi.dsi/fastutil/8.2.1/5ad88f325e424f8dbc2be5459e21ea5cab3864e9/fastutil-8.2.1.jar:/home/geode/.gradle/caches/modules-2/files-2.1/javax.resource/javax.resource-api/1.7/ae40e0864eb1e92c48bf82a2a3399cbbf523fb79/javax.resource-api-1.7.jar:/home/geode/.gradle/caches/modules-2/files-2.1/mx4j/mx4j/3.0.2/47bf147f11b4a026263e1c96a1ea0e029f9e5ab6/mx4j-3.0.2.jar:/home/geode/.gradle/caches/modules-2/files-2.1/mx4j/mx4j-remote/3.0.2/35234324298454ee19efecb86f86b947269c9509/mx4j-remote-3.0.2.jar:/home/geode/.gradle/caches/modules-2/files-2.1/mx4j/mx4j-tools/3.0.1/df853af9fe34d4eb6f849a1b5936fddfcbe67751/mx4j-tools-3.0.1.jar:/home/geode/.gradle/caches/modules-2/files-2.1/net.java.dev.jna/jna/4.1.0/1c12d070e602efd8021
[jira] [Closed] (GEODE-5895) Rolling upgrade tests can fail with port conflicts with dunit debugger ports
[
https://issues.apache.org/jira/browse/GEODE-5895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery closed GEODE-5895.
-
> Rolling upgrade tests can fail with port conflicts with dunit debugger ports
>
>
> Key: GEODE-5895
> URL: https://issues.apache.org/jira/browse/GEODE-5895
> Project: Geode
> Issue Type: Improvement
>Reporter: Dan Smith
>Priority: Major
> Labels: swat
>
> We recently had a rolling upgrade test fail with an address already in use
> failure. Tracking this down, it looks like the issue is that the we picked an
> available port, and then bounced a dunit VM. When the VM restarted it picked
> that same port to listener for debugging connections.
> Failure:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.8.0-build.9/test-results/distributedTest/1539810558/
> {noformat}
> Bouncing VM5 from version 160 to 000
> Old process for vm_5 has exited
> Executing [/usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java, -classpath,
> /home/geode/geode/geode-core/build/classes/java/distributedTest:/home/geode/geode/geode-core/build/resources/distributedTest:/home/geode/geode/geode-dunit/build/libs/geode-dunit-1.8.0-SNAPSHOT.jar:/home/geode/geode/geode-core/build/classes/java/integrationTest:/home/geode/geode/geode-core/build/resources/integrationTest:/home/geode/geode/geode-core/build/libs/geode-core-1.8.0-SNAPSHOT.jar:/home/geode/.gradle/caches/modules-2/files-2.1/antlr/antlr/2.7.7/83cd2cd674a217ade95a4bb83a8a14f351f48bd0/antlr-2.7.7.jar:/home/geode/.gradle/caches/modules-2/files-2.1/com.github.stephenc.findbugs/findbugs-annotations/1.3.9-1/a6b11447635d80757d64b355bed3c00786d86801/findbugs-annotations-1.3.9-1.jar:/home/geode/.gradle/caches/modules-2/files-2.1/org.jgroups/jgroups/3.6.14.Final/ee11e0645462b6937625f56f42bf5e853673168/jgroups-3.6.14.Final.jar:/home/geode/.gradle/caches/modules-2/files-2.1/com.fasterxml.jackson.core/jackson-databind/2.9.6/cfa4f316351a91bfd95cb0644c6a2c95f52db1fc/jackson-databind-2.9.6.jar:/home/geode/.gradle/caches/modules-2/files-2.1/com.fasterxml.jackson.core/jackson-annotations/2.9.6/6a0f0f154edaba00067772ce02e24f8c0973d84c/jackson-annotations-2.9.6.jar:/home/geode/geode/geode-junit/build/libs/geode-junit-1.8.0-SNAPSHOT.jar:/home/geode/.gradle/caches/modules-2/files-2.1/org.springframework.shell/spring-shell/1.2.0.RELEASE/d94047721f292bd5334b5654e8600cef4b845049/spring-shell-1.2.0.RELEASE.jar:/home/geode/.gradle/caches/modules-2/files-2.1/commons-io/commons-io/2.6/815893df5f31da2ece4040fe0a12fd44b577afaf/commons-io-2.6.jar:/home/geode/.gradle/caches/modules-2/files-2.1/commons-validator/commons-validator/1.6/e989d1e87cdd60575df0765ed5bac65c905d7908/commons-validator-1.6.jar:/home/geode/.gradle/caches/modules-2/files-2.1/commons-digester/commons-digester/2.1/73a8001e7a54a255eef0f03521ec1805dc738ca0/commons-digester-2.1.jar:/home/geode/.gradle/caches/modules-2/files-2.1/javax.mail/javax.mail-api/1.6.1/8cababdc2a9caae6e1641aae6671c24394227651/javax.mail-api-1.6.1.jar:/home/geode/.gradle/caches/modules-2/files-2.1/javax.activation/activation/1.1.1/485de3a253e23f645037828c07f1d7f1af40763a/activation-1.1.1.jar:/home/geode/.gradle/caches/modules-2/files-2.1/javax.xml.bind/jaxb-api/2.2.11/32274d4244967ff43e7a5d967743d94ed3d2aea7/jaxb-api-2.2.11.jar:/home/geode/.gradle/caches/modules-2/files-2.1/com.sun.xml.bind/jaxb-core/2.2.11/c3f87d654f8d5943cd08592f3f758856544d279a/jaxb-core-2.2.11.jar:/home/geode/.gradle/caches/modules-2/files-2.1/com.sun.xml.bind/jaxb-impl/2.2.11/a49ce57aee680f9435f49ba6ef427d38c93247a6/jaxb-impl-2.2.11.jar:/home/geode/.gradle/caches/modules-2/files-2.1/commons-lang/commons-lang/2.6/ce1edb914c94ebc388f086c6827e8bdeec71ac2/commons-lang-2.6.jar:/home/geode/.gradle/caches/modules-2/files-2.1/commons-modeler/commons-modeler/2.0.1/7ac36e7db0bb1230a901852ff618d3a3a873e9de/commons-modeler-2.0.1.jar:/home/geode/.gradle/caches/modules-2/files-2.1/io.netty/netty-all/4.1.27.Final/abcefabf95f3b21b3e31019fd89fd8687563076d/netty-all-4.1.27.Final.jar:/home/geode/.gradle/caches/modules-2/files-2.1/it.unimi.dsi/fastutil/8.2.1/5ad88f325e424f8dbc2be5459e21ea5cab3864e9/fastutil-8.2.1.jar:/home/geode/.gradle/caches/modules-2/files-2.1/javax.resource/javax.resource-api/1.7/ae40e0864eb1e92c48bf82a2a3399cbbf523fb79/javax.resource-api-1.7.jar:/home/geode/.gradle/caches/modules-2/files-2.1/mx4j/mx4j/3.0.2/47bf147f11b4a026263e1c96a1ea0e029f9e5ab6/mx4j-3.0.2.jar:/home/geode/.gradle/caches/modules-2/files-2.1/mx4j/mx4j-remote/3.0.2/35234324298454ee19efecb86f86b947269c9509/mx4j-remote-3.0.2.jar:/home/geode/.gradle/caches/modules-2/files-2.1/mx4j/mx4j-tools/3.0.1/df853af9fe34d4eb6f849a1b5936fddfcbe67751/mx4j-tools-3.0.1.jar:/home/geode/.gradle/caches/modules-2/files-2.1/net.java.dev.jna/jna/4.1.0/1c12d070e602efd8021891cdd7fd18bc129372d4/jna-4.1.
[jira] [Resolved] (GEODE-9872) DistTXPersistentDebugDUnitTest tests fail because "cluster configuration service not available"
[
https://issues.apache.org/jira/browse/GEODE-9872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery resolved GEODE-9872.
---
Fix Version/s: 1.15.0
Resolution: Fixed
> DistTXPersistentDebugDUnitTest tests fail because "cluster configuration
> service not available"
> ---
>
> Key: GEODE-9872
> URL: https://issues.apache.org/jira/browse/GEODE-9872
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Bill Burcham
>Assignee: Dale Emery
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
> Fix For: 1.15.0
>
>
> I suspect this failure is due to something in the test framework, or perhaps
> one or more tests failing to manage ports correctly, allowing two or more
> tests to interfere with one another.
> In this distributed test:
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/388]
> we see two failures. Here's the first full stack trace:
>
>
> {code:java}
> [error 2021/12/04 20:40:53.796 UTC
> tid=33] org.apache.geode.GemFireConfigException: cluster configuration
> service not available
> at
> org.junit.vintage.engine.execution.TestRun.getStoredResultOrSuccessful(TestRun.java:196)
> at
> org.junit.vintage.engine.execution.RunListenerAdapter.fireExecutionFinished(RunListenerAdapter.java:226)
> at
> org.junit.vintage.engine.execution.RunListenerAdapter.testFinished(RunListenerAdapter.java:192)
> at
> org.junit.vintage.engine.execution.RunListenerAdapter.testFinished(RunListenerAdapter.java:79)
> at
> org.junit.runner.notification.SynchronizedRunListener.testFinished(SynchronizedRunListener.java:87)
> at
> org.junit.runner.notification.RunNotifier$9.notifyListener(RunNotifier.java:225)
> at
> org.junit.runner.notification.RunNotifier$SafeNotifier.run(RunNotifier.java:72)
> at
> org.junit.runner.notification.RunNotifier.fireTestFinished(RunNotifier.java:222)
> at
> org.junit.internal.runners.model.EachTestNotifier.fireTestFinished(EachTestNotifier.java:38)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:372)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.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:43)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> at
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> at
> java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> at
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
> at
> java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
> at
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:485)
> at
> org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:82)
> at
> org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:73)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:108)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:88)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.lambda$execute$0(EngineExecutionOrchestrator.java:54)
> at
> org.junit.p
[jira] [Resolved] (GEODE-9622) CI Failure: ClientServerTransactionFailoverWithMixedVersionServersDistributedTest fails with BindException
[
https://issues.apache.org/jira/browse/GEODE-9622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery resolved GEODE-9622.
---
Fix Version/s: 1.15.0
Resolution: Fixed
> CI Failure:
> ClientServerTransactionFailoverWithMixedVersionServersDistributedTest fails
> with BindException
> --
>
> Key: GEODE-9622
> URL: https://issues.apache.org/jira/browse/GEODE-9622
> Project: Geode
> Issue Type: Bug
> Components: client/server, tests
>Reporter: Kirk Lund
>Assignee: Dale Emery
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
> Fix For: 1.15.0
>
>
> {noformat}
> org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest
> > clientTransactionOperationsAreNotLostIfTransactionIsOnRolledServer FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest$$Lambda$68/194483270.call
> in VM 5 running on Host
> heavy-lifter-2b8702f1-fe32-5895-9b14-832b7049b607.c.apachegeode-ci.internal
> with 6 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:473)
> at
> org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.rollLocatorToCurrent(ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.java:216)
> at
> org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.setupPartiallyRolledVersion(ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.java:171)
> at
> org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.clientTransactionOperationsAreNotLostIfTransactionIsOnRolledServer(ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.java:127)
> Caused by:
> java.net.BindException: Failed to create server socket on
> heavy-lifter-2b8702f1-fe32-5895-9b14-832b7049b607.c.apachegeode-ci.internal/10.0.0.60[43535]
> at
> org.apache.geode.distributed.internal.tcpserver.ClusterSocketCreatorImpl.createServerSocket(ClusterSocketCreatorImpl.java:75)
> at
> org.apache.geode.internal.net.SCClusterSocketCreator.createServerSocket(SCClusterSocketCreator.java:55)
> at
> org.apache.geode.distributed.internal.tcpserver.ClusterSocketCreatorImpl.createServerSocket(ClusterSocketCreatorImpl.java:54)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.initializeServerSocket(TcpServer.java:196)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.startServerThread(TcpServer.java:183)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.start(TcpServer.java:178)
> at
> org.apache.geode.distributed.internal.membership.gms.locator.MembershipLocatorImpl.start(MembershipLocatorImpl.java:112)
> at
> org.apache.geode.distributed.internal.InternalLocator.startPeerLocation(InternalLocator.java:653)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:394)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:345)
> at
> org.apache.geode.distributed.Locator.startLocator(Locator.java:261)
> at
> org.apache.geode.distributed.Locator.startLocatorAndDS(Locator.java:207)
> at
> org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.startLocator(ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.java:180)
> at
> org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.lambda$rollLocatorToCurrent$92d5d92a$1(ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.java:216)
> Caused by:
> java.net.BindException: Address already in use (Bind failed)
> at java.net.PlainSocketImpl.socketBind(Native Method)
> at
> java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:387)
> at java.net.ServerSocket.bind(ServerSocket.java:390)
> at
> org.apache.geode.distributed.internal.tcpserver.ClusterSocketCreatorImpl.createServerSocket(ClusterSocketCreatorImpl.java:72)
> ... 13 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (GEODE-9622) CI Failure: ClientServerTransactionFailoverWithMixedVersionServersDistributedTest fails with BindException
[
https://issues.apache.org/jira/browse/GEODE-9622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery closed GEODE-9622.
-
> CI Failure:
> ClientServerTransactionFailoverWithMixedVersionServersDistributedTest fails
> with BindException
> --
>
> Key: GEODE-9622
> URL: https://issues.apache.org/jira/browse/GEODE-9622
> Project: Geode
> Issue Type: Bug
> Components: client/server, tests
>Reporter: Kirk Lund
>Assignee: Dale Emery
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
> Fix For: 1.15.0
>
>
> {noformat}
> org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest
> > clientTransactionOperationsAreNotLostIfTransactionIsOnRolledServer FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest$$Lambda$68/194483270.call
> in VM 5 running on Host
> heavy-lifter-2b8702f1-fe32-5895-9b14-832b7049b607.c.apachegeode-ci.internal
> with 6 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:473)
> at
> org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.rollLocatorToCurrent(ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.java:216)
> at
> org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.setupPartiallyRolledVersion(ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.java:171)
> at
> org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.clientTransactionOperationsAreNotLostIfTransactionIsOnRolledServer(ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.java:127)
> Caused by:
> java.net.BindException: Failed to create server socket on
> heavy-lifter-2b8702f1-fe32-5895-9b14-832b7049b607.c.apachegeode-ci.internal/10.0.0.60[43535]
> at
> org.apache.geode.distributed.internal.tcpserver.ClusterSocketCreatorImpl.createServerSocket(ClusterSocketCreatorImpl.java:75)
> at
> org.apache.geode.internal.net.SCClusterSocketCreator.createServerSocket(SCClusterSocketCreator.java:55)
> at
> org.apache.geode.distributed.internal.tcpserver.ClusterSocketCreatorImpl.createServerSocket(ClusterSocketCreatorImpl.java:54)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.initializeServerSocket(TcpServer.java:196)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.startServerThread(TcpServer.java:183)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.start(TcpServer.java:178)
> at
> org.apache.geode.distributed.internal.membership.gms.locator.MembershipLocatorImpl.start(MembershipLocatorImpl.java:112)
> at
> org.apache.geode.distributed.internal.InternalLocator.startPeerLocation(InternalLocator.java:653)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:394)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:345)
> at
> org.apache.geode.distributed.Locator.startLocator(Locator.java:261)
> at
> org.apache.geode.distributed.Locator.startLocatorAndDS(Locator.java:207)
> at
> org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.startLocator(ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.java:180)
> at
> org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.lambda$rollLocatorToCurrent$92d5d92a$1(ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.java:216)
> Caused by:
> java.net.BindException: Address already in use (Bind failed)
> at java.net.PlainSocketImpl.socketBind(Native Method)
> at
> java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:387)
> at java.net.ServerSocket.bind(ServerSocket.java:390)
> at
> org.apache.geode.distributed.internal.tcpserver.ClusterSocketCreatorImpl.createServerSocket(ClusterSocketCreatorImpl.java:72)
> ... 13 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (GEODE-9872) DistTXPersistentDebugDUnitTest tests fail because "cluster configuration service not available"
[
https://issues.apache.org/jira/browse/GEODE-9872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery closed GEODE-9872.
-
> DistTXPersistentDebugDUnitTest tests fail because "cluster configuration
> service not available"
> ---
>
> Key: GEODE-9872
> URL: https://issues.apache.org/jira/browse/GEODE-9872
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Bill Burcham
>Assignee: Dale Emery
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
> Fix For: 1.15.0
>
>
> I suspect this failure is due to something in the test framework, or perhaps
> one or more tests failing to manage ports correctly, allowing two or more
> tests to interfere with one another.
> In this distributed test:
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/388]
> we see two failures. Here's the first full stack trace:
>
>
> {code:java}
> [error 2021/12/04 20:40:53.796 UTC
> tid=33] org.apache.geode.GemFireConfigException: cluster configuration
> service not available
> at
> org.junit.vintage.engine.execution.TestRun.getStoredResultOrSuccessful(TestRun.java:196)
> at
> org.junit.vintage.engine.execution.RunListenerAdapter.fireExecutionFinished(RunListenerAdapter.java:226)
> at
> org.junit.vintage.engine.execution.RunListenerAdapter.testFinished(RunListenerAdapter.java:192)
> at
> org.junit.vintage.engine.execution.RunListenerAdapter.testFinished(RunListenerAdapter.java:79)
> at
> org.junit.runner.notification.SynchronizedRunListener.testFinished(SynchronizedRunListener.java:87)
> at
> org.junit.runner.notification.RunNotifier$9.notifyListener(RunNotifier.java:225)
> at
> org.junit.runner.notification.RunNotifier$SafeNotifier.run(RunNotifier.java:72)
> at
> org.junit.runner.notification.RunNotifier.fireTestFinished(RunNotifier.java:222)
> at
> org.junit.internal.runners.model.EachTestNotifier.fireTestFinished(EachTestNotifier.java:38)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:372)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.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:43)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> at
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> at
> java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> at
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
> at
> java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
> at
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:485)
> at
> org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:82)
> at
> org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:73)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:108)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:88)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.lambda$execute$0(EngineExecutionOrchestrator.java:54)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.withI
[jira] [Created] (GEODE-9897) ClientUserAuthsTest leaves some seemingly tested responsibilities untested
Dale Emery created GEODE-9897:
-
Summary: ClientUserAuthsTest leaves some seemingly tested
responsibilities untested
Key: GEODE-9897
URL: https://issues.apache.org/jira/browse/GEODE-9897
Project: Geode
Issue Type: Test
Components: tests
Reporter: Dale Emery
*Problem 1:* The test class's {{before()}} method uses the {{spy()}} mechanism
to override {{getNextId()}} on the {{ClientUserAuths}} it is testing. This
bypasses the actual implementation for all tests, leaving untested the
following important {{ClientUserAuths}} responsibilities:
- Detect when all IDs have all been used.
- Clear all existing authentications when all IDs have been used, to force
reauthentication.
- Re-seed the ID generator when all IDs have been used.
The tests are likely doing this because {{getNextId()}} relies on a
{{{}Random{}}}, which is uncontrollable by design. Because {{ClientUserAuths}}
creates the {{{}Random{}}}, the tests are unable to inject a testable instance,
and so instead must bypass the {{ClientUserAuths}} methods that interact with
the {{{}Random{}}}.
The solution to this problem is to extract and test an ID generator that
accepts a {{Random}} as a constructor parameter, thus allowing tests to control
it.
This also frees {{ClientUserAuths}} from the responsibility to generate IDs, so
it can instead focus on how it uses the IDs. Then it will be straightforward to
write tests to verify that {{ClientUserAuths}} forces reauthentication when the
generator runs out of IDs.
*Problem 2:* Several tests in this class attempt to verify certain
responsibilities only by spying on how the {{ClientUserAuths}} interacts with
itself. Verifying only these internal interactions leaves the actual
responsibilities (how the {{ClientUserAuths}} responds to subsequent calls)
untested.
The tests can instead verify the actual responsibilities by calling public
methods and making assertions about the returned values.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9897) ClientUserAuthsTest leaves some seemingly tested responsibilities untested
[
https://issues.apache.org/jira/browse/GEODE-9897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery updated GEODE-9897:
--
Labels: GeodeOperationAPI (was: )
> ClientUserAuthsTest leaves some seemingly tested responsibilities untested
> --
>
> Key: GEODE-9897
> URL: https://issues.apache.org/jira/browse/GEODE-9897
> Project: Geode
> Issue Type: Test
> Components: tests
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
> Labels: GeodeOperationAPI
>
> *Problem 1:* The test class's {{before()}} method uses the {{spy()}}
> mechanism to override {{getNextId()}} on the {{ClientUserAuths}} it is
> testing. This bypasses the actual implementation for all tests, leaving
> untested the following important {{ClientUserAuths}} responsibilities:
> - Detect when all IDs have all been used.
> - Clear all existing authentications when all IDs have been used, to force
> reauthentication.
> - Re-seed the ID generator when all IDs have been used.
> The tests are likely doing this because {{getNextId()}} relies on a
> {{{}Random{}}}, which is uncontrollable by design. Because
> {{ClientUserAuths}} creates the {{{}Random{}}}, the tests are unable to
> inject a testable instance, and so instead must bypass the
> {{ClientUserAuths}} methods that interact with the {{{}Random{}}}.
> The solution to this problem is to extract and test an ID generator that
> accepts a {{Random}} as a constructor parameter, thus allowing tests to
> control it.
> This also frees {{ClientUserAuths}} from the responsibility to generate IDs,
> so it can instead focus on how it uses the IDs. Then it will be
> straightforward to write tests to verify that {{ClientUserAuths}} forces
> reauthentication when the generator runs out of IDs.
> *Problem 2:* Several tests in this class attempt to verify certain
> responsibilities only by spying on how the {{ClientUserAuths}} interacts with
> itself. Verifying only these internal interactions leaves the actual
> responsibilities (how the {{ClientUserAuths}} responds to subsequent calls)
> untested.
> The tests can instead verify the actual responsibilities by calling public
> methods and making assertions about the returned values.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-9897) ClientUserAuthsTest leaves some seemingly tested responsibilities untested
[
https://issues.apache.org/jira/browse/GEODE-9897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery reassigned GEODE-9897:
-
Assignee: Dale Emery
> ClientUserAuthsTest leaves some seemingly tested responsibilities untested
> --
>
> Key: GEODE-9897
> URL: https://issues.apache.org/jira/browse/GEODE-9897
> Project: Geode
> Issue Type: Test
> Components: tests
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
>
> *Problem 1:* The test class's {{before()}} method uses the {{spy()}}
> mechanism to override {{getNextId()}} on the {{ClientUserAuths}} it is
> testing. This bypasses the actual implementation for all tests, leaving
> untested the following important {{ClientUserAuths}} responsibilities:
> - Detect when all IDs have all been used.
> - Clear all existing authentications when all IDs have been used, to force
> reauthentication.
> - Re-seed the ID generator when all IDs have been used.
> The tests are likely doing this because {{getNextId()}} relies on a
> {{{}Random{}}}, which is uncontrollable by design. Because
> {{ClientUserAuths}} creates the {{{}Random{}}}, the tests are unable to
> inject a testable instance, and so instead must bypass the
> {{ClientUserAuths}} methods that interact with the {{{}Random{}}}.
> The solution to this problem is to extract and test an ID generator that
> accepts a {{Random}} as a constructor parameter, thus allowing tests to
> control it.
> This also frees {{ClientUserAuths}} from the responsibility to generate IDs,
> so it can instead focus on how it uses the IDs. Then it will be
> straightforward to write tests to verify that {{ClientUserAuths}} forces
> reauthentication when the generator runs out of IDs.
> *Problem 2:* Several tests in this class attempt to verify certain
> responsibilities only by spying on how the {{ClientUserAuths}} interacts with
> itself. Verifying only these internal interactions leaves the actual
> responsibilities (how the {{ClientUserAuths}} responds to subsequent calls)
> untested.
> The tests can instead verify the actual responsibilities by calling public
> methods and making assertions about the returned values.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-6751) CI failure: AcceptanceTestOpenJDK8 ConnectCommandAcceptanceTest.useCurrentGfshToConnectToOlderLocator failure
[ https://issues.apache.org/jira/browse/GEODE-6751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17459385#comment-17459385 ] Dale Emery commented on GEODE-6751: --- I think this test is trying to start the second locator (the one with the current Geode version) with JMX enabled on the default port. Tests designed to run in parallel cannot use default ports, because other concurrently running tests might already be bound to those ports. If that's correct, the fix is to either: # Use `AvailablePortHelper` to assign ports for every service used by every member, instead of using defaults. # Disable JXM if the test doesn't need it. > CI failure: AcceptanceTestOpenJDK8 > ConnectCommandAcceptanceTest.useCurrentGfshToConnectToOlderLocator failure > - > > Key: GEODE-6751 > URL: https://issues.apache.org/jira/browse/GEODE-6751 > Project: Geode > Issue Type: Bug > Components: management >Affects Versions: 1.15.0 >Reporter: Scott Jewell >Priority: Major > > Assertion failure in > ConnectCommandAcceptanceTest.useCurrentGfshToConnectToOlderLocator > Appears to be a new bug > org.apache.geode.management.internal.cli.commands.ConnectCommandAcceptanceTest > > useCurrentGfshToConnectToOlderLocator FAILED > java.lang.AssertionError: > Expecting: > <" > (1) Executing - connect > Connecting to Locator at [host=localhost, port=10334] .. > Exception caused JMX Manager startup to fail because: 'HTTP service > failed to start' > "> > to contain: > <"Cannot use a"> > at > org.apache.geode.management.internal.cli.commands.ConnectCommandAcceptanceTest.useCurrentGfshToConnectToOlderLocator(ConnectCommandAcceptanceTest.java:50) > 60 tests completed, 1 failed > =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > [*http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0258/test-results/acceptanceTest/1557290414/*] > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Test report artifacts from this job are available at: > [*http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0258/test-artifacts/1557290414/acceptancetestfiles-OpenJDK8-1.10.0-SNAPSHOT.0258.tgz*] > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9924) Make repeat tests log each test class instance separately
[ https://issues.apache.org/jira/browse/GEODE-9924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale Emery updated GEODE-9924: -- Component/s: tests > Make repeat tests log each test class instance separately > - > > Key: GEODE-9924 > URL: https://issues.apache.org/jira/browse/GEODE-9924 > Project: Geode > Issue Type: Test > Components: tests >Reporter: Dale Emery >Priority: Major > > Currently, our repeat test tasks merge the output from all executions of a > given test class, making it very difficult to diagnose failures in repeat > tests. > CAUSE: > In order to run tests repeatedly, our repeat test tasks override Gradle code > to allow a test class to execute more than once. > Gradle directs the output from each test to a log associated with the test > class name. > SOLUTION: > Change Gradle to distinguish separate executions of a test class, and to log > the output from each execution separately. This can be done by using a custom > "test result processor" that appends an iteration counter to the end of the > test class name before processing the result. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-9924) Make repeat tests log each test class instance separately
Dale Emery created GEODE-9924: - Summary: Make repeat tests log each test class instance separately Key: GEODE-9924 URL: https://issues.apache.org/jira/browse/GEODE-9924 Project: Geode Issue Type: Test Reporter: Dale Emery Currently, our repeat test tasks merge the output from all executions of a given test class, making it very difficult to diagnose failures in repeat tests. CAUSE: In order to run tests repeatedly, our repeat test tasks override Gradle code to allow a test class to execute more than once. Gradle directs the output from each test to a log associated with the test class name. SOLUTION: Change Gradle to distinguish separate executions of a test class, and to log the output from each execution separately. This can be done by using a custom "test result processor" that appends an iteration counter to the end of the test class name before processing the result. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-9924) Make repeat tests log each test class instance separately
[ https://issues.apache.org/jira/browse/GEODE-9924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale Emery reassigned GEODE-9924: - Assignee: Dale Emery > Make repeat tests log each test class instance separately > - > > Key: GEODE-9924 > URL: https://issues.apache.org/jira/browse/GEODE-9924 > Project: Geode > Issue Type: Test > Components: tests >Reporter: Dale Emery >Assignee: Dale Emery >Priority: Major > Labels: GeodeOperationAPI > > Currently, our repeat test tasks merge the output from all executions of a > given test class, making it very difficult to diagnose failures in repeat > tests. > CAUSE: > In order to run tests repeatedly, our repeat test tasks override Gradle code > to allow a test class to execute more than once. > Gradle directs the output from each test to a log associated with the test > class name. > SOLUTION: > Change Gradle to distinguish separate executions of a test class, and to log > the output from each execution separately. This can be done by using a custom > "test result processor" that appends an iteration counter to the end of the > test class name before processing the result. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9924) Make repeat tests log each test class instance separately
[ https://issues.apache.org/jira/browse/GEODE-9924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale Emery updated GEODE-9924: -- Labels: GeodeOperationAPI (was: ) > Make repeat tests log each test class instance separately > - > > Key: GEODE-9924 > URL: https://issues.apache.org/jira/browse/GEODE-9924 > Project: Geode > Issue Type: Test > Components: tests >Reporter: Dale Emery >Priority: Major > Labels: GeodeOperationAPI > > Currently, our repeat test tasks merge the output from all executions of a > given test class, making it very difficult to diagnose failures in repeat > tests. > CAUSE: > In order to run tests repeatedly, our repeat test tasks override Gradle code > to allow a test class to execute more than once. > Gradle directs the output from each test to a log associated with the test > class name. > SOLUTION: > Change Gradle to distinguish separate executions of a test class, and to log > the output from each execution separately. This can be done by using a custom > "test result processor" that appends an iteration counter to the end of the > test class name before processing the result. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-9924) Make repeat tests log each test class instance separately
[ https://issues.apache.org/jira/browse/GEODE-9924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale Emery resolved GEODE-9924. --- Resolution: Fixed > Make repeat tests log each test class instance separately > - > > Key: GEODE-9924 > URL: https://issues.apache.org/jira/browse/GEODE-9924 > Project: Geode > Issue Type: Test > Components: tests >Reporter: Dale Emery >Assignee: Dale Emery >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > Currently, our repeat test tasks merge the output from all executions of a > given test class, making it very difficult to diagnose failures in repeat > tests. > CAUSE: > In order to run tests repeatedly, our repeat test tasks override Gradle code > to allow a test class to execute more than once. > Gradle directs the output from each test to a log associated with the test > class name. > SOLUTION: > Change Gradle to distinguish separate executions of a test class, and to log > the output from each execution separately. This can be done by using a custom > "test result processor" that appends an iteration counter to the end of the > test class name before processing the result. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (GEODE-9924) Make repeat tests log each test class instance separately
[ https://issues.apache.org/jira/browse/GEODE-9924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale Emery closed GEODE-9924. - > Make repeat tests log each test class instance separately > - > > Key: GEODE-9924 > URL: https://issues.apache.org/jira/browse/GEODE-9924 > Project: Geode > Issue Type: Test > Components: tests >Reporter: Dale Emery >Assignee: Dale Emery >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > Currently, our repeat test tasks merge the output from all executions of a > given test class, making it very difficult to diagnose failures in repeat > tests. > CAUSE: > In order to run tests repeatedly, our repeat test tasks override Gradle code > to allow a test class to execute more than once. > Gradle directs the output from each test to a log associated with the test > class name. > SOLUTION: > Change Gradle to distinguish separate executions of a test class, and to log > the output from each execution separately. This can be done by using a custom > "test result processor" that appends an iteration counter to the end of the > test class name before processing the result. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-9942) Stress test tasks neglect non-public JUnit 5 test classes
Dale Emery created GEODE-9942:
-
Summary: Stress test tasks neglect non-public JUnit 5 test classes
Key: GEODE-9942
URL: https://issues.apache.org/jira/browse/GEODE-9942
Project: Geode
Issue Type: Test
Components: tests
Affects Versions: 1.15.0
Reporter: Dale Emery
JUnit 5 test classes need not be public. Indeed, IntelliJ's default inspections
discourage making JUnit 5 classes public.
{{StressTestHelper}} uses a {{ClassGraph}} to gather information about test
classes. By default, {{ClassGraph}} scans only public classes. So by default,
{{ClassGraph}} does not gather information about JUnit 5 classes with
non-public visibility. As a result, our stress test scripts do not run JUnit 5
tests.
Solution: Call {{ignoreClassVisibility()}} to configure {{ClassGraph}} to scan
all classes, not just public ones.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-9942) Stress test tasks neglect non-public JUnit 5 test classes
[
https://issues.apache.org/jira/browse/GEODE-9942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery reassigned GEODE-9942:
-
Assignee: Dale Emery
> Stress test tasks neglect non-public JUnit 5 test classes
> -
>
> Key: GEODE-9942
> URL: https://issues.apache.org/jira/browse/GEODE-9942
> Project: Geode
> Issue Type: Test
> Components: tests
>Affects Versions: 1.15.0
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
>
> JUnit 5 test classes need not be public. Indeed, IntelliJ's default
> inspections discourage making JUnit 5 classes public.
> {{StressTestHelper}} uses a {{ClassGraph}} to gather information about test
> classes. By default, {{ClassGraph}} scans only public classes. So by default,
> {{ClassGraph}} does not gather information about JUnit 5 classes with
> non-public visibility. As a result, our stress test scripts do not run JUnit
> 5 tests.
> Solution: Call {{ignoreClassVisibility()}} to configure {{ClassGraph}} to
> scan all classes, not just public ones.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9942) Stress test tasks neglect non-public JUnit 5 test classes
[
https://issues.apache.org/jira/browse/GEODE-9942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery updated GEODE-9942:
--
Labels: GeodeOperationAPI pull-request-available (was:
pull-request-available)
> Stress test tasks neglect non-public JUnit 5 test classes
> -
>
> Key: GEODE-9942
> URL: https://issues.apache.org/jira/browse/GEODE-9942
> Project: Geode
> Issue Type: Test
> Components: tests
>Affects Versions: 1.15.0
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> JUnit 5 test classes need not be public. Indeed, IntelliJ's default
> inspections discourage making JUnit 5 classes public.
> {{StressTestHelper}} uses a {{ClassGraph}} to gather information about test
> classes. By default, {{ClassGraph}} scans only public classes. So by default,
> {{ClassGraph}} does not gather information about JUnit 5 classes with
> non-public visibility. As a result, our stress test scripts do not run JUnit
> 5 tests.
> Solution: Call {{ignoreClassVisibility()}} to configure {{ClassGraph}} to
> scan all classes, not just public ones.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (GEODE-9942) Stress test tasks neglect non-public JUnit 5 test classes
[
https://issues.apache.org/jira/browse/GEODE-9942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery resolved GEODE-9942.
---
Resolution: Fixed
> Stress test tasks neglect non-public JUnit 5 test classes
> -
>
> Key: GEODE-9942
> URL: https://issues.apache.org/jira/browse/GEODE-9942
> Project: Geode
> Issue Type: Test
> Components: tests
>Affects Versions: 1.15.0
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> JUnit 5 test classes need not be public. Indeed, IntelliJ's default
> inspections discourage making JUnit 5 classes public.
> {{StressTestHelper}} uses a {{ClassGraph}} to gather information about test
> classes. By default, {{ClassGraph}} scans only public classes. So by default,
> {{ClassGraph}} does not gather information about JUnit 5 classes with
> non-public visibility. As a result, our stress test scripts do not run JUnit
> 5 tests.
> Solution: Call {{ignoreClassVisibility()}} to configure {{ClassGraph}} to
> scan all classes, not just public ones.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9942) Stress test tasks neglect non-public JUnit 5 test classes
[
https://issues.apache.org/jira/browse/GEODE-9942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery updated GEODE-9942:
--
Fix Version/s: 1.15.0
> Stress test tasks neglect non-public JUnit 5 test classes
> -
>
> Key: GEODE-9942
> URL: https://issues.apache.org/jira/browse/GEODE-9942
> Project: Geode
> Issue Type: Test
> Components: tests
>Affects Versions: 1.15.0
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
> Fix For: 1.15.0
>
>
> JUnit 5 test classes need not be public. Indeed, IntelliJ's default
> inspections discourage making JUnit 5 classes public.
> {{StressTestHelper}} uses a {{ClassGraph}} to gather information about test
> classes. By default, {{ClassGraph}} scans only public classes. So by default,
> {{ClassGraph}} does not gather information about JUnit 5 classes with
> non-public visibility. As a result, our stress test scripts do not run JUnit
> 5 tests.
> Solution: Call {{ignoreClassVisibility()}} to configure {{ClassGraph}} to
> scan all classes, not just public ones.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (GEODE-9942) Stress test tasks neglect non-public JUnit 5 test classes
[
https://issues.apache.org/jira/browse/GEODE-9942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery closed GEODE-9942.
-
> Stress test tasks neglect non-public JUnit 5 test classes
> -
>
> Key: GEODE-9942
> URL: https://issues.apache.org/jira/browse/GEODE-9942
> Project: Geode
> Issue Type: Test
> Components: tests
>Affects Versions: 1.15.0
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
> Fix For: 1.15.0
>
>
> JUnit 5 test classes need not be public. Indeed, IntelliJ's default
> inspections discourage making JUnit 5 classes public.
> {{StressTestHelper}} uses a {{ClassGraph}} to gather information about test
> classes. By default, {{ClassGraph}} scans only public classes. So by default,
> {{ClassGraph}} does not gather information about JUnit 5 classes with
> non-public visibility. As a result, our stress test scripts do not run JUnit
> 5 tests.
> Solution: Call {{ignoreClassVisibility()}} to configure {{ClassGraph}} to
> scan all classes, not just public ones.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9897) ClientUserAuthsTest leaves some seemingly tested responsibilities untested
[
https://issues.apache.org/jira/browse/GEODE-9897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery updated GEODE-9897:
--
Fix Version/s: 1.15.0
> ClientUserAuthsTest leaves some seemingly tested responsibilities untested
> --
>
> Key: GEODE-9897
> URL: https://issues.apache.org/jira/browse/GEODE-9897
> Project: Geode
> Issue Type: Test
> Components: tests
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
> Fix For: 1.15.0
>
>
> *Problem 1:* The test class's {{before()}} method uses the {{spy()}}
> mechanism to override {{getNextId()}} on the {{ClientUserAuths}} it is
> testing. This bypasses the actual implementation for all tests, leaving
> untested the following important {{ClientUserAuths}} responsibilities:
> - Detect when all IDs have all been used.
> - Clear all existing authentications when all IDs have been used, to force
> reauthentication.
> - Re-seed the ID generator when all IDs have been used.
> The tests are likely doing this because {{getNextId()}} relies on a
> {{{}Random{}}}, which is uncontrollable by design. Because
> {{ClientUserAuths}} creates the {{{}Random{}}}, the tests are unable to
> inject a testable instance, and so instead must bypass the
> {{ClientUserAuths}} methods that interact with the {{{}Random{}}}.
> The solution to this problem is to extract and test an ID generator that
> accepts a {{Random}} as a constructor parameter, thus allowing tests to
> control it.
> This also frees {{ClientUserAuths}} from the responsibility to generate IDs,
> so it can instead focus on how it uses the IDs. Then it will be
> straightforward to write tests to verify that {{ClientUserAuths}} forces
> reauthentication when the generator runs out of IDs.
> *Problem 2:* Several tests in this class attempt to verify certain
> responsibilities only by spying on how the {{ClientUserAuths}} interacts with
> itself. Verifying only these internal interactions leaves the actual
> responsibilities (how the {{ClientUserAuths}} responds to subsequent calls)
> untested.
> The tests can instead verify the actual responsibilities by calling public
> methods and making assertions about the returned values.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (GEODE-9897) ClientUserAuthsTest leaves some seemingly tested responsibilities untested
[
https://issues.apache.org/jira/browse/GEODE-9897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery resolved GEODE-9897.
---
Resolution: Fixed
> ClientUserAuthsTest leaves some seemingly tested responsibilities untested
> --
>
> Key: GEODE-9897
> URL: https://issues.apache.org/jira/browse/GEODE-9897
> Project: Geode
> Issue Type: Test
> Components: tests
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> *Problem 1:* The test class's {{before()}} method uses the {{spy()}}
> mechanism to override {{getNextId()}} on the {{ClientUserAuths}} it is
> testing. This bypasses the actual implementation for all tests, leaving
> untested the following important {{ClientUserAuths}} responsibilities:
> - Detect when all IDs have all been used.
> - Clear all existing authentications when all IDs have been used, to force
> reauthentication.
> - Re-seed the ID generator when all IDs have been used.
> The tests are likely doing this because {{getNextId()}} relies on a
> {{{}Random{}}}, which is uncontrollable by design. Because
> {{ClientUserAuths}} creates the {{{}Random{}}}, the tests are unable to
> inject a testable instance, and so instead must bypass the
> {{ClientUserAuths}} methods that interact with the {{{}Random{}}}.
> The solution to this problem is to extract and test an ID generator that
> accepts a {{Random}} as a constructor parameter, thus allowing tests to
> control it.
> This also frees {{ClientUserAuths}} from the responsibility to generate IDs,
> so it can instead focus on how it uses the IDs. Then it will be
> straightforward to write tests to verify that {{ClientUserAuths}} forces
> reauthentication when the generator runs out of IDs.
> *Problem 2:* Several tests in this class attempt to verify certain
> responsibilities only by spying on how the {{ClientUserAuths}} interacts with
> itself. Verifying only these internal interactions leaves the actual
> responsibilities (how the {{ClientUserAuths}} responds to subsequent calls)
> untested.
> The tests can instead verify the actual responsibilities by calling public
> methods and making assertions about the returned values.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (GEODE-9897) ClientUserAuthsTest leaves some seemingly tested responsibilities untested
[
https://issues.apache.org/jira/browse/GEODE-9897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery closed GEODE-9897.
-
> ClientUserAuthsTest leaves some seemingly tested responsibilities untested
> --
>
> Key: GEODE-9897
> URL: https://issues.apache.org/jira/browse/GEODE-9897
> Project: Geode
> Issue Type: Test
> Components: tests
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
> Fix For: 1.15.0
>
>
> *Problem 1:* The test class's {{before()}} method uses the {{spy()}}
> mechanism to override {{getNextId()}} on the {{ClientUserAuths}} it is
> testing. This bypasses the actual implementation for all tests, leaving
> untested the following important {{ClientUserAuths}} responsibilities:
> - Detect when all IDs have all been used.
> - Clear all existing authentications when all IDs have been used, to force
> reauthentication.
> - Re-seed the ID generator when all IDs have been used.
> The tests are likely doing this because {{getNextId()}} relies on a
> {{{}Random{}}}, which is uncontrollable by design. Because
> {{ClientUserAuths}} creates the {{{}Random{}}}, the tests are unable to
> inject a testable instance, and so instead must bypass the
> {{ClientUserAuths}} methods that interact with the {{{}Random{}}}.
> The solution to this problem is to extract and test an ID generator that
> accepts a {{Random}} as a constructor parameter, thus allowing tests to
> control it.
> This also frees {{ClientUserAuths}} from the responsibility to generate IDs,
> so it can instead focus on how it uses the IDs. Then it will be
> straightforward to write tests to verify that {{ClientUserAuths}} forces
> reauthentication when the generator runs out of IDs.
> *Problem 2:* Several tests in this class attempt to verify certain
> responsibilities only by spying on how the {{ClientUserAuths}} interacts with
> itself. Verifying only these internal interactions leaves the actual
> responsibilities (how the {{ClientUserAuths}} responds to subsequent calls)
> untested.
> The tests can instead verify the actual responsibilities by calling public
> methods and making assertions about the returned values.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-10079) CI scripts no longer supply docker images for pre-1.15 PR precheck tasks
Dale Emery created GEODE-10079: -- Summary: CI scripts no longer supply docker images for pre-1.15 PR precheck tasks Key: GEODE-10079 URL: https://issues.apache.org/jira/browse/GEODE-10079 Project: Geode Issue Type: Test Components: ci Affects Versions: 1.12.9, 1.13.8, 1.14.4 Reporter: Dale Emery The CI scripts no longer supply docker images when they run PR precheck tasks that use the `-PdunitDockerImage` property. For PRs with base branches prior to `support/1.15`, the `distributedTest` and `upgradeTest` precheck tasks must run each test class in a separate docker container. When `dunitDockerImage` is not defined, these tasks instead run tests concurrently outside of docker. This results in swarms of failures, as the concurrently executing tests all attempt to bind to the same ports. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10079) CI scripts no longer supply docker images for pre-1.15 PR precheck tasks
[ https://issues.apache.org/jira/browse/GEODE-10079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale Emery updated GEODE-10079: --- Description: The CI scripts no longer supply docker images when they run PR precheck tasks that use the `-PdunitDockerImage` property. For PRs with base branches prior to `support/1.15`, the `distributedTest` and `upgradeTest` precheck tasks must run each test class in a separate docker container. When `dunitDockerImage` is not defined, these tasks instead run tests concurrently outside of docker. This results in swarms of failures, as the concurrently executing tests all attempt to bind to the same ports. Examples: - https://concourse.apachegeode-ci.info/builds/27926695 - https://concourse.apachegeode-ci.info/builds/27632643 - https://concourse.apachegeode-ci.info/builds/28861132 was: The CI scripts no longer supply docker images when they run PR precheck tasks that use the `-PdunitDockerImage` property. For PRs with base branches prior to `support/1.15`, the `distributedTest` and `upgradeTest` precheck tasks must run each test class in a separate docker container. When `dunitDockerImage` is not defined, these tasks instead run tests concurrently outside of docker. This results in swarms of failures, as the concurrently executing tests all attempt to bind to the same ports. > CI scripts no longer supply docker images for pre-1.15 PR precheck tasks > > > Key: GEODE-10079 > URL: https://issues.apache.org/jira/browse/GEODE-10079 > Project: Geode > Issue Type: Test > Components: ci >Affects Versions: 1.12.9, 1.13.8, 1.14.4 >Reporter: Dale Emery >Priority: Major > > The CI scripts no longer supply docker images when they run PR precheck tasks > that use the `-PdunitDockerImage` property. > For PRs with base branches prior to `support/1.15`, the `distributedTest` and > `upgradeTest` precheck tasks must run each test class in a separate docker > container. When `dunitDockerImage` is not defined, these tasks instead run > tests concurrently outside of docker. This results in swarms of failures, as > the concurrently executing tests all attempt to bind to the same ports. > Examples: > - https://concourse.apachegeode-ci.info/builds/27926695 > - https://concourse.apachegeode-ci.info/builds/27632643 > - https://concourse.apachegeode-ci.info/builds/28861132 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10119) Handle SslSocket throwing SSLHandshakeException on JDK 17
Dale Emery created GEODE-10119:
--
Summary: Handle SslSocket throwing SSLHandshakeException on JDK 17
Key: GEODE-10119
URL: https://issues.apache.org/jira/browse/GEODE-10119
Project: Geode
Issue Type: Bug
Components: core, tests
Affects Versions: 1.15.0
Reporter: Dale Emery
In some circumstances, on JDK 17 {SslSocket} throws {SSLHandshakeException},
where on JDK 8 and 11 it would throw {SocketException}.
{SocketCreator.configureClientSSLSocket()} handles {SSLHandshakeException} and
{SocketException} differently:
- It catches {SSLHandshakeException}, logs it as fatal, and rethrows it.
- It does not catch {SocketException}.
The new "fatal" log entry on JDK 17 causes
{WANSSLDUnitTest.testSenderSSLReceiverNoSSL()} to fail.
This may be simply a test issue. If so, the fix is to configure the test to
ignore this new exception.
But possibly the product's error handling needs to be changed to account for
{SslSocket} throwing {SSLHandshakeException}.
Example test failure on JDK 17:
{noformat}
java.lang.AssertionError: Suspicious strings were written to the log during
this run.
Fix the strings or use IgnoredException.addIgnoredException to ignore.
---
Found suspect string in 'dunit_suspect-vm4.log' at line 548
[fatal 2022/03/10 01:29:50.162 UTC
tid=144] Problem forming SSL connection to
dale-dunit.c.apachegeode-ci.internal/10.128.0.33[28386].
javax.net.ssl.SSLHandshakeException: Remote host terminated the handshake
at
java.base/sun.security.ssl.SSLSocketImpl.handleEOF(SSLSocketImpl.java:1709)
at
java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1508)
at
java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1415)
at
java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:450)
at
java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:421)
at
org.apache.geode.internal.net.SocketCreator.configureClientSSLSocket(SocketCreator.java:591)
at
org.apache.geode.internal.net.SCAdvancedSocketCreator.connect(SCAdvancedSocketCreator.java:83)
at
org.apache.geode.distributed.internal.tcpserver.TcpSocketCreatorImpl.connect(TcpSocketCreatorImpl.java:59)
at
org.apache.geode.distributed.internal.tcpserver.ClientSocketCreatorImpl.connect(ClientSocketCreatorImpl.java:54)
at
org.apache.geode.cache.client.internal.ConnectionImpl.connect(ConnectionImpl.java:94)
at
org.apache.geode.cache.client.internal.ConnectionConnector.connectClientToServer(ConnectionConnector.java:75)
at
org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:120)
at
org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:243)
at
org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:196)
at
org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:190)
at
org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.borrowConnection(ConnectionManagerImpl.java:282)
at
org.apache.geode.cache.client.internal.PoolImpl.acquireConnection(PoolImpl.java:940)
at
org.apache.geode.cache.wan.internal.GatewaySenderEventRemoteDispatcher.initializeConnection(GatewaySenderEventRemoteDispatcher.java:481)
at
org.apache.geode.cache.wan.internal.GatewaySenderEventRemoteDispatcher.(GatewaySenderEventRemoteDispatcher.java:105)
at
org.apache.geode.cache.wan.internal.serial.RemoteSerialGatewaySenderEventProcessor.initializeEventDispatcher(RemoteSerialGatewaySenderEventProcessor.java:45)
at
org.apache.geode.internal.cache.wan.AbstractGatewaySenderEventProcessor.setRunningStatus(AbstractGatewaySenderEventProcessor.java:1107)
at
org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderEventProcessor.run(SerialGatewaySenderEventProcessor.java:195)
Suppressed: java.net.SocketException: Broken pipe
at
java.base/sun.nio.ch.NioSocketImpl.implWrite(NioSocketImpl.java:420)
at
java.base/sun.nio.ch.NioSocketImpl.write(NioSocketImpl.java:440)
at
java.base/sun.nio.ch.NioSocketImpl$2.write(NioSocketImpl.java:826)
at
java.base/java.net.Socket$SocketOutputStream.write(Socket.java:1035)
at
java.base/sun.security.ssl.SSLSocketOutputRecord.encodeAlert(SSLSocketOutputRecord.java:81)
at
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:407)
at
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:314)
[jira] [Updated] (GEODE-10119) Handle SslSocket throwing SSLHandshakeException on JDK 17
[
https://issues.apache.org/jira/browse/GEODE-10119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery updated GEODE-10119:
---
Labels: Java17 needsTriage (was: needsTriage)
> Handle SslSocket throwing SSLHandshakeException on JDK 17
> -
>
> Key: GEODE-10119
> URL: https://issues.apache.org/jira/browse/GEODE-10119
> Project: Geode
> Issue Type: Bug
> Components: core, tests
>Affects Versions: 1.15.0
>Reporter: Dale Emery
>Priority: Major
> Labels: Java17, needsTriage
>
> In some circumstances, on JDK 17 {SslSocket} throws {SSLHandshakeException},
> where on JDK 8 and 11 it would throw {SocketException}.
> {SocketCreator.configureClientSSLSocket()} handles {SSLHandshakeException}
> and {SocketException} differently:
> - It catches {SSLHandshakeException}, logs it as fatal, and rethrows it.
> - It does not catch {SocketException}.
> The new "fatal" log entry on JDK 17 causes
> {WANSSLDUnitTest.testSenderSSLReceiverNoSSL()} to fail.
> This may be simply a test issue. If so, the fix is to configure the test to
> ignore this new exception.
> But possibly the product's error handling needs to be changed to account for
> {SslSocket} throwing {SSLHandshakeException}.
> Example test failure on JDK 17:
> {noformat}
> java.lang.AssertionError: Suspicious strings were written to the log during
> this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in 'dunit_suspect-vm4.log' at line 548
> [fatal 2022/03/10 01:29:50.162 UTC
> tid=144] Problem forming SSL connection to
> dale-dunit.c.apachegeode-ci.internal/10.128.0.33[28386].
> javax.net.ssl.SSLHandshakeException: Remote host terminated the handshake
> at
> java.base/sun.security.ssl.SSLSocketImpl.handleEOF(SSLSocketImpl.java:1709)
> at
> java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1508)
> at
> java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1415)
> at
> java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:450)
> at
> java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:421)
> at
> org.apache.geode.internal.net.SocketCreator.configureClientSSLSocket(SocketCreator.java:591)
> at
> org.apache.geode.internal.net.SCAdvancedSocketCreator.connect(SCAdvancedSocketCreator.java:83)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpSocketCreatorImpl.connect(TcpSocketCreatorImpl.java:59)
> at
> org.apache.geode.distributed.internal.tcpserver.ClientSocketCreatorImpl.connect(ClientSocketCreatorImpl.java:54)
> at
> org.apache.geode.cache.client.internal.ConnectionImpl.connect(ConnectionImpl.java:94)
> at
> org.apache.geode.cache.client.internal.ConnectionConnector.connectClientToServer(ConnectionConnector.java:75)
> at
> org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:120)
> at
> org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:243)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:196)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:190)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.borrowConnection(ConnectionManagerImpl.java:282)
> at
> org.apache.geode.cache.client.internal.PoolImpl.acquireConnection(PoolImpl.java:940)
> at
> org.apache.geode.cache.wan.internal.GatewaySenderEventRemoteDispatcher.initializeConnection(GatewaySenderEventRemoteDispatcher.java:481)
> at
> org.apache.geode.cache.wan.internal.GatewaySenderEventRemoteDispatcher.(GatewaySenderEventRemoteDispatcher.java:105)
> at
> org.apache.geode.cache.wan.internal.serial.RemoteSerialGatewaySenderEventProcessor.initializeEventDispatcher(RemoteSerialGatewaySenderEventProcessor.java:45)
> at
> org.apache.geode.internal.cache.wan.AbstractGatewaySenderEventProcessor.setRunningStatus(AbstractGatewaySenderEventProcessor.java:1107)
> at
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderEventProcessor.run(SerialGatewaySenderEventProcessor.java:195)
> Suppressed: java.net.SocketException: Broken pipe
> at
> java.base/sun.nio.ch.NioSocketImpl.implWrite(NioSocketImpl.java:420)
> at
> java.base/sun.nio.ch.NioSocketImpl.write(NioSocketImpl.java:440)
> at
> java.base/sun.nio.ch.NioSocketImpl$2.write(NioSocketImpl.java:826)
>
[jira] [Updated] (GEODE-10119) Handle SslSocket throwing SSLHandshakeException on JDK 17
[
https://issues.apache.org/jira/browse/GEODE-10119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery updated GEODE-10119:
---
Description:
In some circumstances, on JDK 17 {{SslSocket}} throws
{{SSLHandshakeException}}, where on JDK 8 and 11 it would throw
{{SocketException}}.
{{SocketCreator.configureClientSSLSocket()}} handles {{SSLHandshakeException}}
and {{SocketException}} differently:
- It catches {{SSLHandshakeException}}, logs it as fatal, and rethrows it.
- It does not catch {{SocketException}}.
The new "fatal" log entry on JDK 17 causes
{{WANSSLDUnitTest.testSenderSSLReceiverNoSSL()}} to fail.
This may be simply a test issue. If so, the fix is to configure the test to
ignore this new exception.
But possibly the product's error handling needs to be changed to account for
{{SslSocket}} throwing {{SSLHandshakeException}}.
Example {{WANSSLDUnitTest.testSenderSSLReceiverNoSSL()}} test failure on JDK 17:
{noformat}
java.lang.AssertionError: Suspicious strings were written to the log during
this run.
Fix the strings or use IgnoredException.addIgnoredException to ignore.
---
Found suspect string in 'dunit_suspect-vm4.log' at line 548
[fatal 2022/03/10 01:29:50.162 UTC
tid=144] Problem forming SSL connection to
dale-dunit.c.apachegeode-ci.internal/10.128.0.33[28386].
javax.net.ssl.SSLHandshakeException: Remote host terminated the handshake
at
java.base/sun.security.ssl.SSLSocketImpl.handleEOF(SSLSocketImpl.java:1709)
at
java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1508)
at
java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1415)
at
java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:450)
at
java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:421)
at
org.apache.geode.internal.net.SocketCreator.configureClientSSLSocket(SocketCreator.java:591)
at
org.apache.geode.internal.net.SCAdvancedSocketCreator.connect(SCAdvancedSocketCreator.java:83)
at
org.apache.geode.distributed.internal.tcpserver.TcpSocketCreatorImpl.connect(TcpSocketCreatorImpl.java:59)
at
org.apache.geode.distributed.internal.tcpserver.ClientSocketCreatorImpl.connect(ClientSocketCreatorImpl.java:54)
at
org.apache.geode.cache.client.internal.ConnectionImpl.connect(ConnectionImpl.java:94)
at
org.apache.geode.cache.client.internal.ConnectionConnector.connectClientToServer(ConnectionConnector.java:75)
at
org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:120)
at
org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:243)
at
org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:196)
at
org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:190)
at
org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.borrowConnection(ConnectionManagerImpl.java:282)
at
org.apache.geode.cache.client.internal.PoolImpl.acquireConnection(PoolImpl.java:940)
at
org.apache.geode.cache.wan.internal.GatewaySenderEventRemoteDispatcher.initializeConnection(GatewaySenderEventRemoteDispatcher.java:481)
at
org.apache.geode.cache.wan.internal.GatewaySenderEventRemoteDispatcher.(GatewaySenderEventRemoteDispatcher.java:105)
at
org.apache.geode.cache.wan.internal.serial.RemoteSerialGatewaySenderEventProcessor.initializeEventDispatcher(RemoteSerialGatewaySenderEventProcessor.java:45)
at
org.apache.geode.internal.cache.wan.AbstractGatewaySenderEventProcessor.setRunningStatus(AbstractGatewaySenderEventProcessor.java:1107)
at
org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderEventProcessor.run(SerialGatewaySenderEventProcessor.java:195)
Suppressed: java.net.SocketException: Broken pipe
at
java.base/sun.nio.ch.NioSocketImpl.implWrite(NioSocketImpl.java:420)
at
java.base/sun.nio.ch.NioSocketImpl.write(NioSocketImpl.java:440)
at
java.base/sun.nio.ch.NioSocketImpl$2.write(NioSocketImpl.java:826)
at
java.base/java.net.Socket$SocketOutputStream.write(Socket.java:1035)
at
java.base/sun.security.ssl.SSLSocketOutputRecord.encodeAlert(SSLSocketOutputRecord.java:81)
at
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:407)
at
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:314)
at
java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:462)
... 18 more
C
[jira] [Created] (GEODE-10128) Open and export additional packages when running tests on JDK 17
Dale Emery created GEODE-10128:
--
Summary: Open and export additional packages when running tests on
JDK 17
Key: GEODE-10128
URL: https://issues.apache.org/jira/browse/GEODE-10128
Project: Geode
Issue Type: Improvement
Components: ci, tests
Affects Versions: 1.16.0
Reporter: Dale Emery
JDK 17 throws exceptions when code attempts certain kinds of access to packages
that are not opened or exported by their modules. JDK 11 issued warnings in
these cases.
When Gradle launches test JVMs, it must open and export the packages that will
be accessed by product and test code during the tests. We currently configure a
few packages in {{{}test.gradle{}}}. To support JDK 17, we must open and export
additional packages.
Additional packages to open (via {{{}--add-opens{}}}):
- java.base/java.lang
- java.base/java.nio
- java.base/java.text
- java.base/java.util
- java.base/java.util.concurrent
- java.base/java.util.concurrent.atomic
- java.base/java.util.concurrent.locks
- java.base/javax.net.ssl
- java.base/sun.security.ssl
- java.base/sun.util.locale
- java.rmi/sun.rmi.transport
Additional packages to export (via {{{}--add-opens{}}}):
- java.base/jdk.internal.util.random
- java.base/sun.nio.ch
- java.base/sun.security.x509
- java.management/com.sun.jmx.remote.security
We may discover additional packages to open/export as we run more tests under
JDK 17, and as we change product and test code.
Note that different JDKs define different {{jdk.internal}} subpackages. For
example:
- JDK 17 has {{{}jdk.internal.util.random{}}}, but JDK 11 does not.
- On Linux, JDK 11 and 17 have {{{}jdk.internal.platform.cgroupv1{}}}, but
Windows and macOS JDKs do not.
We have a few options for dealing with the differing {{jdk.internal}} packages:
- Configure which packages we open/export depending on the JDK implementation.
- Open all of these packages on all JDK platforms and versions (JDK 9 or
higher). This will produce warnings when we open/export a package that does not
exist.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10128) Open and export additional packages when running tests on JDK 17
[
https://issues.apache.org/jira/browse/GEODE-10128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery updated GEODE-10128:
---
Labels: Java17 (was: )
> Open and export additional packages when running tests on JDK 17
>
>
> Key: GEODE-10128
> URL: https://issues.apache.org/jira/browse/GEODE-10128
> Project: Geode
> Issue Type: Improvement
> Components: ci, tests
>Affects Versions: 1.16.0
>Reporter: Dale Emery
>Priority: Major
> Labels: Java17
>
> JDK 17 throws exceptions when code attempts certain kinds of access to
> packages that are not opened or exported by their modules. JDK 11 issued
> warnings in these cases.
> When Gradle launches test JVMs, it must open and export the packages that
> will be accessed by product and test code during the tests. We currently
> configure a few packages in {{{}test.gradle{}}}. To support JDK 17, we must
> open and export additional packages.
> Additional packages to open (via {{{}--add-opens{}}}):
> - java.base/java.lang
> - java.base/java.nio
> - java.base/java.text
> - java.base/java.util
> - java.base/java.util.concurrent
> - java.base/java.util.concurrent.atomic
> - java.base/java.util.concurrent.locks
> - java.base/javax.net.ssl
> - java.base/sun.security.ssl
> - java.base/sun.util.locale
> - java.rmi/sun.rmi.transport
> Additional packages to export (via {{{}--add-opens{}}}):
> - java.base/jdk.internal.util.random
> - java.base/sun.nio.ch
> - java.base/sun.security.x509
> - java.management/com.sun.jmx.remote.security
> We may discover additional packages to open/export as we run more tests under
> JDK 17, and as we change product and test code.
> Note that different JDKs define different {{jdk.internal}} subpackages. For
> example:
> - JDK 17 has {{{}jdk.internal.util.random{}}}, but JDK 11 does not.
> - On Linux, JDK 11 and 17 have {{{}jdk.internal.platform.cgroupv1{}}}, but
> Windows and macOS JDKs do not.
> We have a few options for dealing with the differing {{jdk.internal}}
> packages:
> - Configure which packages we open/export depending on the JDK
> implementation.
> - Open all of these packages on all JDK platforms and versions (JDK 9 or
> higher). This will produce warnings when we open/export a package that does
> not exist.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-10129) Forward module-related options when launching test subprocesses
Dale Emery created GEODE-10129:
--
Summary: Forward module-related options when launching test
subprocesses
Key: GEODE-10129
URL: https://issues.apache.org/jira/browse/GEODE-10129
Project: Geode
Issue Type: Improvement
Components: tests
Affects Versions: 1.16.0
Reporter: Dale Emery
Several tests and test helpers launch JVMs to run Geode code. For tests to run
properly on JDK 17, that code must open or export the packages needed by the
code that will run in the JVMs.
Such helpers include:
- {{GfshCommandRule}}
- {{ProcessManager}} for DUnit tests.
- {{ServerContainer}} for Jetty/Tomcat session tests.
Also, {{ServerLauncherDUnitTest}} launches JVMs via a \{{ProcessBuilder}}.
A simple way to support opening and exporting the required packages is:
# Assume that the current JVM opened and exported all required packages.
# Query the {{\--add-opens}} and {{\--add-exports}} that were used to launch
the current JVM. This can be done by calling
{{ManagementFactory.getRuntimeMXBean().getInputArguments()}}, then filtering
the list to retain only the {{\--add-opens}} and {{\--add-exports}} options.
# Add those options when launching a subprocess.
It would be useful to query and perform the current JVM a single place. I
propose a static method: {{JavaModuleHelper.getJvmModuleOptions()}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10129) Forward module-related options when launching test subprocesses
[
https://issues.apache.org/jira/browse/GEODE-10129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery updated GEODE-10129:
---
Labels: Java17 (was: )
> Forward module-related options when launching test subprocesses
> ---
>
> Key: GEODE-10129
> URL: https://issues.apache.org/jira/browse/GEODE-10129
> Project: Geode
> Issue Type: Improvement
> Components: tests
>Affects Versions: 1.16.0
>Reporter: Dale Emery
>Priority: Major
> Labels: Java17
>
> Several tests and test helpers launch JVMs to run Geode code. For tests to
> run properly on JDK 17, that code must open or export the packages needed by
> the code that will run in the JVMs.
> Such helpers include:
> - {{GfshCommandRule}}
> - {{ProcessManager}} for DUnit tests.
> - {{ServerContainer}} for Jetty/Tomcat session tests.
> Also, {{ServerLauncherDUnitTest}} launches JVMs via a \{{ProcessBuilder}}.
> A simple way to support opening and exporting the required packages is:
> # Assume that the current JVM opened and exported all required packages.
> # Query the {{\--add-opens}} and {{\--add-exports}} that were used to launch
> the current JVM. This can be done by calling
> {{ManagementFactory.getRuntimeMXBean().getInputArguments()}}, then filtering
> the list to retain only the {{\--add-opens}} and {{\--add-exports}} options.
> # Add those options when launching a subprocess.
> It would be useful to query and perform the current JVM a single place. I
> propose a static method: {{JavaModuleHelper.getJvmModuleOptions()}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10129) Forward module-related options when launching test subprocesses
[
https://issues.apache.org/jira/browse/GEODE-10129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery updated GEODE-10129:
---
Description:
Several tests and test helpers launch JVMs to run Geode code. For tests to run
properly on JDK 17, that code must open or export the packages needed by the
code that will run in the JVMs.
Such helpers include:
- {{GfshCommandRule}}
- {{ProcessManager}} for DUnit tests.
- {{ServerContainer}} for Jetty/Tomcat session tests.
Also, {{ServerLauncherDUnitTest}} launches JVMs via a {{{}ProcessBuilder{}}}.
A simple way to support opening and exporting the required packages is:
# Assume that the current JVM opened and exported all required packages. (See
https://issues.apache.org/jira/browse/GEODE-10128)
# Query the {{--add-opens}} and {{--add-exports}} that were used to launch the
current JVM. This can be done by calling
{{{}ManagementFactory.getRuntimeMXBean().getInputArguments(){}}}, then
filtering the list to retain only the {{--add-opens}} and {{--add-exports}}
options.
# Add those options when launching a subprocess.
It would be useful to query and perform the current JVM a single place. I
propose a static method: {{{}JavaModuleHelper.getJvmModuleOptions(){}}}.
was:
Several tests and test helpers launch JVMs to run Geode code. For tests to run
properly on JDK 17, that code must open or export the packages needed by the
code that will run in the JVMs.
Such helpers include:
- {{GfshCommandRule}}
- {{ProcessManager}} for DUnit tests.
- {{ServerContainer}} for Jetty/Tomcat session tests.
Also, {{ServerLauncherDUnitTest}} launches JVMs via a \{{ProcessBuilder}}.
A simple way to support opening and exporting the required packages is:
# Assume that the current JVM opened and exported all required packages.
# Query the {{\--add-opens}} and {{\--add-exports}} that were used to launch
the current JVM. This can be done by calling
{{ManagementFactory.getRuntimeMXBean().getInputArguments()}}, then filtering
the list to retain only the {{\--add-opens}} and {{\--add-exports}} options.
# Add those options when launching a subprocess.
It would be useful to query and perform the current JVM a single place. I
propose a static method: {{JavaModuleHelper.getJvmModuleOptions()}}.
> Forward module-related options when launching test subprocesses
> ---
>
> Key: GEODE-10129
> URL: https://issues.apache.org/jira/browse/GEODE-10129
> Project: Geode
> Issue Type: Improvement
> Components: tests
>Affects Versions: 1.16.0
>Reporter: Dale Emery
>Priority: Major
> Labels: Java17
>
> Several tests and test helpers launch JVMs to run Geode code. For tests to
> run properly on JDK 17, that code must open or export the packages needed by
> the code that will run in the JVMs.
> Such helpers include:
> - {{GfshCommandRule}}
> - {{ProcessManager}} for DUnit tests.
> - {{ServerContainer}} for Jetty/Tomcat session tests.
> Also, {{ServerLauncherDUnitTest}} launches JVMs via a {{{}ProcessBuilder{}}}.
> A simple way to support opening and exporting the required packages is:
> # Assume that the current JVM opened and exported all required packages.
> (See https://issues.apache.org/jira/browse/GEODE-10128)
> # Query the {{--add-opens}} and {{--add-exports}} that were used to launch
> the current JVM. This can be done by calling
> {{{}ManagementFactory.getRuntimeMXBean().getInputArguments(){}}}, then
> filtering the list to retain only the {{--add-opens}} and {{--add-exports}}
> options.
> # Add those options when launching a subprocess.
> It would be useful to query and perform the current JVM a single place. I
> propose a static method: {{{}JavaModuleHelper.getJvmModuleOptions(){}}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-10119) Handle SslSocket throwing SSLHandshakeException on JDK 17
[
https://issues.apache.org/jira/browse/GEODE-10119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17507772#comment-17507772
]
Dale Emery commented on GEODE-10119:
Two changes:
* Change {{test.gradle}} to launch test JVMs with the requisite opens/exports.
See https://issues.apache.org/jira/browse/GEODE-10128 for the list of
opens/exports that I currently know about.
* Change {{ProcessManager}} to forward the test JVM's opens/exports to any
child VM it launches. https://issues.apache.org/jira/browse/GEODE-10129 for how
to query the current JVM's opens/exports.
Those changes may suffice. I learned of this issue in a private experimental
branch that includes other changes, so perhaps I've missed a necessary step.
> Handle SslSocket throwing SSLHandshakeException on JDK 17
> -
>
> Key: GEODE-10119
> URL: https://issues.apache.org/jira/browse/GEODE-10119
> Project: Geode
> Issue Type: Bug
> Components: core, tests
>Affects Versions: 1.15.0
>Reporter: Dale Emery
>Priority: Major
> Labels: Java17, needsTriage
>
> In some circumstances, on JDK 17 {{SslSocket}} throws
> {{SSLHandshakeException}}, where on JDK 8 and 11 it would throw
> {{SocketException}}.
> {{SocketCreator.configureClientSSLSocket()}} handles
> {{SSLHandshakeException}} and {{SocketException}} differently:
> - It catches {{SSLHandshakeException}}, logs it as fatal, and rethrows it.
> - It does not catch {{SocketException}}.
> The new "fatal" log entry on JDK 17 causes
> {{WANSSLDUnitTest.testSenderSSLReceiverNoSSL()}} to fail.
> This may be simply a test issue. If so, the fix is to configure the test to
> ignore this new exception.
> But possibly the product's error handling needs to be changed to account for
> {{SslSocket}} throwing {{SSLHandshakeException}}.
> Example {{WANSSLDUnitTest.testSenderSSLReceiverNoSSL()}} test failure on JDK
> 17:
> {noformat}
> java.lang.AssertionError: Suspicious strings were written to the log during
> this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in 'dunit_suspect-vm4.log' at line 548
> [fatal 2022/03/10 01:29:50.162 UTC
> tid=144] Problem forming SSL connection to
> dale-dunit.c.apachegeode-ci.internal/10.128.0.33[28386].
> javax.net.ssl.SSLHandshakeException: Remote host terminated the handshake
> at
> java.base/sun.security.ssl.SSLSocketImpl.handleEOF(SSLSocketImpl.java:1709)
> at
> java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1508)
> at
> java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1415)
> at
> java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:450)
> at
> java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:421)
> at
> org.apache.geode.internal.net.SocketCreator.configureClientSSLSocket(SocketCreator.java:591)
> at
> org.apache.geode.internal.net.SCAdvancedSocketCreator.connect(SCAdvancedSocketCreator.java:83)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpSocketCreatorImpl.connect(TcpSocketCreatorImpl.java:59)
> at
> org.apache.geode.distributed.internal.tcpserver.ClientSocketCreatorImpl.connect(ClientSocketCreatorImpl.java:54)
> at
> org.apache.geode.cache.client.internal.ConnectionImpl.connect(ConnectionImpl.java:94)
> at
> org.apache.geode.cache.client.internal.ConnectionConnector.connectClientToServer(ConnectionConnector.java:75)
> at
> org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:120)
> at
> org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:243)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:196)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:190)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.borrowConnection(ConnectionManagerImpl.java:282)
> at
> org.apache.geode.cache.client.internal.PoolImpl.acquireConnection(PoolImpl.java:940)
> at
> org.apache.geode.cache.wan.internal.GatewaySenderEventRemoteDispatcher.initializeConnection(GatewaySenderEventRemoteDispatcher.java:481)
> at
> org.apache.geode.cache.wan.internal.GatewaySenderEventRemoteDispatcher.(GatewaySenderEventRemoteDispatcher.java:105)
> at
> org.apache.geode.cache.wan.internal.serial.RemoteSerialGatewaySenderEventProcessor.initializeEventDispatcher(RemoteSerialGatewaySenderEven
[jira] [Updated] (GEODE-10128) Open and export additional packages when running tests on JDK 17
[
https://issues.apache.org/jira/browse/GEODE-10128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery updated GEODE-10128:
---
Labels: GeodeOperationAPI Java17 pull-request-available (was: Java17
pull-request-available)
> Open and export additional packages when running tests on JDK 17
>
>
> Key: GEODE-10128
> URL: https://issues.apache.org/jira/browse/GEODE-10128
> Project: Geode
> Issue Type: Improvement
> Components: ci, tests
>Affects Versions: 1.16.0
>Reporter: Dale Emery
>Priority: Major
> Labels: GeodeOperationAPI, Java17, pull-request-available
>
> JDK 17 throws exceptions when code attempts certain kinds of access to
> packages that are not opened or exported by their modules. JDK 11 issued
> warnings in these cases.
> When Gradle launches test JVMs, it must open and export the packages that
> will be accessed by product and test code during the tests. We currently
> configure a few packages in {{{}test.gradle{}}}. To support JDK 17, we must
> open and export additional packages.
> Additional packages to open (via {{{}--add-opens{}}}):
> - java.base/java.lang
> - java.base/java.nio
> - java.base/java.text
> - java.base/java.util
> - java.base/java.util.concurrent
> - java.base/java.util.concurrent.atomic
> - java.base/java.util.concurrent.locks
> - java.base/javax.net.ssl
> - java.base/sun.security.ssl
> - java.base/sun.util.locale
> - java.rmi/sun.rmi.transport
> Additional packages to export (via {{{}--add-opens{}}}):
> - java.base/jdk.internal.util.random
> - java.base/sun.nio.ch
> - java.base/sun.security.x509
> - java.management/com.sun.jmx.remote.security
> We may discover additional packages to open/export as we run more tests under
> JDK 17, and as we change product and test code.
> Note that different JDKs define different {{jdk.internal}} subpackages. For
> example:
> - JDK 17 has {{{}jdk.internal.util.random{}}}, but JDK 11 does not.
> - On Linux, JDK 11 and 17 have {{{}jdk.internal.platform.cgroupv1{}}}, but
> Windows and macOS JDKs do not.
> We have a few options for dealing with the differing {{jdk.internal}}
> packages:
> - Configure which packages we open/export depending on the JDK
> implementation.
> - Open all of these packages on all JDK platforms and versions (JDK 9 or
> higher). This will produce warnings when we open/export a package that does
> not exist.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-10128) Open and export additional packages when running tests on JDK 17
[
https://issues.apache.org/jira/browse/GEODE-10128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery reassigned GEODE-10128:
--
Assignee: Dale Emery
> Open and export additional packages when running tests on JDK 17
>
>
> Key: GEODE-10128
> URL: https://issues.apache.org/jira/browse/GEODE-10128
> Project: Geode
> Issue Type: Improvement
> Components: ci, tests
>Affects Versions: 1.16.0
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
> Labels: GeodeOperationAPI, Java17, pull-request-available
>
> JDK 17 throws exceptions when code attempts certain kinds of access to
> packages that are not opened or exported by their modules. JDK 11 issued
> warnings in these cases.
> When Gradle launches test JVMs, it must open and export the packages that
> will be accessed by product and test code during the tests. We currently
> configure a few packages in {{{}test.gradle{}}}. To support JDK 17, we must
> open and export additional packages.
> Additional packages to open (via {{{}--add-opens{}}}):
> - java.base/java.lang
> - java.base/java.nio
> - java.base/java.text
> - java.base/java.util
> - java.base/java.util.concurrent
> - java.base/java.util.concurrent.atomic
> - java.base/java.util.concurrent.locks
> - java.base/javax.net.ssl
> - java.base/sun.security.ssl
> - java.base/sun.util.locale
> - java.rmi/sun.rmi.transport
> Additional packages to export (via {{{}--add-opens{}}}):
> - java.base/jdk.internal.util.random
> - java.base/sun.nio.ch
> - java.base/sun.security.x509
> - java.management/com.sun.jmx.remote.security
> We may discover additional packages to open/export as we run more tests under
> JDK 17, and as we change product and test code.
> Note that different JDKs define different {{jdk.internal}} subpackages. For
> example:
> - JDK 17 has {{{}jdk.internal.util.random{}}}, but JDK 11 does not.
> - On Linux, JDK 11 and 17 have {{{}jdk.internal.platform.cgroupv1{}}}, but
> Windows and macOS JDKs do not.
> We have a few options for dealing with the differing {{jdk.internal}}
> packages:
> - Configure which packages we open/export depending on the JDK
> implementation.
> - Open all of these packages on all JDK platforms and versions (JDK 9 or
> higher). This will produce warnings when we open/export a package that does
> not exist.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-10129) Forward module-related options when launching test subprocesses
[
https://issues.apache.org/jira/browse/GEODE-10129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery reassigned GEODE-10129:
--
Assignee: Dale Emery
> Forward module-related options when launching test subprocesses
> ---
>
> Key: GEODE-10129
> URL: https://issues.apache.org/jira/browse/GEODE-10129
> Project: Geode
> Issue Type: Improvement
> Components: tests
>Affects Versions: 1.16.0
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
> Labels: GeodeOperationAPI, Java17
>
> Several tests and test helpers launch JVMs to run Geode code. For tests to
> run properly on JDK 17, that code must open or export the packages needed by
> the code that will run in the JVMs.
> Such helpers include:
> - {{GfshCommandRule}}
> - {{ProcessManager}} for DUnit tests.
> - {{ServerContainer}} for Jetty/Tomcat session tests.
> Also, {{ServerLauncherDUnitTest}} launches JVMs via a {{{}ProcessBuilder{}}}.
> A simple way to support opening and exporting the required packages is:
> # Assume that the current JVM opened and exported all required packages.
> (See https://issues.apache.org/jira/browse/GEODE-10128)
> # Query the {{--add-opens}} and {{--add-exports}} that were used to launch
> the current JVM. This can be done by calling
> {{{}ManagementFactory.getRuntimeMXBean().getInputArguments(){}}}, then
> filtering the list to retain only the {{--add-opens}} and {{--add-exports}}
> options.
> # Add those options when launching a subprocess.
> It would be useful to query and perform the current JVM a single place. I
> propose a static method: {{{}JavaModuleHelper.getJvmModuleOptions(){}}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10129) Forward module-related options when launching test subprocesses
[
https://issues.apache.org/jira/browse/GEODE-10129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery updated GEODE-10129:
---
Labels: GeodeOperationAPI Java17 (was: Java17)
> Forward module-related options when launching test subprocesses
> ---
>
> Key: GEODE-10129
> URL: https://issues.apache.org/jira/browse/GEODE-10129
> Project: Geode
> Issue Type: Improvement
> Components: tests
>Affects Versions: 1.16.0
>Reporter: Dale Emery
>Priority: Major
> Labels: GeodeOperationAPI, Java17
>
> Several tests and test helpers launch JVMs to run Geode code. For tests to
> run properly on JDK 17, that code must open or export the packages needed by
> the code that will run in the JVMs.
> Such helpers include:
> - {{GfshCommandRule}}
> - {{ProcessManager}} for DUnit tests.
> - {{ServerContainer}} for Jetty/Tomcat session tests.
> Also, {{ServerLauncherDUnitTest}} launches JVMs via a {{{}ProcessBuilder{}}}.
> A simple way to support opening and exporting the required packages is:
> # Assume that the current JVM opened and exported all required packages.
> (See https://issues.apache.org/jira/browse/GEODE-10128)
> # Query the {{--add-opens}} and {{--add-exports}} that were used to launch
> the current JVM. This can be done by calling
> {{{}ManagementFactory.getRuntimeMXBean().getInputArguments(){}}}, then
> filtering the list to retain only the {{--add-opens}} and {{--add-exports}}
> options.
> # Add those options when launching a subprocess.
> It would be useful to query and perform the current JVM a single place. I
> propose a static method: {{{}JavaModuleHelper.getJvmModuleOptions(){}}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10128) Open and export additional packages when running tests on JDK 17
[
https://issues.apache.org/jira/browse/GEODE-10128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery updated GEODE-10128:
---
Labels: Java17 pull-request-available (was: GeodeOperationAPI Java17
pull-request-available)
> Open and export additional packages when running tests on JDK 17
>
>
> Key: GEODE-10128
> URL: https://issues.apache.org/jira/browse/GEODE-10128
> Project: Geode
> Issue Type: Improvement
> Components: ci, tests
>Affects Versions: 1.15.0
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
> Labels: Java17, pull-request-available
>
> JDK 17 throws exceptions when code attempts certain kinds of access to
> packages that are not opened or exported by their modules. JDK 11 issued
> warnings in these cases.
> When Gradle launches test JVMs, it must open and export the packages that
> will be accessed by product and test code during the tests. We currently
> configure a few packages in {{{}test.gradle{}}}. To support JDK 17, we must
> open and export additional packages.
> Additional packages to open (via {{{}--add-opens{}}}):
> - java.base/java.lang
> - java.base/java.nio
> - java.base/java.text
> - java.base/java.util
> - java.base/java.util.concurrent
> - java.base/java.util.concurrent.atomic
> - java.base/java.util.concurrent.locks
> - java.base/javax.net.ssl
> - java.base/sun.security.ssl
> - java.base/sun.util.locale
> - java.rmi/sun.rmi.transport
> Additional packages to export (via {{{}--add-opens{}}}):
> - java.base/jdk.internal.util.random
> - java.base/sun.nio.ch
> - java.base/sun.security.x509
> - java.management/com.sun.jmx.remote.security
> We may discover additional packages to open/export as we run more tests under
> JDK 17, and as we change product and test code.
> Note that different JDKs define different {{jdk.internal}} subpackages. For
> example:
> - JDK 17 has {{{}jdk.internal.util.random{}}}, but JDK 11 does not.
> - On Linux, JDK 11 and 17 have {{{}jdk.internal.platform.cgroupv1{}}}, but
> Windows and macOS JDKs do not.
> We have a few options for dealing with the differing {{jdk.internal}}
> packages:
> - Configure which packages we open/export depending on the JDK
> implementation.
> - Open all of these packages on all JDK platforms and versions (JDK 9 or
> higher). This will produce warnings when we open/export a package that does
> not exist.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10129) Forward module-related options when launching test subprocesses
[
https://issues.apache.org/jira/browse/GEODE-10129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery updated GEODE-10129:
---
Labels: Java17 (was: GeodeOperationAPI Java17)
> Forward module-related options when launching test subprocesses
> ---
>
> Key: GEODE-10129
> URL: https://issues.apache.org/jira/browse/GEODE-10129
> Project: Geode
> Issue Type: Improvement
> Components: tests
>Affects Versions: 1.15.0
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
> Labels: Java17
>
> Several tests and test helpers launch JVMs to run Geode code. For tests to
> run properly on JDK 17, that code must open or export the packages needed by
> the code that will run in the JVMs.
> Such helpers include:
> - {{GfshCommandRule}}
> - {{ProcessManager}} for DUnit tests.
> - {{ServerContainer}} for Jetty/Tomcat session tests.
> Also, {{ServerLauncherDUnitTest}} launches JVMs via a {{{}ProcessBuilder{}}}.
> A simple way to support opening and exporting the required packages is:
> # Assume that the current JVM opened and exported all required packages.
> (See https://issues.apache.org/jira/browse/GEODE-10128)
> # Query the {{--add-opens}} and {{--add-exports}} that were used to launch
> the current JVM. This can be done by calling
> {{{}ManagementFactory.getRuntimeMXBean().getInputArguments(){}}}, then
> filtering the list to retain only the {{--add-opens}} and {{--add-exports}}
> options.
> # Add those options when launching a subprocess.
> It would be useful to query and perform the current JVM a single place. I
> propose a static method: {{{}JavaModuleHelper.getJvmModuleOptions(){}}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-10133) ReflectionSingleObjectSizer throws when sizing hidden classes
Dale Emery created GEODE-10133:
--
Summary: ReflectionSingleObjectSizer throws when sizing hidden
classes
Key: GEODE-10133
URL: https://issues.apache.org/jira/browse/GEODE-10133
Project: Geode
Issue Type: Improvement
Components: core
Reporter: Dale Emery
On JDK 17, the class of a lambda is a "hidden" class. When
{{ReflectionSingleObjectSizer}} tries to find the offset of the fields of a
hidden class, the JDK throws {{UnsupportedOperationException}}.
Example exception from {{MemoryOverheadIntegrationTest}}:
{noformat}
ava.lang.UnsupportedOperationException: can't get field offset on a hidden
class: private final org.apache.geode.internal.cache.InternalCache
org.apache.geode.redis.internal.GeodeRedisServer$$Lambda$607/0x0008011434d8.arg$1
at sun.misc.Unsafe.objectFieldOffset(Unsafe.java:645)
at org.apache.geode.unsafe.internal.sun.misc.Unsafe.fieldOffset(Unsafe.java:187)
at
org.apache.geode.internal.size.ReflectionSingleObjectSizer.sizeof(ReflectionSingleObjectSizer.java:106)
at
org.apache.geode.internal.size.ReflectionSingleObjectSizer.sizeof(ReflectionSingleObjectSizer.java:84)
at
org.apache.geode.internal.size.ReflectionSingleObjectSizer.sizeof(ReflectionSingleObjectSizer.java:52)
at
org.apache.geode.internal.size.CachingSingleObjectSizer.sizeof(CachingSingleObjectSizer.java:39)
at
org.apache.geode.internal.size.ObjectGraphSizer$SizeVisitor.visit(ObjectGraphSizer.java:223)
at
org.apache.geode.internal.size.ObjectTraverser$VisitStack.add(ObjectTraverser.java:163)
at
org.apache.geode.internal.size.ObjectTraverser.doSearch(ObjectTraverser.java:87)
at
org.apache.geode.internal.size.ObjectTraverser.breadthFirstSearch(ObjectTraverser.java:54)
at
org.apache.geode.internal.size.ObjectGraphSizer.size(ObjectGraphSizer.java:96)
at
org.apache.geode.redis.internal.data.MemoryOverheadIntegrationTest.getUsedMemory(MemoryOverheadIntegrationTest.java:95)
at
org.apache.geode.redis.internal.data.AbstractMemoryOverheadIntegrationTest.measureAndCheckPerEntryOverhead(AbstractMemoryOverheadIntegrationTest.java:284)
at
org.apache.geode.redis.internal.data.AbstractMemoryOverheadIntegrationTest.measureOverheadPerHash(AbstractMemoryOverheadIntegrationTest.java:127)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:568)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at
org.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:38)
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$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)
at
org.junit.platform.launcher.core.EngineExecutionOrchestrator.lambda$execute$0(EngineExecutionOrchestrator.java:54)
at
org.junit.platform.launcher.core.EngineExecutionOrchestrator.withInterceptedStreams(EngineExecutionOrchestrator.java:67)
at
org.junit.platform.laun
[jira] [Updated] (GEODE-10133) ReflectionSingleObjectSizer throws when sizing hidden classes
[
https://issues.apache.org/jira/browse/GEODE-10133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery updated GEODE-10133:
---
Labels: Java17 (was: )
> ReflectionSingleObjectSizer throws when sizing hidden classes
> -
>
> Key: GEODE-10133
> URL: https://issues.apache.org/jira/browse/GEODE-10133
> Project: Geode
> Issue Type: Improvement
> Components: core
>Reporter: Dale Emery
>Priority: Major
> Labels: Java17
>
> On JDK 17, the class of a lambda is a "hidden" class. When
> {{ReflectionSingleObjectSizer}} tries to find the offset of the fields of a
> hidden class, the JDK throws {{UnsupportedOperationException}}.
>
> Example exception from {{MemoryOverheadIntegrationTest}}:
> {noformat}
> ava.lang.UnsupportedOperationException: can't get field offset on a hidden
> class: private final org.apache.geode.internal.cache.InternalCache
> org.apache.geode.redis.internal.GeodeRedisServer$$Lambda$607/0x0008011434d8.arg$1
> at sun.misc.Unsafe.objectFieldOffset(Unsafe.java:645)
> at
> org.apache.geode.unsafe.internal.sun.misc.Unsafe.fieldOffset(Unsafe.java:187)
> at
> org.apache.geode.internal.size.ReflectionSingleObjectSizer.sizeof(ReflectionSingleObjectSizer.java:106)
> at
> org.apache.geode.internal.size.ReflectionSingleObjectSizer.sizeof(ReflectionSingleObjectSizer.java:84)
> at
> org.apache.geode.internal.size.ReflectionSingleObjectSizer.sizeof(ReflectionSingleObjectSizer.java:52)
> at
> org.apache.geode.internal.size.CachingSingleObjectSizer.sizeof(CachingSingleObjectSizer.java:39)
> at
> org.apache.geode.internal.size.ObjectGraphSizer$SizeVisitor.visit(ObjectGraphSizer.java:223)
> at
> org.apache.geode.internal.size.ObjectTraverser$VisitStack.add(ObjectTraverser.java:163)
> at
> org.apache.geode.internal.size.ObjectTraverser.doSearch(ObjectTraverser.java:87)
> at
> org.apache.geode.internal.size.ObjectTraverser.breadthFirstSearch(ObjectTraverser.java:54)
> at
> org.apache.geode.internal.size.ObjectGraphSizer.size(ObjectGraphSizer.java:96)
> at
> org.apache.geode.redis.internal.data.MemoryOverheadIntegrationTest.getUsedMemory(MemoryOverheadIntegrationTest.java:95)
> at
> org.apache.geode.redis.internal.data.AbstractMemoryOverheadIntegrationTest.measureAndCheckPerEntryOverhead(AbstractMemoryOverheadIntegrationTest.java:284)
> at
> org.apache.geode.redis.internal.data.AbstractMemoryOverheadIntegrationTest.measureOverheadPerHash(AbstractMemoryOverheadIntegrationTest.java:127)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:568)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at
> org.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:38)
> 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$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
[jira] [Updated] (GEODE-10133) ReflectionSingleObjectSizer throws when sizing hidden classes
[
https://issues.apache.org/jira/browse/GEODE-10133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery updated GEODE-10133:
---
Description:
On JDK 17, the class of a lambda is a "hidden" class. When
{{ReflectionSingleObjectSizer}} tries to find the offset of the fields of a
hidden class, the JDK throws {{UnsupportedOperationException}}.
Tests that fail due to this exception:
- {{MemoryOverheadIntegrationTest}}
- {{OutOfMemoryDUnitTest}}
- {{SessionReplicationLocalCacheJUnitTest}}
Example exception from {{MemoryOverheadIntegrationTest}}:
{noformat}
ava.lang.UnsupportedOperationException: can't get field offset on a hidden
class: private final org.apache.geode.internal.cache.InternalCache
org.apache.geode.redis.internal.GeodeRedisServer$$Lambda$607/0x0008011434d8.arg$1
at sun.misc.Unsafe.objectFieldOffset(Unsafe.java:645)
at org.apache.geode.unsafe.internal.sun.misc.Unsafe.fieldOffset(Unsafe.java:187)
at
org.apache.geode.internal.size.ReflectionSingleObjectSizer.sizeof(ReflectionSingleObjectSizer.java:106)
at
org.apache.geode.internal.size.ReflectionSingleObjectSizer.sizeof(ReflectionSingleObjectSizer.java:84)
at
org.apache.geode.internal.size.ReflectionSingleObjectSizer.sizeof(ReflectionSingleObjectSizer.java:52)
at
org.apache.geode.internal.size.CachingSingleObjectSizer.sizeof(CachingSingleObjectSizer.java:39)
at
org.apache.geode.internal.size.ObjectGraphSizer$SizeVisitor.visit(ObjectGraphSizer.java:223)
at
org.apache.geode.internal.size.ObjectTraverser$VisitStack.add(ObjectTraverser.java:163)
at
org.apache.geode.internal.size.ObjectTraverser.doSearch(ObjectTraverser.java:87)
at
org.apache.geode.internal.size.ObjectTraverser.breadthFirstSearch(ObjectTraverser.java:54)
at
org.apache.geode.internal.size.ObjectGraphSizer.size(ObjectGraphSizer.java:96)
at
org.apache.geode.redis.internal.data.MemoryOverheadIntegrationTest.getUsedMemory(MemoryOverheadIntegrationTest.java:95)
at
org.apache.geode.redis.internal.data.AbstractMemoryOverheadIntegrationTest.measureAndCheckPerEntryOverhead(AbstractMemoryOverheadIntegrationTest.java:284)
at
org.apache.geode.redis.internal.data.AbstractMemoryOverheadIntegrationTest.measureOverheadPerHash(AbstractMemoryOverheadIntegrationTest.java:127)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:568)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at
org.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:38)
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$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)
at
org.junit.platform.launcher.core.EngineExecutionOrchestrator.lambda$execute$0(EngineExecutionOrchestrator.java:54)
at
org.junit.platform.launcher.core.EngineExecutionOrchestrator.withInterceptedStreams(EngineExecutionOrchestrator.java:67)
at
org.junit.platform.launcher.core.EngineExecutio
[jira] [Updated] (GEODE-10133) ReflectionSingleObjectSizer throws when sizing hidden classes
[
https://issues.apache.org/jira/browse/GEODE-10133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery updated GEODE-10133:
---
Description:
On JDK 17, the class of a lambda is a "hidden" class. When
{{ReflectionSingleObjectSizer}} tries to find the offset of the fields of a
hidden class, the JDK throws {{UnsupportedOperationException}}.
Tests that fail due to this exception:
- {{MemoryOverheadIntegrationTest}}
- {{OutOfMemoryDUnitTest}}
- {{SessionReplicationLocalCacheJUnitTest}}
Example exception from {{MemoryOverheadIntegrationTest}}:
{noformat}
ava.lang.UnsupportedOperationException: can't get field offset on a hidden
class: private final org.apache.geode.internal.cache.InternalCache
org.apache.geode.redis.internal.GeodeRedisServer$$Lambda$607/0x0008011434d8.arg$1
at sun.misc.Unsafe.objectFieldOffset(Unsafe.java:645)
at org.apache.geode.unsafe.internal.sun.misc.Unsafe.fieldOffset(Unsafe.java:187)
at
org.apache.geode.internal.size.ReflectionSingleObjectSizer.sizeof(ReflectionSingleObjectSizer.java:106)
at
org.apache.geode.internal.size.ReflectionSingleObjectSizer.sizeof(ReflectionSingleObjectSizer.java:84)
at
org.apache.geode.internal.size.ReflectionSingleObjectSizer.sizeof(ReflectionSingleObjectSizer.java:52)
at
org.apache.geode.internal.size.CachingSingleObjectSizer.sizeof(CachingSingleObjectSizer.java:39)
at
org.apache.geode.internal.size.ObjectGraphSizer$SizeVisitor.visit(ObjectGraphSizer.java:223)
at
org.apache.geode.internal.size.ObjectTraverser$VisitStack.add(ObjectTraverser.java:163)
at
org.apache.geode.internal.size.ObjectTraverser.doSearch(ObjectTraverser.java:87)
at
org.apache.geode.internal.size.ObjectTraverser.breadthFirstSearch(ObjectTraverser.java:54)
at
org.apache.geode.internal.size.ObjectGraphSizer.size(ObjectGraphSizer.java:96)
at
org.apache.geode.redis.internal.data.MemoryOverheadIntegrationTest.getUsedMemory(MemoryOverheadIntegrationTest.java:95)
at
org.apache.geode.redis.internal.data.AbstractMemoryOverheadIntegrationTest.measureAndCheckPerEntryOverhead(AbstractMemoryOverheadIntegrationTest.java:284)
at
org.apache.geode.redis.internal.data.AbstractMemoryOverheadIntegrationTest.measureOverheadPerHash(AbstractMemoryOverheadIntegrationTest.java:127)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:568)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at
org.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:38)
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$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)
at
org.junit.platform.launcher.core.EngineExecutionOrchestrator.lambda$execute$0(EngineExecutionOrchestrator.java:54)
at
org.junit.platform.launcher.core.EngineExecutionOrchestrator.withInterceptedStreams(EngineExecutionOrchestrator.java:67)
at
org.junit.platform.launcher.core.EngineExecution
[jira] [Updated] (GEODE-10134) SanctionedSerializablesFilterPattern does not accept proxy classes on JDK 17
[
https://issues.apache.org/jira/browse/GEODE-10134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery updated GEODE-10134:
---
Labels: Java17 (was: )
> SanctionedSerializablesFilterPattern does not accept proxy classes on JDK 17
>
>
> Key: GEODE-10134
> URL: https://issues.apache.org/jira/browse/GEODE-10134
> Project: Geode
> Issue Type: Improvement
> Components: serialization
>Affects Versions: 1.15.0
>Reporter: Dale Emery
>Priority: Major
> Labels: Java17
>
> On JDK 17, the classes of proxies are created in dynamically created
> packages. The current implemention of
> {{SanctionedSerializablesFilterPattern}} does not recognize those packages,
> and so rejects all proxy objects.
> So far I've seen two dynamically created proxy packages:
> - {{jdk.proxy2}}
> - {{jdk.proxy3}}
> Adding {{"jdk.proxy*"}} to the {{SanctionedSerializablesFilterPattern}} fixes
> the problem, at the risk of accepting an overly broad set of classes.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-10134) SanctionedSerializablesFilterPattern does not accept proxy classes on JDK 17
Dale Emery created GEODE-10134:
--
Summary: SanctionedSerializablesFilterPattern does not accept
proxy classes on JDK 17
Key: GEODE-10134
URL: https://issues.apache.org/jira/browse/GEODE-10134
Project: Geode
Issue Type: Improvement
Components: serialization
Affects Versions: 1.15.0
Reporter: Dale Emery
On JDK 17, the classes of proxies are created in dynamically created packages.
The current implemention of {{SanctionedSerializablesFilterPattern}} does not
recognize those packages, and so rejects all proxy objects.
So far I've seen two dynamically created proxy packages:
- {{jdk.proxy2}}
- {{jdk.proxy3}}
Adding {{"jdk.proxy*"}} to the {{SanctionedSerializablesFilterPattern}} fixes
the problem, at the risk of accepting an overly broad set of classes.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10136) FunctionServiceBase tests fail because lambda classes have no canonical name on JDK 17
[
https://issues.apache.org/jira/browse/GEODE-10136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery updated GEODE-10136:
---
Labels: Java17 (was: )
> FunctionServiceBase tests fail because lambda classes have no canonical name
> on JDK 17
> --
>
> Key: GEODE-10136
> URL: https://issues.apache.org/jira/browse/GEODE-10136
> Project: Geode
> Issue Type: Improvement
> Components: functions, tests
>Affects Versions: 1.15.0
>Reporter: Dale Emery
>Priority: Major
> Labels: Java17
>
> {{FunctionServiceBase}} tests fail on JDK 17.
> Here are the relevant factors:
> - {{FunctionServiceBase}} uses lambda expressions to create the function
> objects used to test the function service.
> - The objects that represent these lambda expressions use the default
> implementation of all {{Function}} methods other than
> {{execute(FunctionContext)}}.
> - The default implementation of {{getId()}} returns the canonical name of the
> function object's class.
> - In JDK 17, the class of a lambda expression has no canonical name.
> - The product classes {{AbstractExecution}} and
> {{DistributedRegionFunctionExecutor}} both throw exceptions if the given
> function reports its ID as {{null}}.
> The tests can be fixed by replacing the lambda expressions with uses of a
> class that returns a non-{{null}} ID.
> This may be a product issue. Given that {{Function}} is explicitly annotated
> as a {{@FunctionalInterface}}:
> - It is clearly intended to be used with lambda expressions, yet on JDK 17 it
> cannot be used with lamda expressions.
> - It would be reasonable to expect that an anonymous class that extends
> `Function` could safely use the default implementation of {{getId()}}, yet
> anonymous classes have no canonical names on any JDK.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-10136) FunctionServiceBase tests fail because lambda classes have no canonical name on JDK 17
Dale Emery created GEODE-10136:
--
Summary: FunctionServiceBase tests fail because lambda classes
have no canonical name on JDK 17
Key: GEODE-10136
URL: https://issues.apache.org/jira/browse/GEODE-10136
Project: Geode
Issue Type: Improvement
Components: functions, tests
Affects Versions: 1.15.0
Reporter: Dale Emery
{{FunctionServiceBase}} tests fail on JDK 17.
Here are the relevant factors:
- {{FunctionServiceBase}} uses lambda expressions to create the function
objects used to test the function service.
- The objects that represent these lambda expressions use the default
implementation of all {{Function}} methods other than
{{execute(FunctionContext)}}.
- The default implementation of {{getId()}} returns the canonical name of the
function object's class.
- In JDK 17, the class of a lambda expression has no canonical name.
- The product classes {{AbstractExecution}} and
{{DistributedRegionFunctionExecutor}} both throw exceptions if the given
function reports its ID as {{null}}.
The tests can be fixed by replacing the lambda expressions with uses of a class
that returns a non-{{null}} ID.
This may be a product issue. Given that {{Function}} is explicitly annotated as
a {{@FunctionalInterface}}:
- It is clearly intended to be used with lambda expressions, yet on JDK 17 it
cannot be used with lamda expressions.
- It would be reasonable to expect that an anonymous class that extends
`Function` could safely use the default implementation of {{getId()}}, yet
anonymous classes have no canonical names on any JDK.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10128) Open and export additional packages when running tests on JDK 17
[
https://issues.apache.org/jira/browse/GEODE-10128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery updated GEODE-10128:
---
Fix Version/s: 1.15.0
> Open and export additional packages when running tests on JDK 17
>
>
> Key: GEODE-10128
> URL: https://issues.apache.org/jira/browse/GEODE-10128
> Project: Geode
> Issue Type: Improvement
> Components: ci, tests
>Affects Versions: 1.15.0
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
> Labels: Java17, pull-request-available
> Fix For: 1.15.0
>
>
> JDK 17 throws exceptions when code attempts certain kinds of access to
> packages that are not opened or exported by their modules. JDK 11 issued
> warnings in these cases.
> When Gradle launches test JVMs, it must open and export the packages that
> will be accessed by product and test code during the tests. We currently
> configure a few packages in {{{}test.gradle{}}}. To support JDK 17, we must
> open and export additional packages.
> Additional packages to open (via {{{}--add-opens{}}}):
> - java.base/java.lang
> - java.base/java.nio
> - java.base/java.text
> - java.base/java.util
> - java.base/java.util.concurrent
> - java.base/java.util.concurrent.atomic
> - java.base/java.util.concurrent.locks
> - java.base/javax.net.ssl
> - java.base/sun.security.ssl
> - java.base/sun.util.locale
> - java.rmi/sun.rmi.transport
> Additional packages to export (via {{{}--add-opens{}}}):
> - java.base/jdk.internal.util.random
> - java.base/sun.nio.ch
> - java.base/sun.security.x509
> - java.management/com.sun.jmx.remote.security
> We may discover additional packages to open/export as we run more tests under
> JDK 17, and as we change product and test code.
> Note that different JDKs define different {{jdk.internal}} subpackages. For
> example:
> - JDK 17 has {{{}jdk.internal.util.random{}}}, but JDK 11 does not.
> - On Linux, JDK 11 and 17 have {{{}jdk.internal.platform.cgroupv1{}}}, but
> Windows and macOS JDKs do not.
> We have a few options for dealing with the differing {{jdk.internal}}
> packages:
> - Configure which packages we open/export depending on the JDK
> implementation.
> - Open all of these packages on all JDK platforms and versions (JDK 9 or
> higher). This will produce warnings when we open/export a package that does
> not exist.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (GEODE-10128) Open and export additional packages when running tests on JDK 17
[
https://issues.apache.org/jira/browse/GEODE-10128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery resolved GEODE-10128.
Resolution: Fixed
> Open and export additional packages when running tests on JDK 17
>
>
> Key: GEODE-10128
> URL: https://issues.apache.org/jira/browse/GEODE-10128
> Project: Geode
> Issue Type: Improvement
> Components: ci, tests
>Affects Versions: 1.15.0
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
> Labels: Java17, pull-request-available
> Fix For: 1.15.0
>
>
> JDK 17 throws exceptions when code attempts certain kinds of access to
> packages that are not opened or exported by their modules. JDK 11 issued
> warnings in these cases.
> When Gradle launches test JVMs, it must open and export the packages that
> will be accessed by product and test code during the tests. We currently
> configure a few packages in {{{}test.gradle{}}}. To support JDK 17, we must
> open and export additional packages.
> Additional packages to open (via {{{}--add-opens{}}}):
> - java.base/java.lang
> - java.base/java.nio
> - java.base/java.text
> - java.base/java.util
> - java.base/java.util.concurrent
> - java.base/java.util.concurrent.atomic
> - java.base/java.util.concurrent.locks
> - java.base/javax.net.ssl
> - java.base/sun.security.ssl
> - java.base/sun.util.locale
> - java.rmi/sun.rmi.transport
> Additional packages to export (via {{{}--add-opens{}}}):
> - java.base/jdk.internal.util.random
> - java.base/sun.nio.ch
> - java.base/sun.security.x509
> - java.management/com.sun.jmx.remote.security
> We may discover additional packages to open/export as we run more tests under
> JDK 17, and as we change product and test code.
> Note that different JDKs define different {{jdk.internal}} subpackages. For
> example:
> - JDK 17 has {{{}jdk.internal.util.random{}}}, but JDK 11 does not.
> - On Linux, JDK 11 and 17 have {{{}jdk.internal.platform.cgroupv1{}}}, but
> Windows and macOS JDKs do not.
> We have a few options for dealing with the differing {{jdk.internal}}
> packages:
> - Configure which packages we open/export depending on the JDK
> implementation.
> - Open all of these packages on all JDK platforms and versions (JDK 9 or
> higher). This will produce warnings when we open/export a package that does
> not exist.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-10140) QueryResultFormatterQueryIntegrationTest fails due to illegal reflective access on JDK 17
[ https://issues.apache.org/jira/browse/GEODE-10140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale Emery reassigned GEODE-10140: -- Assignee: Dale Emery > QueryResultFormatterQueryIntegrationTest fails due to illegal reflective > access on JDK 17 > - > > Key: GEODE-10140 > URL: https://issues.apache.org/jira/browse/GEODE-10140 > Project: Geode > Issue Type: Improvement > Components: tests >Affects Versions: 1.15.0 >Reporter: Dale Emery >Assignee: Dale Emery >Priority: Major > Labels: Java17 > > This test requires the following packages to be opened: > - java.base/sun.reflect.generics.repository > - java.base/java.time > - java.base/java.time.chrono > - java.base/java.time.format > - java.base/java.time.temporal > - java.base/sun.reflect.generics.factory > - java.base/sun.reflect.generics.reflectiveObjects > - java.base/sun.reflect.generics.repository > - java.base/sun.reflect.generics.scope > - java.base/sun.reflect.generics.tree -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10140) QueryResultFormatterQueryIntegrationTest fails due to illegal reflective access on JDK 17
[ https://issues.apache.org/jira/browse/GEODE-10140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale Emery updated GEODE-10140: --- Labels: Java17 (was: ) > QueryResultFormatterQueryIntegrationTest fails due to illegal reflective > access on JDK 17 > - > > Key: GEODE-10140 > URL: https://issues.apache.org/jira/browse/GEODE-10140 > Project: Geode > Issue Type: Improvement > Components: tests >Affects Versions: 1.15.0 >Reporter: Dale Emery >Priority: Major > Labels: Java17 > > This test requires the following packages to be opened: > - java.base/sun.reflect.generics.repository > - java.base/java.time > - java.base/java.time.chrono > - java.base/java.time.format > - java.base/java.time.temporal > - java.base/sun.reflect.generics.factory > - java.base/sun.reflect.generics.reflectiveObjects > - java.base/sun.reflect.generics.repository > - java.base/sun.reflect.generics.scope > - java.base/sun.reflect.generics.tree -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10140) QueryResultFormatterQueryIntegrationTest fails due to illegal reflective access on JDK 17
Dale Emery created GEODE-10140: -- Summary: QueryResultFormatterQueryIntegrationTest fails due to illegal reflective access on JDK 17 Key: GEODE-10140 URL: https://issues.apache.org/jira/browse/GEODE-10140 Project: Geode Issue Type: Improvement Components: tests Affects Versions: 1.15.0 Reporter: Dale Emery This test requires the following packages to be opened: - java.base/sun.reflect.generics.repository - java.base/java.time - java.base/java.time.chrono - java.base/java.time.format - java.base/java.time.temporal - java.base/sun.reflect.generics.factory - java.base/sun.reflect.generics.reflectiveObjects - java.base/sun.reflect.generics.repository - java.base/sun.reflect.generics.scope - java.base/sun.reflect.generics.tree -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10141) GMSJoinLeaveJUnitTest is overly specific about the expected exception message
Dale Emery created GEODE-10141: -- Summary: GMSJoinLeaveJUnitTest is overly specific about the expected exception message Key: GEODE-10141 URL: https://issues.apache.org/jira/browse/GEODE-10141 Project: Geode Issue Type: Improvement Components: membership, tests Affects Versions: 1.15.0 Reporter: Dale Emery `GMSJoinLeave` throws the correct exception type, with a message correctly describing its inability to connect to the locators at the specified unresolved addresses. But the test's assertion is overly specific about the description of an unresolved address, and fails on JDK 17. In JDKs up through 13, `toString()` of an unresolved `InetSocketAddress` returned `"hostname:port"`. Starting with JDK 14 it returns `"hostname/:port"`. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10141) GMSJoinLeaveJUnitTest is overly specific about the expected exception message
[ https://issues.apache.org/jira/browse/GEODE-10141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale Emery updated GEODE-10141: --- Labels: Java17 (was: ) > GMSJoinLeaveJUnitTest is overly specific about the expected exception message > - > > Key: GEODE-10141 > URL: https://issues.apache.org/jira/browse/GEODE-10141 > Project: Geode > Issue Type: Improvement > Components: membership, tests >Affects Versions: 1.15.0 >Reporter: Dale Emery >Priority: Major > Labels: Java17 > > `GMSJoinLeave` throws the correct exception type, with a message correctly > describing its inability to connect to the locators at the specified > unresolved addresses. But the test's assertion is overly specific about the > description of an unresolved address, and fails on JDK 17. > In JDKs up through 13, `toString()` of an unresolved `InetSocketAddress` > returned `"hostname:port"`. Starting with JDK 14 it returns > `"hostname/:port"`. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-10129) Forward module-related options when launching test subprocesses
[
https://issues.apache.org/jira/browse/GEODE-10129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery resolved GEODE-10129.
Fix Version/s: 1.15.0
Resolution: Fixed
> Forward module-related options when launching test subprocesses
> ---
>
> Key: GEODE-10129
> URL: https://issues.apache.org/jira/browse/GEODE-10129
> Project: Geode
> Issue Type: Improvement
> Components: tests
>Affects Versions: 1.15.0
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
> Labels: Java17, pull-request-available
> Fix For: 1.15.0
>
>
> Several tests and test helpers launch JVMs to run Geode code. For tests to
> run properly on JDK 17, that code must open or export the packages needed by
> the code that will run in the JVMs.
> Such helpers include:
> - {{GfshCommandRule}}
> - {{ProcessManager}} for DUnit tests.
> - {{ServerContainer}} for Jetty/Tomcat session tests.
> Also, {{ServerLauncherDUnitTest}} launches JVMs via a {{{}ProcessBuilder{}}}.
> A simple way to support opening and exporting the required packages is:
> # Assume that the current JVM opened and exported all required packages.
> (See https://issues.apache.org/jira/browse/GEODE-10128)
> # Query the {{--add-opens}} and {{--add-exports}} that were used to launch
> the current JVM. This can be done by calling
> {{{}ManagementFactory.getRuntimeMXBean().getInputArguments(){}}}, then
> filtering the list to retain only the {{--add-opens}} and {{--add-exports}}
> options.
> # Add those options when launching a subprocess.
> It would be useful to query and perform the current JVM a single place. I
> propose a static method: {{{}JavaModuleHelper.getJvmModuleOptions(){}}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10146) GradleBuildWithGeodeCoreAcceptanceTest fails on JDK 17
[
https://issues.apache.org/jira/browse/GEODE-10146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery updated GEODE-10146:
---
Labels: Java17 (was: )
> GradleBuildWithGeodeCoreAcceptanceTest fails on JDK 17
> --
>
> Key: GEODE-10146
> URL: https://issues.apache.org/jira/browse/GEODE-10146
> Project: Geode
> Issue Type: Improvement
> Components: ci
>Affects Versions: 1.15.0
>Reporter: Dale Emery
>Priority: Major
> Labels: Java17
>
> On JDK 17, GradleBuildWithGeodeCoreAcceptanceTest throws an exception
> ultimately caused by: "NoClassDefFoundError: Could not initialize class
> org.codehaus.groovy.reflection.ReflectionCache"
> Example failure (in a PR precheck):
> [http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7457/test-results/acceptanceTest/1647647868/classes/org.apache.geode.management.internal.rest.GradleBuildWithGeodeCoreAcceptanceTest.html#testBasicGradleBuild]
> {noformat}
> org.gradle.tooling.BuildException: Could not execute build using Gradle
> distribution 'https://services.gradle.org/distributions/gradle-5.1.1-bin.zip'.
> at
> org.gradle.tooling.internal.consumer.ExceptionTransformer.transform(ExceptionTransformer.java:51)
> at
> org.gradle.tooling.internal.consumer.ExceptionTransformer.transform(ExceptionTransformer.java:29)
> at
> org.gradle.tooling.internal.consumer.ResultHandlerAdapter.onFailure(ResultHandlerAdapter.java:41)
> at
> org.gradle.tooling.internal.consumer.async.DefaultAsyncConsumerActionExecutor$1$1.run(DefaultAsyncConsumerActionExecutor.java:57)
> at
> org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:63)
> at
> org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:46)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at
> org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:55)
> at java.lang.Thread.run(Thread.java:833)
> at
> org.gradle.tooling.internal.consumer.BlockingResultHandler.getResult(BlockingResultHandler.java:46)
> at
> org.gradle.tooling.internal.consumer.DefaultBuildLauncher.run(DefaultBuildLauncher.java:77)
> at
> org.apache.geode.management.internal.rest.GradleBuildWithGeodeCoreAcceptanceTest.testBasicGradleBuild(GradleBuildWithGeodeCoreAcceptanceTest.java:71)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:568)
> 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.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:38)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.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$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.
[jira] [Created] (GEODE-10146) GradleBuildWithGeodeCoreAcceptanceTest fails on JDK 17
Dale Emery created GEODE-10146:
--
Summary: GradleBuildWithGeodeCoreAcceptanceTest fails on JDK 17
Key: GEODE-10146
URL: https://issues.apache.org/jira/browse/GEODE-10146
Project: Geode
Issue Type: Improvement
Components: ci
Affects Versions: 1.15.0
Reporter: Dale Emery
On JDK 17, GradleBuildWithGeodeCoreAcceptanceTest throws an exception
ultimately caused by: "NoClassDefFoundError: Could not initialize class
org.codehaus.groovy.reflection.ReflectionCache"
Example failure (in a PR precheck):
[http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7457/test-results/acceptanceTest/1647647868/classes/org.apache.geode.management.internal.rest.GradleBuildWithGeodeCoreAcceptanceTest.html#testBasicGradleBuild]
{noformat}
org.gradle.tooling.BuildException: Could not execute build using Gradle
distribution 'https://services.gradle.org/distributions/gradle-5.1.1-bin.zip'.
at
org.gradle.tooling.internal.consumer.ExceptionTransformer.transform(ExceptionTransformer.java:51)
at
org.gradle.tooling.internal.consumer.ExceptionTransformer.transform(ExceptionTransformer.java:29)
at
org.gradle.tooling.internal.consumer.ResultHandlerAdapter.onFailure(ResultHandlerAdapter.java:41)
at
org.gradle.tooling.internal.consumer.async.DefaultAsyncConsumerActionExecutor$1$1.run(DefaultAsyncConsumerActionExecutor.java:57)
at
org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:63)
at
org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:46)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at
org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:55)
at java.lang.Thread.run(Thread.java:833)
at
org.gradle.tooling.internal.consumer.BlockingResultHandler.getResult(BlockingResultHandler.java:46)
at
org.gradle.tooling.internal.consumer.DefaultBuildLauncher.run(DefaultBuildLauncher.java:77)
at
org.apache.geode.management.internal.rest.GradleBuildWithGeodeCoreAcceptanceTest.testBasicGradleBuild(GradleBuildWithGeodeCoreAcceptanceTest.java:71)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:568)
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.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:38)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.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$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)
at
org.jun
[jira] [Updated] (GEODE-10146) GradleBuildWithGeodeCoreAcceptanceTest fails on JDK 17
[
https://issues.apache.org/jira/browse/GEODE-10146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery updated GEODE-10146:
---
Component/s: build
(was: ci)
> GradleBuildWithGeodeCoreAcceptanceTest fails on JDK 17
> --
>
> Key: GEODE-10146
> URL: https://issues.apache.org/jira/browse/GEODE-10146
> Project: Geode
> Issue Type: Improvement
> Components: build
>Affects Versions: 1.15.0
>Reporter: Dale Emery
>Priority: Major
> Labels: Java17
>
> On JDK 17, GradleBuildWithGeodeCoreAcceptanceTest throws an exception
> ultimately caused by: "NoClassDefFoundError: Could not initialize class
> org.codehaus.groovy.reflection.ReflectionCache"
> Example failure (in a PR precheck):
> [http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7457/test-results/acceptanceTest/1647647868/classes/org.apache.geode.management.internal.rest.GradleBuildWithGeodeCoreAcceptanceTest.html#testBasicGradleBuild]
> {noformat}
> org.gradle.tooling.BuildException: Could not execute build using Gradle
> distribution 'https://services.gradle.org/distributions/gradle-5.1.1-bin.zip'.
> at
> org.gradle.tooling.internal.consumer.ExceptionTransformer.transform(ExceptionTransformer.java:51)
> at
> org.gradle.tooling.internal.consumer.ExceptionTransformer.transform(ExceptionTransformer.java:29)
> at
> org.gradle.tooling.internal.consumer.ResultHandlerAdapter.onFailure(ResultHandlerAdapter.java:41)
> at
> org.gradle.tooling.internal.consumer.async.DefaultAsyncConsumerActionExecutor$1$1.run(DefaultAsyncConsumerActionExecutor.java:57)
> at
> org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:63)
> at
> org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:46)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at
> org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:55)
> at java.lang.Thread.run(Thread.java:833)
> at
> org.gradle.tooling.internal.consumer.BlockingResultHandler.getResult(BlockingResultHandler.java:46)
> at
> org.gradle.tooling.internal.consumer.DefaultBuildLauncher.run(DefaultBuildLauncher.java:77)
> at
> org.apache.geode.management.internal.rest.GradleBuildWithGeodeCoreAcceptanceTest.testBasicGradleBuild(GradleBuildWithGeodeCoreAcceptanceTest.java:71)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:568)
> 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.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:38)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.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$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
[jira] [Commented] (GEODE-10119) Handle SslSocket throwing SSLHandshakeException on JDK 17
[
https://issues.apache.org/jira/browse/GEODE-10119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17510906#comment-17510906
]
Dale Emery commented on GEODE-10119:
On JDK 17, this exception can occur multiple times, causing
\{{SocketCreator.configureClientSSLSocket}} to write multiple "fatal" log
entries.
Further up the call stack,
\{{ConnectionFactoryImpl.createClientToServerConnection()}} also logs each
occurrence as a warning. Perhaps it should log this as debug instead.
> Handle SslSocket throwing SSLHandshakeException on JDK 17
> -
>
> Key: GEODE-10119
> URL: https://issues.apache.org/jira/browse/GEODE-10119
> Project: Geode
> Issue Type: Bug
> Components: core, tests
>Affects Versions: 1.15.0
>Reporter: Dale Emery
>Priority: Major
> Labels: Java17, needsTriage
>
> In some circumstances, on JDK 17 {{SslSocket}} throws
> {{SSLHandshakeException}}, where on JDK 8 and 11 it would throw
> {{SocketException}}.
> {{SocketCreator.configureClientSSLSocket()}} handles
> {{SSLHandshakeException}} and {{SocketException}} differently:
> - It catches {{SSLHandshakeException}}, logs it as fatal, and rethrows it.
> - It does not catch {{SocketException}}.
> The new "fatal" log entry on JDK 17 causes
> {{WANSSLDUnitTest.testSenderSSLReceiverNoSSL()}} to fail.
> This may be simply a test issue. If so, the fix is to configure the test to
> ignore this new exception.
> But possibly the product's error handling needs to be changed to account for
> {{SslSocket}} throwing {{SSLHandshakeException}}.
> Example {{WANSSLDUnitTest.testSenderSSLReceiverNoSSL()}} test failure on JDK
> 17:
> {noformat}
> java.lang.AssertionError: Suspicious strings were written to the log during
> this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in 'dunit_suspect-vm4.log' at line 548
> [fatal 2022/03/10 01:29:50.162 UTC
> tid=144] Problem forming SSL connection to
> dale-dunit.c.apachegeode-ci.internal/10.128.0.33[28386].
> javax.net.ssl.SSLHandshakeException: Remote host terminated the handshake
> at
> java.base/sun.security.ssl.SSLSocketImpl.handleEOF(SSLSocketImpl.java:1709)
> at
> java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1508)
> at
> java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1415)
> at
> java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:450)
> at
> java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:421)
> at
> org.apache.geode.internal.net.SocketCreator.configureClientSSLSocket(SocketCreator.java:591)
> at
> org.apache.geode.internal.net.SCAdvancedSocketCreator.connect(SCAdvancedSocketCreator.java:83)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpSocketCreatorImpl.connect(TcpSocketCreatorImpl.java:59)
> at
> org.apache.geode.distributed.internal.tcpserver.ClientSocketCreatorImpl.connect(ClientSocketCreatorImpl.java:54)
> at
> org.apache.geode.cache.client.internal.ConnectionImpl.connect(ConnectionImpl.java:94)
> at
> org.apache.geode.cache.client.internal.ConnectionConnector.connectClientToServer(ConnectionConnector.java:75)
> at
> org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:120)
> at
> org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:243)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:196)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:190)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.borrowConnection(ConnectionManagerImpl.java:282)
> at
> org.apache.geode.cache.client.internal.PoolImpl.acquireConnection(PoolImpl.java:940)
> at
> org.apache.geode.cache.wan.internal.GatewaySenderEventRemoteDispatcher.initializeConnection(GatewaySenderEventRemoteDispatcher.java:481)
> at
> org.apache.geode.cache.wan.internal.GatewaySenderEventRemoteDispatcher.(GatewaySenderEventRemoteDispatcher.java:105)
> at
> org.apache.geode.cache.wan.internal.serial.RemoteSerialGatewaySenderEventProcessor.initializeEventDispatcher(RemoteSerialGatewaySenderEventProcessor.java:45)
> at
> org.apache.geode.internal.cache.wan.AbstractGatewaySenderEventProcessor.setRunningStatus(AbstractGatewaySenderEventProcessor.java:1107)
> at
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySend
[jira] [Assigned] (GEODE-10119) Handle SslSocket throwing SSLHandshakeException on JDK 17
[
https://issues.apache.org/jira/browse/GEODE-10119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery reassigned GEODE-10119:
--
Assignee: Dale Emery
> Handle SslSocket throwing SSLHandshakeException on JDK 17
> -
>
> Key: GEODE-10119
> URL: https://issues.apache.org/jira/browse/GEODE-10119
> Project: Geode
> Issue Type: Bug
> Components: core, tests
>Affects Versions: 1.15.0
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
> Labels: Java17, needsTriage, pull-request-available
>
> In some circumstances, on JDK 17 {{SslSocket}} throws
> {{SSLHandshakeException}}, where on JDK 8 and 11 it would throw
> {{SocketException}}.
> {{SocketCreator.configureClientSSLSocket()}} handles
> {{SSLHandshakeException}} and {{SocketException}} differently:
> - It catches {{SSLHandshakeException}}, logs it as fatal, and rethrows it.
> - It does not catch {{SocketException}}.
> The new "fatal" log entry on JDK 17 causes
> {{WANSSLDUnitTest.testSenderSSLReceiverNoSSL()}} to fail.
> This may be simply a test issue. If so, the fix is to configure the test to
> ignore this new exception.
> But possibly the product's error handling needs to be changed to account for
> {{SslSocket}} throwing {{SSLHandshakeException}}.
> Example {{WANSSLDUnitTest.testSenderSSLReceiverNoSSL()}} test failure on JDK
> 17:
> {noformat}
> java.lang.AssertionError: Suspicious strings were written to the log during
> this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in 'dunit_suspect-vm4.log' at line 548
> [fatal 2022/03/10 01:29:50.162 UTC
> tid=144] Problem forming SSL connection to
> dale-dunit.c.apachegeode-ci.internal/10.128.0.33[28386].
> javax.net.ssl.SSLHandshakeException: Remote host terminated the handshake
> at
> java.base/sun.security.ssl.SSLSocketImpl.handleEOF(SSLSocketImpl.java:1709)
> at
> java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1508)
> at
> java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1415)
> at
> java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:450)
> at
> java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:421)
> at
> org.apache.geode.internal.net.SocketCreator.configureClientSSLSocket(SocketCreator.java:591)
> at
> org.apache.geode.internal.net.SCAdvancedSocketCreator.connect(SCAdvancedSocketCreator.java:83)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpSocketCreatorImpl.connect(TcpSocketCreatorImpl.java:59)
> at
> org.apache.geode.distributed.internal.tcpserver.ClientSocketCreatorImpl.connect(ClientSocketCreatorImpl.java:54)
> at
> org.apache.geode.cache.client.internal.ConnectionImpl.connect(ConnectionImpl.java:94)
> at
> org.apache.geode.cache.client.internal.ConnectionConnector.connectClientToServer(ConnectionConnector.java:75)
> at
> org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:120)
> at
> org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:243)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:196)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:190)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.borrowConnection(ConnectionManagerImpl.java:282)
> at
> org.apache.geode.cache.client.internal.PoolImpl.acquireConnection(PoolImpl.java:940)
> at
> org.apache.geode.cache.wan.internal.GatewaySenderEventRemoteDispatcher.initializeConnection(GatewaySenderEventRemoteDispatcher.java:481)
> at
> org.apache.geode.cache.wan.internal.GatewaySenderEventRemoteDispatcher.(GatewaySenderEventRemoteDispatcher.java:105)
> at
> org.apache.geode.cache.wan.internal.serial.RemoteSerialGatewaySenderEventProcessor.initializeEventDispatcher(RemoteSerialGatewaySenderEventProcessor.java:45)
> at
> org.apache.geode.internal.cache.wan.AbstractGatewaySenderEventProcessor.setRunningStatus(AbstractGatewaySenderEventProcessor.java:1107)
> at
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderEventProcessor.run(SerialGatewaySenderEventProcessor.java:195)
> Suppressed: java.net.SocketException: Broken pipe
> at
> java.base/sun.nio.ch.NioSocketImpl.implWrite(NioSocketImpl.java:420)
> at
> java.base/sun.nio.ch.NioSocketImpl.write(NioSocketIm
[jira] [Created] (GEODE-10152) Make gfsh "wrapper" scripts compatible with Java 17
Dale Emery created GEODE-10152:
--
Summary: Make gfsh "wrapper" scripts compatible with Java 17
Key: GEODE-10152
URL: https://issues.apache.org/jira/browse/GEODE-10152
Project: Geode
Issue Type: Improvement
Components: gfsh
Affects Versions: 1.15.0
Reporter: Dale Emery
On JDK 17, the Gfsh "wrapper" scripts (geode-assembly/src/main/dist/bin/gfsh
and geode-assembly/src/main/dist/bin/gfsh.bat) must open/export all required
packages when they run the Geode CLI launcher
(org.apache.geode.management.internal.cli.Launcher) via Java.
Also, Gfsh must open and export all required packages whenever it starts Java
process that will execute Geode code.
Here is a possible approach: * Create argument files for each set of
opens/exports that are selected together. Each argument file will define the
{{--add-opens}} and {{--add-exports}} commands for the relevant packages.
* Change the Gfsh executables (geode-assembly/src/main/dist/bin/gfsh and
geode-assembly/src/main/dist/bin/gfsh) to:
** Inspect the requested JDK to learn the version and OS it reports.
** Select the argument files for the JDK based on its version and OS
** Add the argument files to the java command line when starting the CLI
launcher.
* Change Gfsh Java classes to forward the opens/exports when launching java
subprocesses (e.g. when starting a locator or server).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10152) Make gfsh "wrapper" scripts compatible with Java 17
[
https://issues.apache.org/jira/browse/GEODE-10152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery updated GEODE-10152:
---
Labels: Java17 (was: )
> Make gfsh "wrapper" scripts compatible with Java 17
> ---
>
> Key: GEODE-10152
> URL: https://issues.apache.org/jira/browse/GEODE-10152
> Project: Geode
> Issue Type: Improvement
> Components: gfsh
>Affects Versions: 1.15.0
>Reporter: Dale Emery
>Priority: Major
> Labels: Java17
>
> On JDK 17, the Gfsh "wrapper" scripts (geode-assembly/src/main/dist/bin/gfsh
> and geode-assembly/src/main/dist/bin/gfsh.bat) must open/export all required
> packages when they run the Geode CLI launcher
> (org.apache.geode.management.internal.cli.Launcher) via Java.
>
> Also, Gfsh must open and export all required packages whenever it starts Java
> process that will execute Geode code.
>
> Here is a possible approach: * Create argument files for each set of
> opens/exports that are selected together. Each argument file will define the
> {{--add-opens}} and {{--add-exports}} commands for the relevant packages.
> * Change the Gfsh executables (geode-assembly/src/main/dist/bin/gfsh and
> geode-assembly/src/main/dist/bin/gfsh) to:
> ** Inspect the requested JDK to learn the version and OS it reports.
> ** Select the argument files for the JDK based on its version and OS
> ** Add the argument files to the java command line when starting the CLI
> launcher.
> * Change Gfsh Java classes to forward the opens/exports when launching java
> subprocesses (e.g. when starting a locator or server).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-10134) SanctionedSerializablesFilterPattern does not accept proxy classes on JDK 17
[
https://issues.apache.org/jira/browse/GEODE-10134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery reassigned GEODE-10134:
--
Assignee: Dale Emery
> SanctionedSerializablesFilterPattern does not accept proxy classes on JDK 17
>
>
> Key: GEODE-10134
> URL: https://issues.apache.org/jira/browse/GEODE-10134
> Project: Geode
> Issue Type: Improvement
> Components: serialization
>Affects Versions: 1.15.0
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
> Labels: Java17
>
> On JDK 17, the classes of proxies are created in dynamically created
> packages. The current implemention of
> {{SanctionedSerializablesFilterPattern}} does not recognize those packages,
> and so rejects all proxy objects.
> So far I've seen two dynamically created proxy packages:
> - {{jdk.proxy2}}
> - {{jdk.proxy3}}
> Adding {{"jdk.proxy*"}} to the {{SanctionedSerializablesFilterPattern}} fixes
> the problem, at the risk of accepting an overly broad set of classes.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10165) DatagramSocket can throw SocketException instead of IOException when operation not permitted on JDK17
[
https://issues.apache.org/jira/browse/GEODE-10165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery updated GEODE-10165:
---
Description:
On JDK 17, a DatagramSocket can throw `SocketException` for "Operation not
permitted". In the same situation where on JDK11 it would throw `IOException`.
`Transport.doSend()` logs a `SocketException` as an error. It delegates
handling the `IOException` to its messenger, which logs it as a warning.
Example failure in CI:
- Failure in CI (PR precheckin):
https://concourse.apachegeode-ci.info/builds/39064786
- Test results:
http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7475/test-results/distributedTest/1648074003/
- Test run artifacts:
http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7475/test-artifacts/1648074003/distributedtestfiles-geode-pr-7475.tgz
Example stack trace on JDK17:
{noformat}
[vm5] [error 2022/03/23 20:00:06.635 UTC :47672> tid=0x40d]
Exception caught while sending message
[vm5] java.net.SocketException: Operation not permitted
[vm5] at java.base/sun.nio.ch.DatagramChannelImpl.send0(Native Method)
[vm5] at
java.base/sun.nio.ch.DatagramChannelImpl.sendFromNativeBuffer(DatagramChannelImpl.java:901)
[vm5] at
java.base/sun.nio.ch.DatagramChannelImpl.send(DatagramChannelImpl.java:863)
[vm5] at
java.base/sun.nio.ch.DatagramChannelImpl.send(DatagramChannelImpl.java:821)
[vm5] at
java.base/sun.nio.ch.DatagramChannelImpl.blockingSend(DatagramChannelImpl.java:853)
[vm5] at
java.base/sun.nio.ch.DatagramSocketAdaptor.send(DatagramSocketAdaptor.java:218)
[vm5] at java.base/java.net.DatagramSocket.send(DatagramSocket.java:664)
[vm5] at org.jgroups.protocols.UDP._send(UDP.java:224)
[vm5] at org.jgroups.protocols.UDP.sendUnicast(UDP.java:215)
[vm5] at org.jgroups.protocols.TP.sendToSingleMember(TP.java:1985)
[vm5] at org.jgroups.protocols.TP.doSend(TP.java:1962)
[vm5] at
org.apache.geode.distributed.internal.membership.gms.messenger.Transport.doSend(Transport.java:85)
[vm5] at org.jgroups.protocols.TP.send(TP.java:1948)
[vm5] at
org.apache.geode.distributed.internal.membership.gms.messenger.Transport._send(Transport.java:57)
[vm5] at org.jgroups.protocols.TP.down(TP.java:1515)
[vm5] at org.jgroups.stack.Protocol.down(Protocol.java:439)
[vm5] at
org.apache.geode.distributed.internal.membership.gms.messenger.StatRecorder.down(StatRecorder.java:87)
[vm5] at org.jgroups.protocols.UNICAST3.down(UNICAST3.java:646)
[vm5] at org.jgroups.protocols.FlowControl.down(FlowControl.java:347)
[vm5] at org.jgroups.protocols.FRAG2.down(FRAG2.java:136)
[vm5] at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:1039)
[vm5] at org.jgroups.JChannel.down(JChannel.java:790)
[vm5] at org.jgroups.JChannel.send(JChannel.java:426)
[vm5] at
org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger.send(JGroupsMessenger.java:838)
[vm5] at
org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger.send(JGroupsMessenger.java:681)
[vm5] at
org.apache.geode.distributed.internal.membership.gms.GMSMembership.send(GMSMembership.java:1335)
[vm5] at
org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:291)
[vm5] at
org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2067)
[vm5] at
org.apache.geode.distributed.internal.ClusterDistributionManager.sendShutdownMessage(ClusterDistributionManager.java:1965)
[vm5] at
org.apache.geode.distributed.internal.ClusterDistributionManager.lambda$shutdown$2(ClusterDistributionManager.java:1134)
[vm5] at java.base/java.lang.Thread.run(Thread.java:833)
{noformat}
Example stack trace on JDK11:
{noformat}
[vm7] [warn 2022/03/24 23:40:50.949 UTC :52674> tid=0x2d5] Unable to send message to
dale-dunit(50205):52673
[vm7] java.io.IOException: Operation not permitted
[vm7] at java.base/java.net.PlainDatagramSocketImpl.send(Native Method)
[vm7] at java.base/java.net.DatagramSocket.send(DatagramSocket.java:695)
[vm7] at org.jgroups.protocols.UDP._send(UDP.java:224)
[vm7] at org.jgroups.protocols.UDP.sendUnicast(UDP.java:215)
[vm7] at org.jgroups.protocols.TP.sendToSingleMember(TP.java:1985)
[vm7] at org.jgroups.protocols.TP.doSend(TP.java:1962)
[vm7] at
org.apache.geode.distributed.internal.membership.gms.messenger.Transport.doSend(Transport.java:85)
[vm7] at org.jgroups.protocols.TP.send(TP.java:1948)
[vm7] at
org.apache.geode.distributed.internal.membership.gms.messenger.Transport._send(Transport.java:57)
[vm7] at org.jgroups.protocols.TP.down(TP.java:1515)
[vm7] at org.jgroups.stack.Protocol.down(Protocol.java:439)
[vm7] at
org.apache.geode.distributed.internal.membership.gms.messenger.StatRecorder.down(StatRecorder.java:87)
[vm7] at org.jgroups.protocols.UNICAST3.down(UNICAST3.java:646)
[vm7] at org.jgroups.protocols.FlowControl.down(FlowControl.java:347)
[vm7] at org.jgroups.protocols.FRAG2.
[jira] [Created] (GEODE-10165) DatagramSocket can throw SocketException instead of IOException when operation not permitted on JDK17
Dale Emery created GEODE-10165:
--
Summary: DatagramSocket can throw SocketException instead of
IOException when operation not permitted on JDK17
Key: GEODE-10165
URL: https://issues.apache.org/jira/browse/GEODE-10165
Project: Geode
Issue Type: Improvement
Components: membership
Affects Versions: 1.15.0
Reporter: Dale Emery
On JDK 17, a DatagramSocket can throw `SocketException` for "Operation not
permitted". In the same situation where on JDK11 it would throw `IOException`.
`Transport.doSend()` logs a `SocketException` as an error. It delegates
handling the `IOException` to its messenger, which logs it as a warning.
Example failure in CI:
- Failure in CI (PR precheckin):
https://concourse.apachegeode-ci.info/builds/39064786
- Test results:
http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7475/test-results/distributedTest/1648074003/
- Test run artifacts:
http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7475/test-artifacts/1648074003/distributedtestfiles-geode-pr-7475.tgz
Example stack trace on JDK17:
{noformat}
[vm5] [error 2022/03/23 20:00:06.635 UTC :47672> tid=0x40d]
Exception caught while sending message
[vm5] java.net.SocketException: Operation not permitted
[vm5] at java.base/sun.nio.ch.DatagramChannelImpl.send0(Native Method)
[vm5] at
java.base/sun.nio.ch.DatagramChannelImpl.sendFromNativeBuffer(DatagramChannelImpl.java:901)
[vm5] at
java.base/sun.nio.ch.DatagramChannelImpl.send(DatagramChannelImpl.java:863)
[vm5] at
java.base/sun.nio.ch.DatagramChannelImpl.send(DatagramChannelImpl.java:821)
[vm5] at
java.base/sun.nio.ch.DatagramChannelImpl.blockingSend(DatagramChannelImpl.java:853)
[vm5] at
java.base/sun.nio.ch.DatagramSocketAdaptor.send(DatagramSocketAdaptor.java:218)
[vm5] at java.base/java.net.DatagramSocket.send(DatagramSocket.java:664)
[vm5] at org.jgroups.protocols.UDP._send(UDP.java:224)
[vm5] at org.jgroups.protocols.UDP.sendUnicast(UDP.java:215)
[vm5] at org.jgroups.protocols.TP.sendToSingleMember(TP.java:1985)
[vm5] at org.jgroups.protocols.TP.doSend(TP.java:1962)
[vm5] at
org.apache.geode.distributed.internal.membership.gms.messenger.Transport.doSend(Transport.java:85)
[vm5] at org.jgroups.protocols.TP.send(TP.java:1948)
[vm5] at
org.apache.geode.distributed.internal.membership.gms.messenger.Transport._send(Transport.java:57)
[vm5] at org.jgroups.protocols.TP.down(TP.java:1515)
[vm5] at org.jgroups.stack.Protocol.down(Protocol.java:439)
[vm5] at
org.apache.geode.distributed.internal.membership.gms.messenger.StatRecorder.down(StatRecorder.java:87)
[vm5] at org.jgroups.protocols.UNICAST3.down(UNICAST3.java:646)
[vm5] at org.jgroups.protocols.FlowControl.down(FlowControl.java:347)
[vm5] at org.jgroups.protocols.FRAG2.down(FRAG2.java:136)
[vm5] at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:1039)
[vm5] at org.jgroups.JChannel.down(JChannel.java:790)
[vm5] at org.jgroups.JChannel.send(JChannel.java:426)
[vm5] at
org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger.send(JGroupsMessenger.java:838)
[vm5] at
org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger.send(JGroupsMessenger.java:681)
[vm5] at
org.apache.geode.distributed.internal.membership.gms.GMSMembership.send(GMSMembership.java:1335)
[vm5] at
org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:291)
[vm5] at
org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2067)
[vm5] at
org.apache.geode.distributed.internal.ClusterDistributionManager.sendShutdownMessage(ClusterDistributionManager.java:1965)
[vm5] at
org.apache.geode.distributed.internal.ClusterDistributionManager.lambda$shutdown$2(ClusterDistributionManager.java:1134)
[vm5] at java.base/java.lang.Thread.run(Thread.java:833)
{noformat}
Example stack trace on JDK11:
{noformat}
[vm7] [warn 2022/03/24 23:40:50.949 UTC :52674> tid=0x2d5] Unable to send message to
dale-dunit(50205):52673
[vm7] java.io.IOException: Operation not permitted
[vm7] at java.base/java.net.PlainDatagramSocketImpl.send(Native Method)
[vm7] at java.base/java.net.DatagramSocket.send(DatagramSocket.java:695)
[vm7] at org.jgroups.protocols.UDP._send(UDP.java:224)
[vm7] at org.jgroups.protocols.UDP.sendUnicast(UDP.java:215)
[vm7] at org.jgroups.protocols.TP.sendToSingleMember(TP.java:1985)
[vm7] at org.jgroups.protocols.TP.doSend(TP.java:1962)
[vm7] at
org.apache.geode.distributed.internal.membership.gms.messenger.Transport.doSend(Transport.java:85)
[vm7] at org.jgroups.protocols.TP.send(TP.java:1948)
[vm7] at
org.apache.geode.distributed.internal.membership.gms.messenger.Transport._send(Transport.java:57)
[vm7] at org.jgroups.protocols.TP.down(TP.java:1515)
[vm7] at org.jgroups.stack.Protocol.down(Protocol.java:439)
[vm7] at
org.apache.geode.distribute
[jira] [Updated] (GEODE-10165) DatagramSocket can throw SocketException instead of IOException when operation not permitted on JDK17
[
https://issues.apache.org/jira/browse/GEODE-10165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery updated GEODE-10165:
---
Labels: Java17 (was: )
> DatagramSocket can throw SocketException instead of IOException when
> operation not permitted on JDK17
> -
>
> Key: GEODE-10165
> URL: https://issues.apache.org/jira/browse/GEODE-10165
> Project: Geode
> Issue Type: Improvement
> Components: membership
>Affects Versions: 1.15.0
>Reporter: Dale Emery
>Priority: Major
> Labels: Java17
>
>
> On JDK 17, a DatagramSocket can throw `SocketException` for "Operation not
> permitted". In the same situation where on JDK11 it would throw `IOException`.
>
> `Transport.doSend()` logs a `SocketException` as an error. It delegates
> handling the `IOException` to its messenger, which logs it as a warning.
>
> Example failure in CI:
> - Failure in CI (PR precheckin):
> https://concourse.apachegeode-ci.info/builds/39064786
> - Test results:
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7475/test-results/distributedTest/1648074003/
> - Test run artifacts:
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7475/test-artifacts/1648074003/distributedtestfiles-geode-pr-7475.tgz
> Example stack trace on JDK17:
> {noformat}
> [vm5] [error 2022/03/23 20:00:06.635 UTC heavy-lifter-1c2c92cd-65e8-5d6a-a2fd-52d05cdafe97(45303):47672>
> tid=0x40d] Exception caught while sending message
> [vm5] java.net.SocketException: Operation not permitted
> [vm5] at java.base/sun.nio.ch.DatagramChannelImpl.send0(Native Method)
> [vm5] at
> java.base/sun.nio.ch.DatagramChannelImpl.sendFromNativeBuffer(DatagramChannelImpl.java:901)
> [vm5] at
> java.base/sun.nio.ch.DatagramChannelImpl.send(DatagramChannelImpl.java:863)
> [vm5] at
> java.base/sun.nio.ch.DatagramChannelImpl.send(DatagramChannelImpl.java:821)
> [vm5] at
> java.base/sun.nio.ch.DatagramChannelImpl.blockingSend(DatagramChannelImpl.java:853)
> [vm5] at
> java.base/sun.nio.ch.DatagramSocketAdaptor.send(DatagramSocketAdaptor.java:218)
> [vm5] at java.base/java.net.DatagramSocket.send(DatagramSocket.java:664)
> [vm5] at org.jgroups.protocols.UDP._send(UDP.java:224)
> [vm5] at org.jgroups.protocols.UDP.sendUnicast(UDP.java:215)
> [vm5] at org.jgroups.protocols.TP.sendToSingleMember(TP.java:1985)
> [vm5] at org.jgroups.protocols.TP.doSend(TP.java:1962)
> [vm5] at
> org.apache.geode.distributed.internal.membership.gms.messenger.Transport.doSend(Transport.java:85)
> [vm5] at org.jgroups.protocols.TP.send(TP.java:1948)
> [vm5] at
> org.apache.geode.distributed.internal.membership.gms.messenger.Transport._send(Transport.java:57)
> [vm5] at org.jgroups.protocols.TP.down(TP.java:1515)
> [vm5] at org.jgroups.stack.Protocol.down(Protocol.java:439)
> [vm5] at
> org.apache.geode.distributed.internal.membership.gms.messenger.StatRecorder.down(StatRecorder.java:87)
> [vm5] at org.jgroups.protocols.UNICAST3.down(UNICAST3.java:646)
> [vm5] at org.jgroups.protocols.FlowControl.down(FlowControl.java:347)
> [vm5] at org.jgroups.protocols.FRAG2.down(FRAG2.java:136)
> [vm5] at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:1039)
> [vm5] at org.jgroups.JChannel.down(JChannel.java:790)
> [vm5] at org.jgroups.JChannel.send(JChannel.java:426)
> [vm5] at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger.send(JGroupsMessenger.java:838)
> [vm5] at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger.send(JGroupsMessenger.java:681)
> [vm5] at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership.send(GMSMembership.java:1335)
> [vm5] at
> org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:291)
> [vm5] at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2067)
> [vm5] at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendShutdownMessage(ClusterDistributionManager.java:1965)
> [vm5] at
> org.apache.geode.distributed.internal.ClusterDistributionManager.lambda$shutdown$2(ClusterDistributionManager.java:1134)
> [vm5] at java.base/java.lang.Thread.run(Thread.java:833)
> {noformat}
>
> Example stack trace on JDK11:
> {noformat}
> [vm7] [warn 2022/03/24 23:40:50.949 UTC dale-dunit(51430):52674> tid=0x2d5] Unable to send message to
> dale-dunit(50205):52673
> [vm7] java.io.IOException: Operation not permitted
> [vm7] at java.base/java.net.PlainDatagramSocketImpl.send(Native Method)
> [vm7] at java.base/java.net.DatagramSocket.send(DatagramSocket.java:695)
> [vm7] at org.jgroups.protocols.UDP._send(UDP.java:224)
> [vm7] at org.jgroups.protocols.UDP.sendUnicast(UDP.java:215)
> [vm7]
