[jira] [Commented] (GEODE-9819) Client socket leak in CacheClientNotifier.registerClientInternal when error conditions occur for the durable client
[
https://issues.apache.org/jira/browse/GEODE-9819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17475878#comment-17475878
]
ASF subversion and git services commented on GEODE-9819:
Commit 14e92a03ad51b27e441385771d3ebdef73399d76 in geode's branch
refs/heads/support/1.14 from Darrel Schneider
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=14e92a0 ]
GEODE-9819: fix durable client socket leak (#7266)
Added unit test that reproduced the socket leak.
This involved some change to the product classes
to make them unit testable.
Fixed the leak by making sure socket.close is called
if the response code was not successful.
(cherry picked from commit 97601eb2cd585f844b7f02bb73ba42fcb86a7cb4)
> Client socket leak in CacheClientNotifier.registerClientInternal when error
> conditions occur for the durable client
> ---
>
> Key: GEODE-9819
> URL: https://issues.apache.org/jira/browse/GEODE-9819
> Project: Geode
> Issue Type: Bug
> Components: client/server, core
>Affects Versions: 1.12.5, 1.13.4, 1.14.0, 1.15.0
>Reporter: Leon Finker
>Assignee: Darrel Schneider
>Priority: Critical
> Labels: GeodeOperationAPI, blocks-1.15.0, pull-request-available
> Fix For: 1.14.4, 1.15.0
>
>
> In CacheClientNotifier.registerClientInternal client socket can be left half
> open and not properly closed when error conditions occur. Such as the case of:
> {code:java}
> } else {
> // The existing proxy is already running (which means that another
> // client is already using this durable id.
> unsuccessfulMsg =
> String.format(
> "The requested durable client has the same identifier ( %s ) as an
> existing durable client ( %s ). Duplicate durable clients are not allowed.",
> clientProxyMembershipID.getDurableId(), cacheClientProxy);
> logger.warn(unsuccessfulMsg);
> // Set the unsuccessful response byte.
> responseByte = Handshake.REPLY_EXCEPTION_DUPLICATE_DURABLE_CLIENT;
> } {code}
> It considers the current client connect attempt to have failed. It writes
> this response back to client: REPLY_EXCEPTION_DUPLICATE_DURABLE_CLIENT. This
> will cause the client to throw ServerRefusedConnectionException. What seems
> wrong about this method is that even though it sets "unsuccessfulMsg" and
> correctly sends back a handshake saying the client is rejected, it does not
> throw an exception and it does not close "socket". I think right before it
> calls performPostAuthorization it should do the followiing:
> {code:java}
> if (unsuccessfulMsg != null) {
> try {
> socket.close();
> } catch (IOException ignore) {
> }
> } else {
> performPostAuthorization(...)
> }{code}
> Full discussion details can be found at
> https://markmail.org/thread/2gqmbq2m57pz7pxu
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9819) Client socket leak in CacheClientNotifier.registerClientInternal when error conditions occur for the durable client
[
https://issues.apache.org/jira/browse/GEODE-9819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider updated GEODE-9819:
Fix Version/s: 1.14.4
> Client socket leak in CacheClientNotifier.registerClientInternal when error
> conditions occur for the durable client
> ---
>
> Key: GEODE-9819
> URL: https://issues.apache.org/jira/browse/GEODE-9819
> Project: Geode
> Issue Type: Bug
> Components: client/server, core
>Affects Versions: 1.12.5, 1.13.4, 1.14.0, 1.15.0
>Reporter: Leon Finker
>Assignee: Darrel Schneider
>Priority: Critical
> Labels: GeodeOperationAPI, blocks-1.15.0, pull-request-available
> Fix For: 1.14.4, 1.15.0
>
>
> In CacheClientNotifier.registerClientInternal client socket can be left half
> open and not properly closed when error conditions occur. Such as the case of:
> {code:java}
> } else {
> // The existing proxy is already running (which means that another
> // client is already using this durable id.
> unsuccessfulMsg =
> String.format(
> "The requested durable client has the same identifier ( %s ) as an
> existing durable client ( %s ). Duplicate durable clients are not allowed.",
> clientProxyMembershipID.getDurableId(), cacheClientProxy);
> logger.warn(unsuccessfulMsg);
> // Set the unsuccessful response byte.
> responseByte = Handshake.REPLY_EXCEPTION_DUPLICATE_DURABLE_CLIENT;
> } {code}
> It considers the current client connect attempt to have failed. It writes
> this response back to client: REPLY_EXCEPTION_DUPLICATE_DURABLE_CLIENT. This
> will cause the client to throw ServerRefusedConnectionException. What seems
> wrong about this method is that even though it sets "unsuccessfulMsg" and
> correctly sends back a handshake saying the client is rejected, it does not
> throw an exception and it does not close "socket". I think right before it
> calls performPostAuthorization it should do the followiing:
> {code:java}
> if (unsuccessfulMsg != null) {
> try {
> socket.close();
> } catch (IOException ignore) {
> }
> } else {
> performPostAuthorization(...)
> }{code}
> Full discussion details can be found at
> https://markmail.org/thread/2gqmbq2m57pz7pxu
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9965) geode release should not delete Kafka connector release
[ https://issues.apache.org/jira/browse/GEODE-9965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9965: -- Labels: needsTriage pull-request-available (was: needsTriage) > geode release should not delete Kafka connector release > --- > > Key: GEODE-9965 > URL: https://issues.apache.org/jira/browse/GEODE-9965 > Project: Geode > Issue Type: Bug > Components: release >Reporter: Owen Nichols >Priority: Major > Labels: needsTriage, pull-request-available > > logic intended to retain 3 most-recent Geode minors inadvertently deleted > kafka-connector-1.1.0, which is on a separate release track but shares the > same release location in ASF -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-9965) geode release should not delete Kafka connector release
Owen Nichols created GEODE-9965: --- Summary: geode release should not delete Kafka connector release Key: GEODE-9965 URL: https://issues.apache.org/jira/browse/GEODE-9965 Project: Geode Issue Type: Bug Components: release Reporter: Owen Nichols logic intended to retain 3 most-recent Geode minors inadvertently deleted kafka-connector-1.1.0, which is on a separate release track but shares the same release location in ASF -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9965) geode release should not delete Kafka connector release
[ https://issues.apache.org/jira/browse/GEODE-9965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-9965: - Labels: needsTriage (was: ) > geode release should not delete Kafka connector release > --- > > Key: GEODE-9965 > URL: https://issues.apache.org/jira/browse/GEODE-9965 > Project: Geode > Issue Type: Bug > Components: release >Reporter: Owen Nichols >Priority: Major > Labels: needsTriage > > logic intended to retain 3 most-recent Geode minors inadvertently deleted > kafka-connector-1.1.0, which is on a separate release track but shares the > same release location in ASF -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9937) Add convenience methods to FileWatchingX509Extended*Manager
[ https://issues.apache.org/jira/browse/GEODE-9937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17475835#comment-17475835 ] ASF subversion and git services commented on GEODE-9937: Commit 93fdcccf19538562e932471c5711f26a295155ea in geode's branch refs/heads/develop from Jens Deppe [ https://gitbox.apache.org/repos/asf?p=geode.git;h=93fdccc ] GEODE-9937: Add convenience methods to FileWatchingX509Extended*Manager (#7251) > Add convenience methods to FileWatchingX509Extended*Manager > --- > > Key: GEODE-9937 > URL: https://issues.apache.org/jira/browse/GEODE-9937 > Project: Geode > Issue Type: Improvement > Components: security >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9925) Update LICENSE and notice for confluent connector
[ https://issues.apache.org/jira/browse/GEODE-9925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9925: -- Labels: pull-request-available (was: ) > Update LICENSE and notice for confluent connector > - > > Key: GEODE-9925 > URL: https://issues.apache.org/jira/browse/GEODE-9925 > Project: Geode > Issue Type: Bug > Components: extensions >Reporter: Dan Smith >Priority: Major > Labels: pull-request-available > > The geode-confluent-connector is bundling geode-core and it's third party > dependencies in the binary distribution. The LICENSE and NOTICE for the > binary distribution need to reflect this and include information related to > third party licenses. See the geode-core LICENSE and NOTICE files for example > - > [https://github.com/apache/geode/tree/develop/geode-assembly/src/main/dist.] > Perhaps we can just copy these in the geode-confluent-connectors LICENSE and > NOTICE? -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9925) Update LICENSE and notice for confluent connector
[ https://issues.apache.org/jira/browse/GEODE-9925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17475823#comment-17475823 ] ASF GitHub Bot commented on GEODE-9925: --- upthewaterspout opened a new pull request #18: URL: https://github.com/apache/geode-kafka-connector/pull/18 The kafka connector binary zip distribution includes apache geode and all it's dependencies, some of which are not apache licensed. Creating a LICENSE and NOTICE for the binary distribution, which are copied from Apache Geodes LICENSE and NOTICE. Changing the build to include these files in the doc directory of the binary distribution. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Update LICENSE and notice for confluent connector > - > > Key: GEODE-9925 > URL: https://issues.apache.org/jira/browse/GEODE-9925 > Project: Geode > Issue Type: Bug > Components: extensions >Reporter: Dan Smith >Priority: Major > > The geode-confluent-connector is bundling geode-core and it's third party > dependencies in the binary distribution. The LICENSE and NOTICE for the > binary distribution need to reflect this and include information related to > third party licenses. See the geode-core LICENSE and NOTICE files for example > - > [https://github.com/apache/geode/tree/develop/geode-assembly/src/main/dist.] > Perhaps we can just copy these in the geode-confluent-connectors LICENSE and > NOTICE? -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-6751) CI failure: AcceptanceTestOpenJDK8 ConnectCommandAcceptanceTest.useCurrentGfshToConnectToOlderLocator failure
[ https://issues.apache.org/jira/browse/GEODE-6751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17475736#comment-17475736 ] Geode Integration commented on GEODE-6751: -- Seen in [upgrade-test-openjdk8 #94|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/upgrade-test-openjdk8/builds/94] ... see [test results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0780/test-results/upgradeTest/1642042948/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0780/test-artifacts/1642042948/upgradetestfiles-openjdk8-1.15.0-build.0780.tgz]. > CI failure: AcceptanceTestOpenJDK8 > ConnectCommandAcceptanceTest.useCurrentGfshToConnectToOlderLocator failure > - > > Key: GEODE-6751 > URL: https://issues.apache.org/jira/browse/GEODE-6751 > Project: Geode > Issue Type: Bug > Components: management >Affects Versions: 1.15.0 >Reporter: Scott Jewell >Priority: Major > > Assertion failure in > ConnectCommandAcceptanceTest.useCurrentGfshToConnectToOlderLocator > Appears to be a new bug > org.apache.geode.management.internal.cli.commands.ConnectCommandAcceptanceTest > > useCurrentGfshToConnectToOlderLocator FAILED > java.lang.AssertionError: > Expecting: > <" > (1) Executing - connect > Connecting to Locator at [host=localhost, port=10334] .. > Exception caused JMX Manager startup to fail because: 'HTTP service > failed to start' > "> > to contain: > <"Cannot use a"> > at > org.apache.geode.management.internal.cli.commands.ConnectCommandAcceptanceTest.useCurrentGfshToConnectToOlderLocator(ConnectCommandAcceptanceTest.java:50) > 60 tests completed, 1 failed > =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > [*http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0258/test-results/acceptanceTest/1557290414/*] > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Test report artifacts from this job are available at: > [*http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0258/test-artifacts/1557290414/acceptancetestfiles-OpenJDK8-1.10.0-SNAPSHOT.0258.tgz*] > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9964) ExplicitMoveDirector incorrectly compares Member with InternalDistributedMember.
[
https://issues.apache.org/jira/browse/GEODE-9964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-9964:
-
Labels: needsTriage (was: )
> ExplicitMoveDirector incorrectly compares Member with
> InternalDistributedMember.
>
>
> Key: GEODE-9964
> URL: https://issues.apache.org/jira/browse/GEODE-9964
> Project: Geode
> Issue Type: Bug
> Components: core
>Affects Versions: 1.14.2, 1.15.0
>Reporter: Jacob Barrett
>Priority: Major
> Labels: needsTriage
>
> {{ExplicitMoveDirector}} incorrectly compares {{Member}} with
> {{InternalDistributedMember}} due use of raw types rather than generics. It
> is also likely there is either no testing for this failure case or the test
> is passing for the wrong reasons.
> See
> [here|https://github.com/apache/geode/blob/2b032440eb9d0f3c68a94602289cc41435c68fad/geode-core/src/main/java/org/apache/geode/internal/cache/partitioned/rebalance/ExplicitMoveDirector.java#L93]
> See
> [here|https://github.com/apache/geode/blob/2b032440eb9d0f3c68a94602289cc41435c68fad/geode-core/src/main/java/org/apache/geode/internal/cache/partitioned/rebalance/ExplicitMoveDirector.java#L99]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-9964) ExplicitMoveDirector incorrectly compares Member with InternalDistributedMember.
Jacob Barrett created GEODE-9964:
Summary: ExplicitMoveDirector incorrectly compares Member with
InternalDistributedMember.
Key: GEODE-9964
URL: https://issues.apache.org/jira/browse/GEODE-9964
Project: Geode
Issue Type: Bug
Components: core
Affects Versions: 1.14.2, 1.15.0
Reporter: Jacob Barrett
{{ExplicitMoveDirector}} incorrectly compares {{Member}} with
{{InternalDistributedMember}} due use of raw types rather than generics. It is
also likely there is either no testing for this failure case or the test is
passing for the wrong reasons.
See
[here|https://github.com/apache/geode/blob/2b032440eb9d0f3c68a94602289cc41435c68fad/geode-core/src/main/java/org/apache/geode/internal/cache/partitioned/rebalance/ExplicitMoveDirector.java#L93]
See
[here|https://github.com/apache/geode/blob/2b032440eb9d0f3c68a94602289cc41435c68fad/geode-core/src/main/java/org/apache/geode/internal/cache/partitioned/rebalance/ExplicitMoveDirector.java#L99]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9737) CI failure in TomcatSessionBackwardsCompatibilityTomcat7079WithOldModulesMixedWithCurrentCanDoPutFromCurrentModuleTest
[
https://issues.apache.org/jira/browse/GEODE-9737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wayne updated GEODE-9737:
-
Labels: blocks-1.15.0 release-blocker (was: release-blocker)
> CI failure in
> TomcatSessionBackwardsCompatibilityTomcat7079WithOldModulesMixedWithCurrentCanDoPutFromCurrentModuleTest
> --
>
> Key: GEODE-9737
> URL: https://issues.apache.org/jira/browse/GEODE-9737
> Project: Geode
> Issue Type: Bug
> Components: http session
>Affects Versions: 1.15.0
>Reporter: Kamilla Aslami
>Assignee: Benjamin P Ross
>Priority: Major
> Labels: blocks-1.15.0, release-blocker
> Attachments: gemfire.log
>
>
> {noformat}
> TomcatSessionBackwardsCompatibilityTomcat7079WithOldModulesMixedWithCurrentCanDoPutFromCurrentModuleTest
> > test[0] FAILED
> java.lang.RuntimeException: Something very bad happened when trying to
> start container
> TOMCAT7_client-server_test0_1_dd13a1a6-effb-4430-8ccd-ee6c9142938c_
> at
> org.apache.geode.session.tests.ContainerManager.startContainer(ContainerManager.java:82)
> at
> org.apache.geode.session.tests.ContainerManager.startContainers(ContainerManager.java:93)
> at
> org.apache.geode.session.tests.ContainerManager.startAllInactiveContainers(ContainerManager.java:101)
> at
> org.apache.geode.session.tests.TomcatSessionBackwardsCompatibilityTestBase.doPutAndGetSessionOnAllClients(TomcatSessionBackwardsCompatibilityTestBase.java:187)
> at
> org.apache.geode.session.tests.TomcatSessionBackwardsCompatibilityTomcat7079WithOldModulesMixedWithCurrentCanDoPutFromCurrentModuleTest.test(TomcatSessionBackwardsCompatibilityTomcat7079WithOldModulesMixedWithCurrentCanDoPutFromCurrentModuleTest.java:36)
> Caused by:
> java.lang.RuntimeException: Something very bad happened to this
> container when starting. Check the cargo_logs folder for container logs.
> at
> org.apache.geode.session.tests.ServerContainer.start(ServerContainer.java:220)
> at
> org.apache.geode.session.tests.ContainerManager.startContainer(ContainerManager.java:79)
> ... 4 more
> Caused by:
> org.codehaus.cargo.container.ContainerException: Deployable
> [http://localhost:26322/cargocpc/index.html] failed to finish deploying
> within the timeout period [12]. The Deployable state is thus unknown.
> at
> org.codehaus.cargo.container.spi.deployer.DeployerWatchdog.watch(DeployerWatchdog.java:111)
> at
> org.codehaus.cargo.container.spi.AbstractLocalContainer.waitForCompletion(AbstractLocalContainer.java:387)
> at
> org.codehaus.cargo.container.spi.AbstractLocalContainer.start(AbstractLocalContainer.java:234)
> at
> org.apache.geode.session.tests.ServerContainer.start(ServerContainer.java:218)
> ... 5 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-9829) SINTER Command Supported
[ https://issues.apache.org/jira/browse/GEODE-9829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bala Tripura Sundari Kaza Venkata reassigned GEODE-9829: Assignee: Bala Tripura Sundari Kaza Venkata > SINTER Command Supported > > > Key: GEODE-9829 > URL: https://issues.apache.org/jira/browse/GEODE-9829 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Wayne >Assignee: Bala Tripura Sundari Kaza Venkata >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > The SINTER command has been implemented but lacks sufficient testing to > ensure that the implementation is robust and does not regress in the future. > > Write unit/integration tests that run against both Geode Redis and native > Redis, and dunit tests which test multiple concurrent clients accessing > different servers. > > +Acceptance Criteria+ > > Passing Unit/integration tests for both Geode and native Redis. The > RedisCommandType class and > README/redis_api_for_[geode.html.md.erb|http://geode.html.md.erb/] updated to > make command "supported". Stories in the backlog to fix the identified issues > (with JIRA tickets) and problem tests that are ignored should be fixed and > enabled. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (GEODE-9963) Test
[ https://issues.apache.org/jira/browse/GEODE-9963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wayne closed GEODE-9963. This ticket was created as an experiment for attempting to diagnose Bala's Jira permission issues. > Test > > > Key: GEODE-9963 > URL: https://issues.apache.org/jira/browse/GEODE-9963 > Project: Geode > Issue Type: Bug >Reporter: Bala Tripura Sundari Kaza Venkata >Priority: Major > Labels: needsTriage > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9963) Test
[ https://issues.apache.org/jira/browse/GEODE-9963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-9963: - Labels: needsTriage (was: ) > Test > > > Key: GEODE-9963 > URL: https://issues.apache.org/jira/browse/GEODE-9963 > Project: Geode > Issue Type: Bug >Reporter: Bala Tripura Sundari Kaza Venkata >Priority: Major > Labels: needsTriage > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-9963) Test
Bala Tripura Sundari Kaza Venkata created GEODE-9963: Summary: Test Key: GEODE-9963 URL: https://issues.apache.org/jira/browse/GEODE-9963 Project: Geode Issue Type: Bug Reporter: Bala Tripura Sundari Kaza Venkata -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-9963) Test
[ https://issues.apache.org/jira/browse/GEODE-9963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bala Tripura Sundari Kaza Venkata resolved GEODE-9963. -- Resolution: Invalid > Test > > > Key: GEODE-9963 > URL: https://issues.apache.org/jira/browse/GEODE-9963 > Project: Geode > Issue Type: Bug >Reporter: Bala Tripura Sundari Kaza Venkata >Priority: Major > Labels: needsTriage > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9962) SPIKE: Redis INFO Command Support for Cluster Mode
[ https://issues.apache.org/jira/browse/GEODE-9962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wayne updated GEODE-9962: - Labels: blocks-1.15.0 (was: ) > SPIKE: Redis INFO Command Support for Cluster Mode > -- > > Key: GEODE-9962 > URL: https://issues.apache.org/jira/browse/GEODE-9962 > Project: Geode > Issue Type: Task > Components: redis >Affects Versions: 1.15.0 >Reporter: Wayne >Priority: Major > Labels: blocks-1.15.0 > > The Redis INFO command does not show correct information for cluster mode. > > Research what changes must occur to support the correct information for > cluster mode and ensure tickets are created for tracking. > > +Acceptance Criteria+ > > Gaps in cluster mode supported are identified and tickets are created for > tracking. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-9962) SPIKE: Redis INFO Command Support for Cluster Mode
Wayne created GEODE-9962: Summary: SPIKE: Redis INFO Command Support for Cluster Mode Key: GEODE-9962 URL: https://issues.apache.org/jira/browse/GEODE-9962 Project: Geode Issue Type: Task Components: redis Affects Versions: 1.15.0 Reporter: Wayne The Redis INFO command does not show correct information for cluster mode. Research what changes must occur to support the correct information for cluster mode and ensure tickets are created for tracking. +Acceptance Criteria+ Gaps in cluster mode supported are identified and tickets are created for tracking. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9829) SINTER Command Supported
[ https://issues.apache.org/jira/browse/GEODE-9829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristen updated GEODE-9829: --- Fix Version/s: 1.15.0 > SINTER Command Supported > > > Key: GEODE-9829 > URL: https://issues.apache.org/jira/browse/GEODE-9829 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Wayne >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > The SINTER command has been implemented but lacks sufficient testing to > ensure that the implementation is robust and does not regress in the future. > > Write unit/integration tests that run against both Geode Redis and native > Redis, and dunit tests which test multiple concurrent clients accessing > different servers. > > +Acceptance Criteria+ > > Passing Unit/integration tests for both Geode and native Redis. The > RedisCommandType class and > README/redis_api_for_[geode.html.md.erb|http://geode.html.md.erb/] updated to > make command "supported". Stories in the backlog to fix the identified issues > (with JIRA tickets) and problem tests that are ignored should be fixed and > enabled. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-9944) NPE could occur if HARegion is being created again but not fully initialized
[
https://issues.apache.org/jira/browse/GEODE-9944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Shu resolved GEODE-9944.
-
Fix Version/s: 1.15.0
Resolution: Fixed
> NPE could occur if HARegion is being created again but not fully initialized
> -
>
> Key: GEODE-9944
> URL: https://issues.apache.org/jira/browse/GEODE-9944
> Project: Geode
> Issue Type: Bug
> Components: client queues
>Affects Versions: 1.15.0
>Reporter: Eric Shu
>Assignee: Eric Shu
>Priority: Major
> Labels: GeodeOperationAPI, needsTriage, pull-request-available
> Fix For: 1.15.0
>
>
> The stack trace for the NPE is:
> {noformat}
> fatal 2022/01/08 12:45:33.175 PST bridgegemfire7_host1_25026 Processor 7> tid=0x148] Uncaught exception processing
> QueueSynchronizationProcessor$QueueSynchronizationMessage@340d586b
> processorId=4029
> sender=rs-FullRegression15142100a3i3large-hydra-client-18(bridgegemfire6_host1_25009:25009):41006
> java.lang.NullPointerException
> at
> org.apache.geode.internal.cache.ha.QueueSynchronizationProcessor$QueueSynchronizationMessage.getDispatchedEvents(QueueSynchronizationProcessor.java:160)
> at
> org.apache.geode.internal.cache.ha.QueueSynchronizationProcessor$QueueSynchronizationMessage.process(QueueSynchronizationProcessor.java:127)
> at
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376)
> at
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:441)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:444)
> at
> org.apache.geode.distributed.internal.ClusterOperationExecutors.doProcessingThread(ClusterOperationExecutors.java:391)
> at
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> This could occur when a client is not able to re-auth in time, and the server
> removes the HARegionQueue to the client. When the client is able to re-auth
> later, the new HARegionQueue is created again. There is a race that when the
> server process the above message, the HARegionQueue is not fully initialized
> and cause this NPE.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9944) NPE could occur if HARegion is being created again but not fully initialized
[
https://issues.apache.org/jira/browse/GEODE-9944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17475572#comment-17475572
]
ASF subversion and git services commented on GEODE-9944:
Commit 2b032440eb9d0f3c68a94602289cc41435c68fad in geode's branch
refs/heads/develop from Eric Shu
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=2b03244 ]
GEODE-9944: Handle a race when HARegionQueue is not initialized yet. (#7259)
> NPE could occur if HARegion is being created again but not fully initialized
> -
>
> Key: GEODE-9944
> URL: https://issues.apache.org/jira/browse/GEODE-9944
> Project: Geode
> Issue Type: Bug
> Components: client queues
>Affects Versions: 1.15.0
>Reporter: Eric Shu
>Assignee: Eric Shu
>Priority: Major
> Labels: GeodeOperationAPI, needsTriage, pull-request-available
>
> The stack trace for the NPE is:
> {noformat}
> fatal 2022/01/08 12:45:33.175 PST bridgegemfire7_host1_25026 Processor 7> tid=0x148] Uncaught exception processing
> QueueSynchronizationProcessor$QueueSynchronizationMessage@340d586b
> processorId=4029
> sender=rs-FullRegression15142100a3i3large-hydra-client-18(bridgegemfire6_host1_25009:25009):41006
> java.lang.NullPointerException
> at
> org.apache.geode.internal.cache.ha.QueueSynchronizationProcessor$QueueSynchronizationMessage.getDispatchedEvents(QueueSynchronizationProcessor.java:160)
> at
> org.apache.geode.internal.cache.ha.QueueSynchronizationProcessor$QueueSynchronizationMessage.process(QueueSynchronizationProcessor.java:127)
> at
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376)
> at
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:441)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:444)
> at
> org.apache.geode.distributed.internal.ClusterOperationExecutors.doProcessingThread(ClusterOperationExecutors.java:391)
> at
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> This could occur when a client is not able to re-auth in time, and the server
> removes the HARegionQueue to the client. When the client is able to re-auth
> later, the new HARegionQueue is created again. There is a race that when the
> server process the above message, the HARegionQueue is not fully initialized
> and cause this NPE.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-9961) Server restart during processing of incoming batches, causes infinite loop till cache is closed.
[ https://issues.apache.org/jira/browse/GEODE-9961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Ivanac reassigned GEODE-9961: --- Assignee: Mario Ivanac > Server restart during processing of incoming batches, causes infinite loop > till cache is closed. > > > Key: GEODE-9961 > URL: https://issues.apache.org/jira/browse/GEODE-9961 > Project: Geode > Issue Type: Bug > Components: wan >Reporter: Mario Ivanac >Assignee: Mario Ivanac >Priority: Major > Labels: needsTriage > > Server restart during processing of incoming batches, causes infinite loop > till cache is closed. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9961) Server restart during processing of incoming batches, causes infinite loop till cache is closed.
[ https://issues.apache.org/jira/browse/GEODE-9961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-9961: - Labels: needsTriage (was: ) > Server restart during processing of incoming batches, causes infinite loop > till cache is closed. > > > Key: GEODE-9961 > URL: https://issues.apache.org/jira/browse/GEODE-9961 > Project: Geode > Issue Type: Bug > Components: wan >Reporter: Mario Ivanac >Priority: Major > Labels: needsTriage > > Server restart during processing of incoming batches, causes infinite loop > till cache is closed. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-9961) Server restart during processing of incoming batches, causes infinite loop till cache is closed.
Mario Ivanac created GEODE-9961: --- Summary: Server restart during processing of incoming batches, causes infinite loop till cache is closed. Key: GEODE-9961 URL: https://issues.apache.org/jira/browse/GEODE-9961 Project: Geode Issue Type: Bug Components: wan Reporter: Mario Ivanac Server restart during processing of incoming batches, causes infinite loop till cache is closed. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-9889) LettucePubSubIntegrationTest > subscribePsubscribeSameClient FAILED
[
https://issues.apache.org/jira/browse/GEODE-9889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hale Bales resolved GEODE-9889.
---
Resolution: Cannot Reproduce
Could not reproduce on 1.14 or develop. Given that this failure has only failed
twice on 1.14, and the code it tests has been completely reworked in 1.15, this
issue is not worth pursuing further at this time.
> LettucePubSubIntegrationTest > subscribePsubscribeSameClient FAILED
> ---
>
> Key: GEODE-9889
> URL: https://issues.apache.org/jira/browse/GEODE-9889
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.14.0
>Reporter: Ray Ingles
>Assignee: Hale Bales
>Priority: Major
>
> Seen in a CI build:
>
> {{> Task :geode-apis-compatible-with-redis:integrationTest}}
> {{org.apache.geode.redis.internal.executor.pubsub.LettucePubSubIntegrationTest
> > subscribePsubscribeSameClient FAILED}}
> {{org.junit.ComparisonFailure: expected:<[2]L> but was:<[0]L>}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-9892) Create Infrastructure for Redis Lists
[ https://issues.apache.org/jira/browse/GEODE-9892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ray Ingles reassigned GEODE-9892: - Assignee: Ray Ingles > Create Infrastructure for Redis Lists > - > > Key: GEODE-9892 > URL: https://issues.apache.org/jira/browse/GEODE-9892 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Assignee: Ray Ingles >Priority: Major > > Create the infrastructure for supporting Redis Lists including: > * Use of the appropriate underlying Java collection > * Implementing the [LPUSH|https://redis.io/commands/lpush] Command > * Implementing the [LRANGE|https://redis.io/commands/lrange] command > +Acceptance Critera+ > The LPUSH and LRANGE commands have been implemented with appropriate unit > testing. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9829) SINTER Command Supported
[ https://issues.apache.org/jira/browse/GEODE-9829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17475534#comment-17475534 ] ASF subversion and git services commented on GEODE-9829: Commit 4a688b0f8c9a91948bf75ade0c03a2e66032ff3c in geode's branch refs/heads/develop from Bala Kaza Venkata [ https://gitbox.apache.org/repos/asf?p=geode.git;h=4a688b0 ] GEODE-9829: Add SINTER command to Redis supported commands. (#7236) SINTER command is implemented and integration tests and added to test this command. Co-authored-by: Bala Kaza Venkata Co-authored-by: Steve Sienkowski Co-authored-by: Kristen Oduca > SINTER Command Supported > > > Key: GEODE-9829 > URL: https://issues.apache.org/jira/browse/GEODE-9829 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Wayne >Priority: Major > Labels: pull-request-available > > The SINTER command has been implemented but lacks sufficient testing to > ensure that the implementation is robust and does not regress in the future. > > Write unit/integration tests that run against both Geode Redis and native > Redis, and dunit tests which test multiple concurrent clients accessing > different servers. > > +Acceptance Criteria+ > > Passing Unit/integration tests for both Geode and native Redis. The > RedisCommandType class and > README/redis_api_for_[geode.html.md.erb|http://geode.html.md.erb/] updated to > make command "supported". Stories in the backlog to fix the identified issues > (with JIRA tickets) and problem tests that are ignored should be fixed and > enabled. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-9960) Remove support for strong name signing of assemblies
Blake Bender created GEODE-9960: --- Summary: Remove support for strong name signing of assemblies Key: GEODE-9960 URL: https://issues.apache.org/jira/browse/GEODE-9960 Project: Geode Issue Type: Task Components: native client Reporter: Blake Bender This has historically caused problems in builds and CI pipelines. Microsoft has recognized that it's not actually solving the problems originally intended, and has removed any code that uses it from .net 5 and .net core. We could continue to build with it, but literally nothing would use it, so let's get rid of another weird vestigial artifact from our Windows support. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-9959) Add FQDN during SSL handshake error while reaching a locator
[ https://issues.apache.org/jira/browse/GEODE-9959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Salazar de Torres reassigned GEODE-9959: -- Assignee: Mario Salazar de Torres > Add FQDN during SSL handshake error while reaching a locator > > > Key: GEODE-9959 > URL: https://issues.apache.org/jira/browse/GEODE-9959 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: pull-request-available > > *WHEN* a geode-native client tries to reach a locator > *AND* the locator being reached has SSL configured > *BUT* the geode-native client does not have SSL configured > *THEN* a log will be written indicating the issue > *AND* an AuthenticationRequiredException exception will be thrown, which > can't be catched > The improvement proposed here is to log the FQDN of the locator being reached > in order to have further information when troubleshooting this kind of issues. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9959) Add FQDN during SSL handshake error while reaching a locator
[ https://issues.apache.org/jira/browse/GEODE-9959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17475392#comment-17475392 ] ASF GitHub Bot commented on GEODE-9959: --- gaussianrecurrence opened a new pull request #904: URL: https://github.com/apache/geode-native/pull/904 - Whenever there is an SSL missoconfiguration while trying to reach a locator, an AuthenticationRequiredException is thrown and a log is written. Currently FQDN of the locator is not logged. - This commit adds the locator FQDN in order to further troubleshoot this kind of scenarios. - Also, in order to ease implementation, toString method was implemented for ServerLocation. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Add FQDN during SSL handshake error while reaching a locator > > > Key: GEODE-9959 > URL: https://issues.apache.org/jira/browse/GEODE-9959 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Salazar de Torres >Priority: Major > Labels: pull-request-available > > *WHEN* a geode-native client tries to reach a locator > *AND* the locator being reached has SSL configured > *BUT* the geode-native client does not have SSL configured > *THEN* a log will be written indicating the issue > *AND* an AuthenticationRequiredException exception will be thrown, which > can't be catched > The improvement proposed here is to log the FQDN of the locator being reached > in order to have further information when troubleshooting this kind of issues. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9959) Add FQDN during SSL handshake error while reaching a locator
[ https://issues.apache.org/jira/browse/GEODE-9959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17475242#comment-17475242 ] ASF GitHub Bot commented on GEODE-9959: --- gaussianrecurrence closed pull request #903: URL: https://github.com/apache/geode-native/pull/903 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Add FQDN during SSL handshake error while reaching a locator > > > Key: GEODE-9959 > URL: https://issues.apache.org/jira/browse/GEODE-9959 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Salazar de Torres >Priority: Major > Labels: pull-request-available > > *WHEN* a geode-native client tries to reach a locator > *AND* the locator being reached has SSL configured > *BUT* the geode-native client does not have SSL configured > *THEN* a log will be written indicating the issue > *AND* an AuthenticationRequiredException exception will be thrown, which > can't be catched > The improvement proposed here is to log the FQDN of the locator being reached > in order to have further information when troubleshooting this kind of issues. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9959) Add FQDN during SSL handshake error while reaching a locator
[ https://issues.apache.org/jira/browse/GEODE-9959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17475240#comment-17475240 ] ASF GitHub Bot commented on GEODE-9959: --- gaussianrecurrence opened a new pull request #903: URL: https://github.com/apache/geode-native/pull/903 - Whenever there is an SSL missoconfiguration while trying to reach a locator, an AuthenticationRequiredException is thrown and a log is written. Currently FQDN of the locator is not logged. - This commit adds the locator FQDN in order to further troubleshoot this kind of scenarios. - Also, in order to ease implementation, toString method was implemented for ServerLocation. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Add FQDN during SSL handshake error while reaching a locator > > > Key: GEODE-9959 > URL: https://issues.apache.org/jira/browse/GEODE-9959 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Salazar de Torres >Priority: Major > > *WHEN* a geode-native client tries to reach a locator > *AND* the locator being reached has SSL configured > *BUT* the geode-native client does not have SSL configured > *THEN* a log will be written indicating the issue > *AND* an AuthenticationRequiredException exception will be thrown, which > can't be catched > The improvement proposed here is to log the FQDN of the locator being reached > in order to have further information when troubleshooting this kind of issues. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9959) Add FQDN during SSL handshake error while reaching a locator
[ https://issues.apache.org/jira/browse/GEODE-9959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9959: -- Labels: pull-request-available (was: ) > Add FQDN during SSL handshake error while reaching a locator > > > Key: GEODE-9959 > URL: https://issues.apache.org/jira/browse/GEODE-9959 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Salazar de Torres >Priority: Major > Labels: pull-request-available > > *WHEN* a geode-native client tries to reach a locator > *AND* the locator being reached has SSL configured > *BUT* the geode-native client does not have SSL configured > *THEN* a log will be written indicating the issue > *AND* an AuthenticationRequiredException exception will be thrown, which > can't be catched > The improvement proposed here is to log the FQDN of the locator being reached > in order to have further information when troubleshooting this kind of issues. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9753) Coredump during PdxSerializable object serialization
[ https://issues.apache.org/jira/browse/GEODE-9753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17475212#comment-17475212 ] ASF GitHub Bot commented on GEODE-9753: --- gaussianrecurrence commented on pull request #891: URL: https://github.com/apache/geode-native/pull/891#issuecomment-1011957005 I am reviewing all of my pending PRs, and this has been awating review for quite some time. Maybe @pdxcodemonkey, @pivotal-jbarrett @albertogpz @mkevo @jvarenina or anyone else could take a look at it and provide some feedback? Thanks! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Coredump during PdxSerializable object serialization > > > Key: GEODE-9753 > URL: https://issues.apache.org/jira/browse/GEODE-9753 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: needsTriage, pull-request-available > > *GIVEN* **a single server and locator cluster with 1 PdxSerializable class > registered, named Order > *AND* a geode-native client with 1 PdxSerializable 1 PdxSerializable class > registered, named Order > *WHEN* a Order object is tried to be serialized > *WHILE* the cluster is being restarted > *THEN* a coredump happens due to PdxType=nullptr > — > *Additional information*. As seen by early troubleshooting, the coredump > happens because the pdx type is tried to be fetched from the PdxTypeRegist by > its class name, but the PdxTypeRegistry is cleaned up during serialization > given that subscription redundancy was lost. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9959) Add FQDN during SSL handshake error while reaching a locator
[ https://issues.apache.org/jira/browse/GEODE-9959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Salazar de Torres updated GEODE-9959: --- Summary: Add FQDN during SSL handshake error while reaching a locator (was: Add FQDN during SSL handshake error when reaching a locator) > Add FQDN during SSL handshake error while reaching a locator > > > Key: GEODE-9959 > URL: https://issues.apache.org/jira/browse/GEODE-9959 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Salazar de Torres >Priority: Major > > *WHEN* a geode-native client tries to reach a locator > *AND* the locator being reached has SSL configured > *BUT* the geode-native client does not have SSL configured > *THEN* a log will be written indicating the issue > *AND* an AuthenticationRequiredException exception will be thrown, which > can't be catched > The improvement proposed here is to log the FQDN of the locator being reached > in order to have further information when troubleshooting this kind of issues. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9959) Add FQDN during SSL handshake error when reaching a locator
[ https://issues.apache.org/jira/browse/GEODE-9959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Salazar de Torres updated GEODE-9959: --- Summary: Add FQDN during SSL handshake error when reaching a locator (was: Add FQDN in SSL handshake error when reaching a locator) > Add FQDN during SSL handshake error when reaching a locator > --- > > Key: GEODE-9959 > URL: https://issues.apache.org/jira/browse/GEODE-9959 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Salazar de Torres >Priority: Major > > *WHEN* a geode-native client tries to reach a locator > *AND* the locator being reached has SSL configured > *BUT* the geode-native client does not have SSL configured > *THEN* a log will be written indicating the issue > *AND* an AuthenticationRequiredException exception will be thrown, which > can't be catched > The improvement proposed here is to log the FQDN of the locator being reached > in order to have further information when troubleshooting this kind of issues. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-9959) Add FQDN in SSL handshake error when reaching a locator
Mario Salazar de Torres created GEODE-9959: -- Summary: Add FQDN in SSL handshake error when reaching a locator Key: GEODE-9959 URL: https://issues.apache.org/jira/browse/GEODE-9959 Project: Geode Issue Type: Improvement Components: native client Reporter: Mario Salazar de Torres *WHEN* a geode-native client tries to reach a locator *AND* the locator being reached has SSL configured *BUT* the geode-native client does not have SSL configured *THEN* a log will be written indicating the issue *AND* an AuthenticationRequiredException exception will be thrown, which can't be catched The improvement proposed here is to log the FQDN of the locator being reached in order to have further information when troubleshooting this kind of issues. -- This message was sent by Atlassian Jira (v8.20.1#820001)
