[DOCS-12252]  isMaster.compression documentation is misleading Created: 10/Dec/18  Updated: 10/Dec/18  Resolved: 10/Dec/18

Status: Closed
Project: Documentation
Component/s: None
Affects Version/s: None
Fix Version/s: DOCS-12251

Type: Bug Priority: Minor - P4
Reporter: Oleg Pudeyev (Inactive) Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to RUBY-1216 Add support for reading and writing O... Closed
is related to DOCS-12251 isMaster.compression is not always r... Closed
is related to DOCS-11045 Add missing output fields to isMaster... Closed
Participants:
Days since reply: 5 years, 9 weeks, 2 days ago

 Description   

Description

https://docs.mongodb.com/manual/reference/command/isMaster/#isMaster.compression says:

An array listing the compression algorithms used to compress the current connection's network communication between the mongod or mongos and other members of the deployment or the mongo shell.

My understanding is ismaster.compression includes the compressors that have been negotiated between the client sending the ismaster request and the server responding, for the particular ismaster request. For example, if the server is configured to use snappy,zlib:

1. If the driver doesn't request any compression in ismaster, ismaster.compression is not returned at all, despite server potentially actively using it to compress communication between mongod/mongoses.
2. If the driver requests zlib only compression in ismaster, ismaster.compression will be zlib only, despite server potentially using snappy to compress mongod/mongos communication.
3. The ismaster request containing ismaster.compression, if it is part of the handshake, is not compressed (contrary to the "used to compress the current connection's network communication" language). Rather the compressor(s) returned in ismaster.compression could be used by the driver to compress subsequent requests and by the server to compress subsequent responses, but neither side is obligated to perform compression (but is obligated to correctly handle incoming compressed data).
4. If compression has been negotiated on a given connection, and the ismaster request does not contain `compression` key, the the response's `compression` seems to indicate compression used by the current connection:

=> #<Mongo::Operation::Result:0x47008169198800 documents=[{"ismaster"=>true, "maxBsonObjectSize"=>16777216, "maxMessageSizeBytes"=>48000000, "maxWriteBatchSize"=>100000, "localTime"=>2018-12-10 17:41:29 UTC, "logicalSessionTimeoutMinutes"=>30, "connectionId"=>4, "minWireVersion"=>0, "maxWireVersion"=>8, "readOnly"=>false, "compression"=>["zlib"], "ok"=>1.0}]>

However, if I specify a `compression` key on the request, the response's `compression` is the result of negotiation again:

irb(main):016:0> Mongoid.default_client.database.command(ismaster: 1,compression:[])
 
=> #<Mongo::Operation::Result:0x47008169274080 documents=[{"ismaster"=>true, "maxBsonObjectSize"=>16777216, "maxMessageSizeBytes"=>48000000, "maxWriteBatchSize"=>100000, "localTime"=>2018-12-10 17:41:26 UTC, "logicalSessionTimeoutMinutes"=>30, "connectionId"=>4, "minWireVersion"=>0, "maxWireVersion"=>8, "readOnly"=>false, "ok"=>1.0}]>

It seems that sending a `compression` argument in ismaster request changes the negotiated compression on the active connection, but I was unsuccessful in trying to brick the client by requesting `snappy` which the Ruby driver does not implement.

Scope of changes

Impact to Other Docs

MVP (Work and Date)

Resources (Scope or Design Docs, Invision, etc.)


Generated at Thu Feb 08 08:04:46 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.