Uploaded image for project: 'Java Driver'
  1. Java Driver
  2. JAVA-5288

Sessions do not work with deployments with hidden members

    • Type: Icon: Question Question
    • Resolution: Done
    • Priority: Icon: Unknown Unknown
    • None
    • Affects Version/s: None
    • Component/s: Sessions
    • Labels:
      None
    • Hide

      1. What would you like to communicate to the user about this feature?
      2. Would you like the user to see examples of the syntax and/or executable code and its output?
      3. Which versions of the driver/connector does this apply to?

      Show
      1. What would you like to communicate to the user about this feature? 2. Would you like the user to see examples of the syntax and/or executable code and its output? 3. Which versions of the driver/connector does this apply to?

      Summary

      I'm unable to unable to start session on a deployment that contains hidden member.

      Please provide the version of the driver. If applicable, please provide the MongoDB server version and topology (standalone, replica set, or sharded cluster).

      Driver version is 3.12.11. I believe all versions are affected. See the next section for a topology compose file.

      How to Reproduce

      See this github repository containing reproduction. Run the compose file and test.

      Additional Background

      Why I think this is a bug. Server sessions documentation contains no mention of sessions not being available for hidden members. Same holds for sessions specification. Also docs on hidden members contain no information on that and present hidden member as a secondary.

      Driver code. I've checked the driver code as information why this should not work was not available elsewhere. While session is started (MongoClientDelegate.createClientSession), ClusterDescription.getLogicalSessionTimeoutMinutes is used to determine whether sessions are supported by a cluster – as advised by sessions specification. That method filters ServerDescriptions picking only primary and secondary.

      With this deployment and way  of connecting, there is only one server description – hidden member which has a type REPLICA_SET_OTHER }}hence will be filtered out. But the hidden member docs advertise it as a {{{}secondary. And also this hidden member has value of logicalSessionTimeoutMinutes set, so I presume it should be capable of handling sessions.

      Possible solution. Would it make sense to consider hidden member secondary?

      Why do I need this? Hidden member docs advise to use this feature for non-standard workloads as eg. analytics. That exactly is my use case. I need to use sessions here to be able to kill running operations.

      Aside on standalone deployments. General docs I've linked say, that sessions are only available for replica sets and sharded clusters. But we are able to run sessions also on standalone deployments. It seems like inconsistency.

      Thank you in advance for looking into this.

            Assignee:
            jeff.yemin@mongodb.com Jeffrey Yemin
            Reporter:
            lbr.dnk@posteo.net Libor Danek
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: