[SERVER-34577] read_after_optime.js fails on mongoe Created: 19/Apr/18  Updated: 29/Oct/23  Resolved: 14/Sep/18

Status: Closed
Project: Core Server
Component/s: Storage
Affects Version/s: None
Fix Version/s: 4.0.3, 4.1.4

Type: Task Priority: Major - P3
Reporter: Henrik Edin Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
is depended on by SERVER-34533 Fix the jstests in core tagged with i... Closed
Backwards Compatibility: Fully Compatible
Backport Requested:
v4.0
Sprint: Platforms 2018-08-13, Platforms 2018-08-27, Platforms 2018-09-10, Platforms 2018-09-24
Participants:
Linked BF Score: 0

 Description   

Reproduce by doing this:

python buildscripts\resmoke.py --suites=core --mongod=./mongoe jstests/core/read_after_optime.js

readConcern is not implemented for embedded. What should the correct behavior be for embedded? I see these alternatives:

  • Fail operations that try and set read/write concern
  • Partially implement read concern so this test works
  • Leave the code as-is, it doesn't sound dangerous that you can do this.


 Comments   
Comment by Githook User [ 14/Sep/18 ]

Author:

{'name': 'Henrik Edin', 'email': 'henrik.edin@mongodb.com', 'username': 'henrikedin'}

Message: SERVER-34577 isEphemeralForTest does not support majority readConcern

(cherry picked from commit 45fccee20b37579662fabc6268a76a52f00661c4)
Branch: v4.0
https://github.com/mongodb/mongo/commit/5b63deeda771f453044a3c9cf219710149984205

Comment by Githook User [ 14/Sep/18 ]

Author:

{'name': 'Henrik Edin', 'email': 'henrik.edin@mongodb.com', 'username': 'henrikedin'}

Message: SERVER-34577 isEphemeralForTest does not support majority readConcern
Branch: master
https://github.com/mongodb/mongo/commit/45fccee20b37579662fabc6268a76a52f00661c4

Comment by Githook User [ 14/Sep/18 ]

Author:

{'name': 'Henrik Edin', 'email': 'henrik.edin@mongodb.com', 'username': 'henrikedin'}

Message: SERVER-34577 Parse read and write concern for command invocation in embedded. Behave like a standalone mongod.

(cherry picked from commit 5de2e9361b92fbbc59625636eecbe6bd1f1a78c5)
Branch: v4.0
https://github.com/mongodb/mongo/commit/d1a7071f3ab06fc50a66db3d4ca8f929fc8ef1f0

Comment by Githook User [ 14/Sep/18 ]

Author:

{'name': 'Henrik Edin', 'email': 'henrik.edin@mongodb.com', 'username': 'henrikedin'}

Message: SERVER-34577 Parse read and write concern for command invocation in embedded. Behave like a standalone mongod.
Branch: master
https://github.com/mongodb/mongo/commit/5de2e9361b92fbbc59625636eecbe6bd1f1a78c5

Comment by Henrik Edin [ 31/Jul/18 ]

Calling waitForReadConcern / waitForWriteConcern for embedded sounds resonable to me. Do you want to bounce it back to me to give it a try?

Comment by Tess Avitabile (Inactive) [ 30/Jul/18 ]

I would recommend that embedded accept the same values for readConcern as standalones. Standalone nodes accept readConcern levels of local, majority, and available. They do not support the readConcern levels snapshot or linearizable, and they do not support the options afterClusterTime, afterOpTime, or atClusterTime. This can be accomplished by calling waitForReadConcern(), similarly to ServiceEntryPointMongod. This will perform the correct validation for non-replica-sets, and it will not do any waiting.

Similarly for writeConcern, embedded should accept the same values as standalones. Standalones accept w:"majority", w:1, and w:0. Embedded can get the same behavior by calling waitForWriteConcern(), like in ServiceEntryPointMongod. This will not wait for replication. I'm not sure whether the embedded storage engine is durable, so I'm not sure whether it will wait for durability.

Also, I wanted to follow up on the issue I described for transactions. Since this session info is not parsed, the individual reads and writes in the transaction will succeed as if they were not in a transaction (but they will not be atomic). Then when commitTransaction or abortTransaction is run, it will fail because the command was not run within a session. This is strange behavior. Do you have another mechanism for making sure users do not send transactions to the embedded database (for example, the drivers' transactions helpers are disabled)?

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