[SERVER-18277] Sanitize maxTimeMS and the CurOp type Created: 30/Apr/15  Updated: 25/Jan/17  Resolved: 23/May/16

Status: Closed
Project: Core Server
Component/s: Querying
Affects Version/s: None
Fix Version/s: 3.3.8

Type: Improvement Priority: Major - P3
Reporter: Eric Milkie Assignee: Andy Schwerin
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by SERVER-16506 race condition in currentOp Closed
Related
related to SERVER-18625 Discrepancy between lockTime and tota... Closed
Backwards Compatibility: Fully Compatible
Sprint: Sharding 14 (05/13/16), Sharding 15 (06/03/16)
Participants:
Linked BF Score: 0

 Description   

Work to ensure that maxTimeMS measures the time of the operation starting from when the operation is first received by the server, whether that server, whether that server is mongos or mongod.



 Comments   
Comment by Githook User [ 23/May/16 ]

Author:

{u'username': u'andy10gen', u'name': u'Andy Schwerin', u'email': u'schwerin@mongodb.com'}

Message: SERVER-18277 Track elapsed time on cursors using microsecond resolution on OperationContext.

This completes the mechanics of moving max-time tracking to OperationContext and
switching the checkForInterrupt checks to use the service context's fast clock
source, while tracking the amount of execution time remaining on a cursor with
microsecond granularity to ensure that remaining execution time always declines,
even for very brief operations on cursors.

This patch does not complete the transition from wait_for waiting to wait_until
waiting in all places that do waiting based on operation deadlines.
Branch: master
https://github.com/mongodb/mongo/commit/2e627487ef0475c46143b5f57d3e7c3d3027d5dc

Comment by Githook User [ 23/May/16 ]

Author:

{u'username': u'andy10gen', u'name': u'Andy Schwerin', u'email': u'schwerin@mongodb.com'}

Message: SERVER-18277 Track operation deadlines in OperationContext, not CurOp.

This also unifies the implementations of checkForInterrupt and checkForInterruptNoAssert.
Branch: master
https://github.com/mongodb/mongo/commit/c9aac9d6eaba6ef2eb8903f07e997b594e88addc

Comment by Githook User [ 09/May/16 ]

Author:

{u'username': u'RedBeard0531', u'name': u'Mathias Stearn', u'email': u'mathias@10gen.com'}

Message: SERVER-18277 Fill in clock and tick sources in ServiceContext constructor

Now they only need to be set in cases where the defaults need to be changed.
Tests that just want the defaults can link against
$BUILD_DIR/mongo/db/service_context_noop_init to get a working global
ServiceContext.
Branch: master
https://github.com/mongodb/mongo/commit/9dc08e38ada5a8567753469e688c821c8b96530e

Comment by Githook User [ 25/Apr/16 ]

Author:

{u'username': u'andy10gen', u'name': u'Andy Schwerin', u'email': u'schwerin@mongodb.com'}

Message: SERVER-18277 Properly configure ServiceContext in document_source_test.

This is prerequisite to moving checkForInterrupt and maxTimeMs tracking
from CurOp to OperationContext.
Branch: master
https://github.com/mongodb/mongo/commit/fdef84d6f3dec1f97228c4dbddd34b4dac34d4a5

Comment by Githook User [ 16/Apr/16 ]

Author:

{u'username': u'andy10gen', u'name': u'Andy Schwerin', u'email': u'schwerin@mongodb.com'}

Message: SERVER-18277 Remove guard against interruptibility inside WUOW which is no longer needed.
Branch: master
https://github.com/mongodb/mongo/commit/63ea3e59a735b3fb6047e994c28834f841abccaa

Comment by Githook User [ 05/Jun/15 ]

Author:

{u'username': u'andy10gen', u'name': u'Andy Schwerin', u'email': u'schwerin@mongodb.com'}

Message: SERVER-18277 Do not do database reads under client spinlock.
Branch: master
https://github.com/mongodb/mongo/commit/99efb5fc4f771feb8ae81434b4e2d6f7445665e1

Comment by Githook User [ 05/Jun/15 ]

Author:

{u'username': u'andy10gen', u'name': u'Andy Schwerin', u'email': u'schwerin@mongodb.com'}

Message: SERVER-18277 Move server status metrics code out of curop.cpp into curop_metrics.cpp.
Branch: master
https://github.com/mongodb/mongo/commit/54040db4fa000284cb1148b93e85f81c54ca12d6

Comment by Githook User [ 05/Jun/15 ]

Author:

{u'username': u'andy10gen', u'name': u'Andy Schwerin', u'email': u'schwerin@mongodb.com'}

Message: SERVER-18277 Get references to the Top object out of CurOp.
Branch: master
https://github.com/mongodb/mongo/commit/f4ca1b7eb3850719049d938b4b4562b6324ec284

Comment by Githook User [ 05/Jun/15 ]

Author:

{u'username': u'andy10gen', u'name': u'Andy Schwerin', u'email': u'schwerin@mongodb.com'}

Message: SERVER-18277 Stronger locking rules for CurOp and OpDebug.
Branch: master
https://github.com/mongodb/mongo/commit/51c2064d518140fbeae62f9d7ba29f1d69fb530f

Comment by Githook User [ 04/Jun/15 ]

Author:

{u'username': u'andy10gen', u'name': u'Andy Schwerin', u'email': u'schwerin@mongodb.com'}

Message: SERVER-18277 Stop using OldClientContext in BatchExecutor.

This simplifies the interaction between write commands and the curop structure.
Branch: master
https://github.com/mongodb/mongo/commit/8c0cb681459834433c9d467fbfa51bdadc9f42fd

Comment by Githook User [ 02/Jun/15 ]

Author:

{u'username': u'andy10gen', u'name': u'Andy Schwerin', u'email': u'schwerin@mongodb.com'}

Message: Reapply "SERVER-18277 Clarify locking of Client when accessing its stored OperationContext."

This reverts commit 993fc5e4ed9264965f16a948d3732d3fc55d1255.
Branch: master
https://github.com/mongodb/mongo/commit/5f225a7464862686a8422bb02d1f638d5568d529

Comment by Githook User [ 29/May/15 ]

Author:

{u'username': u'stbrody', u'name': u'Spencer T Brody', u'email': u'spencer@mongodb.com'}

Message: Revert "SERVER-18277 Clarify locking of Client when accessing its stored OperationContext."

This reverts commit 5c2d133871b2ad2adf6c617364d036ca25261f2d.
Branch: master
https://github.com/mongodb/mongo/commit/993fc5e4ed9264965f16a948d3732d3fc55d1255

Comment by Githook User [ 29/May/15 ]

Author:

{u'username': u'andy10gen', u'name': u'Andy Schwerin', u'email': u'schwerin@mongodb.com'}

Message: SERVER-18277 Clarify locking of Client when accessing its stored OperationContext.

As a side-effect, clean up operation killing in ServiceContextMongoD.
Branch: master
https://github.com/mongodb/mongo/commit/5c2d133871b2ad2adf6c617364d036ca25261f2d

Comment by Githook User [ 22/May/15 ]

Author:

{u'username': u'andy10gen', u'name': u'Andy Schwerin', u'email': u'schwerin@mongodb.com'}

Message: SERVER-18277/SERVER-18482 Remove "_remote" field from CurOp.
Branch: master
https://github.com/mongodb/mongo/commit/d6e686859c6187df791b7f61abbb9839f7e85c9a

Comment by Githook User [ 22/May/15 ]

Author:

{u'username': u'andy10gen', u'name': u'Andy Schwerin', u'email': u'schwerin@mongodb.com'}

Message: SERVER-18277 Prefer getting CurOp via the OperationContext rather than the Client.

Eventually, the CurOp should be a part of the OperationContext. Presently, the only
thing that prevents our maintaining that illusion is that ServiceContextMongoD
expects to be able to extract the CurOp for each existing Client object, but there
is no way to enumerate the OperationContexts for a Client.
Branch: master
https://github.com/mongodb/mongo/commit/765616c3dee87c963d57f8f80d68b4b06ef5f679

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