[SERVER-531] error1.js test may fail due to client sending killcursors Created: 11/Jan/10 Updated: 12/Jul/16 Resolved: 12/Jan/10 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Tools |
| Affects Version/s: | None |
| Fix Version/s: | 1.3.1 |
| Type: | Bug | Priority: | Minor - P4 |
| Reporter: | Aaron Staple | Assignee: | Aaron Staple |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Participants: |
| Description |
|
The error1.js test checks consistency of the lastError and prevError commands. Our js clients may destroy a DBClientCursor at any time (as the js garbage collector runs) and send a killCursors message at any time. This killCursors message may be sent during an error1.js run, interfering with the proper running of the test. One way to fix this would be to add the option in the shell to kill all cursors manually (through a shell command) instead of automatically through garbage collection. Another fix is to move the error1.js and other similar error tests to the c++ client test, where we have more control over killCursors already. Yet another fix would be to continue killing cursors in the shell triggered by gc, but to send the killCursors request via a separate db connection. |
| Comments |
| Comment by auto [ 12/Jan/10 ] |
|
Author: {'name': 'Aaron', 'email': 'aaron@10gen.com'}Message: |
| Comment by auto [ 12/Jan/10 ] |
|
Author: {'name': 'Aaron', 'email': 'aaron@10gen.com'}Message: |
| Comment by auto [ 12/Jan/10 ] |
|
Author: {'name': 'Aaron', 'email': 'aaron@10gen.com'}Message: |
| Comment by Aaron Staple [ 12/Jan/10 ] |
|
Sure, I'll do it |
| Comment by Dwight Merriman [ 12/Jan/10 ] |
|
yes - let's have killcursors not effect lasterror, and rather, put something in db log if necessary. can you make that change aaron? |
| Comment by Michael Dirolf [ 11/Jan/10 ] |
|
i think eliot's suggestion makes sense - users would probably be surprised to have their lastError calls affected by killcursors they didn't even make |
| Comment by Aaron Staple [ 11/Jan/10 ] |
|
If you're happy with that from a functionality standpoint, it's fine with me. Right now killCursors can assert in a few different situations (including if the client requests that too many cursors be killed) but with the current code there's no actual confirmation that cursors were found and have been killed (presumably b/c it's not an error if the cursor timed out on its own first). I guess we could say that killCursors is just a hint for mongod and therefore confirmation / lastError isn't necessary. I'll just double check with Dwight. Dwight, is it ok to disable lastError for killCursors? |
| Comment by Eliot Horowitz (Inactive) [ 11/Jan/10 ] |
|
What about not making kill cursors effect last error? Lots of drivers randomly call it, so this might make sense anyway |