Currently WT_SESSION::drop has an undocumented "lock_wait" config which controls whether the operation waits for high-level locks (such as the schema lock), or gives up immediately when they are unavailable. That undocumented flag is also unused: MongoDB now sets "force,checkpoint_wait=false" on all drops.

Recent work in WT-3362 fixed a situation where even with those flags, drop could block while a checkpoint was active. At issue was the path to close all handles, which requires exclusive access, conflicting with a "lock-only" handle acquired by checkpoint.

That change can cause EBUSY to be returned to other operations, such as WT_SESSION::verify, where previously it would have waited. That was noted in WT-3328.

Consider implementing the "lock_wait" config of WT_SESSION::drop more thoroughly, with a WT_DHANDLE_LOCK_WAIT flag that control this behavior in the handle locking code rather than never waiting if WT_DHANDLE_LOCK_ONLY is set.

Also consider adding "lock_wait" to more calls that need exclusive access (specifically WT_SESSION::verify, which can reasonably be called on a busy system.