[jira] [Updated] (GEODE-10028) Testing the needsTriage bot
[ https://issues.apache.org/jira/browse/GEODE-10028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10028: -- > Testing the needsTriage bot > --- > > Key: GEODE-10028 > URL: https://issues.apache.org/jira/browse/GEODE-10028 > Project: Geode > Issue Type: Bug >Reporter: Alexander Murmann >Priority: Major > Labels: needsTriage > > this is text for the humans -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10028) Testing the needsTriage bot
Alexander Murmann created GEODE-10028: - Summary: Testing the needsTriage bot Key: GEODE-10028 URL: https://issues.apache.org/jira/browse/GEODE-10028 Project: Geode Issue Type: Bug Reporter: Alexander Murmann this is text for the humans -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Deleted] (GEODE-10028) Testing the needsTriage bot
[ https://issues.apache.org/jira/browse/GEODE-10028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann deleted GEODE-10028: -- > Testing the needsTriage bot > --- > > Key: GEODE-10028 > URL: https://issues.apache.org/jira/browse/GEODE-10028 > Project: Geode > Issue Type: Bug >Reporter: Alexander Murmann >Priority: Major > Labels: needsTriage > > this is text for the humans -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10027) Exception parsing using the Java serialized object
Mario Salazar de Torres created GEODE-10027: --- Summary: Exception parsing using the Java serialized object Key: GEODE-10027 URL: https://issues.apache.org/jira/browse/GEODE-10027 Project: Geode Issue Type: Improvement Components: native client Reporter: Mario Salazar de Torres Currently, exceptions received in the native client are using just the exception message to identify the exceptions. Also there is the problem that the exception chain is lost, only the first identified exception in the message is thrown. Also there is the thing that it would be way easier to handle all kind of exceptions, and also, in the future, could allow to parse custom implemented exceptions. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10026) Implement java deserialization
Mario Salazar de Torres created GEODE-10026: --- Summary: Implement java deserialization Key: GEODE-10026 URL: https://issues.apache.org/jira/browse/GEODE-10026 Project: Geode Issue Type: Improvement Components: native client Reporter: Mario Salazar de Torres Currently, the native client does not support deserializing Java serialized objects. I.E exceptions are sent as Java serialized and also a message is sent, so if the Java serialized object could be read instead of the exception message, this would solve several issues while parsing exceptions. Java (de)serialization is an [standard|https://docs.oracle.com/javase/8/docs/platform/serialization/spec/protocol.html] so and has not changed in a while, so adding this would require so little maintenance. -- 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 ] Owen Nichols updated GEODE-10009: - Fix Version/s: 1.16.0 > 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 > Fix For: 1.15.0, 1.16.0 > > > 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] [Created] (GEODE-10025) Change TcrMessage response parse
Mario Salazar de Torres created GEODE-10025: --- Summary: Change TcrMessage response parse Key: GEODE-10025 URL: https://issues.apache.org/jira/browse/GEODE-10025 Project: Geode Issue Type: Improvement Components: native client Reporter: Mario Salazar de Torres Currently, all implementations of TcrMessage are in the same file, and also, the response for any request is processed on the same place and under TcrMessageReply. I'd be ideal to split implementations on several files and also to try and parse response using some kind of factory instead of just a switch. This will dramatically improve code readability, hence will set the bases to identify several issues on message parsing. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10024) Improve protocol parsing by introducing Parts
Mario Salazar de Torres created GEODE-10024: --- Summary: Improve protocol parsing by introducing Parts Key: GEODE-10024 URL: https://issues.apache.org/jira/browse/GEODE-10024 Project: Geode Issue Type: Improvement Components: native client Reporter: Mario Salazar de Torres In order to limit serialization issues, and to make the message parsing code more readable, it would be good to have Parts introduced into the native client -- 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=17489160#comment-17489160
]
ASF subversion and git services commented on GEODE-10015:
-
Commit dde5dbafc7f8e4a830a431997a264709372151ac in geode's branch
refs/heads/support/1.15 from Jacob Barrett
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=dde5dba ]
GEODE-10015: Set java.rmi.server.hostname when SSL enabled. (#7350)
When SSL is enabled we set the java.rmi.server.hostname System Property
to force creation of endpoints bound to that address rather than the
default, which is the local IP address. When RMI clients make
connections for these endpoints they will use the correct hostname,
which should match the hostname in the SSL certificate.
(cherry picked from commit 1da903901bf4bb4d339d83a244051eaf58d8b690)
> 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
> Fix For: 1.15.0, 1.16.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] [Resolved] (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
]
Jacob Barrett resolved GEODE-10015.
---
Resolution: Fixed
> 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
> Fix For: 1.15.0, 1.16.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] [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
]
Jacob Barrett updated GEODE-10015:
--
Fix Version/s: 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
> Fix For: 1.15.0, 1.16.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-10023) Security and management classes have broken javadocs
Kirk Lund created GEODE-10023: - Summary: Security and management classes have broken javadocs Key: GEODE-10023 URL: https://issues.apache.org/jira/browse/GEODE-10023 Project: Geode Issue Type: Bug Components: management, security Reporter: Kirk Lund -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10023) Security and management classes have broken javadocs
[ https://issues.apache.org/jira/browse/GEODE-10023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10023: -- Labels: needsTriage (was: ) > Security and management classes have broken javadocs > > > Key: GEODE-10023 > URL: https://issues.apache.org/jira/browse/GEODE-10023 > Project: Geode > Issue Type: Bug > Components: management, security >Reporter: Kirk Lund >Priority: Major > Labels: needsTriage > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9980) Startup of Locator or Server should fail fast if geode.enableGlobalSerialFilter is enabled but fails configuration
[
https://issues.apache.org/jira/browse/GEODE-9980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17489096#comment-17489096
]
ASF subversion and git services commented on GEODE-9980:
Commit ce57e9fd2b8b644cadc469209e12e4fbd281e0d9 in geode's branch
refs/heads/develop from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=ce57e9f ]
GEODE-9980: Improve error handling of serial filters (#7299)
Improves the error handling of serial filter configuration and
filtering. The API throws a runtime exception wrapping any thrown
exceptions.
When geode.enableGlobalSerialFilter is FALSE:
* Startup succeeds without throwing any exceptions even if an older
version of Java throws "java.lang.ClassNotFoundException
sun.misc.ObjectInputFilter".
When geode.enableGlobalSerialFilter is TRUE:
* Startup fails by throwing an exception when configuration of serial
filter fails for any reason.
Renames ObjectInputFilter to avoid confusion with the Java interface of
the same name.
Fixes a bug found in ReflectiveFacadeGlobalSerialFilterTest which
resulted in configuring a non-mocked process-wide serial filter that
polluted the JVM for all later tests.
Fixes other minor details in LocatorLauncher, InternalDataSerializer
and various related tests.
> Startup of Locator or Server should fail fast if
> geode.enableGlobalSerialFilter is enabled but fails configuration
> --
>
> Key: GEODE-9980
> URL: https://issues.apache.org/jira/browse/GEODE-9980
> Project: Geode
> Issue Type: Bug
> Components: serialization
>Affects Versions: 1.15.0
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI, blocks-1.15.0, pull-request-available
>
> The following error conditions need better handling which includes handling
> of all errors consistently and cause the startup of a Locator or Server to
> fail if it's unable to honor the setting of
> {{-Dgeode.enableGlobalSerialFilter=true}} for any reason. Currently, if
> {{-Dgeode.enableGlobalSerialFilter=true}} is specified but Geode is unable to
> create a global serial filter, then it will will log a warning and continue
> running. A user may easily miss that log statement and believe that the JVM
> is running with a properly configured serialization filter.
> 1) The user is trying to secure the JVM very thoroughly and accidentally
> specifies both {{-Djdk.serialFilter}} and
> {{-Dgeode.enableGlobalSerialFilter}}.
> 2) The user runs some non-Geode code in the same JVM that invokes
> {{ObjectInputFilter.Config.setFilter(...)}} directly.
> 3) The user is using a version of Java 8 prior to 8u121 (the release that
> first added {{sun.misc.ObjectInputFilter}}) and specifies
> {{-Dgeode.enableGlobalSerialFilter=true}}. Also, the same behavior occurs if
> they do NOT specify enabling that property.
> 4) {{LocatorLauncher}} or {{ServerLauncher}} is started in a JVM that has
> already created at least one {{ObjectInputStream}} which will cause
> {{ObjectInputFilter.Config.setFilter(...)}} to fail.
> 5) {{LocatorLauncher}} or {{ServerLauncher}} is started in a Java 8 JVM that
> is not based on OpenJDK (ie {{sun.misc.ObjectInputFilter}} does not exist).
> 6) {{LocatorLauncher}} or {{ServerLauncher}} is started in an unforeseen
> environment that causes invocation of
> {{ObjectInputFilter.Config.setFilter(...)}} via Java Reflection to throw
> {{IllegalAccessException}}.
--
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
]
Jacob Barrett updated GEODE-10015:
--
Fix Version/s: 1.16.0
(was: 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
> Fix For: 1.16.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] [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
]
Jacob Barrett updated GEODE-10015:
--
Fix Version/s: 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
> Fix For: 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] [Resolved] (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 ] Barrett Oglesby resolved GEODE-10009. - Fix Version/s: 1.15.0 Resolution: Fixed > 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 > Fix For: 1.15.0 > > > 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] [Updated] (GEODE-10022) CacheClientProxy will omit exception stack trace when handling an exception
[
https://issues.apache.org/jira/browse/GEODE-10022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-10022:
---
Labels: needsTriage pull-request-available (was: needsTriage)
> CacheClientProxy will omit exception stack trace when handling an exception
> ---
>
> Key: GEODE-10022
> URL: https://issues.apache.org/jira/browse/GEODE-10022
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.14.3
>Reporter: Jinmei Liao
>Priority: Major
> Labels: needsTriage, pull-request-available
>
> line 807 in CacheClientProxy:
> {quote}
> } catch (Exception ex) {
> if (_cache.getSecurityLogger().warningEnabled()) {
> _cache.getSecurityLogger().warning(String.format("%s : %s", this, ex));
> }
> }
> {quote}
> this will cause the exception to not to be fully logged to see the cause of
> it.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-10022) CacheClientProxy will omit exception stack trace when handling an exception
Jinmei Liao created GEODE-10022:
---
Summary: CacheClientProxy will omit exception stack trace when
handling an exception
Key: GEODE-10022
URL: https://issues.apache.org/jira/browse/GEODE-10022
Project: Geode
Issue Type: Bug
Components: client/server
Affects Versions: 1.14.3
Reporter: Jinmei Liao
line 807 in CacheClientProxy:
{quote}
} catch (Exception ex) {
if (_cache.getSecurityLogger().warningEnabled()) {
_cache.getSecurityLogger().warning(String.format("%s : %s", this, ex));
}
}
{quote}
this will cause the exception to not to be fully logged to see the cause of it.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10022) CacheClientProxy will omit exception stack trace when handling an exception
[
https://issues.apache.org/jira/browse/GEODE-10022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10022:
--
Labels: needsTriage (was: )
> CacheClientProxy will omit exception stack trace when handling an exception
> ---
>
> Key: GEODE-10022
> URL: https://issues.apache.org/jira/browse/GEODE-10022
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.14.3
>Reporter: Jinmei Liao
>Priority: Major
> Labels: needsTriage
>
> line 807 in CacheClientProxy:
> {quote}
> } catch (Exception ex) {
> if (_cache.getSecurityLogger().warningEnabled()) {
> _cache.getSecurityLogger().warning(String.format("%s : %s", this, ex));
> }
> }
> {quote}
> this will cause the exception to not to be fully logged to see the cause of
> it.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (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:comment-tabpanel=17489032#comment-17489032 ] ASF subversion and git services commented on GEODE-10009: - Commit 05eba09d0f3881344b130dca226f5e8203d546d2 in geode's branch refs/heads/support/1.15 from Barry Oglesby [ https://gitbox.apache.org/repos/asf?p=geode.git;h=05eba09 ] GEODE-10009: Invoked internalClose with keepAlive true (#7332) (cherry picked from commit 551d7d78548f10218146b074df9b0c4adc0940f7) > 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] [Updated] (GEODE-9087) Fix the documentation for SCAN commands.
[ https://issues.apache.org/jira/browse/GEODE-9087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9087: - Component/s: docs > Fix the documentation for SCAN commands. > > > Key: GEODE-9087 > URL: https://issues.apache.org/jira/browse/GEODE-9087 > Project: Geode > Issue Type: Bug > Components: docs, redis >Reporter: Nabarun Nag >Assignee: Hale Bales >Priority: Major > Labels: blocks-1.14.0, pull-request-available > Fix For: 1.14.0, 1.15.0 > > > Fix documentation for SCAN command, especially the data types accepted by it. > -- 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: pull-request-available) > 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-10021) Clean up RemoteTrasactionDUnitTest
[ https://issues.apache.org/jira/browse/GEODE-10021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hale Bales reassigned GEODE-10021: -- Assignee: Hale Bales > Clean up RemoteTrasactionDUnitTest > -- > > Key: GEODE-10021 > URL: https://issues.apache.org/jira/browse/GEODE-10021 > Project: Geode > Issue Type: Improvement >Affects Versions: 1.16.0 >Reporter: Hale Bales >Assignee: Hale Bales >Priority: Major > > I have been working on GEODE-9929 and the failing DUnitTest has a lot of > errors. I want to clean up some of the errors where I can use find and > replace, as well as a couple of changes to make it easier for the next person > who works on GEODE-9929. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-1537) DurableRegistrationDUnitTest.testDurableClientWithRegistrationHA
[ https://issues.apache.org/jira/browse/GEODE-1537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-1537: - Labels: CI pull-request-available testing (was: CI pull-request-available) > DurableRegistrationDUnitTest.testDurableClientWithRegistrationHA > > > Key: GEODE-1537 > URL: https://issues.apache.org/jira/browse/GEODE-1537 > Project: Geode > Issue Type: Bug > Components: client queues >Reporter: Jinmei Liao >Assignee: Jens Deppe >Priority: Major > Labels: CI, pull-request-available, testing > Fix For: 1.15.0 > > > Geode_develop_DistributedTests/2883 > Error Message > com.gemstone.gemfire.test.dunit.RMIException: While invoking > com.gemstone.gemfire.internal.cache.tier.sockets.DurableRegistrationDUnitTest$$Lambda$373/449639279.run > in VM 1 running on Host timor.gemstone.com with 4 VMs > Stacktrace > com.gemstone.gemfire.test.dunit.RMIException: While invoking > com.gemstone.gemfire.internal.cache.tier.sockets.DurableRegistrationDUnitTest$$Lambda$373/449639279.run > in VM 1 running on Host timor.gemstone.com with 4 VMs > at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:389) > at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:355) > at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:293) > at > com.gemstone.gemfire.internal.cache.tier.sockets.DurableRegistrationDUnitTest.testDurableClientWithRegistrationHA(DurableRegistrationDUnitTest.java:421) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at > org.junit.internal.runners.statements.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:55) > at org.junit.rules.RunRules.evaluate(RunRules.java:20) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:112) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66) > at > org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51) > at sun.reflect.GeneratedMethodAccessor426.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at > org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35) > at > org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24) > at > org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32) > at > org.gradle.messaging.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93) > at com.sun.proxy.$Proxy2.processTestClass(Unknown Source) > at > org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109) > at sun.reflect.GeneratedMethodAccessor425.invoke(Unknown Source) > at >
[jira] [Updated] (GEODE-6143) PowerMock should not be used in Geode tests [PERMANENT]
[
https://issues.apache.org/jira/browse/GEODE-6143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-6143:
-
Issue Type: Task (was: Bug)
> PowerMock should not be used in Geode tests [PERMANENT]
> ---
>
> Key: GEODE-6143
> URL: https://issues.apache.org/jira/browse/GEODE-6143
> Project: Geode
> Issue Type: Task
> Components: build, tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
> Fix For: 1.15.0
>
> Time Spent: 13h 10m
> Remaining Estimate: 0h
>
> At least one usage of PowerMock in our unit tests is leaking and causing
> other tests to fail with the following stack.
> No further tests should be written using PowerMock and all tests that
> currently use it need to be identified and changed (along with product code
> refactoring) to not use PowerMock.
> We will then remove PowerMock as a dependency from Geode.
> {noformat}
> 2018-12-04 18:11:36,258 Distributed system shutdown hook ERROR Could not
> reconfigure JMX java.lang.LinkageError: loader constraint violation: loader
> (instance of org/powermock/core/classloader/MockClassLoader) previously
> initiated loading for a different type with name
> "javax/management/MBeanServer"
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
> at
> org.powermock.core.classloader.MockClassLoader.loadUnmockedClass(MockClassLoader.java:262)
> at
> org.powermock.core.classloader.MockClassLoader.loadModifiedClass(MockClassLoader.java:206)
> at
> org.powermock.core.classloader.DeferSupportingClassLoader.loadClass1(DeferSupportingClassLoader.java:89)
> at
> org.powermock.core.classloader.DeferSupportingClassLoader.loadClass(DeferSupportingClassLoader.java:79)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at
> org.apache.logging.log4j.core.jmx.Server.unregisterAllMatching(Server.java:337)
> at
> org.apache.logging.log4j.core.jmx.Server.unregisterLoggerContext(Server.java:261)
> at
> org.apache.logging.log4j.core.jmx.Server.reregisterMBeansAfterReconfigure(Server.java:165)
> at
> org.apache.logging.log4j.core.jmx.Server.reregisterMBeansAfterReconfigure(Server.java:141)
> at
> org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:558)
> at
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:619)
> at
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:636)
> at
> org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:231)
> at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:243)
> at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45)
> at org.apache.logging.log4j.LogManager.getContext(LogManager.java:174)
> at org.apache.logging.log4j.LogManager.getLogger(LogManager.java:661)
> at
> org.apache.geode.internal.logging.LogService.getLogger(LogService.java:64)
> at
> org.apache.geode.internal.tcp.ConnectionTable.(ConnectionTable.java:61)
> at
> org.apache.geode.distributed.DistributedSystem.setThreadsSocketPolicy(DistributedSystem.java:263)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.lambda$static$0(InternalDistributedSystem.java:2317)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-8192) Redis MSET command needs to be atomic
[ https://issues.apache.org/jira/browse/GEODE-8192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-8192: - Labels: pull-request-available unreleased (was: pull-request-available) > Redis MSET command needs to be atomic > - > > Key: GEODE-8192 > URL: https://issues.apache.org/jira/browse/GEODE-8192 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Darrel Schneider >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available, unreleased > Fix For: 1.15.0 > > > All of the supported and unsupported redis string commands (for the 1.14 > release) that need to be atomic now are except for MSET. > Note that MGET does not need to be atomic. > To make MSET atomic it could do something like RENAME does to lock multiple > keys in a manner that prevent a distributed deadlock. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-8097) ClientClusterManagementServiceTest expects 1 callback but gets 295
[
https://issues.apache.org/jira/browse/GEODE-8097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-8097:
-
Labels: GeodeOperationAPI blocks-1.14.0 pull-request-available testing
(was: GeodeOperationAPI blocks-1.14.0 pull-request-available)
> ClientClusterManagementServiceTest expects 1 callback but gets 295
> --
>
> Key: GEODE-8097
> URL: https://issues.apache.org/jira/browse/GEODE-8097
> Project: Geode
> Issue Type: Bug
> Components: management
>Reporter: Bill Burcham
>Assignee: Jinmei Liao
>Priority: Major
> Labels: GeodeOperationAPI, blocks-1.14.0,
> pull-request-available, testing
> Fix For: 1.14.0, 1.15.0
>
>
> CI test failed here:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsUnitTestOpenJDK8/builds/138#A
> {code}
> org.apache.geode.management.internal.ClientClusterManagementServiceTest >
> getOperationCallsSubmitMessageAndReturnsFuture FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.management.internal.ClientClusterManagementServiceTest
> clusterManagementServiceTransport.submitMessageForGetOperation(
>
> same(org.apache.geode.management.operation.RebalanceOperation@6d6b2db0),
> same("opId")
> );
> Wanted 1 time:
> -> at
> org.apache.geode.management.internal.ClientClusterManagementServiceTest.lambda$getOperationCallsSubmitMessageAndReturnsFuture$1(ClientClusterManagementServiceTest.java:170)
> But was 295 times:
> -> at
> org.apache.geode.management.internal.ClientClusterManagementService.get(ClientClusterManagementService.java:114)
> -> at
> org.apache.geode.management.internal.ClientClusterManagementService.get(ClientClusterManagementService.java:114)
> -> at
> org.apache.geode.management.internal.ClientClusterManagementService.get(ClientClusterManagementService.java:114)
> …
> {code}
> Ran it 100 times in IntelliJ with no failures.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-8528) PutAllClientServerDistributedTest.testPartialKeyInPRSingleHop fails due to missing disk store after server restart
[ https://issues.apache.org/jira/browse/GEODE-8528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-8528: - Labels: GeodeOperationAPI testing (was: GeodeOperationAPI) > PutAllClientServerDistributedTest.testPartialKeyInPRSingleHop fails due to > missing disk store after server restart > -- > > Key: GEODE-8528 > URL: https://issues.apache.org/jira/browse/GEODE-8528 > Project: Geode > Issue Type: Bug > Components: tests >Affects Versions: 1.12.0 >Reporter: Benjamin P Ross >Assignee: Kirk Lund >Priority: Major > Labels: GeodeOperationAPI, testing > Fix For: 1.15.0 > > > org.apache.geode.internal.cache.PutAllClientServerDistributedTest > > testPartialKeyInPRSingleHop FAILED > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.internal.cache.PutAllClientServerDistributedTest$$Lambda$313/839097690.call > in VM 1 running on Host 3e9ce4ee92bd with 4 VMs > at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610) > at org.apache.geode.test.dunit.VM.invoke(VM.java:462) > at > org.apache.geode.internal.cache.PutAllClientServerDistributedTest.testPartialKeyInPRSingleHop(PutAllClientServerDistributedTest.java:1894) > Caused by: > java.lang.IllegalStateException: Disk store ds1 not found > at > org.apache.geode.internal.cache.LocalRegion.findDiskStore(LocalRegion.java:7480) > at > org.apache.geode.internal.cache.PartitionedRegion.findDiskStore(PartitionedRegion.java:9203) > at > org.apache.geode.internal.cache.LocalRegion.(LocalRegion.java:602) > at > org.apache.geode.internal.cache.LocalRegion.(LocalRegion.java:546) > at > org.apache.geode.internal.cache.PartitionedRegion.(PartitionedRegion.java:760) > at > org.apache.geode.internal.cache.GemFireCacheImpl.createVMRegion(GemFireCacheImpl.java:2925) > at > org.apache.geode.internal.cache.GemFireCacheImpl.basicCreateRegion(GemFireCacheImpl.java:2869) > at > org.apache.geode.internal.cache.GemFireCacheImpl.createRegion(GemFireCacheImpl.java:2853) > at > org.apache.geode.cache.RegionFactory.create(RegionFactory.java:768) > at > org.apache.geode.internal.cache.PutAllClientServerDistributedTest.createServer(PutAllClientServerDistributedTest.java:2797) > at > org.apache.geode.internal.cache.PutAllClientServerDistributedTest.lambda$testPartialKeyInPRSingleHop$515fd116$1(PutAllClientServerDistributedTest.java:1894) > Halfway through the test we shutdown Server2 and restart it, but upon > attempting to start the server with the same disk store name we used original > we get missing disk store errors. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-8616) ClientServerCacheOperationDUnitTest > largeObjectPutWithReadTimeoutThrowsException fails with ServerConnectivityException : Pool unexpected socket timed out on client
[
https://issues.apache.org/jira/browse/GEODE-8616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-8616:
-
Labels: GeodeOperationAPI flaky-test pull-request-available testing (was:
GeodeOperationAPI flaky-test pull-request-available)
> ClientServerCacheOperationDUnitTest >
> largeObjectPutWithReadTimeoutThrowsException fails with
> ServerConnectivityException : Pool unexpected socket timed out on client
> --
>
> Key: GEODE-8616
> URL: https://issues.apache.org/jira/browse/GEODE-8616
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.12.1, 1.13.7, 1.14.3, 1.15.0
>Reporter: Donal Evans
>Assignee: Nabarun Nag
>Priority: Major
> Labels: GeodeOperationAPI, flaky-test, pull-request-available,
> testing
> Fix For: 1.15.0, 1.16.0
>
> Attachments: hansonm-findfailures-11-10-2021-23-52-38-logs.tgz,
> hansonm-findfailures-11-10-2021-23-52-45-logs.tgz
>
>
> {noformat}
> > Task :geode-core:distributedTest
> org.apache.geode.cache30.ClientServerCacheOperationDUnitTest >
> largeObjectPutWithReadTimeoutThrowsException FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache30.ClientServerCacheOperationDUnitTest$$Lambda$177/0x000100b52040.run
> in VM 2 running on Host c1346ab7b3e3 with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
> at
> org.apache.geode.cache30.ClientServerCacheOperationDUnitTest.largeObjectPutWithReadTimeoutThrowsException(ClientServerCacheOperationDUnitTest.java:117)
> Caused by:
> org.apache.geode.cache.client.ServerConnectivityException: Pool
> unexpected socket timed out on client connection=Pooled Connection to
> c1346ab7b3e3:35437: Connection[DESTROYED]). Server unreachable: could not
> connect after 1 attempts
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:659)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:501)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:153)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:108)
> at
> org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:774)
> at
> org.apache.geode.cache.client.internal.GetOp.execute(GetOp.java:91)
> at
> org.apache.geode.cache.client.internal.ServerRegionProxy.get(ServerRegionProxy.java:116)
> at
> org.apache.geode.internal.cache.LocalRegion.findObjectInSystem(LocalRegion.java:2795)
> at
> org.apache.geode.internal.cache.LocalRegion.getObject(LocalRegion.java:1472)
> at
> org.apache.geode.internal.cache.LocalRegion.nonTxnFindObject(LocalRegion.java:1445)
> at
> org.apache.geode.internal.cache.LocalRegionDataView.findObject(LocalRegionDataView.java:196)
> at
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1382)
> at
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1321)
> at
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1306)
> at
> org.apache.geode.internal.cache.AbstractRegion.get(AbstractRegion.java:436)
> at
> org.apache.geode.cache30.ClientServerCacheOperationDUnitTest.lambda$largeObjectPutWithReadTimeoutThrowsException$3ab01cf6$2(ClientServerCacheOperationDUnitTest.java:120)
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.1-build.0106/test-results/distributedTest/1601514101/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.1-build.0106/test-artifacts/1601514101/distributedtestfiles-OpenJDK11-1.12.1-build.0106.tgz
> This is a flaky failure.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-8859) Redis data structures may not accurately reflect their size in Geode stats
[
https://issues.apache.org/jira/browse/GEODE-8859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-8859:
-
Labels: pull-request-available unreleased (was: pull-request-available)
> Redis data structures may not accurately reflect their size in Geode stats
> --
>
> Key: GEODE-8859
> URL: https://issues.apache.org/jira/browse/GEODE-8859
> Project: Geode
> Issue Type: Bug
> Components: redis, statistics
>Affects Versions: 1.14.0
>Reporter: Jens Deppe
>Assignee: Hale Bales
>Priority: Major
> Labels: pull-request-available, unreleased
> Fix For: 1.15.0
>
>
> Here is a comment from Darrel regarding this issue. For some background, the
> Redis structures implement {{Delta}}.
>
> {quote}I was playing around with RedisInsight and was able to get most the
> the overview dashboard and the data browser working with geode redis. But I
> found a problem with how we are using geode that causes the geode stats that
> track how much data is stored in a partitioned region to be wrong and the
> bucket sizes used for rebalancing are also wrong. Basically when we do create
> ops on the region the stats track it okay. But when we do updates then geode
> always thinks that nothing (size wise) changed. So for example I created a
> string by doing a redis “set” command. I saw the size of the string accounted
> for in dataStoreBytesInUse. But then I kept doing redis “append” commands on
> that key and the dataStoreBytesInUse did not change at all. I think the
> problem is in how we are updating the data structure in place instead of
> getting a copy, modifying it, and then putting the copy into the region.
> Avoiding this copy gives us MUCH better performance but it messes up geode
> when it is trying to calculate the memory increase or decrease. It is
> possible that this is only an issue on the primary and that the secondary
> sizing may be correct. If so that could lead to other problems because for a
> given bucket our primary size would be different than the secondary. The
> bucket sizes are used when you do a rebalance but basically we can have a
> bunch of memory that is “untracked” so we might see the JVM heaps unbalanced
> but geode will think the buckets are balanced. I’m not sure what we should do
> about this.
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-8644) SerialGatewaySenderQueueDUnitTest.unprocessedTokensMapShouldDrainCompletely() intermittently fails when queues drain too slowly
[ https://issues.apache.org/jira/browse/GEODE-8644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-8644: - Labels: GeodeOperationAPI pull-request-available testing (was: GeodeOperationAPI pull-request-available test) > SerialGatewaySenderQueueDUnitTest.unprocessedTokensMapShouldDrainCompletely() > intermittently fails when queues drain too slowly > --- > > Key: GEODE-8644 > URL: https://issues.apache.org/jira/browse/GEODE-8644 > Project: Geode > Issue Type: Bug >Affects Versions: 1.15.0 >Reporter: Benjamin P Ross >Assignee: Xiaojian Zhou >Priority: Major > Labels: GeodeOperationAPI, pull-request-available, testing > Fix For: 1.15.0 > > > Currently the test > SerialGatewaySenderQueueDUnitTest.unprocessedTokensMapShouldDrainCompletely() > relies on a 2 second delay to allow for queues to finish draining after > finishing the put operation. If queues take longer than 2 seconds to drain > the test will fail. We should change the test to wait for the queues to be > empty with a long timeout in case the queues never fully drain. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-8644) SerialGatewaySenderQueueDUnitTest.unprocessedTokensMapShouldDrainCompletely() intermittently fails when queues drain too slowly
[ https://issues.apache.org/jira/browse/GEODE-8644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-8644: - Labels: GeodeOperationAPI pull-request-available test (was: GeodeOperationAPI pull-request-available) > SerialGatewaySenderQueueDUnitTest.unprocessedTokensMapShouldDrainCompletely() > intermittently fails when queues drain too slowly > --- > > Key: GEODE-8644 > URL: https://issues.apache.org/jira/browse/GEODE-8644 > Project: Geode > Issue Type: Bug >Affects Versions: 1.15.0 >Reporter: Benjamin P Ross >Assignee: Xiaojian Zhou >Priority: Major > Labels: GeodeOperationAPI, pull-request-available, test > Fix For: 1.15.0 > > > Currently the test > SerialGatewaySenderQueueDUnitTest.unprocessedTokensMapShouldDrainCompletely() > relies on a 2 second delay to allow for queues to finish draining after > finishing the put operation. If queues take longer than 2 seconds to drain > the test will fail. We should change the test to wait for the queues to be > empty with a long timeout in case the queues never fully drain. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-8945) deploy pipelines for new support branch should not create mass test run pipeline
[ https://issues.apache.org/jira/browse/GEODE-8945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-8945: - Issue Type: Task (was: Bug) > deploy pipelines for new support branch should not create mass test run > pipeline > > > Key: GEODE-8945 > URL: https://issues.apache.org/jira/browse/GEODE-8945 > Project: Geode > Issue Type: Task > Components: release >Affects Versions: 1.14.0 >Reporter: Owen Nichols >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0, 1.15.0 > > > only develop needs mass test enabled -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-8950) Benchmark failure - P2pPartitionedPutLongBenchmark
[ https://issues.apache.org/jira/browse/GEODE-8950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-8950: - Labels: testing (was: ) > Benchmark failure - P2pPartitionedPutLongBenchmark > -- > > Key: GEODE-8950 > URL: https://issues.apache.org/jira/browse/GEODE-8950 > Project: Geode > Issue Type: Bug > Components: benchmarks >Affects Versions: 1.15.0 >Reporter: Donal Evans >Assignee: Donal Evans >Priority: Major > Labels: testing > Fix For: 1.14.0, 1.15.0 > > Attachments: GEODE-8950-before-after-histogram-chart.png, > GEODE-8950-performance degradation vs 1.13.png > > > Multiple benchmark failures due to P2pPartitionedPutLongBenchmark have been > seen recently. > This run saw 3 out of the 5 repeats fail due to flagged degradations in > P2pPartitionedPutLongBenchmark: > [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark_base/builds/16|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark_base/builds/16#L601ed52d:5552] > This run saw 1 out of the 5 repeats fail due to flagged degradations in > P2pPartitionedPutLongBenchmark: > [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark_base/builds/20] > This run saw 4 out of the 5 repeats fail due to flagged degradations in > P2pPartitionedPutLongBenchmark: > [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark_base/builds/27] > In all the above benchmarks, the other failed runs were due to EOFExceptions > rather than flagged degradations. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9019) Convert all redis data structures to DataSerializableFixedID
[ https://issues.apache.org/jira/browse/GEODE-9019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9019: - Labels: blocks-1.14.0 pull-request-available unreleased (was: blocks-1.14.0 pull-request-available) > Convert all redis data structures to DataSerializableFixedID > > > Key: GEODE-9019 > URL: https://issues.apache.org/jira/browse/GEODE-9019 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Nabarun Nag >Assignee: Nabarun Nag >Priority: Major > Labels: blocks-1.14.0, pull-request-available, unreleased > Fix For: 1.14.0, 1.15.0 > > > Issue: > * Currently, a couple of redis data structures are using DataSerializable > * This will cause issues during rolling upgrade > Solution: > * Convert these data structures to DataSerializableFixedIDs. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9006) MemoryStatsNativeRedisAcceptanceTest CI failure
[
https://issues.apache.org/jira/browse/GEODE-9006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-9006:
-
Labels: pull-request-available testing (was: pull-request-available)
> MemoryStatsNativeRedisAcceptanceTest CI failure
> ---
>
> Key: GEODE-9006
> URL: https://issues.apache.org/jira/browse/GEODE-9006
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.14.0, 1.15.0
>Reporter: Ray Ingles
>Assignee: Donal Evans
>Priority: Major
> Labels: pull-request-available, testing
> Fix For: 1.14.0, 1.15.0
>
>
> CI failure:
> {{org.apache.geode.redis.internal.executor.server.MemoryStatsNativeRedisAcceptanceTest
> > usedMemory_shouldReflectActualMemoryUsage FAILED
> java.lang.AssertionError:
> Expecting:
> 854912L
> to be greater than:
> 855176L}}
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/AcceptanceTestOpenJDK11/builds/51]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9084) Remove Redis GFSH command
[ https://issues.apache.org/jira/browse/GEODE-9084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9084: - Labels: blocks-1.14.0 pull-request-available unreleased (was: blocks-1.14.0 pull-request-available) > Remove Redis GFSH command > - > > Key: GEODE-9084 > URL: https://issues.apache.org/jira/browse/GEODE-9084 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Nabarun Nag >Assignee: Nabarun Nag >Priority: Major > Labels: blocks-1.14.0, pull-request-available, unreleased > Fix For: 1.14.0, 1.15.0 > > > Things have changed since we first introduced the concept of Unsupported vs > Unimplemented. > _Original Idea:_ Allow users to use the unsupported commands, log which one's > were being used. Use this information to help drive future iterations. > Given: > * new direction of the product (Tanzu Cache) > * Safety for customers not to get into a bad situation > * Confusion for support, our team, the field > We should remove the ability to use the unsupported commands unless the > system property 'enable-unsupported-commands' is set. > > End result: > * The 'redis' gfsh command is no longer present > * Remove the documentation -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9050) Redis test fails with Netty 4.1.60 and later
[
https://issues.apache.org/jira/browse/GEODE-9050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-9050:
-
Labels: pull-request-available unreleased (was: pull-request-available)
> Redis test fails with Netty 4.1.60 and later
>
>
> Key: GEODE-9050
> URL: https://issues.apache.org/jira/browse/GEODE-9050
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.14.0, 1.15.0
>Reporter: Owen Nichols
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available, unreleased
> Fix For: 1.15.0
>
>
> {{PubSubIntegrationTest > ensureOrderingOfPublishedMessages}}
> [fails|http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-6153/test-results/integrationTest/1616031328/index.html]
> reliably, on both Linux and Windows, if I [bump
> Netty|https://github.com/apache/geode/pull/6153/commits/03b81f93b011377a5021a4b87acecacfa02b93a4]
> from 4.1.59.Final to 4.1.60.Final. It's important to keep up to date with
> latest versions of our 3rd-party dependencies but breaking this out
> separately so someone with redis knowledge can tackle it.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9046) Refactor references to the subclass from superclasses in geode-redis
[ https://issues.apache.org/jira/browse/GEODE-9046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9046: - Labels: pull-request-available unreleased (was: pull-request-available) > Refactor references to the subclass from superclasses in geode-redis > > > Key: GEODE-9046 > URL: https://issues.apache.org/jira/browse/GEODE-9046 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Nabarun Nag >Priority: Major > Labels: pull-request-available, unreleased > Fix For: 1.14.0, 1.15.0 > > > Currently, in geode-redis > * NullRedisString is referenced from RedisString > * NullRedisHash is referenced from RedisHash > * NullRedisSet is referenced from RedisSet > These Null redis data structures need to be moved to a separate class to > avoid the superclass referencing subclasses. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9086) Documentation for DECRBY command
[ https://issues.apache.org/jira/browse/GEODE-9086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9086: - Component/s: docs > Documentation for DECRBY command > > > Key: GEODE-9086 > URL: https://issues.apache.org/jira/browse/GEODE-9086 > Project: Geode > Issue Type: Bug > Components: docs, redis >Reporter: Nabarun Nag >Assignee: Hale Bales >Priority: Major > Labels: blocks-1.14.0, pull-request-available > Fix For: 1.14.0, 1.15.0 > > > Ensure that there is sufficient documentation for the DECRBY command in the > compatible with redis module. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9062) DataSerializableJUnitTest fails in StressTest task
[
https://issues.apache.org/jira/browse/GEODE-9062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-9062:
-
Labels: pull-request-available testing (was: pull-request-available)
> DataSerializableJUnitTest fails in StressTest task
> --
>
> Key: GEODE-9062
> URL: https://issues.apache.org/jira/browse/GEODE-9062
> Project: Geode
> Issue Type: Bug
>Reporter: Alberto Bustamante Reyes
>Assignee: Alberto Bustamante Reyes
>Priority: Major
> Labels: pull-request-available, testing
> Fix For: 1.15.0
>
>
> DataSerializableJUnitTest is failing if executed using the "repeatUnitTest"
> gradle task. I dont know what is causing this failure, but I got the error
> when verifying a PR ( [https://concourse.apachegeode-ci.info/builds/17155] )
> and I realized it is failing in develop branch too.
> {code}
> ~/git/apache/geode (develop) $ ./gradlew geode-core:repeatUnitTest
> --tests=DataSerializableJUnitTest
> ...
> org.apache.geode.internal.DataSerializableJUnitTest > testUDDS2 FAILED
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:87)
> at org.junit.Assert.assertTrue(Assert.java:42)
> at org.junit.Assert.assertFalse(Assert.java:65)
> at org.junit.Assert.assertFalse(Assert.java:75)
> at
> org.apache.geode.internal.DataSerializableJUnitTest.testUDDS2(DataSerializableJUnitTest.java:2284)
> org.apache.geode.internal.DataSerializableJUnitTest > testUDDS4 FAILED
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:87)
> at org.junit.Assert.assertTrue(Assert.java:42)
> at org.junit.Assert.assertFalse(Assert.java:65)
> at org.junit.Assert.assertFalse(Assert.java:75)
> at
> org.apache.geode.internal.DataSerializableJUnitTest.testUDDS4(DataSerializableJUnitTest.java:2307)
> org.apache.geode.internal.DataSerializableJUnitTest > testSupportedClasses
> FAILED
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:87)
> at org.junit.Assert.assertTrue(Assert.java:42)
> at org.junit.Assert.assertFalse(Assert.java:65)
> at org.junit.Assert.assertFalse(Assert.java:75)
> at
> org.apache.geode.internal.DataSerializableJUnitTest.testSupportedClasses(DataSerializableJUnitTest.java:2260)
> 11100 tests completed, 297 failed, 200 skipped
> > Task :geode-core:repeatUnitTest FAILED
> > Task :combineReports
> All test reports at /home/alb3rtobr/git/apache/geode/build/reports/combined
> FAILURE: Build failed with an exception.
> * What went wrong:
> Execution failed for task ':geode-core:repeatUnitTest'.
> > There were failing tests. See the report at:
> > file:///home/alb3rtobr/git/apache/geode/geode-core/build/reports/repeatUnitTest/index.html
> * Try:
> Run with --stacktrace option to get the stack trace. Run with --info or
> --debug option to get more log output. Run with --scan to get full insights.
> * Get more help at https://help.gradle.org
> BUILD FAILED in 1m 8s
> 36 actionable tasks: 2 executed, 34 up-to-date
> ~/git/apache/geode (develop) $ git log -n 1
> commit a45dbf94de2f35b869a3dd0e1cf945f5282e2fd0 (HEAD -> develop,
> origin/develop, origin/HEAD)
> Author: Mario Kevo <48509719+mk...@users.noreply.github.com>
> Date: Wed Mar 24 10:25:29 2021 +0100
> GEODE-8962: add an option to escape dollar($) character in the query (#6044)
>
> * GEODE-8962: add an option to escape dollar($) character in the query
> {code}
> Three tests are failing: testSupportedClasses, testUDDS2 and testUDDS4.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9153) alpine-tools image fails to build
[ https://issues.apache.org/jira/browse/GEODE-9153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9153: - Issue Type: Task (was: Bug) > alpine-tools image fails to build > - > > Key: GEODE-9153 > URL: https://issues.apache.org/jira/browse/GEODE-9153 > Project: Geode > Issue Type: Task > Components: ci >Reporter: Sean Goller >Assignee: Sean Goller >Priority: Major > Labels: pull-request-available > Fix For: 1.12.2, 1.13.3, 1.14.0, 1.15.0 > > > The alpine-tools docker image fails to build properly. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9192) test-container docker image is unstable due to dependencies
[ https://issues.apache.org/jira/browse/GEODE-9192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9192: - Issue Type: Task (was: Bug) > test-container docker image is unstable due to dependencies > --- > > Key: GEODE-9192 > URL: https://issues.apache.org/jira/browse/GEODE-9192 > Project: Geode > Issue Type: Task > Components: ci >Affects Versions: 1.12.2, 1.13.2 >Reporter: Sean Goller >Assignee: Sean Goller >Priority: Major > Labels: pull-request-available > Fix For: 1.12.3, 1.13.3, 1.14.0, 1.15.0 > > > buildpack-scm, a docker image that our test container relies on, has become > unstable. This has caused problems for mass-test. Replace the base image with > ubuntu. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9287) Eliminate use of platform dependent String.getBytes() and new String(bytes) calls in redis
[ https://issues.apache.org/jira/browse/GEODE-9287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9287: - Labels: pull-request-available unreleased (was: pull-request-available) > Eliminate use of platform dependent String.getBytes() and new String(bytes) > calls in redis > --- > > Key: GEODE-9287 > URL: https://issues.apache.org/jira/browse/GEODE-9287 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Dan Smith >Assignee: Donal Evans >Priority: Major > Labels: pull-request-available, unreleased > Fix For: 1.15.0 > > > We have a number of places that call either String.getBytes() or new > String(bytes) in the redis module. > These methods may produce different output depending on the underlying > platforms default encoding. > We should switch these places to call use our standard Coder.stringToBytes > and bytesToString methods. Those methods should use UTF-8 encoding, eg > String.getBytes(StandardCharsets.UTF-8). > We should eliminate conversions between bytes and strings as much as possible > on critical path code. In particular, our parser should have constants for > the byte[] values of all of the static strings in the commands. > We may want to consider encoding error responses as ASCII, rather than UTF-8, > for more compatibility with different clients if an error message > accidentally contains a non-ascii character. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9208) StressNewTest doesn't pick up tests from all directories
[
https://issues.apache.org/jira/browse/GEODE-9208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-9208:
-
Issue Type: Task (was: Bug)
> StressNewTest doesn't pick up tests from all directories
>
>
> Key: GEODE-9208
> URL: https://issues.apache.org/jira/browse/GEODE-9208
> Project: Geode
> Issue Type: Task
> Components: build, ci, tests
>Affects Versions: 1.15.0
>Reporter: Sarah Abbey
>Assignee: Sarah Abbey
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
>
> When detecting which tests to run for StressNewTest, we use paths like the
> following:
> {code:java}
> '*/src/distributedTest/java'
> {code}
> This will pick up a file like this one:
> {code:java}
>
> geode-assembly/src/distributedTest/java/org/apache/geode/session/tests/Jetty9CachingClientServerTest.java
> {code}
> But won't pick up this file since the `src` dir here is more than one
> directory deep:
> {code:java}
> extensions/geode-modules/src/distributedTest/java/org/apache/geode/modules/util/ClientServerSessionCacheDUnitTest.java
>
> {code}
> We can use git's pathspec `:glob` keyword described
> [here|https://git-scm.com/docs/gitglossary] to pick up any number of
> directories preceding our desired path:
> {code:java}
> ':(glob)**/src/distributedTest/java/**'
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9218) Geode has tests for TLSv1.1 which is disabled by default now
[ https://issues.apache.org/jira/browse/GEODE-9218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9218: - Labels: pull-request-available testing (was: pull-request-available) > Geode has tests for TLSv1.1 which is disabled by default now > > > Key: GEODE-9218 > URL: https://issues.apache.org/jira/browse/GEODE-9218 > Project: Geode > Issue Type: Bug > Components: security >Affects Versions: 1.12.3, 1.13.3, 1.14.0, 1.15.0 >Reporter: Sean Goller >Assignee: Sean Goller >Priority: Major > Labels: pull-request-available, testing > Fix For: 1.12.3, 1.13.3, 1.14.0, 1.15.0 > > > According to the [Oracle JRE/JDK cryptographic > roadmap|https://java.com/en/jre-jdk-cryptoroadmap.html#releasedChangesTable], > TLSv1 and TLSv1.1 are disabled by default as of 11.0.11+9 and 8u291b10. This > causes TLSv1.1 tests to fail. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9304) Make RedisSortedSet's measurement of byes in use more accurate
[ https://issues.apache.org/jira/browse/GEODE-9304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9304: - Labels: pull-request-available unreleased (was: pull-request-available) > Make RedisSortedSet's measurement of byes in use more accurate > -- > > Key: GEODE-9304 > URL: https://issues.apache.org/jira/browse/GEODE-9304 > Project: Geode > Issue Type: Bug > Components: redis >Affects Versions: 1.15.0 >Reporter: Ray Ingles >Assignee: Donal Evans >Priority: Major > Labels: pull-request-available, unreleased > Fix For: 1.15.0 > > > The current calculation of bytes in use by RedisSortedSet is inaccurate, and > needs to be improved. Once a strategy for size calculation for classes using > Object2ObjectCustomHash and OrderStatisticsTree has been decided, it should > be implemented for this data type. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9311) It is possible that JedisCluster client may still retry if the Geode Redis server it is connected to shuts down
[ https://issues.apache.org/jira/browse/GEODE-9311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9311: - Labels: unreleased (was: ) > It is possible that JedisCluster client may still retry if the Geode Redis > server it is connected to shuts down > --- > > Key: GEODE-9311 > URL: https://issues.apache.org/jira/browse/GEODE-9311 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Eric Shu >Priority: Major > Labels: unreleased > Fix For: 1.15.0 > > > Even after the issue (GEODE-9310) is addressed, the retry issue may still > occur if the JedisCluster client is connected to the node is being shut down. > Here is a test run result: > vm2 gets the command: > [vm2] [warn 2021/05/25 16:01:41.479 PDT server-2 > tid=0x64] Executing Redis command: ZREM key member1-212 member1-211 > member1-214 member1-213 member1-210 member1-209 member1-208 member1-205 > member1-204 > *** command is executed on the primary *** > [vm2] [warn 2021/05/25 16:01:41.503 PDT server-2 Processor2> tid=0x51] bucket region is > BucketRegion[path='/__PR/_B__REDIS__DATA_123;serial=200;primary=true] key key > [vm2] java.lang.Exception > [vm2] at > org.apache.geode.internal.cache.BucketRegion.virtualPut(BucketRegion.java:533) > [vm2] at > org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5586) > [vm2] at > org.apache.geode.internal.cache.PartitionedRegionDataStore.putLocally(PartitionedRegionDataStore.java:1213) > [vm2] at > org.apache.geode.internal.cache.PartitionedRegion.putInBucket(PartitionedRegion.java:3024) > [vm2] at > org.apache.geode.internal.cache.PartitionedRegion.virtualPut(PartitionedRegion.java:2236) > [vm2] at > org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5586) > And distributed to replica (vm1): > vm1] [warn 2021/05/25 16:01:41.518 PDT server-1 192.168.0.14(server-2:83136):41002 shared ordered sender uid=7 local > port=58643 remote port=53459> tid=0x59] membersRemoveAll invoked > [vm1] java.lang.Exception > [vm1] at > org.apache.geode.redis.internal.data.RedisSortedSet.membersRemoveAll(RedisSortedSet.java:175) > [vm1] at > org.apache.geode.redis.internal.data.RedisSortedSet.applyDelta(RedisSortedSet.java:89) > [vm1] at > org.apache.geode.redis.internal.data.AbstractRedisData.fromDelta(AbstractRedisData.java:193) > [vm1] at > org.apache.geode.internal.cache.EntryEventImpl.processDeltaBytes(EntryEventImpl.java:1841) > [vm1] at > org.apache.geode.internal.cache.EntryEventImpl.setNewValueInRegion(EntryEventImpl.java:1696) > [vm1] at > org.apache.geode.internal.cache.EntryEventImpl.putExistingEntry(EntryEventImpl.java:1643) > [vm1] at > org.apache.geode.internal.cache.map.RegionMapPut.updateEntry(RegionMapPut.java:485) > [vm1] at > org.apache.geode.internal.cache.map.RegionMapPut.createOrUpdateEntry(RegionMapPut.java:256) > vm2 is bounced: > [vm2] [info 2021/05/25 16:01:41.526 PDT server-2 Connection(1)-192.168.0.14> tid=0x14] Got result: 83136 > [vm2] from org.apache.geode.test.dunit.VM$$Lambda$370/1141741369.call with 0 > args on object: > org.apache.geode.test.dunit.VM$$Lambda$370/1141741369@68ecd55a (took 0 ms) > [info 2021/05/25 16:01:41.527 PDT tid=0x36] Bouncing 2 old > pid is 83136 and version is 10240.0.0 > The JedisCluster client did not get response back (possibly detects > connection is gone), and it does retry again, as the test failed with > following: > java.util.concurrent.ExecutionException: > redis.clients.jedis.exceptions.JedisClusterMaxAttemptsException: No more > cluster attempts left. > at java.util.concurrent.FutureTask.report(FutureTask.java:122) > at java.util.concurrent.FutureTask.get(FutureTask.java:192) > at > org.apache.geode.redis.internal.executor.sortedset.ZRemDUnitTest.zRemCanRemoveMembersFromSortedSetDuringPrimaryIsCrashed(ZRemDUnitTest.java:177) > 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 >
[jira] [Updated] (GEODE-9314) Redis CLUSTER NODES incorrect when primary buckets are moving
[ https://issues.apache.org/jira/browse/GEODE-9314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9314: - Labels: pull-request-available unreleased (was: pull-request-available) > Redis CLUSTER NODES incorrect when primary buckets are moving > - > > Key: GEODE-9314 > URL: https://issues.apache.org/jira/browse/GEODE-9314 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Jens Deppe >Priority: Major > Labels: pull-request-available, unreleased > Fix For: 1.15.0 > > > When buckets are moving the CLUSTER NODES command may produce incorrect > results - specifically the node host/port information may be > duplicated/incorrect. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9343) Refactoring: move getInfo() method from INFO command to a TestHelper class
[ https://issues.apache.org/jira/browse/GEODE-9343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9343: - Labels: pull-request-available testing (was: pull-request-available) > Refactoring: move getInfo() method from INFO command to a TestHelper class > -- > > Key: GEODE-9343 > URL: https://issues.apache.org/jira/browse/GEODE-9343 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: pull-request-available, testing > Fix For: 1.15.0 > > > the getInfo() method is used throughout our tests to parse the data returned > by the INFO command. There is a lot of duplication of this implementation, > which is risky for future development. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9333) SessionsAndCrashesDUnitTest.sessionOperationsDoNotFail_whileServersAreRestarted may fail due to IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/GEODE-9333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-9333:
-
Labels: testing (was: )
> SessionsAndCrashesDUnitTest.sessionOperationsDoNotFail_whileServersAreRestarted
> may fail due to IndexOutOfBoundsException
> -
>
> Key: GEODE-9333
> URL: https://issues.apache.org/jira/browse/GEODE-9333
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Jens Deppe
>Priority: Major
> Labels: testing
> Fix For: 1.15.0
>
>
> Seen in a PR pre-checkin test run:
> {noformat}
> org.apache.geode.redis.session.SessionsAndCrashesDUnitTest >
> sessionOperationsDoNotFail_whileServersAreRestarted FAILED
> java.lang.IndexOutOfBoundsException: Index -5 out of bounds for length 100
> at jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:64)
> at
> jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:70)
> at jdk.internal.util.Preconditions.checkIndex(Preconditions.java:248)
> at java.util.Objects.checkIndex(Objects.java:372)
> at java.util.ArrayList.get(ArrayList.java:459)
> at
> org.apache.geode.redis.session.SessionsAndCrashesDUnitTest.validateSessionAttributes(SessionsAndCrashesDUnitTest.java:179)
> at
> org.apache.geode.redis.session.SessionsAndCrashesDUnitTest.sessionOperationsDoNotFail_whileServersAreRestarted(SessionsAndCrashesDUnitTest.java:170)
> {noformat}
> This occurs in the below block when {{totalUpdates}} is less than
> {{NUM_SESSIONS}}.
> {code:java}
> for (int i = totalUpdates - NUM_SESSIONS; i < totalUpdates; i++) {
> int sessionIdx = i % NUM_SESSIONS;
> String sessionId = sessionIds.get(sessionIdx);
> ...
> {code}
> Running the test locally with some trace logging added, it seems that
> {{totalUpdates}} is typically ~120, so if something were to cause updates to
> be 20% slower on a run of the test, this failure could show up. A solution
> might be to either await until at least {{NUM_SESSIONS}} updates have been
> performed by the updater threads, or to put in some logic to handle the case
> when {{totalUpdates}} is less than {{NUM_SESSIONS}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9317) ZADD/ZSCORE do not properly handle infinity
[ https://issues.apache.org/jira/browse/GEODE-9317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9317: - Labels: pull-request-available unreleased (was: pull-request-available) > ZADD/ZSCORE do not properly handle infinity > --- > > Key: GEODE-9317 > URL: https://issues.apache.org/jira/browse/GEODE-9317 > Project: Geode > Issue Type: Bug > Components: redis >Affects Versions: 1.15.0 >Reporter: Ray Ingles >Assignee: Hale Bales >Priority: Critical > Labels: pull-request-available, unreleased > Fix For: 1.15.0 > > > Native Redis accepts values like "inf", "+inf", "-infinity", etc. Currently > Radish considers these values invalid and returns "ERR value is not a valid > float". -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9366) Redis SynchronizedStripeExecutor can throw IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/GEODE-9366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-9366:
-
Labels: pull-request-available unreleased (was: pull-request-available)
> Redis SynchronizedStripeExecutor can throw IndexOutOfBoundsException
>
>
> Key: GEODE-9366
> URL: https://issues.apache.org/jira/browse/GEODE-9366
> Project: Geode
> Issue Type: Bug
> Components: redis
>Reporter: Jens Deppe
>Priority: Major
> Labels: pull-request-available, unreleased
> Fix For: 1.15.0
>
>
> Saw the following issue being logged:
> {noformat}
> [warn 2021/06/08 08:25:48.005 PDT redisServergemfire1_host1_9978
> tid=0x79] Execution of Redis command HMSET
> \xac\xed\x00\x05t\x00 \xac\xed\x00\x05t\x00\x10lastAccessedTime
>
> \xac\xed\x00\x05sr\x00\x0ejava.lang.Long;\x8b\xe4\x90\xcc\x8f#\xdf\x02\x00\x01J\x00\x05valuexr\x00\x10java.lang.Number\x86\xac\x95\x1d\x0b\x94\xe0\x8b\x02\x00\x00xp\x00\x00\x01y\xec:\xd0c
> \xac\xed\x00\x05t\x00\x13maxInactiveInterval \xac\xed\x00\x05sr\x00\x11ja
> va.lang.Integer\x12\xe2\xa0\xa4\xf7\x81\x878\x02\x00\x01I\x00\x05valuexr\x00\x10java.lang.Number\x86\xac\x95\x1d\x0b\x94\xe0\x8b\x02\x00\x00xp\x00\x00\x00<
> \xac\xed\x00\x05t\x00\x19sessionAttr:Object_214669
> \xac\xed\x00\x05t\x00\rObject_214669 \xac\xed\x00\x05t\
> x00\x0ccreationTime
> \xac\xed\x00\x05sr\x00\x0ejava.lang.Long;\x8b\xe4\x90\xcc\x8f#\xdf\x02\x00\x01J\x00\x05valuexr\x00\x10java.lang.Number\x86\xac\x95\x1d\x0b\x94\xe0\x8b\x02\x00\x00xp\x00\x00\x01y\xec:\xd0c
> failed: java.lang.ArrayIndexOutOfBoundsException: -11
> 52
> [error 2021/06/08 08:25:48.018 PDT redisServergemfire1_host1_9978
> tid=0x79] GeodeRedisServer-Unexpected error
> handler for [id: 0x7d55de8e, L:/10.32.109.109:21171 - R:/10.32.109.109:39854]
> java.lang.ArrayIndexOutOfBoundsException: -1152
> at
> org.apache.geode.redis.internal.executor.SynchronizedStripedExecutor.getSync(SynchronizedStripedExecutor.java:56)
> at
> org.apache.geode.redis.internal.executor.SynchronizedStripedExecutor.execute(SynchronizedStripedExecutor.java:44)
> at
> org.apache.geode.redis.internal.RegionProvider.execute(RegionProvider.java:136)
> at
> org.apache.geode.redis.internal.data.RedisDataCommandsFunctionExecutor.stripedExecute(RedisDataCommandsFunctionExecutor.java:48)
> at
> org.apache.geode.redis.internal.data.RedisHashCommandsFunctionExecutor.hset(RedisHashCommandsFunctionExecutor.java:42)
> at
> org.apache.geode.redis.internal.executor.hash.HMSetExecutor.executeCommand(HMSetExecutor.java:58)
> at
> org.apache.geode.redis.internal.RedisCommandType.executeCommand(RedisCommandType.java:353)
> at
> org.apache.geode.redis.internal.netty.Command.execute(Command.java:178)
> at
> org.apache.geode.redis.internal.netty.ExecutionHandlerContext.executeCommand(ExecutionHandlerContext.java:330)
> at
> org.apache.geode.redis.internal.netty.ExecutionHandlerContext.processCommandQueue(ExecutionHandlerContext.java:155)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9377) Revert deploymentName on Deployment configuration object.
[ https://issues.apache.org/jira/browse/GEODE-9377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9377: - Labels: pull-request-available unreleased (was: pull-request-available) > Revert deploymentName on Deployment configuration object. > - > > Key: GEODE-9377 > URL: https://issues.apache.org/jira/browse/GEODE-9377 > Project: Geode > Issue Type: Bug > Components: configuration, gfsh, management >Reporter: Patrick Johnsn >Assignee: Patrick Johnsn >Priority: Major > Labels: pull-request-available, unreleased > Fix For: 1.15.0 > > > Revert the addition of deploymentName to Deployment to avoid serialization > issues with older versions that use fileName. Deployment name was added as > part of ticket GEODE-8705, to support a dropped feature. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9386) google-windows-geode-builder image doesn't properly delete geode directory after dependency caching
[ https://issues.apache.org/jira/browse/GEODE-9386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9386: - Issue Type: Task (was: Bug) > google-windows-geode-builder image doesn't properly delete geode directory > after dependency caching > --- > > Key: GEODE-9386 > URL: https://issues.apache.org/jira/browse/GEODE-9386 > Project: Geode > Issue Type: Task > Components: ci >Affects Versions: 1.15.0 >Reporter: Sean Goller >Assignee: Sean Goller >Priority: Minor > Labels: pull-request-available > Fix For: 1.12.4, 1.13.4, 1.14.0, 1.15.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9411) ExecutionHandlerContext.getExceptionResponse() should not close the client connection on IOException
[
https://issues.apache.org/jira/browse/GEODE-9411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-9411:
-
Labels: pull-request-available unreleased (was: pull-request-available
unable)
> ExecutionHandlerContext.getExceptionResponse() should not close the client
> connection on IOException
>
>
> Key: GEODE-9411
> URL: https://issues.apache.org/jira/browse/GEODE-9411
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
> Labels: pull-request-available, unreleased
> Fix For: 1.15.0
>
>
> In {{ExecutionHandlerContext.getExceptionResponse()}} we always return a
> response of some kind to the client, except for if we hit an {{IOException}}
> during command execution, in which case we close the client connection and
> don't send any reply. This behaviour is leftover from the now-removed
> function execution approach that Radish was taking, so should also be removed.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9417) ZRANGE Behavior After Deletion of Key Inconsistent With Redis
[ https://issues.apache.org/jira/browse/GEODE-9417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9417: - Labels: blocks-1.15.0 redis unreleased (was: blocks-1.15.0 redis) > ZRANGE Behavior After Deletion of Key Inconsistent With Redis > - > > Key: GEODE-9417 > URL: https://issues.apache.org/jira/browse/GEODE-9417 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Wayne >Assignee: Donal Evans >Priority: Major > Labels: blocks-1.15.0, redis, unreleased > Fix For: 1.15.0 > > > After deleting a SortedSet the behavior for ZRANGE differs from native Redis. > > +Reproduction Steps:+ > Add some data to a SortedSet: > * ZADD leaderboard 1 "one" > * ZADD leaderboard 2 "two" > Delete the SortedSet with the key "leaderboard": > * DEL leaderboard > Now perform a ZRANGE command on the deleted key > ZRANGE leaderboard 0 10 > > Native Redis returns "(empty array)" where as we return " > "(error) ERR The server had an internal error please try again". > > The same behavior occurs even if the SortedSet never existed. For example: > ZRANGE nonexistent 0 10 will also result in > "(error) ERR The server had an internal error please try again". > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9427) Radish HSCAN implementation does not accept values for CURSOR argument that match Redis
[
https://issues.apache.org/jira/browse/GEODE-9427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-9427:
-
Labels: unreleased (was: )
> Radish HSCAN implementation does not accept values for CURSOR argument that
> match Redis
> ---
>
> Key: GEODE-9427
> URL: https://issues.apache.org/jira/browse/GEODE-9427
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
> Labels: unreleased
> Fix For: 1.15.0
>
>
> The HSCAN command takes an argument, CURSOR, which in native Redis can be any
> value between -18446744073709551615 and 18446744073709551615 (the maximum
> value of an unsigned long). The Radish implementation of HSCAN only accepts
> values in the range {{Integer.MIN_VALUE}} -> {{Integer.MAX_VALUE}} and
> returns an error if values outside this range are used.
> The Radish HSCAN implementation should be modified to accept the same range
> of values as Redis. Examples of this can be found in the implementations of
> the currently unsupported SCAN and SSCAN commands.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9424) Radish command arguments must support Long values
[
https://issues.apache.org/jira/browse/GEODE-9424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-9424:
-
Labels: pull-request-available unreleased (was: pull-request-available)
> Radish command arguments must support Long values
> -
>
> Key: GEODE-9424
> URL: https://issues.apache.org/jira/browse/GEODE-9424
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
> Labels: pull-request-available, unreleased
> Fix For: 1.15.0
>
>
> To match the behaviour seen when using native Redis, all command arguments
> that take integer values (that is, as opposed to float or string) must allow
> values in the range of {{Long.MIN_VALUE}} -> {{Long.MAX_VALUE}}.
> Currently, passing a value smaller than {{Integer.MIN_VALUE}} or larger than
> {{Integer.MAX_VALUE}} to these commands results in an error being returned,
> which is not the case for native Redis.
> Currently affected commands are:
> SCAN
> SSCAN
> HSCAN
> SPOP
> SRANDMEMBER
> BITPOS
> GETBIT
> SETBIT
> SETRANGE
> It should be enough to simply parse the argument as a Long and then narrow it
> to an int in most cases, as internally the maximum value that the argument
> can possibly take is {{Integer.MAX_VALUE}}. For example, [the maximum number
> of elements in a Redis set is 2^32 -
> 1|https://redis.io/topics/data-types#sets], so the largest meaningful value
> for the SSCAN CURSOR argument internally is {{Integer.MAX_VALUE}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9411) ExecutionHandlerContext.getExceptionResponse() should not close the client connection on IOException
[
https://issues.apache.org/jira/browse/GEODE-9411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-9411:
-
Labels: pull-request-available unable (was: pull-request-available)
> ExecutionHandlerContext.getExceptionResponse() should not close the client
> connection on IOException
>
>
> Key: GEODE-9411
> URL: https://issues.apache.org/jira/browse/GEODE-9411
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
> Labels: pull-request-available, unable
> Fix For: 1.15.0
>
>
> In {{ExecutionHandlerContext.getExceptionResponse()}} we always return a
> response of some kind to the client, except for if we hit an {{IOException}}
> during command execution, in which case we close the client connection and
> don't send any reply. This behaviour is leftover from the now-removed
> function execution approach that Radish was taking, so should also be removed.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9429) Radish HSCAN implementation cannot handle values for COUNT greater than Integer.MAX_VALUE / 2
[
https://issues.apache.org/jira/browse/GEODE-9429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-9429:
-
Labels: pull-request-available unreleased (was: pull-request-available)
> Radish HSCAN implementation cannot handle values for COUNT greater than
> Integer.MAX_VALUE / 2
> -
>
> Key: GEODE-9429
> URL: https://issues.apache.org/jira/browse/GEODE-9429
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
> Labels: pull-request-available, unreleased
> Fix For: 1.15.0
>
>
> The below code is the current implementation of HSCAN in {{RedisHash}}. When
> the value of {{count}} passed to this method is greater than
> {{Integer.MAX_VALUE / 2}} the condition of the while loop suffers from
> integer overflow and the loop does not execute correctly.
> {code:java}
> public ImmutablePair> hscan(Pattern matchPattern, int
> count, int cursor) {
> ArrayList resultList = new ArrayList<>(count + 2);
> do {
> cursor = hash.scan(cursor, 1,
> (list, key, value) -> addIfMatching(matchPattern, list, key,
> value), resultList);
> } while (cursor != 0 && resultList.size() < (count * 2));
> return new ImmutablePair<>(cursor, resultList);
> {code}
> This could be fixed by changing the type of {{resultList}} to
> {{List>}} and modifying the {{addIfMatching()}}
> method to populate the list with {{ImmutablePair}}s of keys and values rather
> than a single continuous list of interleaved keys and values.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9482) Radish commands do not match Redis error behaviour for integer arguments beginning "-0" and "+"
[
https://issues.apache.org/jira/browse/GEODE-9482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-9482:
-
Labels: pull-request-available unreleased (was: pull-request-available)
> Radish commands do not match Redis error behaviour for integer arguments
> beginning "-0" and "+"
> ---
>
> Key: GEODE-9482
> URL: https://issues.apache.org/jira/browse/GEODE-9482
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Darrel Schneider
>Priority: Major
> Labels: pull-request-available, unreleased
> Fix For: 1.15.0
>
>
> When using native Redis, commands that take integer arguments return {{"ERR
> value is not an integer or out of range"}} if the argument begins with "-0"
> or "+". The current implementation of these commands in Geode does not behave
> the same way.
> The {{Coder.bytesToLong()}} method should be modified to check for the first
> two characters being "-0" or "+" and throw a {{NumberFormatException}} if
> that is the case. Alternately, if there are places where we want to preserve
> the existing behaviour of {{Coder.bytesToLong()}}, an additional
> {{bytesToLongStrict()}} method could be added to the {{Coder}} class with
> this additional check.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9481) Upgrade OldClientSupportDUnitTest to not use deprecated methods
[ https://issues.apache.org/jira/browse/GEODE-9481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9481: - Labels: pull-request-available testing (was: pull-request-available) > Upgrade OldClientSupportDUnitTest to not use deprecated methods > --- > > Key: GEODE-9481 > URL: https://issues.apache.org/jira/browse/GEODE-9481 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Nabarun Nag >Assignee: Nabarun Nag >Priority: Major > Labels: pull-request-available, testing > Fix For: 1.15.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9493) redis data structure sizing is hard coded for compressed oops
[ https://issues.apache.org/jira/browse/GEODE-9493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9493: - Labels: pull-request-available unreleased (was: pull-request-available) > redis data structure sizing is hard coded for compressed oops > - > > Key: GEODE-9493 > URL: https://issues.apache.org/jira/browse/GEODE-9493 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: pull-request-available, unreleased > Fix For: 1.15.0 > > > The sizing of the redis data structures (string, hash, set, sorted set) has > some constants that were precomputed by tests. Because the tests are run with > smaller heaps that use compressed oops the size estimates end up being too > small for large heaps or if compressed oops are disabled. > Also a "strategy" object is currently part of the size and should not be > since it is a single canonical instance shared by all hash and set instances. > Also the way sizing is currently done does not take advantage of us knowing > the element type. By optimizing the code for "byte[]" for example we can > compute the size faster and use less memory by storing less "sizing" state in > our objects. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9500) RedisData keeps DeltaInfo references too long
[ https://issues.apache.org/jira/browse/GEODE-9500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9500: - Labels: pull-request-available unreleased (was: pull-request-available) > RedisData keeps DeltaInfo references too long > - > > Key: GEODE-9500 > URL: https://issues.apache.org/jira/browse/GEODE-9500 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: pull-request-available, unreleased > Fix For: 1.15.0 > > > The current implementation of Delta for RedisData does not clear the > reference to the DeltaInfo until toDelta is called. This works fine in the > normal case but in the abnormal case it can case extra memory to be used by > the DeltaInfo instances being kept alive. > What can happen is that if the extra server goes down so that geode is > running with one server then some optimization are done by geode and it never > calls toDelta. So in that case the DeltaInfo instances will be kept stored on > the primary. > We actually have sizing tests that found this problem but those tests were > changes to clear the DeltaInfo reference in the test. > Instead we should have these tests not clear it and change geode to clear it > in AbstractRedisData.storeChanges after the put returns. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9574) Changes to exception handling may be causing changes to connection state.
[
https://issues.apache.org/jira/browse/GEODE-9574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-9574:
-
Labels: pull-request-available unreleased (was: pull-request-available)
> Changes to exception handling may be causing changes to connection state.
> -
>
> Key: GEODE-9574
> URL: https://issues.apache.org/jira/browse/GEODE-9574
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
> Labels: pull-request-available, unreleased
> Fix For: 1.15.0
>
>
> {{OpExectorImpl}} has very specific exception cause checks that may have been
> affected by adding a cause to certain exceptions.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9564) Radish ParameterRequirements package name does not follow naming conventions
[ https://issues.apache.org/jira/browse/GEODE-9564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9564: - Labels: pull-request-available unreleased (was: pull-request-available) > Radish ParameterRequirements package name does not follow naming conventions > > > Key: GEODE-9564 > URL: https://issues.apache.org/jira/browse/GEODE-9564 > Project: Geode > Issue Type: Bug > Components: redis >Affects Versions: 1.15.0 >Reporter: Donal Evans >Assignee: Donal Evans >Priority: Major > Labels: pull-request-available, unreleased > Fix For: 1.15.0 > > > Per [the style > guide|https://google.github.io/styleguide/javaguide.html#s5.2.1-package-names] > adopted by Geode, package names should be all lower-case. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9581) SerialWANStatsDUnitTest > testReplicatedSerialPropagationWithGroupTransactionEventsWithoutBatchRedistributionSend fails
[
https://issues.apache.org/jira/browse/GEODE-9581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-9581:
-
Labels: pull-request-available testing (was: pull-request-available)
> SerialWANStatsDUnitTest >
> testReplicatedSerialPropagationWithGroupTransactionEventsWithoutBatchRedistributionSend
> fails
> ---
>
> Key: GEODE-9581
> URL: https://issues.apache.org/jira/browse/GEODE-9581
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.15.0
>Reporter: Bill Burcham
>Assignee: Alberto Gomez
>Priority: Major
> Labels: pull-request-available, testing
> Fix For: 1.15.0
>
>
> In this run
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1583
> SerialWANStatsDUnitTest >
> testReplicatedSerialPropagationWithGroupTransactionEventsWithoutBatchRedistributionSendsBatchesWithCompleteTransactions_SeveralClients
> failed:
> {code:java}
> org.apache.geode.internal.cache.wan.serial.SerialWANStatsDUnitTest >
> testReplicatedSerialPropagationWithGroupTransactionEventsWithoutBatchRedistributionSendsBatchesWithCompleteTransactions_SeveralClients
> FAILED
> org.junit.ComparisonFailure: expected:<[0]> but was:<[1]>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.wan.serial.SerialWANStatsDUnitTest.checkQueuesAreEmptyAndOnlyCompleteTransactionsAreReplicated(SerialWANStatsDUnitTest.java:949)
> at
> org.apache.geode.internal.cache.wan.serial.SerialWANStatsDUnitTest.testReplicatedSerialPropagationWithGroupTransactionEventsSendsBatchesWithCompleteTransactions_SeveralClients(SerialWANStatsDUnitTest.java:309)
> at
> org.apache.geode.internal.cache.wan.serial.SerialWANStatsDUnitTest.testReplicatedSerialPropagationWithGroupTransactionEventsWithoutBatchRedistributionSendsBatchesWithCompleteTransactions_SeveralClients(SerialWANStatsDUnitTest.java:218)
> {code}
> This is a new test. It failed in the mass test run.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9582) redis glob pattern should never throw PatternSyntaxException
[
https://issues.apache.org/jira/browse/GEODE-9582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-9582:
-
Labels: pull-request-available unreleased (was: pull-request-available)
> redis glob pattern should never throw PatternSyntaxException
>
>
> Key: GEODE-9582
> URL: https://issues.apache.org/jira/browse/GEODE-9582
> Project: Geode
> Issue Type: Bug
> Components: redis
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>Priority: Major
> Labels: pull-request-available, unreleased
> Fix For: 1.15.0
>
>
> The GlobPattern class converts a user's glob pattern into a pattern that is
> compiled by the jdk's Pattern.compile method. Some character sequences will
> cause the jdk to throw PatternSynaxException. For example giving it the bytes
> {{stringToBytes("\C")}} causes an exception.
> Native redis with this same pattern treats it like just "C".
> I think we need to look at every case in which the jdk compile throws
> PatternSynaxException and make sure GlobPattern will not submit a pattern to
> Pattern.compile that will cause it to throw.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9607) radish publish or subscribe operations could run the server out of memory
[ https://issues.apache.org/jira/browse/GEODE-9607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9607: - Labels: pull-request-available unreleased (was: pull-request-available) > radish publish or subscribe operations could run the server out of memory > - > > Key: GEODE-9607 > URL: https://issues.apache.org/jira/browse/GEODE-9607 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: pull-request-available, unreleased > Fix For: 1.15.0 > > > Each subscribe op stores some data in the server memory. If you keep doing > this the server will eventually run out of memory. Operations that store data > are supposed to honor the geode critical memory threshold and fail with a > LowMemory exception but subscribe does no check for critical but instead just > uses more memory. > Each publish op is added to an unbound queue that can take a while to process > (longer when more than one server is running). If enough publish ops are > received in a burst they can also cause the server to run out of memory. > Before adding the op to the queue geode's critical memory threshold should be > checked. > Since the server queues publish ops and needs to send them to remote servers > using a geode function, the implementation should be enhanced to do this with > a batch of publish ops instead of doing them one at a time. This will > improve the performance of publish which will allow it to free up memory > faster. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9641) Benchmark instability in P2pPartitionedPutBytesBenchmark
[
https://issues.apache.org/jira/browse/GEODE-9641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-9641:
-
Labels: pull-request-available testing (was: pull-request-available)
> Benchmark instability in P2pPartitionedPutBytesBenchmark
>
>
> Key: GEODE-9641
> URL: https://issues.apache.org/jira/browse/GEODE-9641
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Kamilla Aslami
>Assignee: Kamilla Aslami
>Priority: Major
> Labels: pull-request-available, testing
> Fix For: 1.15.0
>
>
> P2pPartitionedPutBytesBenchmark started failing in CI after the fix for
> GEODE-9204 was merged.
> {code:java}
> org.apache.geode.benchmark.tests.P2pPartitionedPutBytesBenchmark
> average ops/second Baseline:179582.83 Test:170268.31
> Difference: -5.2%
>ops/second standard error Baseline: 849.15 Test: 649.44
> Difference: -23.5%
>ops/second standard deviation Baseline: 25346.86 Test: 19374.76
> Difference: -23.6%
> YS 99th percentile latency Baseline: 5010.00 Test: 5110.00
> Difference: +2.0%
> median latency Baseline: 2416639.00 Test: 2412543.00
> Difference: -0.2%
> 90th percentile latency Baseline: 4698111.00 Test: 4567039.00
> Difference: -2.8%
> 99th percentile latency Baseline: 38141951.00 Test: 81723391.00
> Difference: +114.3%
>99.9th percentile latency Baseline: 196214783.00 Test: 205389823.00
> Difference: +4.7%
> average latency Baseline: 4033453.68 Test: 4258029.39
> Difference: +5.6%
> latency standard deviation Baseline: 14549153.77 Test: 15673393.37
> Difference: +7.7%
> latency standard error Baseline: 1149.00 Test: 1271.79
> Difference: +10.7%
> average ops/second Baseline:533863.27 Test:505986.13
> Difference: -5.2%
> BENCHMARK FAILED:
> org.apache.geode.benchmark.tests.P2pPartitionedPutBytesBenchmark average
> latency is 5% worse than baseline.{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9645) MultiUserAuth: DataSerializerRecoveryListener is called without auth information. Promptly fails
[
https://issues.apache.org/jira/browse/GEODE-9645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-9645:
-
Labels: GeodeOperationAPI pull-request-available unreleased (was:
GeodeOperationAPI pull-request-available)
> MultiUserAuth: DataSerializerRecoveryListener is called without auth
> information. Promptly fails
>
>
> Key: GEODE-9645
> URL: https://issues.apache.org/jira/browse/GEODE-9645
> Project: Geode
> Issue Type: Bug
> Components: core
>Reporter: Mark Hanson
>Assignee: Mark Hanson
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available, unreleased
> Fix For: 1.15.0
>
>
> When multiuserSecureModeEnabled is enabled, a user may register a
> DataSerializer. When endpoint manager detects a new endpoint, it will attempt
> to register the data serializers with other machines. This is a problem was
> there is no authentication information in the background process to
> authenticate. Hence the error seen below.
>
> {noformat}
> [warn 2021/09/27 18:03:02.804 PDT tid=0x62]
> DataSerializerRecoveryTask - Error recovering dataSerializers:
> java.lang.UnsupportedOperationException: Use Pool APIs for doing operations
> when multiuser-secure-mode-enabled is set to true.
> at
> org.apache.geode.cache.client.internal.PoolImpl.authenticateIfRequired(PoolImpl.java:1540)
>
> at
> org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:816)
> at
> org.apache.geode.cache.client.internal.RegisterDataSerializersOp.execute(RegisterDataSerializersOp.java:40)
>
> at
> org.apache.geode.cache.client.internal.DataSerializerRecoveryListener$RecoveryTask.run2(DataSerializerRecoveryListener.java:116)
>
> at
> org.apache.geode.cache.client.internal.PoolImpl$PoolTask.run(PoolImpl.java:1337)
>
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>
> at java.lang.Thread.run(Thread.java:748){noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9665) RENAME or RENAMENX using keys on different servers causes multiple redirections
[ https://issues.apache.org/jira/browse/GEODE-9665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9665: - Labels: pull-request-available unreleased (was: pull-request-available) > RENAME or RENAMENX using keys on different servers causes multiple > redirections > --- > > Key: GEODE-9665 > URL: https://issues.apache.org/jira/browse/GEODE-9665 > Project: Geode > Issue Type: Bug > Components: redis >Affects Versions: 1.15.0 >Reporter: Eric Zoerner >Assignee: Eric Zoerner >Priority: Major > Labels: pull-request-available, unreleased > Fix For: 1.15.0 > > > when running on a multi-server cluster, an attempt to rename with source and > target keys that are hosted on different servers causes multiple MOVED > redirects. > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9687) Remove deprecated elements from RegionMembershipMBeanDistributedTestBase
[ https://issues.apache.org/jira/browse/GEODE-9687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9687: - Labels: pull-request-available testing (was: pull-request-available) > Remove deprecated elements from RegionMembershipMBeanDistributedTestBase > > > Key: GEODE-9687 > URL: https://issues.apache.org/jira/browse/GEODE-9687 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Nabarun Nag >Priority: Major > Labels: pull-request-available, testing > Fix For: 1.15.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9690) Restore Redis TCL integration test patch file
[ https://issues.apache.org/jira/browse/GEODE-9690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9690: - Labels: pull-request-available testing (was: pull-request-available) > Restore Redis TCL integration test patch file > - > > Key: GEODE-9690 > URL: https://issues.apache.org/jira/browse/GEODE-9690 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Ray Ingles >Assignee: Ray Ingles >Priority: Major > Labels: pull-request-available, testing > Fix For: 1.15.0 > > > GEODE-9567 accidentally removed the Redis TCL patch file. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9699) ZUNIONSTORE returns 1 instead of 0 when running against non-existing key
[
https://issues.apache.org/jira/browse/GEODE-9699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-9699:
-
Labels: pull-request-available release-blocker unreleased (was:
pull-request-available release-blocker)
> ZUNIONSTORE returns 1 instead of 0 when running against non-existing key
>
>
> Key: GEODE-9699
> URL: https://issues.apache.org/jira/browse/GEODE-9699
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Eric Zoerner
>Assignee: Donal Evans
>Priority: Major
> Labels: pull-request-available, release-blocker, unreleased
> Fix For: 1.15.0
>
>
> The following redis TCL test fails when running against Geode for Redis:
> {code}
> # Geode fails with: Expected '1' to be equal to '0'
> test "ZUNIONSTORE against non-existing key doesn't set destination -
> $encoding" {
> r del "{slot}zseta"
> assert_equal 0 [r zunionstore "{slot}dst_key" 1 "{slot}zseta"]
> assert_equal 0 [r exists "{slot}dst_key"]
> }
> {code}
> Enable this test as part of this fix.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9693) Remove deprecated elements from ListIndexCommandDistributedTestBase
[ https://issues.apache.org/jira/browse/GEODE-9693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9693: - Labels: pull-request-available testing (was: pull-request-available) > Remove deprecated elements from ListIndexCommandDistributedTestBase > --- > > Key: GEODE-9693 > URL: https://issues.apache.org/jira/browse/GEODE-9693 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Nabarun Nag >Priority: Major > Labels: pull-request-available, testing > Fix For: 1.15.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9701) ClusterStartupRule starts 4 VMs even if fewer VMs is specified
[
https://issues.apache.org/jira/browse/GEODE-9701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-9701:
-
Labels: GeodeOperationAPI pull-request-available testing (was:
GeodeOperationAPI pull-request-available)
> ClusterStartupRule starts 4 VMs even if fewer VMs is specified
> --
>
> Key: GEODE-9701
> URL: https://issues.apache.org/jira/browse/GEODE-9701
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available, testing
> Fix For: 1.15.0
>
>
> Bill reported that ClusterStartupRule seems to be creating 4 VMs no matter
> how few VMs he specifies in a new test for [PR
> #6930|https://github.com/apache/geode/pull/6930]. The concern is that by
> creating more VMs, we are causing unnecessary load on machines in the cloud.
> I wrote this simple test which confirms the problem:
> {noformat}
> import static org.apache.geode.test.dunit.VM.getVMCount;
> import static org.assertj.core.api.Assertions.assertThat;
> import org.junit.Rule;
> import org.junit.Test;
> import org.apache.geode.test.dunit.rules.ClusterStartupRule;
> public class ClusterStartupRuleVmCountDistributedTest {
> @Rule
> public ClusterStartupRule clusterStartupRule = new ClusterStartupRule(3);
> @Test
> public void limitsVMsTo3() {
> assertThat(getVMCount()).isEqualTo(3);
> }
> }
> {noformat}
> But if I replace {{ClusterStartupRule}} with {{DistributedRule}}, it passes
> so the problem is specific to {{ClusterStartupRule}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9703) redis benchmarks fail to compile after rename
[ https://issues.apache.org/jira/browse/GEODE-9703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9703: - Issue Type: Task (was: Bug) > redis benchmarks fail to compile after rename > - > > Key: GEODE-9703 > URL: https://issues.apache.org/jira/browse/GEODE-9703 > Project: Geode > Issue Type: Task > Components: benchmarks >Affects Versions: 1.15.0 >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > Looks like Redis Benchmarks are [failing to > compile|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-radish/builds/115] > the baseline after the rename, since the module name is now different in > HEAD than in the baseline. The easiest fix might be to update [the redis > baseline|https://github.com/apache/geode/blob/develop/ci/pipelines/shared/jinja.variables.yml#L41] > to some Geode SHA *after* the big rename (the current redis benchmark > baseline SHA is from Aug 18) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9707) artifacts not archived when a ci job fails due to OOM
[ https://issues.apache.org/jira/browse/GEODE-9707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9707: - Issue Type: Task (was: Bug) > artifacts not archived when a ci job fails due to OOM > - > > Key: GEODE-9707 > URL: https://issues.apache.org/jira/browse/GEODE-9707 > Project: Geode > Issue Type: Task > Components: ci >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > example: https://concourse.apachegeode-ci.info/builds/86869 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9702) japicmp should fail when new methods are added to public interface
[ https://issues.apache.org/jira/browse/GEODE-9702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9702: - Issue Type: Task (was: Bug) > japicmp should fail when new methods are added to public interface > -- > > Key: GEODE-9702 > URL: https://issues.apache.org/jira/browse/GEODE-9702 > Project: Geode > Issue Type: Task > Components: ci >Affects Versions: 1.15.0 >Reporter: Owen Nichols >Assignee: Robert Houghton >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > At least twice in 1.15.0 (commits 7aa03824 and b377e3f8), new methods were > added to Geode's public API (such as > `GatewaySender.getRetriesToGetTransactionEventsFromQueue`). While adding > methods _is_ compatible with existing source and binary calls to this > interface, it breaks anything else that implements this interface. _Even if_ > a default implementation had been provided, there are still edge cases where > it could collide with existing implementation that may already have methods > with those names. These two examples have been fixed now by GEODE-9629 and > GEODE-9630; this ticket is to fix CI to prevent this in the future. > Our required PR check "*api-check-test-openjdk11*" should have prevented this > from happening... > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9727) Redis Command COMMAND Should Throw Error With Invalid Arguments
[ https://issues.apache.org/jira/browse/GEODE-9727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9727: - Labels: pull-request-available unreleased (was: pull-request-available) > Redis Command COMMAND Should Throw Error With Invalid Arguments > --- > > Key: GEODE-9727 > URL: https://issues.apache.org/jira/browse/GEODE-9727 > Project: Geode > Issue Type: Bug > Components: redis >Affects Versions: 1.15.0 >Reporter: Wayne >Assignee: Kristen >Priority: Major > Labels: pull-request-available, unreleased > Fix For: 1.15.0 > > > The Redis command COMMAND should throw an error when provided with an illegal > argument. > Native Redis behaves as follows: > COMMAND foo > (error) ERR Unknown subcommand or wrong number of arguments for 'foo'. Try > COMMAND HELP. > Our existing COMMANDimplementation does not provide an error messages for the > extra argument and just executes the COMMAND normally as if no additional > arguments were provided. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9709) Clean up GcCommandDUnitTest
[ https://issues.apache.org/jira/browse/GEODE-9709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9709: - Labels: pull-request-available testing (was: pull-request-available) > Clean up GcCommandDUnitTest > --- > > Key: GEODE-9709 > URL: https://issues.apache.org/jira/browse/GEODE-9709 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Nabarun Nag >Priority: Major > Labels: pull-request-available, testing > Fix For: 1.15.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9734) ClientPublisher has race causing it to never publish a single message
[ https://issues.apache.org/jira/browse/GEODE-9734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9734: - Labels: pull-request-available unreleased (was: pull-request-available) > ClientPublisher has race causing it to never publish a single message > - > > Key: GEODE-9734 > URL: https://issues.apache.org/jira/browse/GEODE-9734 > Project: Geode > Issue Type: Bug > Components: redis >Affects Versions: 1.15.0 >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: pull-request-available, unreleased > Fix For: 1.15.0 > > > The ClientPublisher has a race condition that can cause it to add a message > to the queue but not drain it right away. The msg will never be published > unless that client publishes a second message. > The order of events that cause the race is: > 1. drainerThread: set active and publishes current batch > 2. drainerThread: calls batch.fill and gets nothing > 3. publishThread: adds msg to queue > 4. publishThread: tests "active" see it is true so it does not call > fillBatchIfNeeded > 5. drainerThread: sets "active" to false > We now have one msg in the queue that will not be published until we add > another msg to the queue. > This should be easy to fix. All we need to do in the drainerThread is one > more check of the queue after setting active to false -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9721) the constant names for redis gemfire properties should contain GEODE_FOR_REDIS
[ https://issues.apache.org/jira/browse/GEODE-9721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9721: - Labels: pull-request-available unreleased (was: pull-request-available) > the constant names for redis gemfire properties should contain GEODE_FOR_REDIS > -- > > Key: GEODE-9721 > URL: https://issues.apache.org/jira/browse/GEODE-9721 > Project: Geode > Issue Type: Bug > Components: redis >Affects Versions: 1.15.0 >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: pull-request-available, unreleased > Fix For: 1.15.0 > > > The following constant names in ConfigurationProperties should all be > renamed: REDIS_PORT, REDIS_USERNAME, REDIS_ENABLED, REDIS_BIND_ADDRESS > to: GEODE_FOR_REDIS_PORT, GEODE_FOR_REDIS_USERNAME, GEODE_FOR_REDIS_ENABLED, > GEODE_FOR_REDIS_BIND_ADDRESS. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9725) AvailablePort inherently incompatible with default membership port range
[
https://issues.apache.org/jira/browse/GEODE-9725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-9725:
-
Labels: GeodeOperationAPI pull-request-available testing (was:
GeodeOperationAPI pull-request-available)
> AvailablePort inherently incompatible with default membership port range
>
>
> Key: GEODE-9725
> URL: https://issues.apache.org/jira/browse/GEODE-9725
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.15.0
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available, testing
> Fix For: 1.15.0
>
>
> {{AvailablePortHelperIntegrationTest}} failed in CI:
>
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/integration-test-openjdk8/builds/259]
> *Cause:* {{AvailablePort}} and {{AvailablePortHelper}} have methods to
> retrieve an "available" port from the membership port range. This feature is
> both unnecessary and inherently unreliable.
> *Inherently unreliable:* The default membership port range overlaps each OS's
> ephemeral port range. An ephemeral port deemed to be "available" by one of
> these methods can be put into use by another process even before the method
> returns. It is not safe to rely on such a port to remain available after it
> is checked.
> *Unnecessary:* Currently the only callers that request ports from the
> membership port range are two tests in {{DistributedSystemDUnitTest}}. In
> each case, the test uses the returned ports to +set+ the membership port
> range for a member. There is no need for the ports to come from any
> particular range.
> There are no other uses of this feature, either in the product or in tests.
> *Solution:* Remove this feature from {{AvailablePort}} and
> {{AvailablePortHelper}}.
> *Alternatives:*
> * {{DistributedSystemDUnitTest}} can get available ports from the available
> port range. This range is safe to use (assuming all other
> concurrently-running tests are well-behaved).
> * A caller that needs ports in a specific range can call
> {{AvailablePort.getRandomAvailablePortInRange(lower, upper, protocol)}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9736) publishes that find no pattern subscribers can cause server to run out of memory
[ https://issues.apache.org/jira/browse/GEODE-9736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9736: - Labels: unreleased (was: ) > publishes that find no pattern subscribers can cause server to run out of > memory > > > Key: GEODE-9736 > URL: https://issues.apache.org/jira/browse/GEODE-9736 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: unreleased > Fix For: 1.15.0 > > > Currently each time a publish is done the server will check existing pattern > subscribers to see if they want the publish. If it finds no subscribers it > remembers that and the publish channel. > Since you can just keep making up new publish channels that have no memory, > remembering these can cause the server to run out of memory. > If you hit this problem you will see an instance of > PatternSubscriptionManager with a large "patternSubscriptionCache" > ConcurrentHashMap. It will be full of entries whose value is an instance of > Collections$EmptyList -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9745) geode-for-redis stats expose unbranded names
[ https://issues.apache.org/jira/browse/GEODE-9745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9745: - Labels: pull-request-available unreleased (was: pull-request-available) > geode-for-redis stats expose unbranded names > > > Key: GEODE-9745 > URL: https://issues.apache.org/jira/browse/GEODE-9745 > Project: Geode > Issue Type: Bug > Components: redis >Affects Versions: 1.15.0 >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: pull-request-available, unreleased > Fix For: 1.15.0 > > > The stats for geode-for-redis when seen in an external tool (like vsd) are > named "redisStats". They should instead be "geodeForRedisStats". Also the > type name is very non-standard and too wordy "statsForServergeodeForRedis". > It should just be "GeodeForRedisStats". > The description also has some old terminology "Statistics for a Geode server > compatible with Redis". -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9751) [CI-only] render.py needs to call yaml.safe_load instead of yaml.load
[ https://issues.apache.org/jira/browse/GEODE-9751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9751: - Issue Type: Task (was: Bug) > [CI-only] render.py needs to call yaml.safe_load instead of yaml.load > - > > Key: GEODE-9751 > URL: https://issues.apache.org/jira/browse/GEODE-9751 > Project: Geode > Issue Type: Task > Components: ci >Affects Versions: 1.12.5, 1.13.5, 1.14.1, 1.15.0 >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > Labels: pull-request-available > Fix For: 1.12.6, 1.13.5, 1.14.1, 1.15.0 > > > after previously being deprecated, the latest version of pyyaml removes this > insecure call (see > https://stackoverflow.com/questions/69564817/typeerror-load-missing-1-required-positional-argument-loader-in-google-col). > render.py is used in several jobs in our meta pipeline to transform our > jinja2 templates into concourse yaml. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9767) bump netty to recommended version
[ https://issues.apache.org/jira/browse/GEODE-9767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9767: - Issue Type: Improvement (was: Bug) > bump netty to recommended version > - > > Key: GEODE-9767 > URL: https://issues.apache.org/jira/browse/GEODE-9767 > Project: Geode > Issue Type: Improvement > Components: redis >Affects Versions: 1.12.5, 1.13.4, 1.14.0, 1.15.0 >Reporter: Owen Nichols >Assignee: Dan Smith >Priority: Major > Labels: pull-request-available > Fix For: 1.12.6, 1.13.5, 1.14.1, 1.15.0 > > > latest is 4.1.69, we should be using 4.1.68 or 4.1.69 on all branches if > possible -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9778) Benchmark degradation in RedisHsetBenchmark since netty bump
[
https://issues.apache.org/jira/browse/GEODE-9778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-9778:
-
Labels: pull-request-available unreleased (was: pull-request-available)
> Benchmark degradation in RedisHsetBenchmark since netty bump
>
>
> Key: GEODE-9778
> URL: https://issues.apache.org/jira/browse/GEODE-9778
> Project: Geode
> Issue Type: Bug
> Components: benchmarks, redis
>Affects Versions: 1.15.0
>Reporter: Owen Nichols
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available, unreleased
> Fix For: 1.14.1, 1.15.0
>
>
> examples:
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-radish/builds/179]
> #179 seems to show a consistent 10-15% degradation in only in the Hset
> benchmark
> {noformat}
> ...
> This is ITERATION 3 of benchmarking against baseline.
> RedisHsetBenchmark avg ops/sec
> Baseline:234210.78 Test:207591.61 Difference: -11.4%
> avg latency
> Baseline: 3070166.30 Test: 3468289.49 Difference: +13.0%
> This is ITERATION 4 of benchmarking against baseline.
> RedisHsetBenchmark avg ops/sec
> Baseline:238884.30 Test:216618.91 Difference: -9.3%
> avg latency
> Baseline: 3016750.52 Test: 3319615.79 Difference: +10.0%
> This is ITERATION 5 of benchmarking against baseline.
> RedisHsetBenchmark avg ops/sec
> Baseline:248656.29 Test:211220.74 Difference: -15.1%
> avg latency
> Baseline: 2894368.00 Test: 3405200.04 Difference: +17.6% {noformat}
>
> Also
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-radish/builds/180]
> shows similar results:
> {noformat}
> This is ITERATION 2 of benchmarking against baseline.
> RedisHsetAndHgetBenchmark avg ops/sec
> Baseline:146409.80 Test:134019.47 Difference: -8.5%
> avg latency
> Baseline: 4914049.28 Test: 5365514.18 Difference: +9.2%
> RedisHsetBenchmark avg ops/sec
> Baseline:217729.26 Test:191512.40 Difference: -12.0%
> avg latency
> Baseline: 3302672.13 Test: 3750731.05 Difference: +13.6%
> This is ITERATION 3 of benchmarking against baseline.
> RedisHsetAndHgetBenchmark avg ops/sec
> Baseline:141960.20 Test:129616.40 Difference: -8.7%
> avg latency
> Baseline: 5065570.96 Test: 5554949.31 Difference: +9.7%
> RedisHsetBenchmark avg ops/sec
> Baseline:219985.85 Test:199572.01 Difference: -9.3%
> avg latency
> Baseline: 3268138.34 Test: 3603197.51 Difference: +10.3%
> This is ITERATION 4 of benchmarking against baseline.
> RedisHsetAndHgetBenchmark avg ops/sec
> Baseline:140404.88 Test:134341.05 Difference: -4.3%
> avg latency
> Baseline: 5127629.59 Test: 5354599.94 Difference: +4.4%
> RedisHsetBenchmark avg ops/sec
> Baseline:224728.82 Test:194024.96 Difference: -13.7%
> avg latency
> Baseline: 3205365.68 Test: 3706058.86 Difference: +15.6%
> This is ITERATION 5 of benchmarking against baseline.
> RedisHsetBenchmark avg ops/sec
> Baseline:220019.47 Test:192107.91 Difference: -12.7%
> avg latency
> Baseline: 3268273.76 Test: 3744842.51 Difference: +14.6%
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9792) Client in some cases would send in AuthenticationRequest multiple times even when they share the same connection
[ https://issues.apache.org/jira/browse/GEODE-9792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9792: - Labels: GeodeOperationAPI pull-request-available unreleased (was: GeodeOperationAPI pull-request-available) > Client in some cases would send in AuthenticationRequest multiple times even > when they share the same connection > > > Key: GEODE-9792 > URL: https://issues.apache.org/jira/browse/GEODE-9792 > Project: Geode > Issue Type: Bug > Components: core >Affects Versions: 1.15.0 >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: GeodeOperationAPI, pull-request-available, unreleased > Fix For: 1.15.0 > > > It's observed that AuthenticationRequest will come in multiple times in the > same connection by different threads. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9778) Benchmark degradation in RedisHsetBenchmark since netty bump
[
https://issues.apache.org/jira/browse/GEODE-9778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-9778:
-
Labels: pull-request-available testing unreleased (was:
pull-request-available unreleased)
> Benchmark degradation in RedisHsetBenchmark since netty bump
>
>
> Key: GEODE-9778
> URL: https://issues.apache.org/jira/browse/GEODE-9778
> Project: Geode
> Issue Type: Bug
> Components: benchmarks, redis
>Affects Versions: 1.15.0
>Reporter: Owen Nichols
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available, testing, unreleased
> Fix For: 1.14.1, 1.15.0
>
>
> examples:
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-radish/builds/179]
> #179 seems to show a consistent 10-15% degradation in only in the Hset
> benchmark
> {noformat}
> ...
> This is ITERATION 3 of benchmarking against baseline.
> RedisHsetBenchmark avg ops/sec
> Baseline:234210.78 Test:207591.61 Difference: -11.4%
> avg latency
> Baseline: 3070166.30 Test: 3468289.49 Difference: +13.0%
> This is ITERATION 4 of benchmarking against baseline.
> RedisHsetBenchmark avg ops/sec
> Baseline:238884.30 Test:216618.91 Difference: -9.3%
> avg latency
> Baseline: 3016750.52 Test: 3319615.79 Difference: +10.0%
> This is ITERATION 5 of benchmarking against baseline.
> RedisHsetBenchmark avg ops/sec
> Baseline:248656.29 Test:211220.74 Difference: -15.1%
> avg latency
> Baseline: 2894368.00 Test: 3405200.04 Difference: +17.6% {noformat}
>
> Also
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-radish/builds/180]
> shows similar results:
> {noformat}
> This is ITERATION 2 of benchmarking against baseline.
> RedisHsetAndHgetBenchmark avg ops/sec
> Baseline:146409.80 Test:134019.47 Difference: -8.5%
> avg latency
> Baseline: 4914049.28 Test: 5365514.18 Difference: +9.2%
> RedisHsetBenchmark avg ops/sec
> Baseline:217729.26 Test:191512.40 Difference: -12.0%
> avg latency
> Baseline: 3302672.13 Test: 3750731.05 Difference: +13.6%
> This is ITERATION 3 of benchmarking against baseline.
> RedisHsetAndHgetBenchmark avg ops/sec
> Baseline:141960.20 Test:129616.40 Difference: -8.7%
> avg latency
> Baseline: 5065570.96 Test: 5554949.31 Difference: +9.7%
> RedisHsetBenchmark avg ops/sec
> Baseline:219985.85 Test:199572.01 Difference: -9.3%
> avg latency
> Baseline: 3268138.34 Test: 3603197.51 Difference: +10.3%
> This is ITERATION 4 of benchmarking against baseline.
> RedisHsetAndHgetBenchmark avg ops/sec
> Baseline:140404.88 Test:134341.05 Difference: -4.3%
> avg latency
> Baseline: 5127629.59 Test: 5354599.94 Difference: +4.4%
> RedisHsetBenchmark avg ops/sec
> Baseline:224728.82 Test:194024.96 Difference: -13.7%
> avg latency
> Baseline: 3205365.68 Test: 3706058.86 Difference: +15.6%
> This is ITERATION 5 of benchmarking against baseline.
> RedisHsetBenchmark avg ops/sec
> Baseline:220019.47 Test:192107.91 Difference: -12.7%
> avg latency
> Baseline: 3268273.76 Test: 3744842.51 Difference: +14.6%
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9794) Radish PassiveExpirationManager can throw NPE
[
https://issues.apache.org/jira/browse/GEODE-9794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-9794:
-
Labels: pull-request-available unable (was: pull-request-available)
> Radish PassiveExpirationManager can throw NPE
> -
>
> Key: GEODE-9794
> URL: https://issues.apache.org/jira/browse/GEODE-9794
> Project: Geode
> Issue Type: Bug
> Components: redis
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available, unable
> Fix For: 1.15.0
>
>
> I noticed this log entry in a recent test:
>
> {noformat}
> [warn 2021/11/02 15:12:08.402 PDT redisServergemfire1_host1_9725
> tid=0x47] Passive expiration failed. Will
> try again in 1 second.
> java.lang.NullPointerException
> at
> org.apache.geode.redis.internal.PassiveExpirationManager.doDataExpiration(PassiveExpirationManager.java:66)
> at
> org.apache.geode.redis.internal.PassiveExpirationManager.lambda$new$0(PassiveExpirationManager.java:49)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9805) Debug logging of Radish AUTH command in ExecutionHandlerContext.executeCommand() reveals sensitive information
[ https://issues.apache.org/jira/browse/GEODE-9805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9805: - Labels: blocks-1.15.0 pull-request-available unreleased (was: blocks-1.15.0 pull-request-available) > Debug logging of Radish AUTH command in > ExecutionHandlerContext.executeCommand() reveals sensitive information > -- > > Key: GEODE-9805 > URL: https://issues.apache.org/jira/browse/GEODE-9805 > Project: Geode > Issue Type: Bug > Components: redis >Affects Versions: 1.15.0 >Reporter: Donal Evans >Assignee: Donal Evans >Priority: Major > Labels: blocks-1.15.0, pull-request-available, unreleased > Fix For: 1.15.0 > > > With debug logging enabled, the ExecutionHandlerContext.executeCommand() > method logs every command executed along with its arguments. In the case of > the AUTH command, this results in un-redacted userId and/or password being > logged, which represents a serious security issue. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9794) Radish PassiveExpirationManager can throw NPE
[
https://issues.apache.org/jira/browse/GEODE-9794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-9794:
-
Labels: pull-request-available unreleased (was: pull-request-available
unable)
> Radish PassiveExpirationManager can throw NPE
> -
>
> Key: GEODE-9794
> URL: https://issues.apache.org/jira/browse/GEODE-9794
> Project: Geode
> Issue Type: Bug
> Components: redis
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available, unreleased
> Fix For: 1.15.0
>
>
> I noticed this log entry in a recent test:
>
> {noformat}
> [warn 2021/11/02 15:12:08.402 PDT redisServergemfire1_host1_9725
> tid=0x47] Passive expiration failed. Will
> try again in 1 second.
> java.lang.NullPointerException
> at
> org.apache.geode.redis.internal.PassiveExpirationManager.doDataExpiration(PassiveExpirationManager.java:66)
> at
> org.apache.geode.redis.internal.PassiveExpirationManager.lambda$new$0(PassiveExpirationManager.java:49)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9815) Recovering persistent members can result in extra copies of a bucket or two copies in the same redundancy zone
[ https://issues.apache.org/jira/browse/GEODE-9815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9815: - Labels: GeodeOperationAPI blocks-1.15.0 pull-request-available unreleased (was: GeodeOperationAPI blocks-1.15.0 pull-request-available) > Recovering persistent members can result in extra copies of a bucket or two > copies in the same redundancy zone > -- > > Key: GEODE-9815 > URL: https://issues.apache.org/jira/browse/GEODE-9815 > Project: Geode > Issue Type: Bug > Components: regions >Affects Versions: 1.15.0 >Reporter: Dan Smith >Assignee: Mark Hanson >Priority: Major > Labels: GeodeOperationAPI, blocks-1.15.0, > pull-request-available, unreleased > Fix For: 1.15.0 > > > The fix in GEODE-9554 is incomplete for some cases, and it also introduces a > new issue when removing buckets that are over redundancy. > GEODE-9554 and these new issues are all related to using redundancy zones and > having persistent members. > With persistence, when we start up a member with persisted buckets, we always > recover the persisted buckets on startup, regardless of whether redundancy is > already met or what zone the existing buckets are on. This is necessary to > ensure that we can recover all colocated buckets that might be persisted on > the member. > Because recovering these persistent buckets may cause us to go over > redundancy, after we recover from disk, we run a "restore redundancy" task > that actually removes copies of buckets that are over redundancy. > GEODE-9554 addressed one case where we end up removing the last copy of a > bucket from one redundancy zone while leaving two copies in another > redundancy zone. It did so by disallowing the removal of a bucket if it is > the last copy in a redundancy zone. > There are a couple of issues with this approach. > *Problem 1:* We may end up with two copies of the bucket in one zone in some > cases > With a slight tweak to the scenario fixed with GEODE-9554 we can end up never > getting out of the situation where we have two copies of a bucket in the same > zone. > Steps: > 1. Start two redundancy zones A and B with two members each. Bucket 0 is on > member A1 and B1. > 2. Shutdown member A1. > 3. Rebalance - this will create bucket 0 on A2. > 4. Shutdown B1. Revoke it's disk store and delete the data > 5. Startup A1 - it will recover bucket 0. > 6. At this point, bucket 0 is on A1 and A2, and nothing will resolve that > situation. > *Problem 2:* We may never delete extra copies of a bucket > The fix for GEODE-9554 introduces a new problem if we have more than 2 > redundancy zones > Steps > 1. Start three redundancy zones A,B,C with one member each. Bucket 0 is on A1 > and B1 > 2. Shutdown A1 > 3. Rebalance - this will create Bucket 0 on C1 > 4. Startup A1 - this will recreate bucket 0 > 5. Now we have bucket 0 on A1, B1, and C1. Nothing will remove the extra copy. > I think the overall fix is probably to do something different than prevent > removing the last copy of a bucket from a redundancy zone. Instead, I think > we should do something like this: > 1. Change PartitionRegionLoadModel.getOverRedundancyBuckets to return *any* > buckets that have two copies in the same zone, as well as any buckets that > are actually over redundancy. > 2. Change PartitionRegionLoadModel.findBestRemove to always remove extra > copies of a bucket in the same zone first > 3. Back out the changes for GEODE-9554 and let the last copy be deleted from > a zone. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9811) When a node is stopped using nice_exit or its cache is closing, client may fail due to UnavailableSecurityManagerException
[ https://issues.apache.org/jira/browse/GEODE-9811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9811: - Labels: GeodeOperationAPI pull-request-available unreleased (was: GeodeOperationAPI pull-request-available) > When a node is stopped using nice_exit or its cache is closing, client may > fail due to UnavailableSecurityManagerException > -- > > Key: GEODE-9811 > URL: https://issues.apache.org/jira/browse/GEODE-9811 > Project: Geode > Issue Type: Bug > Components: core, security >Affects Versions: 1.14.0 >Reporter: Joris Melchior >Assignee: Joris Melchior >Priority: Major > Labels: GeodeOperationAPI, pull-request-available, unreleased > Fix For: 1.15.0 > > > Due to the sequence of events occurring when a server is shutting down it's > possible for some transactions to not be able to get the security manager > while performing an operation. > Currently the operation fails without retry while the correct behaviour would > be to try and retry the operation at least once on another member. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9554) Rebalancing a region with multiple redundancy zones can fail
[ https://issues.apache.org/jira/browse/GEODE-9554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9554: - Labels: pull-request-available unreleased (was: pull-request-available) > Rebalancing a region with multiple redundancy zones can fail > > > Key: GEODE-9554 > URL: https://issues.apache.org/jira/browse/GEODE-9554 > Project: Geode > Issue Type: Bug > Components: core >Affects Versions: 1.12.4, 1.13.4, 1.14.0, 1.15.0 >Reporter: Mark Hanson >Assignee: Mark Hanson >Priority: Major > Labels: pull-request-available, unreleased > Fix For: 1.12.5, 1.13.5, 1.14.1, 1.15.0 > > > When attempting to rebalance a region with multiple redundancy zones, the > code does not distinguish between zones when deleting redundant bucket > copies. This can mean that a bucket from a different zone gets deleted > leaving the servers in a state of reduced redundancy. -- This message was sent by Atlassian Jira (v8.20.1#820001)
