[GitHub] [geode] bschuchardt opened pull request #4743: Feature/geode 7808 - standardize on use of HostAndPort to form client-side connections

["bschuchardt (GitHub)" <gi...@apache.org>]

This PR builds on a previously approved PR (commit #1) to standardize our client->server interfaces on use of HostAndPort, allowing clients to hold server and locator names and resolve them just before use.  This PR (commit #2, which is all you need to review) refactors socket-creators to separate concerns

    ServerSocketCreator holds methods for non-client comms
    ClientSocketCreator holds methods that clients should use for comms
    AdvancedSocketCreator holds methods for people who need to get around
    the limitations of the other two interfaces



Thank you for submitting a contribution to Apache Geode.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

### For all changes:
- [ ] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message?

- [ ] Has your PR been rebased against the latest commit within the target branch (typically `develop`)?

- [ ] Is your initial contribution a single, squashed commit?

- [ ] Does `gradlew build` run cleanly?

- [ ] Have you written or updated unit tests to verify your changes?

- [ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under [ASF 2.0](http://www.apache.org/legal/resolved.html#category-a)?

### Note:
Please ensure that once the PR is submitted, check Concourse for build issues and
submit an update to your PR as soon as possible. If you need help, please send an
email to dev@geode.apache.org.


[ Full content available at: https://github.com/apache/geode/pull/4743 ]
This message was relayed via gitbox.apache.org for notifications@geode.apache.org

[GitHub] [geode] bschuchardt commented on pull request #4743: GEODE-7808: standardize on use of HostAndPort to form client-side connections

["bschuchardt (GitHub)" <gi...@apache.org>]

The socket configuration is needed by all dependent socket-creators.  We could do the refactor you're suggesting anytime w/o changing the public interface to these services.

[ Full content available at: https://github.com/apache/geode/pull/4743 ]
This message was relayed via gitbox.apache.org for notifications@geode.apache.org

[GitHub] [geode] Bill commented on pull request #4743: GEODE-7808: standardize on use of HostAndPort to form client-side connections

["Bill (GitHub)" <gi...@apache.org>]

why is this "connectFor_Client_" and not merely "connect"? I wonder if that distinction (the "client" one) was important when this was mushed together with passive socket creation methods and maybe now is less important?

Oh from looking at `ServerSocketCreator` I think I understand now. Yeah, it has it's own "connect" methods. These method signatures seem to be mixing two different concerns and overloading the terms "client" and "server" to apply to both. I find that confusing…

Usually when I hear somebody talking about a "server" socket I think they are referring to a passive socket (one that is bound to a well-known port). And when I hear them talk about "client" sockets I think they are referring to sockets created via (active) connect calls.

But our new interfaces are not segregating two kinds of "sockets". They're segregating methods for use by clients from methods for use by servers. If I have that right you don't use `ServerSocketCreator` to create "server sockets", rather, servers use it to create all their sockets (actively, passively). And so on for `ClientSocketCreator`.

If this is correct, and obvious to everybody, then just carry on. If it's wrong or not obvious it might be worth some clarification in the class-level comments.

[ Full content available at: https://github.com/apache/geode/pull/4743 ]
This message was relayed via gitbox.apache.org for notifications@geode.apache.org

[GitHub] [geode] Bill commented on pull request #4743: GEODE-7808: standardize on use of HostAndPort to form client-side connections

["Bill (GitHub)" <gi...@apache.org>]

If you like my suggestion to send in a `SocketConfiguration` instead of a `SocketCreator` (to the constructor), here is the method (`configureClientSSLSocket`) that would have to be hoisted into this class (from `SocketCreator`).

[ Full content available at: https://github.com/apache/geode/pull/4743 ]
This message was relayed via gitbox.apache.org for notifications@geode.apache.org

[GitHub] [geode] bschuchardt commented on pull request #4743: GEODE-7808: standardize on use of HostAndPort to form client-side connections

["bschuchardt (GitHub)" <gi...@apache.org>]

renaming to forCluster() in TcpSocketCreator

[ Full content available at: https://github.com/apache/geode/pull/4743 ]
This message was relayed via gitbox.apache.org for notifications@geode.apache.org

[GitHub] [geode] Bill commented on pull request #4743: GEODE-7808: standardize on use of HostAndPort to form client-side connections

["Bill (GitHub)" <gi...@apache.org>]

Only a few methods on`SocketCreator` are used by this class. Most of them have to do with configuration. The same can be said of use of `SocketCreator` by the two other sibling classes: `SCClientSocketCreator`, `SCAdvancedSocketCreator`. That being the case I wonder if it would be reasonable to make e.g. a `SocketConfiguration` interface and use that instead here.

The only exception I see to this situation is that `SCAdvancedSocketCreator.connect` calls `SocketCreator.configureClientSSLSocket()`. But perhaps that method could be moved from `SocketCreator` to `SCAdvancedSocketCreator`. That method, in turn, needs some SSL configuration settings, but it should be able to access all those from the `SocketConfiguration`.

[ Full content available at: https://github.com/apache/geode/pull/4743 ]
This message was relayed via gitbox.apache.org for notifications@geode.apache.org

[GitHub] [geode] Bill commented on pull request #4743: GEODE-7808: standardize on use of HostAndPort to form client-side connections

["Bill (GitHub)" <gi...@apache.org>]

get rid of spurious back tick `

[ Full content available at: https://github.com/apache/geode/pull/4743 ]
This message was relayed via gitbox.apache.org for notifications@geode.apache.org