[SERVER-22554] WiredTiger data handles not closed when collection is dropped Created: 10/Feb/16 Updated: 11/Mar/16 Resolved: 23/Feb/16 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | WiredTiger |
| Affects Version/s: | 3.0.8, 3.0.9 |
| Fix Version/s: | 3.0.10 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Bruce Lucas (Inactive) | Assignee: | Alexander Gorrod |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||
| Issue Links: |
|
||||
| Backwards Compatibility: | Fully Compatible | ||||
| Operating System: | ALL | ||||
| Participants: | |||||
| Description |
|
Test case creates collections and indexes and then drops them at a high rate through point A below. WT data handles accumulate and are never closed.
Problem reproduces in several 3.0 versions, but not in 3.2.1. Repro script:
|
| Comments |
| Comment by Githook User [ 23/Feb/16 ] | |||||||||||
|
Author: {u'name': u'Ramon Fernandez', u'email': u'ramon@mongodb.com'}Message: Import wiredtiger-wiredtiger-mongodb-3.0.9-2-g62b3ca8.tar.gz from wiredtiger branch mongodb-3.0 ref: cae5fcf..62b3ca8
| |||||||||||
| Comment by Githook User [ 22/Feb/16 ] | |||||||||||
|
Author: {u'username': u'michaelcahill', u'name': u'Michael Cahill', u'email': u'michael.cahill@mongodb.com'}Message: Merge pull request #2514 from wiredtiger/server-22554-backport
| |||||||||||
| Comment by Githook User [ 22/Feb/16 ] | |||||||||||
|
Author: {u'username': u'agorrod', u'name': u'Alex Gorrod', u'email': u'alexg@wiredtiger.com'}Message: The code has diverged a lot between 3.0 and the latest develop, and This change does both while holding the lock to keep reference count | |||||||||||
| Comment by Alexander Gorrod [ 12/Feb/16 ] | |||||||||||
|
It appears as though this is related to an incomplete backport of either What I'm seeing is that the forced drops are being issued to WiredTiger, and WiredTiger is queing the handles to be closed by the sweep server. The sweep server is repeatedly attempting the drops but the session_ref field is non-zero, so it never finalizes the drop. When I look through all of the sessions handle caches in a debugger none of them are referencing the handles. Part of this is that there is a change to the reference counting of dhandles here: That should have removed a bump to session_ref that is present in __session_add_dhandle. The code change for that is:
Making just that change and testing locally wasn't enough to resolve the issue, so I'll need to spend more time figuring out the missing piece. |