Uploaded image for project: 'WiredTiger'
  1. WiredTiger
  2. WT-1168

Issue dropping file

XMLWordPrintableJSON

    • Type: Icon: Task Task
    • Resolution: Done
    • None
    • Affects Version/s: None
    • Component/s: None
    • None

      I'm getting EBUSY when attempting to drop a file (via the MongoDB API). The call stack where EBUSY is returned is:

      (gdb) where
#0  __conn_dhandle_open_lock (session=0x7fffedbe1ba0, dhandle=0x7fffea2cae20, flags=20)
    at ../src/conn/conn_dhandle.c:68
WT-1  0x00007ffff7b4c1a8 in __conn_dhandle_get (session=0x7fffedbe1ba0, 
    name=0x7fffeee61a40 "file:test.basic1.wt", ckpt=0x0, flags=20) at ../src/conn/conn_dhandle.c:105
WT-2  0x00007ffff7b4ca32 in __wt_conn_btree_get (session=0x7fffedbe1ba0, 
    name=0x7fffeee61a40 "file:test.basic1.wt", ckpt=0x0, op_cfg=0x0, flags=20)
    at ../src/conn/conn_dhandle.c:387
WT-3  0x00007ffff7ba43a4 in __wt_session_get_btree (session=0x7fffedbe1ba0, 
    uri=0x7fffeee61a40 "file:test.basic1.wt", checkpoint=0x0, cfg=0x0, flags=20)
    at ../src/session/session_dhandle.c:389
WT-4  0x00007ffff7b4cf09 in __wt_conn_dhandle_close_all (session=0x7fffedbe1ba0, 
    name=0x7fffedc787f0 "file:test.basic1.wt") at ../src/conn/conn_dhandle.c:533
WT-5  0x00007ffff7b95079 in __drop_file (session=0x7fffedbe1ba0, 
    uri=0x7fffedc787f0 "file:test.basic1.wt", force=0, cfg=0x7fffe9298870)
    at ../src/schema/schema_drop.c:31
WT-6  0x00007ffff7b956c3 in __wt_schema_drop (session=0x7fffedbe1ba0, 
    uri=0x7fffedc787f0 "file:test.basic1.wt", cfg=0x7fffe9298870) at ../src/schema/schema_drop.c:174
WT-7  0x00007ffff7b95460 in __drop_table (session=0x7fffedbe1ba0, 
    uri=0x7fffeef97578 "table:test.basic1", force=0, cfg=0x7fffe9298870)
    at ../src/schema/schema_drop.c:126
WT-8  0x00007ffff7b957aa in __wt_schema_drop (session=0x7fffedbe1ba0, 
    uri=0x7fffeef97578 "table:test.basic1", cfg=0x7fffe9298870) at ../src/schema/schema_drop.c:180
WT-9  0x00007ffff7ba130a in __session_drop (wt_session=0x7fffedbe1ba0, 
    uri=0x7fffeef97578 "table:test.basic1", config=0x0) at ../src/session/session_api.c:423
WT-10 0x0000000001b11d56 in mongo::WiredTigerDatabaseCatalogEntry::dropCollection (
    this=0x7ffff7f336a0, opCtx=0x7fffe929aa60, ns=...)

      The write lock fails because there is a read lock still held:

      (gdb) p *dhandle->rwlock 
$57 = {name = 0x7ffff7bb8c09 "data handle", rwlock = {__data = {__lock = 0, __nr_readers = 1, 
      __readers_wakeup = 0, __writer_wakeup = 0, __nr_readers_queued = 0, __nr_writers_queued = 0, 
      __writer = 0, __shared = 0, __pad1 = 0, __pad2 = 0, __flags = 0}, 
    __size = "\000\000\000\000\001", '\000' <repeats 50 times>, __align = 4294967296}}

      There are twelve sessions open, none of them have any open cursors.

      The code is multi threaded, as far as I'm aware what happens is:

      • A session creates the table
      • Some items are added to the table, and a query is executed (within the same session that created the file).
      • A new session is opened in a different thread
      • We call drop from that session handle.

      I tried replicating similar steps through the Python API and didn't encounter any failures.

      I'll keep digging, but wanted to record a snapshot of the status.

            Assignee:
            alexander.gorrod@mongodb.com Alexander Gorrod
            Reporter:
            alexander.gorrod@mongodb.com Alexander Gorrod
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Created:
              Updated:
              Resolved: