-
Type: Question
-
Resolution: Done
-
Priority: Unknown
-
None
-
Affects Version/s: None
-
Component/s: Sessions
-
None
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.
- related to
-
JAVA-4860 Do not perform server selection to determine sessions support
- Closed