[SERVER-535] possible concurrency issues in id-based lastError code Created: 12/Jan/10 Updated: 12/Jul/16 Resolved: 15/Jan/10 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 1.3.1 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Aaron Staple | Assignee: | Eliot Horowitz (Inactive) |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Participants: |
| Description |
|
I don't know much about how message-id based lastErrors are to be used, but it seems like there could be some concurrency issues: For example, lastError.startRequest() is called in connThread() without any mutex, and it in turn calls lastError.get() which reads and modifies the lastError._ids map without a mutex. Since there's only one global lastError object shared by all threads this could be a problem. In addition, only the top two bytes of the message id are used to map a LastError object. Conceivably a single LastError object could be used by two threads, though depending on usage perhaps this is prevented in practice? |
| Comments |
| Comment by Eliot Horowitz (Inactive) [ 15/Jan/10 ] |
|
forgot 2 locks the multiple thread same is managed above this in the sharding layer. |
| Comment by auto [ 15/Jan/10 ] |
|
Author: {'name': 'Eliot Horowitz', 'email': 'eliot@10gen.com'}Message: fix id based last error concurrency |