[jira] [Updated] (GEODE-8954) Use a GEODE_VERSION variable for the CI
[ https://issues.apache.org/jira/browse/GEODE-8954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Martell updated GEODE-8954: --- Priority: Minor (was: Major) > Use a GEODE_VERSION variable for the CI > > > Key: GEODE-8954 > URL: https://issues.apache.org/jira/browse/GEODE-8954 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Michael Martell >Priority: Minor > > Several CI related files have GEODE_VERSION hardcodes. This includes > .lgtm.yml, serveral Dockerfiles and Packer files. This ticket is to create a > variable that can be utilized and passed in as opposed to hardcoding in a > bunch of files. > Setting the variable and passing in to *_docker build_* as an argument seems > prudent. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-10013) Remove unused code in Geode for Redis tests
[ https://issues.apache.org/jira/browse/GEODE-10013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ray Ingles resolved GEODE-10013. Fix Version/s: 1.16.0 Resolution: Fixed Small cleanup of unneeded test code. > Remove unused code in Geode for Redis tests > --- > > Key: GEODE-10013 > URL: https://issues.apache.org/jira/browse/GEODE-10013 > Project: Geode > Issue Type: Improvement > Components: redis >Affects Versions: 1.16.0 >Reporter: Ray Ingles >Assignee: Ray Ingles >Priority: Major > Labels: pull-request-available > Fix For: 1.16.0 > > > Several Geode for Redis tests contain redundant server.stop() calls and > unnecessary "canStoreBinaryData" tests. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10015) gfsh sends does not send hostname in SNI header
[
https://issues.apache.org/jira/browse/GEODE-10015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10015:
--
Labels: needsTriage (was: )
> gfsh sends 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: Major
> Labels: needsTriage
>
> 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.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-10015) gfsh sends does not send hostname in SNI header
Jacob Barrett created GEODE-10015:
-
Summary: gfsh sends 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
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.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10015) gfsh sends does not send hostname in SNI header
[
https://issues.apache.org/jira/browse/GEODE-10015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob Barrett updated GEODE-10015:
--
Priority: Blocker (was: Major)
> gfsh sends 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: needsTriage
>
> 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.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10015) gfsh sends does not send hostname in SNI header
[
https://issues.apache.org/jira/browse/GEODE-10015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob Barrett updated GEODE-10015:
--
Description:
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.
was:
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.
> gfsh sends 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: needsTriage
>
> 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;
> n
[jira] [Updated] (GEODE-10015) gfsh sends does not send hostname in SNI header
[
https://issues.apache.org/jira/browse/GEODE-10015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10015:
--
Labels: blocks-1.15.0 (was: needsTriage)
> gfsh sends 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
>
> 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] [Created] (GEODE-10016) Use Thread Name In Log Messages
Michael Martell created GEODE-10016: --- Summary: 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 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. 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] [Updated] (GEODE-10016) Use Thread Name In Log Messages
[ https://issues.apache.org/jira/browse/GEODE-10016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Martell updated GEODE-10016: Description: 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. was: 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. 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. Priority: Minor (was: Major) > 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 > > 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] [Updated] (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:all-tabpanel
]
Dave Barnes updated GEODE-10015:
Summary: gfsh does not send hostname in SNI header (was: gfsh sends does
not send hostname in SNI header)
> 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
>
> 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&focusedCommentId=17486616#comment-17486616 ] ASF GitHub Bot commented on GEODE-10016: mmartell opened a new pull request #918: URL: https://github.com/apache/geode-native/pull/918 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. -- 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 > > 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] [Updated] (GEODE-10016) Use Thread Name In Log Messages
[ https://issues.apache.org/jira/browse/GEODE-10016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-10016: --- Labels: pull-request-available (was: ) > 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] [Updated] (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:all-tabpanel
]
ASF GitHub Bot updated GEODE-10015:
---
Labels: blocks-1.15.0 pull-request-available (was: blocks-1.15.0)
> 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-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 ] Eric Zoerner reassigned GEODE-9998: --- Assignee: Eric Zoerner > 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 > > 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] [Updated] (GEODE-9845) CI failure: Multiple tests in OutOfMemoryDUnitTest failed with ConnectException
[
https://issues.apache.org/jira/browse/GEODE-9845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-9845:
--
Labels: pull-request-available (was: )
> CI failure: Multiple tests in OutOfMemoryDUnitTest failed with
> ConnectException
> ---
>
> Key: GEODE-9845
> URL: https://issues.apache.org/jira/browse/GEODE-9845
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Kamilla Aslami
>Priority: Major
> Labels: pull-request-available
> Attachments: PXL_20220114_205141950.MP.jpg,
> PXL_20220114_205147440.jpg, PXL_20220114_205152268.jpg,
> PXL_20220114_205156514.jpg
>
>
> 4 tests in OutOfMemoryDUnitTest failed with `java.net.ConnectException:
> Connection refused`.
> {noformat}
> OutOfMemoryDUnitTest > shouldAllowDeleteOperations_afterThresholdReached
> FAILED
> java.lang.AssertionError:
> Expecting throwable message:
> "No more cluster attempts left."
> to contain:
> "OOM command not allowed"
> but did not.
> Throwable that failed the check:
> redis.clients.jedis.exceptions.JedisClusterMaxAttemptsException: No more
> cluster attempts left.
> at
> redis.clients.jedis.JedisClusterCommand.runWithRetries(JedisClusterCommand.java:156)
> at
> redis.clients.jedis.JedisClusterCommand.run(JedisClusterCommand.java:45)
> at redis.clients.jedis.JedisCluster.set(JedisCluster.java:293)
> at
> org.apache.geode.redis.OutOfMemoryDUnitTest.setRedisKeyAndValue(OutOfMemoryDUnitTest.java:228)
> at
> org.apache.geode.redis.OutOfMemoryDUnitTest.lambda$addMultipleKeys$5(OutOfMemoryDUnitTest.java:212)
> at
> org.assertj.core.api.ThrowableAssert.catchThrowable(ThrowableAssert.java:62)
> at
> org.assertj.core.api.AssertionsForClassTypes.catchThrowable(AssertionsForClassTypes.java:877)
> at
> org.apache.geode.redis.OutOfMemoryDUnitTest.addMultipleKeys(OutOfMemoryDUnitTest.java:210)
> at
> org.apache.geode.redis.OutOfMemoryDUnitTest.fillMemory(OutOfMemoryDUnitTest.java:201)
> at
> org.apache.geode.redis.OutOfMemoryDUnitTest.shouldAllowDeleteOperations_afterThresholdReached(OutOfMemoryDUnitTest.java:166)
> 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.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.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule$1.evaluate(ClusterStartupRule.java:138)
> 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)
[jira] [Assigned] (GEODE-10001) CI Failure: ExportLogsStatsOverHttpDistributedTest > testExportLogsAndStats
[
https://issues.apache.org/jira/browse/GEODE-10001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hale Bales reassigned GEODE-10001:
--
Assignee: (was: Hale Bales)
> CI Failure: ExportLogsStatsOverHttpDistributedTest > testExportLogsAndStats
> ---
>
> Key: GEODE-10001
> URL: https://issues.apache.org/jira/browse/GEODE-10001
> Project: Geode
> Issue Type: Bug
> Components: gfsh, logging
>Affects Versions: 1.15.0
>Reporter: Hale Bales
>Priority: Major
>
> ExportLogsStatsOverHttpDistributedTest.testExportLogsAndStats has failed with
> missing files in a windows job. It appears that the server 1 logs and stats
> are not there.
> {code:java}
> ExportLogsStatsOverHttpDistributedTest > testExportLogsAndStats FAILED
> java.lang.AssertionError:
> Expecting HashSet:
> ["locator-0\\locator-0.log"]
> to contain:
> ["server-1\\server-1.log", "locator-0\\locator-0.log",
> "server-1\\statistics.gfs"]
> but could not find the following element(s):
> ["server-1\\server-1.log", "server-1\\statistics.gfs"]
> at
> org.apache.geode.management.internal.cli.commands.ExportLogsStatsDistributedTestBase.testExportLogsAndStats(ExportLogsStatsDistributedTestBase.java:96)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
> at
> org.apache.geode.test.junit.rules.serializable.SerializableTemporaryFolder$1.evaluate(SerializableTemporaryFolder.java:130)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.apache.geode.test.junit.rules.DescribedExternalResource$1.evaluate(DescribedExternalResource.java:40)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule$1.evaluate(ClusterStartupRule.java:139)
> 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: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.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:52)
> at
> org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:96)
> at
> org.junit.platform.la
[jira] [Updated] (GEODE-10001) CI Failure: ExportLogsStatsOverHttpDistributedTest > testExportLogsAndStats
[
https://issues.apache.org/jira/browse/GEODE-10001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hale Bales updated GEODE-10001:
---
Labels: (was: needsTriage)
> CI Failure: ExportLogsStatsOverHttpDistributedTest > testExportLogsAndStats
> ---
>
> Key: GEODE-10001
> URL: https://issues.apache.org/jira/browse/GEODE-10001
> Project: Geode
> Issue Type: Bug
> Components: gfsh, logging
>Affects Versions: 1.15.0
>Reporter: Hale Bales
>Assignee: Hale Bales
>Priority: Major
>
> ExportLogsStatsOverHttpDistributedTest.testExportLogsAndStats has failed with
> missing files in a windows job. It appears that the server 1 logs and stats
> are not there.
> {code:java}
> ExportLogsStatsOverHttpDistributedTest > testExportLogsAndStats FAILED
> java.lang.AssertionError:
> Expecting HashSet:
> ["locator-0\\locator-0.log"]
> to contain:
> ["server-1\\server-1.log", "locator-0\\locator-0.log",
> "server-1\\statistics.gfs"]
> but could not find the following element(s):
> ["server-1\\server-1.log", "server-1\\statistics.gfs"]
> at
> org.apache.geode.management.internal.cli.commands.ExportLogsStatsDistributedTestBase.testExportLogsAndStats(ExportLogsStatsDistributedTestBase.java:96)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
> at
> org.apache.geode.test.junit.rules.serializable.SerializableTemporaryFolder$1.evaluate(SerializableTemporaryFolder.java:130)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.apache.geode.test.junit.rules.DescribedExternalResource$1.evaluate(DescribedExternalResource.java:40)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule$1.evaluate(ClusterStartupRule.java:139)
> 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: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.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:52)
> at
> org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:96)
> at
[jira] [Commented] (GEODE-9710) Clean up PRColocationDUnitTestHelper
[ https://issues.apache.org/jira/browse/GEODE-9710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17486765#comment-17486765 ] ASF subversion and git services commented on GEODE-9710: Commit 507565e994c14aa5a26f497604a36a1592ea4f28 in geode's branch refs/heads/develop 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-10016) Use Thread Name In Log Messages
[
https://issues.apache.org/jira/browse/GEODE-10016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17486822#comment-17486822
]
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_r799169581
##
File path: cppcache/src/DistributedSystemImpl.cpp
##
@@ -38,6 +38,10 @@
#include "util/Log.hpp"
#include "version.h"
+namespace {
+std::map m_threadNames;
Review comment:
Does not conform to naming convention.
--
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] [Updated] (GEODE-10017) Fix new ITs unstability for TC that involves members restart
[
https://issues.apache.org/jira/browse/GEODE-10017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10017:
--
Labels: needsTriage (was: )
> Fix new ITs unstability for TC that involves 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)
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-10017) Fix new ITs unstability for TC that involves members restart
Mario Salazar de Torres created GEODE-10017:
---
Summary: Fix new ITs unstability for TC that involves 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
*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)
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10017) Fix new ITs unstability for TC that involves 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:
Description:
*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
* ···
was:
*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)
> Fix new ITs unstability for TC that involves 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
> * ···
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10017) Fix new ITs unstability for TC that involves 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:
Description:
*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
was:
*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
* ···
> Fix new ITs unstability for TC that involves 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] [Commented] (GEODE-10017) Fix new ITs unstability for TC that involves members restart
[
https://issues.apache.org/jira/browse/GEODE-10017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17486856#comment-17486856
]
Mario Salazar de Torres commented on GEODE-10017:
-
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 TC that involves 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)
