[SERVER-30492] Drop can fail because it is run in a session with cached cursors Created: 03/Aug/17  Updated: 30/Oct/23  Resolved: 14/Sep/17

Status: Closed
Project: Core Server
Component/s: Storage
Affects Version/s: None
Fix Version/s: 3.6.0-rc0

Type: Improvement Priority: Major - P3
Reporter: Michael Cahill (Inactive) Assignee: Michael Cahill (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to WT-3471 Clear out each session's table cache Closed
Backwards Compatibility: Fully Compatible
Sprint: Storage 2017-08-21, Storage 2017-09-11, Storage 2017-10-02
Participants:

 Description   

While testing a simple workload that creates and drops collections in a tight loop (see below), I noticed that many drop operations could not be completed immediately and instead were queued and retried later.

Since the queuing and retrying is expensive, I looked into what was causing the drops to fail the first time and noticed that there could be cursors active in the session used for the drop operation that were not being closed before attempting the drop.

Test:

collections=100000
 
mongo --eval "
for (var i=0; i<$collections; i++) {
    c = db['c' + i]
    c.insert({a:i, b:i, c:i})
    c.drop()
}
"

The fix is to call closeAllCursors(uri) on the enclosing session.



 Comments   
Comment by Ramon Fernandez Marina [ 14/Sep/17 ]

Author:

{'username': u'michaelcahill', 'name': u'Michael Cahill', 'email': u'michael.cahill@mongodb.com'}

Message:SERVER-30492 Clean up more cached cursors during drop.
Branch:master
https://github.com/mongodb/mongo/commit/b15fb2303c5c9ef72b64061c4b931bf7d39cdfab

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