[jira] [Updated] (GEODE-10019) add jira id to release-related commits
[ https://issues.apache.org/jira/browse/GEODE-10019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-10019: --- Labels: pull-request-available (was: ) > add jira id to release-related commits > -- > > Key: GEODE-10019 > URL: https://issues.apache.org/jira/browse/GEODE-10019 > Project: Geode > Issue Type: Improvement > Components: release >Reporter: Owen Nichols >Priority: Major > Labels: pull-request-available > > problem: commits generated during release process fail to adhere to Geode > commit-message standards: they do not include a Jira ticket. > > solution: add a required -j parameter to all release scripts -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9998) Update jedis library to the current latest (>= 4.1.0)
[ https://issues.apache.org/jira/browse/GEODE-9998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9998: -- Labels: pull-request-available (was: ) > Update jedis library to the current latest (>= 4.1.0) > - > > Key: GEODE-9998 > URL: https://issues.apache.org/jira/browse/GEODE-9998 > Project: Geode > Issue Type: Test > Components: redis >Affects Versions: 1.16.0 >Reporter: Jens Deppe >Assignee: Eric Zoerner >Priority: Major > Labels: pull-request-available > > The 4.x version has been out for a while and we're still on 3.6.x (3.8 is the > last in the 3.x line). > This is not a trivial change as various APIs have changed which will affect a > lot of test code. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10019) add jira id to release-related commits
Owen Nichols created GEODE-10019: Summary: add jira id to release-related commits Key: GEODE-10019 URL: https://issues.apache.org/jira/browse/GEODE-10019 Project: Geode Issue Type: Improvement Components: release Reporter: Owen Nichols problem: commits generated during release process fail to adhere to Geode commit-message standards: they do not include a Jira ticket. solution: add a required -j parameter to all release scripts -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10015) gfsh does not send hostname in SNI header
[
https://issues.apache.org/jira/browse/GEODE-10015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17487386#comment-17487386
]
Jacob Barrett commented on GEODE-10015:
---
RMI defaults to using the local IP address rather than hostname. It has a
System Property, {{java.rmi.server.hostname}}, which allows you to override an
set a specific hostname. We set this property to the value of
{{jmx-manager-hostname-for-clients}}, if it is set. Adjusting the logic such
that when {{jmx-manager-hostname-for-clients}} is not set then we to set
{{java.rmi.server.hostname}} to the {{jmx-manager-bind-address}}, if set, or
the local hostname when SSL is enabled corrects this problem.
> gfsh does not send hostname in SNI header
> -
>
> Key: GEODE-10015
> URL: https://issues.apache.org/jira/browse/GEODE-10015
> Project: Geode
> Issue Type: Bug
> Components: gfsh, jmx
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Jacob Barrett
>Priority: Blocker
> Labels: blocks-1.15.0, pull-request-available
>
> When {{gfsh}} tries to connect the JMX port on the locator it sends the IP
> address of the locator in the SNI header rather than the hostname. This
> results in a certificate validation failure when the IP is not found in the
> SAN entries.
> Version 1.14.3 sends the correct hostname in the SNI. Something changed
> between 1.14.3 and now.
>
> Reproduction:
> {noformat}
> gfsh -e version --full -e start locator --name=locator2
> --bind-address=myhost.example.com --port=20005
> --J=-Dgemfire.jmx-manager-port=20007
> --security-properties-file=/path/to/security.properties --http-service-port=0
> --locators=myhost.example.com[20004]
> (1) Executing - version --full
> ...
> Product-Version: 1.16.0-build.0
> ...
> (2) Executing - start locator --name=locator2
> --bind-address=myhost.example.com --port=20005
> --J=-Dgemfire.jmx-manager-port=20007 --security-properties-file=
> --http-service-port=0 --locators=myhost.example.com[20004]
> ...
> [fatal 2022/02/02 19:47:27.050 PST tid=0x1] Problem forming SSL
> connection to /192.168.68.56[20007].
> javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException:
> No subject alternative names matching IP address 192.168.68.56 found
> ...
> Locator in /path/to/locator2 on myhost.example.com[20005] as locator2 is
> currently online.
> ...
> Unable to auto-connect (Security Manager may be enabled). Please use "connect
> --locator=myhost.example.com[20005]" to connect Gfsh to the locator.
> SSL configuration required to connect to the Manager.
> Failed to connect; unknown cause: error during JRMP connection establishment;
> nested exception is:
> javax.net.ssl.SSLHandshakeException:
> sun.security.validator.ValidatorException: PKIX path building failed:
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find
> valid certification path to requested target
> {noformat}
> Where {{/path/to/security.properties}} contains:
> {noformat}
> ssl-require-authentication=true
> ssl-keystore=/path/to/keystore.jks
> ssl-truststore-type=jks
> ssl-keystore-password=password
> ssl-truststore=/path/to/truststore.jks
> ssl-enabled-components=all
> ssl-truststore-password=password
> ssl-protocols=any
> ssl-endpoint-identification-enabled=true
> ssl-keystore-type=jks
> {noformat}
> The certificate used in the key store is singed by a fake CA and contains
> only the hostname, {{myhost.example.com}}. The trust store contains the fake
> CA.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-9724) CI Failure: RollingUpgradeRollServersOnReplicatedRegion_dataserializable.testRollServersOnReplicatedRegion_dataserializable[from_v1.4.0] FAILED
[ https://issues.apache.org/jira/browse/GEODE-9724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hale Bales reassigned GEODE-9724: - Assignee: Hale Bales > CI Failure: > RollingUpgradeRollServersOnReplicatedRegion_dataserializable.testRollServersOnReplicatedRegion_dataserializable[from_v1.4.0] > FAILED > --- > > Key: GEODE-9724 > URL: https://issues.apache.org/jira/browse/GEODE-9724 > Project: Geode > Issue Type: Bug > Components: serialization >Affects Versions: 1.14.1 >Reporter: Eric Shu >Assignee: Hale Bales >Priority: Major > Labels: needsTriage > > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeDUnitTest$1.run > in VM 2 running on Host 05a785bb07ad with 4 VMs > at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631) > at org.apache.geode.test.dunit.VM.invoke(VM.java:448) > at > org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeDUnitTest.rollLocatorToCurrent(RollingUpgradeDUnitTest.java:370) > at > org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeDUnitTest.doTestRollAll(RollingUpgradeDUnitTest.java:206) > at > org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeRollServersOnReplicatedRegion_dataserializable.testRollServersOnReplicatedRegion_dataserializable(RollingUpgradeRollServersOnReplicatedRegion_dataserializable.java:24) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61) > at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) > at > org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63) > at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329) > at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293) > at org.junit.runners.ParentRunner.run(ParentRunner.java:413) > at org.junit.runners.Suite.runChild(Suite.java:128) > at org.junit.runners.Suite.runChild(Suite.java:27) > at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329) > at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293) > at > org.junit.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.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38) > at > org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62) > at > org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51) > at
[jira] [Updated] (GEODE-9929) testTXCreationAndCleanupAtCommit when running RemoteTransactionDUnitTest
[ https://issues.apache.org/jira/browse/GEODE-9929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9929: -- Labels: pull-request-available (was: ) > testTXCreationAndCleanupAtCommit when running RemoteTransactionDUnitTest > > > Key: GEODE-9929 > URL: https://issues.apache.org/jira/browse/GEODE-9929 > Project: Geode > Issue Type: Bug >Affects Versions: 1.14.3 >Reporter: Kristen >Priority: Major > Labels: pull-request-available > > org.apache.geode.internal.cache.RemoteTransactionDUnitTest > > testTXCreationAndCleanupAtCommit FAILED > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.internal.cache.RemoteTransactionDUnitTest$8.call in VM 0 > running on Host 9acb6806d25d with 4 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.RemoteTransactionDUnitTest.doBasicChecks(RemoteTransactionDUnitTest.java:590) > at > org.apache.geode.internal.cache.RemoteTransactionDUnitTest.testTXCreationAndCleanupAtCommit(RemoteTransactionDUnitTest.java:565) > Caused by: > java.lang.AssertionError > at org.junit.Assert.fail(Assert.java:87) > at org.junit.Assert.assertTrue(Assert.java:42) > at org.junit.Assert.assertNotNull(Assert.java:713) > at org.junit.Assert.assertNotNull(Assert.java:723) > at > org.apache.geode.internal.cache.RemoteTransactionDUnitTest$8.call(RemoteTransactionDUnitTest.java:595) > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.internal.cache.RemoteTransactionDUnitTest$2.call in VM 1 > running on Host 9acb6806d25d with 4 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.test.dunit.Invoke.invokeInEveryVM(Invoke.java:121) > at org.apache.geode.test.dunit.Invoke.invokeInEveryVM(Invoke.java:109) > at > org.apache.geode.internal.cache.RemoteTransactionDUnitTest.preTearDownCacheTestCase(RemoteTransactionDUnitTest.java:182) > Caused by: > java.lang.AssertionError: Event never occurred after 3 ms: > at org.junit.Assert.fail(Assert.java:89) > at > org.apache.geode.test.dunit.Wait.waitForCriterion(Wait.java:144) > at > org.apache.geode.internal.cache.RemoteTransactionDUnitTest$2.call(RemoteTransactionDUnitTest.java:149) > 8838 tests completed, 1 failed, 458 skipped -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9929) testTXCreationAndCleanupAtCommit when running RemoteTransactionDUnitTest
[ https://issues.apache.org/jira/browse/GEODE-9929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17487361#comment-17487361 ] Hale Bales commented on GEODE-9929: --- Removing needsTriage label as this is not a release blocker. What I found was that `testTXCreationAndCleanupAtCommit` calls `doBasicChecks`. In this there is a callable that attempts to pause the transaction through the manager, but the returned `TXStateProxy` is null. The call to `TXManagerImpl.pauseTransaction()` that should return a `TXStateProxy` calls `internalSuspend(bool)`. In this method we call `getTXState()` but receive a null result instead of a `TXStateProxy`. `getTXState()` can return null if the `TXStateProxy` on the context is null; if the `TXStateProxy` is Paused; or if the `TXStateProxy` is does not have any transactions in progress. As I was never able to reproduce the failure after thousands of runs, I do not know which of these cases has resulted in the error. Given all that, this seems like a timing issue in the test, and an infrequent one at that. This timing issue is unlikely to affect users, and is therefore not of high enough priority to be a 1.15 release blocker. > testTXCreationAndCleanupAtCommit when running RemoteTransactionDUnitTest > > > Key: GEODE-9929 > URL: https://issues.apache.org/jira/browse/GEODE-9929 > Project: Geode > Issue Type: Bug >Affects Versions: 1.14.3 >Reporter: Kristen >Priority: Major > > org.apache.geode.internal.cache.RemoteTransactionDUnitTest > > testTXCreationAndCleanupAtCommit FAILED > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.internal.cache.RemoteTransactionDUnitTest$8.call in VM 0 > running on Host 9acb6806d25d with 4 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.RemoteTransactionDUnitTest.doBasicChecks(RemoteTransactionDUnitTest.java:590) > at > org.apache.geode.internal.cache.RemoteTransactionDUnitTest.testTXCreationAndCleanupAtCommit(RemoteTransactionDUnitTest.java:565) > Caused by: > java.lang.AssertionError > at org.junit.Assert.fail(Assert.java:87) > at org.junit.Assert.assertTrue(Assert.java:42) > at org.junit.Assert.assertNotNull(Assert.java:713) > at org.junit.Assert.assertNotNull(Assert.java:723) > at > org.apache.geode.internal.cache.RemoteTransactionDUnitTest$8.call(RemoteTransactionDUnitTest.java:595) > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.internal.cache.RemoteTransactionDUnitTest$2.call in VM 1 > running on Host 9acb6806d25d with 4 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.test.dunit.Invoke.invokeInEveryVM(Invoke.java:121) > at org.apache.geode.test.dunit.Invoke.invokeInEveryVM(Invoke.java:109) > at > org.apache.geode.internal.cache.RemoteTransactionDUnitTest.preTearDownCacheTestCase(RemoteTransactionDUnitTest.java:182) > Caused by: > java.lang.AssertionError: Event never occurred after 3 ms: > at org.junit.Assert.fail(Assert.java:89) > at > org.apache.geode.test.dunit.Wait.waitForCriterion(Wait.java:144) > at > org.apache.geode.internal.cache.RemoteTransactionDUnitTest$2.call(RemoteTransactionDUnitTest.java:149) > 8838 tests completed, 1 failed, 458 skipped -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-9929) testTXCreationAndCleanupAtCommit when running RemoteTransactionDUnitTest
[ https://issues.apache.org/jira/browse/GEODE-9929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hale Bales reassigned GEODE-9929: - Assignee: (was: Hale Bales) > testTXCreationAndCleanupAtCommit when running RemoteTransactionDUnitTest > > > Key: GEODE-9929 > URL: https://issues.apache.org/jira/browse/GEODE-9929 > Project: Geode > Issue Type: Bug >Affects Versions: 1.14.3 >Reporter: Kristen >Priority: Major > > org.apache.geode.internal.cache.RemoteTransactionDUnitTest > > testTXCreationAndCleanupAtCommit FAILED > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.internal.cache.RemoteTransactionDUnitTest$8.call in VM 0 > running on Host 9acb6806d25d with 4 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.RemoteTransactionDUnitTest.doBasicChecks(RemoteTransactionDUnitTest.java:590) > at > org.apache.geode.internal.cache.RemoteTransactionDUnitTest.testTXCreationAndCleanupAtCommit(RemoteTransactionDUnitTest.java:565) > Caused by: > java.lang.AssertionError > at org.junit.Assert.fail(Assert.java:87) > at org.junit.Assert.assertTrue(Assert.java:42) > at org.junit.Assert.assertNotNull(Assert.java:713) > at org.junit.Assert.assertNotNull(Assert.java:723) > at > org.apache.geode.internal.cache.RemoteTransactionDUnitTest$8.call(RemoteTransactionDUnitTest.java:595) > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.internal.cache.RemoteTransactionDUnitTest$2.call in VM 1 > running on Host 9acb6806d25d with 4 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.test.dunit.Invoke.invokeInEveryVM(Invoke.java:121) > at org.apache.geode.test.dunit.Invoke.invokeInEveryVM(Invoke.java:109) > at > org.apache.geode.internal.cache.RemoteTransactionDUnitTest.preTearDownCacheTestCase(RemoteTransactionDUnitTest.java:182) > Caused by: > java.lang.AssertionError: Event never occurred after 3 ms: > at org.junit.Assert.fail(Assert.java:89) > at > org.apache.geode.test.dunit.Wait.waitForCriterion(Wait.java:144) > at > org.apache.geode.internal.cache.RemoteTransactionDUnitTest$2.call(RemoteTransactionDUnitTest.java:149) > 8838 tests completed, 1 failed, 458 skipped -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9929) testTXCreationAndCleanupAtCommit when running RemoteTransactionDUnitTest
[ https://issues.apache.org/jira/browse/GEODE-9929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hale Bales updated GEODE-9929: -- Labels: (was: needsTriage) > testTXCreationAndCleanupAtCommit when running RemoteTransactionDUnitTest > > > Key: GEODE-9929 > URL: https://issues.apache.org/jira/browse/GEODE-9929 > Project: Geode > Issue Type: Bug >Affects Versions: 1.14.3 >Reporter: Kristen >Assignee: Hale Bales >Priority: Major > > org.apache.geode.internal.cache.RemoteTransactionDUnitTest > > testTXCreationAndCleanupAtCommit FAILED > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.internal.cache.RemoteTransactionDUnitTest$8.call in VM 0 > running on Host 9acb6806d25d with 4 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.RemoteTransactionDUnitTest.doBasicChecks(RemoteTransactionDUnitTest.java:590) > at > org.apache.geode.internal.cache.RemoteTransactionDUnitTest.testTXCreationAndCleanupAtCommit(RemoteTransactionDUnitTest.java:565) > Caused by: > java.lang.AssertionError > at org.junit.Assert.fail(Assert.java:87) > at org.junit.Assert.assertTrue(Assert.java:42) > at org.junit.Assert.assertNotNull(Assert.java:713) > at org.junit.Assert.assertNotNull(Assert.java:723) > at > org.apache.geode.internal.cache.RemoteTransactionDUnitTest$8.call(RemoteTransactionDUnitTest.java:595) > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.internal.cache.RemoteTransactionDUnitTest$2.call in VM 1 > running on Host 9acb6806d25d with 4 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.test.dunit.Invoke.invokeInEveryVM(Invoke.java:121) > at org.apache.geode.test.dunit.Invoke.invokeInEveryVM(Invoke.java:109) > at > org.apache.geode.internal.cache.RemoteTransactionDUnitTest.preTearDownCacheTestCase(RemoteTransactionDUnitTest.java:182) > Caused by: > java.lang.AssertionError: Event never occurred after 3 ms: > at org.junit.Assert.fail(Assert.java:89) > at > org.apache.geode.test.dunit.Wait.waitForCriterion(Wait.java:144) > at > org.apache.geode.internal.cache.RemoteTransactionDUnitTest$2.call(RemoteTransactionDUnitTest.java:149) > 8838 tests completed, 1 failed, 458 skipped -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10015) gfsh does not send hostname in SNI header
[
https://issues.apache.org/jira/browse/GEODE-10015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17487327#comment-17487327
]
Jacob Barrett commented on GEODE-10015:
---
This issue was introduced in
[55921a4d7b66a51279e71d1a665dc797fcc8ca6f|https://github.com/apache/geode/commit/55921a4d7b66a51279e71d1a665dc797fcc8ca6f].
When {{SocketCreator}} would configuration the SNI entries it used to convert
IP addresses into canonical host names. This was removed to better support
managed environments with strict usage of bind addresses. Restoring this
behavior might introduce other issues in these scenarios.
The IP address seems to be coming the RMI registry. The solution will require
fixing how those entries are created so they use the bind address of the JXM
service.
> gfsh does not send hostname in SNI header
> -
>
> Key: GEODE-10015
> URL: https://issues.apache.org/jira/browse/GEODE-10015
> Project: Geode
> Issue Type: Bug
> Components: gfsh, jmx
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Jacob Barrett
>Priority: Blocker
> Labels: blocks-1.15.0, pull-request-available
>
> When {{gfsh}} tries to connect the JMX port on the locator it sends the IP
> address of the locator in the SNI header rather than the hostname. This
> results in a certificate validation failure when the IP is not found in the
> SAN entries.
> Version 1.14.3 sends the correct hostname in the SNI. Something changed
> between 1.14.3 and now.
>
> Reproduction:
> {noformat}
> gfsh -e version --full -e start locator --name=locator2
> --bind-address=myhost.example.com --port=20005
> --J=-Dgemfire.jmx-manager-port=20007
> --security-properties-file=/path/to/security.properties --http-service-port=0
> --locators=myhost.example.com[20004]
> (1) Executing - version --full
> ...
> Product-Version: 1.16.0-build.0
> ...
> (2) Executing - start locator --name=locator2
> --bind-address=myhost.example.com --port=20005
> --J=-Dgemfire.jmx-manager-port=20007 --security-properties-file=
> --http-service-port=0 --locators=myhost.example.com[20004]
> ...
> [fatal 2022/02/02 19:47:27.050 PST tid=0x1] Problem forming SSL
> connection to /192.168.68.56[20007].
> javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException:
> No subject alternative names matching IP address 192.168.68.56 found
> ...
> Locator in /path/to/locator2 on myhost.example.com[20005] as locator2 is
> currently online.
> ...
> Unable to auto-connect (Security Manager may be enabled). Please use "connect
> --locator=myhost.example.com[20005]" to connect Gfsh to the locator.
> SSL configuration required to connect to the Manager.
> Failed to connect; unknown cause: error during JRMP connection establishment;
> nested exception is:
> javax.net.ssl.SSLHandshakeException:
> sun.security.validator.ValidatorException: PKIX path building failed:
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find
> valid certification path to requested target
> {noformat}
> Where {{/path/to/security.properties}} contains:
> {noformat}
> ssl-require-authentication=true
> ssl-keystore=/path/to/keystore.jks
> ssl-truststore-type=jks
> ssl-keystore-password=password
> ssl-truststore=/path/to/truststore.jks
> ssl-enabled-components=all
> ssl-truststore-password=password
> ssl-protocols=any
> ssl-endpoint-identification-enabled=true
> ssl-keystore-type=jks
> {noformat}
> The certificate used in the key store is singed by a fake CA and contains
> only the hostname, {{myhost.example.com}}. The trust store contains the fake
> CA.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-10016) Use Thread Name In Log Messages
[
https://issues.apache.org/jira/browse/GEODE-10016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17487324#comment-17487324
]
ASF GitHub Bot commented on GEODE-10016:
pivotal-jbarrett commented on a change in pull request #918:
URL: https://github.com/apache/geode-native/pull/918#discussion_r799849525
##
File path: cppcache/src/DistributedSystemImpl.cpp
##
@@ -38,6 +38,10 @@
#include "util/Log.hpp"
#include "version.h"
+namespace {
+std::map m_threadNames;
Review comment:
I am referring to the variable name. This is a global variable, now a
member variable and even member variables aren't supported to have the old `m_`
prefix.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Use Thread Name In Log Messages
> ---
>
> Key: GEODE-10016
> URL: https://issues.apache.org/jira/browse/GEODE-10016
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Michael Martell
>Priority: Minor
> Labels: pull-request-available
>
> The native client logging system currently prints the threadId in all log
> messages. Since all internally created native client threads are named, we
> should print the threadName instead of threadId. This will be extremely
> helpful to understanding the flow of messages since there are many background
> threads in the native client.
> Note: Lots of log messages are running on an application thread which was not
> created internally by the native client. Messages running on these threads
> should continue to print the threadId.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-10016) Use Thread Name In Log Messages
[
https://issues.apache.org/jira/browse/GEODE-10016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17487321#comment-17487321
]
ASF GitHub Bot commented on GEODE-10016:
pivotal-jbarrett commented on a change in pull request #918:
URL: https://github.com/apache/geode-native/pull/918#discussion_r799170401
##
File path: cppcache/src/DistributedSystemImpl.cpp
##
@@ -143,11 +147,24 @@ void DistributedSystemImpl::unregisterCliCallback(int
appdomainId) {
}
}
-void DistributedSystemImpl::setThreadName(const std::string& threadName) {
+std::string DistributedSystemImpl::getThreadName(std::thread::id id) {
+ std::string threadName = m_threadNames[id];
Review comment:
Not thread safe access to global variable.
##
File path: cppcache/src/Log.cpp
##
@@ -382,7 +383,8 @@ std::string Log::formatLogLine(LogLevel level) {
<< std::put_time(_val, "%Y/%m/%d %H:%M:%S") << '.' <<
std::setfill('0')
<< std::setw(6) << microseconds.count() << ' '
<< std::put_time(_val, "%z ") << g_hostName << ":"
- << boost::this_process::get_id() << " " << std::this_thread::get_id()
+ << boost::this_process::get_id() << " "
+ << DistributedSystemImpl::getThreadName(std::this_thread::get_id())
Review comment:
If the only place we get the name is from within the thread itself when
logging then why not store the name in a thread_local? This avoids the
synchronization issues mentioned previously.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Use Thread Name In Log Messages
> ---
>
> Key: GEODE-10016
> URL: https://issues.apache.org/jira/browse/GEODE-10016
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Michael Martell
>Priority: Minor
> Labels: pull-request-available
>
> The native client logging system currently prints the threadId in all log
> messages. Since all internally created native client threads are named, we
> should print the threadName instead of threadId. This will be extremely
> helpful to understanding the flow of messages since there are many background
> threads in the native client.
> Note: Lots of log messages are running on an application thread which was not
> created internally by the native client. Messages running on these threads
> should continue to print the threadId.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9833) SPOP Command Supported
[ https://issues.apache.org/jira/browse/GEODE-9833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17487302#comment-17487302 ] ASF subversion and git services commented on GEODE-9833: Commit afa17f65ec57052b0ee110326385568df784ba1a in geode's branch refs/heads/GEODE-9892-Create-Infrastructure-for-Redis-Lists from Kris10 [ https://gitbox.apache.org/repos/asf?p=geode.git;h=afa17f6 ] GEODE-9833: SPOP Command Support (#7319) - Modified implementation of retrieving a random element from SizeableObjectOpenCustomHashSetWithCursor backing array > SPOP Command Supported > -- > > Key: GEODE-9833 > URL: https://issues.apache.org/jira/browse/GEODE-9833 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Wayne >Assignee: Kristen >Priority: Major > Labels: blocks-1.15.0, pull-request-available > Fix For: 1.15.0, 1.16.0 > > > The SPOP command has been implemented but lacks sufficient testing to ensure > that the implementation is robust and does not regress in the future. > > Write unit/integration tests that run against both Geode Redis and native > Redis, and dunit tests which test multiple concurrent clients accessing > different servers. > > +Acceptance Criteria+ > > Passing Unit/integration tests for both Geode and native Redis. The > RedisCommandType class and > README/redis_api_for_[geode.html.md.erb|http://geode.html.md.erb/] updated to > make command "supported". Stories in the backlog to fix the identified issues > (with JIRA tickets) and problem tests that are ignored should be fixed and > enabled. > > The current implementation of RedisSet spop and srandmember always copy the > entire MemberSet. So if you have a redis set with a million items, and than > ask for one random one, instead of it reading just one of the items out of > the set it first copies the entire set. > The call that makes the copy is "members.toArray". It should be pretty easy > to add spop and srandmember support to the MemberSet super class. Since > MemberSet uses a flat array to store its items it should work well with > supporting indexing of its array to get a random element. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9710) Clean up PRColocationDUnitTestHelper
[ https://issues.apache.org/jira/browse/GEODE-9710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17487303#comment-17487303 ] ASF subversion and git services commented on GEODE-9710: Commit 507565e994c14aa5a26f497604a36a1592ea4f28 in geode's branch refs/heads/GEODE-9892-Create-Infrastructure-for-Redis-Lists from Nabarun Nag [ https://gitbox.apache.org/repos/asf?p=geode.git;h=507565e ] GEODE-9710: Cleanup PRColocationDUnitTestHelper (#6969) > Clean up PRColocationDUnitTestHelper > > > Key: GEODE-9710 > URL: https://issues.apache.org/jira/browse/GEODE-9710 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Nabarun Nag >Priority: Major > Labels: needsTriage, pull-request-available > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9999) Update the Geode for Redis documentation
[ https://issues.apache.org/jira/browse/GEODE-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17487300#comment-17487300 ] ASF subversion and git services commented on GEODE-: Commit 064fe005297e82094a1ef68d754efa2579b3277a in geode's branch refs/heads/GEODE-9892-Create-Infrastructure-for-Redis-Lists from John Martin [ https://gitbox.apache.org/repos/asf?p=geode.git;h=064fe00 ] GEODE-: Update the Geode for Redis documentation (#7326) > Update the Geode for Redis documentation > > > Key: GEODE- > URL: https://issues.apache.org/jira/browse/GEODE- > Project: Geode > Issue Type: Improvement > Components: redis >Affects Versions: 1.15.0, 1.16.0 >Reporter: John Martin >Assignee: John Martin >Priority: Major > Labels: backport, blocks-1.15.0, pull-request-available > Fix For: 1.15.0, 1.16.0 > > > A few updates are needed to update the Geode for Redis documentation to > better reflect the current implementation of the Redis module. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9994) Redis RENAME command should be atomic
[ https://issues.apache.org/jira/browse/GEODE-9994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17487301#comment-17487301 ] ASF subversion and git services commented on GEODE-9994: Commit 6413c33d6b0050a1ebe7e88f9ea20295ab780cab in geode's branch refs/heads/GEODE-9892-Create-Infrastructure-for-Redis-Lists from Eric Zoerner [ https://gitbox.apache.org/repos/asf?p=geode.git;h=6413c33 ] GEODE-9994 Make Redis RENAME atomic (#7328) - change verification to allow for erroneous client retries - change error logging to warning level to prevent false negative test failure due to log > Redis RENAME command should be atomic > - > > Key: GEODE-9994 > URL: https://issues.apache.org/jira/browse/GEODE-9994 > Project: Geode > Issue Type: Bug > Components: redis >Affects Versions: 1.15.0, 1.16.0 >Reporter: Donal Evans >Assignee: Eric Zoerner >Priority: Major > Labels: blocks-1.15.0, pull-request-available > Fix For: 1.15.0, 1.16.0 > > > The current implementation of RENAME in the geode-for-redis module is not > atomic, which could result in partially-applied renames if servers crash > during a rename. > The implementation should be changed to use the > 'lockedExecuteInTransaction()' method in the AbstractRenameExecutor class. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10018) Remove tx flag from Redis SetOptions
Jens Deppe created GEODE-10018:
--
Summary: Remove tx flag from Redis SetOptions
Key: GEODE-10018
URL: https://issues.apache.org/jira/browse/GEODE-10018
Project: Geode
Issue Type: Improvement
Components: redis
Reporter: Jens Deppe
A recent change ([https://github.com/apache/geode/pull/7321)] consolidated the
logic for transactional operations, avoiding the need for individual data
structs and commands to take different code paths to account for delta changes
vs tx contexts.
The MSET command still contains this older approach which can now be removed.
Practically, we can remove the {{SetOptions.inTransaction}} field and all logic
surrounding this flag.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-10016) Use Thread Name In Log Messages
[
https://issues.apache.org/jira/browse/GEODE-10016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17487137#comment-17487137
]
ASF GitHub Bot commented on GEODE-10016:
mmartell commented on a change in pull request #918:
URL: https://github.com/apache/geode-native/pull/918#discussion_r799580487
##
File path: cppcache/src/DistributedSystemImpl.cpp
##
@@ -38,6 +38,10 @@
#include "util/Log.hpp"
#include "version.h"
+namespace {
+std::map m_threadNames;
Review comment:
I'm using this anonymous namespace to solve an apparent linking issue.
Without it, this map is an unresolved reference in the clicache. Do you know of
another way to solve that?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Use Thread Name In Log Messages
> ---
>
> Key: GEODE-10016
> URL: https://issues.apache.org/jira/browse/GEODE-10016
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Michael Martell
>Priority: Minor
> Labels: pull-request-available
>
> The native client logging system currently prints the threadId in all log
> messages. Since all internally created native client threads are named, we
> should print the threadName instead of threadId. This will be extremely
> helpful to understanding the flow of messages since there are many background
> threads in the native client.
> Note: Lots of log messages are running on an application thread which was not
> created internally by the native client. Messages running on these threads
> should continue to print the threadId.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9712) Genericize All .NET Core Classes
[ https://issues.apache.org/jira/browse/GEODE-9712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17487125#comment-17487125 ] ASF GitHub Bot commented on GEODE-9712: --- mmartell commented on pull request #909: URL: https://github.com/apache/geode-native/pull/909#issuecomment-1030084621 With the decision to go with a pure C# client for .NET, we no loner need this interop based approach. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Genericize All .NET Core Classes > > > Key: GEODE-9712 > URL: https://issues.apache.org/jira/browse/GEODE-9712 > Project: Geode > Issue Type: New Feature > Components: native client >Reporter: Michael Martell >Assignee: Michael Martell >Priority: Major > Labels: pull-request-available > > We need to implement IRegion in .NET Core. This will require > writing generic versions of RegionFactory, Region, and Cache. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9712) Genericize All .NET Core Classes
[ https://issues.apache.org/jira/browse/GEODE-9712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17487124#comment-17487124 ] ASF GitHub Bot commented on GEODE-9712: --- mmartell closed pull request #909: URL: https://github.com/apache/geode-native/pull/909 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Genericize All .NET Core Classes > > > Key: GEODE-9712 > URL: https://issues.apache.org/jira/browse/GEODE-9712 > Project: Geode > Issue Type: New Feature > Components: native client >Reporter: Michael Martell >Assignee: Michael Martell >Priority: Major > Labels: pull-request-available > > We need to implement IRegion in .NET Core. This will require > writing generic versions of RegionFactory, Region, and Cache. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10009) The CacheClientProxy for a durable client can be terminated when it shouldn't be
[ https://issues.apache.org/jira/browse/GEODE-10009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade updated GEODE-10009: -- Labels: blocks-1.15.0 pull-request-available (was: blocks-1.15.0 needsTriage pull-request-available) > The CacheClientProxy for a durable client can be terminated when it shouldn't > be > > > Key: GEODE-10009 > URL: https://issues.apache.org/jira/browse/GEODE-10009 > Project: Geode > Issue Type: Bug > Components: client queues >Affects Versions: 1.15.0 >Reporter: Barrett Oglesby >Assignee: Barrett Oglesby >Priority: Major > Labels: blocks-1.15.0, pull-request-available > > When the client connection is closed but the server has not left or crashed > (e.g in the re-authentication failed case), its possible that two threads in > a durable client can interleave in a way that causes an extra durable task to > be created on the server that eventually causes the CacheClientProxy to be > terminated. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10016) Use Thread Name In Log Messages
[
https://issues.apache.org/jira/browse/GEODE-10016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17486932#comment-17486932
]
ASF GitHub Bot commented on GEODE-10016:
gaussianrecurrence commented on a change in pull request #918:
URL: https://github.com/apache/geode-native/pull/918#discussion_r799326466
##
File path: cppcache/src/Log.cpp
##
@@ -382,7 +383,8 @@ std::string Log::formatLogLine(LogLevel level) {
<< std::put_time(_val, "%Y/%m/%d %H:%M:%S") << '.' <<
std::setfill('0')
<< std::setw(6) << microseconds.count() << ' '
<< std::put_time(_val, "%z ") << g_hostName << ":"
- << boost::this_process::get_id() << " " << std::this_thread::get_id()
+ << boost::this_process::get_id() << " "
+ << DistributedSystemImpl::getThreadName(std::this_thread::get_id())
Review comment:
I am not totally sure about this, but changing the logging format might
break the GNMSG tool that @pdxcodemonkey implemented some time ago. I am not
sure what level of support you are intending to provide for this tool, but
might be good to make sure that the tool could handle both log formats
##
File path: cppcache/src/ThreadPool.cpp
##
@@ -16,6 +16,8 @@
*/
#include "ThreadPool.hpp"
+#include
Review comment:
I think this might be a remaining of some dev debugging. Is this needed
anymore?
##
File path: cppcache/src/DistributedSystemImpl.cpp
##
@@ -143,11 +147,24 @@ void DistributedSystemImpl::unregisterCliCallback(int
appdomainId) {
}
}
-void DistributedSystemImpl::setThreadName(const std::string& threadName) {
+std::string DistributedSystemImpl::getThreadName(std::thread::id id) {
Review comment:
Is there any particular reason why you would want to obtain the thread
name from another thread which is not the caller thread? Because if there is no
reason, I'd say it'd be best to get the thread ID of the current thread within
the function, and that would make syntax a little bit simpler.
##
File path: cppcache/src/DistributedSystemImpl.cpp
##
@@ -143,11 +147,24 @@ void DistributedSystemImpl::unregisterCliCallback(int
appdomainId) {
}
}
-void DistributedSystemImpl::setThreadName(const std::string& threadName) {
+std::string DistributedSystemImpl::getThreadName(std::thread::id id) {
+ std::string threadName = m_threadNames[id];
+ if (threadName == "") {
+std::stringstream ss;
+ss << id;
+threadName = ss.str();
+ }
+ return threadName;
+}
+
+void DistributedSystemImpl::setThreadName(const std::string& threadName,
Review comment:
Same comment regarding thread ID as for getThreadName, IMHO I don't see
a reason why you would need to pass a thread ID here
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Use Thread Name In Log Messages
> ---
>
> Key: GEODE-10016
> URL: https://issues.apache.org/jira/browse/GEODE-10016
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Michael Martell
>Priority: Minor
> Labels: pull-request-available
>
> The native client logging system currently prints the threadId in all log
> messages. Since all internally created native client threads are named, we
> should print the threadName instead of threadId. This will be extremely
> helpful to understanding the flow of messages since there are many background
> threads in the native client.
> Note: Lots of log messages are running on an application thread which was not
> created internally by the native client. Messages running on these threads
> should continue to print the threadId.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-10017) Fix new ITs unstability for TCs that involve members restart
[
https://issues.apache.org/jira/browse/GEODE-10017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17486926#comment-17486926
]
ASF GitHub Bot commented on GEODE-10017:
gaussianrecurrence opened a new pull request #919:
URL: https://github.com/apache/geode-native/pull/919
- Due to a rare race-condition described on the Jira case, it could
happen that some test cases that needed to restart a/some server(s)
could end up getting stuck.
- This change introduces a mechanism to verify the server process has
been actually stopped.
- Also, removed sleeps on some TCs which were put in place as a WA.
- Modified all of the new IT TCs that were restarting servers in order
to use the above mentioned mechanism, so the race-condition is
avoided.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Fix new ITs unstability for TCs that involve members restart
>
>
> Key: GEODE-10017
> URL: https://issues.apache.org/jira/browse/GEODE-10017
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Major
> Labels: needsTriage
>
> *GIVEN* an integration TC on which a server restart needs to be restarted
> *WHEN* the server is starting up again
> *THEN* +{color:#172b4d}it might{color}+{color:#172b4d} happen that the TC
> gets stuck{color}
>
> *Additional information.* This issue does not always happens, and I've seen
> it happening more frequently with the latest version of Geode server (1.15.0)
> Some examples of this TC are:
> * RegisterKeysTest.RegisterKeySetAndClusterRestart
> * PartitionRegionWithRedundancyTest.putgetWithSingleHop
> * ···
> Also, this is normally the exec flow for the TCs that get stuck:
> # Setup cluster
> # Do TC specific ops
> # Stop server(s)/Cluster shutdown
> # Start server(s)
> In all cases, the server gets stuck at step 4
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10017) Fix new ITs unstability for TCs that involve members restart
[
https://issues.apache.org/jira/browse/GEODE-10017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-10017:
---
Labels: needsTriage pull-request-available (was: needsTriage)
> Fix new ITs unstability for TCs that involve members restart
>
>
> Key: GEODE-10017
> URL: https://issues.apache.org/jira/browse/GEODE-10017
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Major
> Labels: needsTriage, pull-request-available
>
> *GIVEN* an integration TC on which a server restart needs to be restarted
> *WHEN* the server is starting up again
> *THEN* +{color:#172b4d}it might{color}+{color:#172b4d} happen that the TC
> gets stuck{color}
>
> *Additional information.* This issue does not always happens, and I've seen
> it happening more frequently with the latest version of Geode server (1.15.0)
> Some examples of this TC are:
> * RegisterKeysTest.RegisterKeySetAndClusterRestart
> * PartitionRegionWithRedundancyTest.putgetWithSingleHop
> * ···
> Also, this is normally the exec flow for the TCs that get stuck:
> # Setup cluster
> # Do TC specific ops
> # Stop server(s)/Cluster shutdown
> # Start server(s)
> In all cases, the server gets stuck at step 4
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-10017) Fix new ITs unstability for TCs that involve members restart
[
https://issues.apache.org/jira/browse/GEODE-10017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Salazar de Torres reassigned GEODE-10017:
---
Assignee: Mario Salazar de Torres
> Fix new ITs unstability for TCs that involve members restart
>
>
> Key: GEODE-10017
> URL: https://issues.apache.org/jira/browse/GEODE-10017
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Major
> Labels: needsTriage
>
> *GIVEN* an integration TC on which a server restart needs to be restarted
> *WHEN* the server is starting up again
> *THEN* +{color:#172b4d}it might{color}+{color:#172b4d} happen that the TC
> gets stuck{color}
>
> *Additional information.* This issue does not always happens, and I've seen
> it happening more frequently with the latest version of Geode server (1.15.0)
> Some examples of this TC are:
> * RegisterKeysTest.RegisterKeySetAndClusterRestart
> * PartitionRegionWithRedundancyTest.putgetWithSingleHop
> * ···
> Also, this is normally the exec flow for the TCs that get stuck:
> # Setup cluster
> # Do TC specific ops
> # Stop server(s)/Cluster shutdown
> # Start server(s)
> In all cases, the server gets stuck at step 4
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (GEODE-10017) Fix new ITs unstability for TCs that involve members restart
[
https://issues.apache.org/jira/browse/GEODE-10017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17486856#comment-17486856
]
Mario Salazar de Torres edited comment on GEODE-10017 at 2/4/22, 8:46 AM:
--
After some digging I noticed that for the executions on which one of these TCs
get stuck, GFSH tool running the "start server ..." command, never returns.
So I checked why GFSH was not returning and I saw that it was stuck checking
the server state, which was always returning as non-responding, even whenever
there was a server instance running (as I could see by connecting to the
cluster and running list member)/listing processes in the test
container/looking at the logs.
So, looking for all of the possible scenarios which could cause ServerState to
show up as "Not responding" I noticed that there were no PID file inside the
recently started server and this was causing the whole issue.
Now, my theory for why that's happening is the following:
# First instance of the server is notified to be stopped.
# Cache for the first server is closed, and GFSH process stopping the server
exists, returning the control to the test process.
# Given that the from the point of view of the test the server has been
stopped already, it runs the startup for the new server.
# The newer server instance writes the PID file with its PID.
# The older server instance, which was still running, deletes its PID along
some other files and actually terminate its process.
The time gap between step 4 and 5 normally is really tight, so that would
explain why this issue only reproduces sometimes and mostly on overloaded
systems.
was (Author: gaussianrecurrence):
After some digging I noticed that for the executions on which one of these TCs
get stuck, GFSH tool running the "start server ..." command, never returns.
So I checked why GFSH was not returning and I saw that it was stuck checking
the server state, which was always returning as non-responding, even whenever
there was a server instance running (as I could see by connecting to the
cluster and running list member)/listing processes in the test
container/looking at the logs.
So, looking for all of the possible scenarios which could cause ServerState to
show up as "Not responding" I noticed that there were no PID file inside the
recently started server and this was causing the whole issue.
Now, my theory for why that's happening is the following:
# First instance of the server is notified to be stopped.
# Cache for the first server is closed, and GFSH process stopping the server
exists, returning the control to the test process.
# Given that the from the point of view of the test the server has been
stopped already, it runs the startup for the new server.
# The newer server instance writes the PID file with its PID.
# The older server instance, which was still running, deletes its PID along
some other files and actually terminate its process.
The time gap between step 4 and 5 normally is really tight, so that would
explain why this issue only reproduces sometimes and mostly on overloaded
systems.
> Fix new ITs unstability for TCs that involve members restart
>
>
> Key: GEODE-10017
> URL: https://issues.apache.org/jira/browse/GEODE-10017
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Mario Salazar de Torres
>Priority: Major
> Labels: needsTriage
>
> *GIVEN* an integration TC on which a server restart needs to be restarted
> *WHEN* the server is starting up again
> *THEN* +{color:#172b4d}it might{color}+{color:#172b4d} happen that the TC
> gets stuck{color}
>
> *Additional information.* This issue does not always happens, and I've seen
> it happening more frequently with the latest version of Geode server (1.15.0)
> Some examples of this TC are:
> * RegisterKeysTest.RegisterKeySetAndClusterRestart
> * PartitionRegionWithRedundancyTest.putgetWithSingleHop
> * ···
> Also, this is normally the exec flow for the TCs that get stuck:
> # Setup cluster
> # Do TC specific ops
> # Stop server(s)/Cluster shutdown
> # Start server(s)
> In all cases, the server gets stuck at step 4
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10017) Fix new ITs unstability for TCs that involve members restart
[
https://issues.apache.org/jira/browse/GEODE-10017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Salazar de Torres updated GEODE-10017:
Summary: Fix new ITs unstability for TCs that involve members restart
(was: Fix new ITs unstability for TC that involves members restart)
> Fix new ITs unstability for TCs that involve members restart
>
>
> Key: GEODE-10017
> URL: https://issues.apache.org/jira/browse/GEODE-10017
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Mario Salazar de Torres
>Priority: Major
> Labels: needsTriage
>
> *GIVEN* an integration TC on which a server restart needs to be restarted
> *WHEN* the server is starting up again
> *THEN* +{color:#172b4d}it might{color}+{color:#172b4d} happen that the TC
> gets stuck{color}
>
> *Additional information.* This issue does not always happens, and I've seen
> it happening more frequently with the latest version of Geode server (1.15.0)
> Some examples of this TC are:
> * RegisterKeysTest.RegisterKeySetAndClusterRestart
> * PartitionRegionWithRedundancyTest.putgetWithSingleHop
> * ···
> Also, this is normally the exec flow for the TCs that get stuck:
> # Setup cluster
> # Do TC specific ops
> # Stop server(s)/Cluster shutdown
> # Start server(s)
> In all cases, the server gets stuck at step 4
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
