[SERVER-14651] listDatabases command errors under high database create/delete load Created: 22/Jul/14 Updated: 15/May/15 Resolved: 15/May/15 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Storage |
| Affects Version/s: | 2.2.7, 2.4.10, 2.6.3 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | David Golden | Assignee: | Unassigned |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Operating System: | ALL | ||||||||||||
| Steps To Reproduce: | [PERL-387] has example code that replicates the problem. In short: have several threads/processes repeatedly and rapidly create a database, add a document to a collection, and then drop the database. In another thread/process, call "listDatabases" once a second until the error occurs. |
||||||||||||
| Participants: | |||||||||||||
| Description |
|
If many databases are rapidly created and deleted, the listDatabases command can fail with error 15927 ("can't open database in a read lock..."), which apparently is from database_holder.cpp. I think listDatabases needs to catch that error and either retry or just omit the offending database in the list it returns. Otherwise, a transient error from a single database prevents the rest of the valid results from being returned. |
| Comments |
| Comment by Daniel Pasette (Inactive) [ 15/May/15 ] | ||||||||||||||||||||||||||||||||||
|
fixed in 3.0+; won't backport | ||||||||||||||||||||||||||||||||||
| Comment by David Golden [ 11/Aug/14 ] | ||||||||||||||||||||||||||||||||||
|
I tested it on 2.7.4 and did not see the error. I suspect it was "fixed" somewhere in the refactoring for pluggable storage engines. | ||||||||||||||||||||||||||||||||||
| Comment by Ramon Fernandez Marina [ 11/Aug/14 ] | ||||||||||||||||||||||||||||||||||
|
Thanks for the repro eric.daniels@10gen.com, I'm able to reproduce the problem in 2.6.4. However I'm not able to reproduce on 2.7.4. david.golden, have you tested 2.7.4 with the Perl reproducer? | ||||||||||||||||||||||||||||||||||
| Comment by Eric Daniels (Inactive) [ 11/Aug/14 ] | ||||||||||||||||||||||||||||||||||
|
Here's a reproduction in python using pymongo:
| ||||||||||||||||||||||||||||||||||
| Comment by David Golden [ 08/Aug/14 ] | ||||||||||||||||||||||||||||||||||
|
Were you using the latest release of the Perl driver? It has a workaround so you won't see it. You need to use v0.704.2.0 or earlier. I tried it again on 2.6.4-rc1 (from perl driver commit 8f961fb right before the fix) and got the same exception:
You can download http://www.cpan.org/authors/id/M/MO/MONGODB/MongoDB-v0.704.2.0.tar.gz and install it. Or if you have all prereqs installed (including Proc::Fork), you can probably repo from the perl repository directory with something like this:
| ||||||||||||||||||||||||||||||||||
| Comment by Eric Daniels (Inactive) [ 22/Jul/14 ] | ||||||||||||||||||||||||||||||||||
|
If it helps, this is the associated stack trace:
| ||||||||||||||||||||||||||||||||||
| Comment by David Golden [ 22/Jul/14 ] | ||||||||||||||||||||||||||||||||||
|
I replicated this under 2.6.3, 2.4.10 and 2.2.7. I did not see the error on 2.0.9 in ~ 20 seconds of observation. (The others fail within seconds.) UPDATE:
|