Uploaded image for project: 'Ruby Driver'
  1. Ruby Driver
  2. RUBY-1805

Use per-connection server description & features

    • Type: Icon: Improvement Improvement
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 2.12.0.rc0
    • Affects Version/s: None
    • Component/s: Connections
    • None
    • Fully Compatible

      Currently the driver has a number of places where it reads server description or features from a Server instance prior to constructing an operation to be dispatched to said server. A connection is obtained from the connection pool after the operation has been constructed. There are three problems with this:

      1. As pointed out in https://jira.mongodb.org/browse/RUBY-1798, SDAM logic may mark the server unknown as a result of response processing, and this marking can happen at any time. An unknown server has an empty server description, therefore currently (after https://jira.mongodb.org/browse/RUBY-1584 was implemented) retrieving description or features from an unknown server fails, and prior to 1584 the server would have no features and capabilities which wasn't correct or ideal either.
      2. A server may be upgraded or downgraded at any time. This means even though the driver at some point in the past determined that the server may support feature X, a connection established to the server just now may discover that X is not supported, or vice versa.
      3. For things like compression, which can be negotiated on a per connection basis, it is not correct to assume that compression is or is not usable based on whether it was negotiated on another connection (monitoring or non-monitoring). The compression issue specifically has https://jira.mongodb.org/browse/RUBY-1804 filed for it but it is possible that the implementation of this ticket will end up also covering compression.

      The driver should, instead, obtain a connection first, then use this connection's description and features to construct operations appropriate for this connection.

      Note that in some cases the driver may (must?) use the server's features and description anyway - for example, when determining max bson size for the connection handshake. Since the ismaster on the new connection has not completed yet, the description and features of this new connection are not yet known. Another way of dealing with this is to use non-server specific driver defaults for all handshakes rather than using the last server description/features for subsequent handshakes to the said server.

            Assignee:
            oleg.pudeyev@mongodb.com Oleg Pudeyev (Inactive)
            Reporter:
            oleg.pudeyev@mongodb.com Oleg Pudeyev (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: