[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.
it is supposed to guarantee only 1 thread has a given id at any time

Comment by auto [ 15/Jan/10 ]

Author:

{'name': 'Eliot Horowitz', 'email': 'eliot@10gen.com'}

Message: fix id based last error concurrency SERVER-535
http://github.com/mongodb/mongo/commit/02e33dafc066677d0f6c33f78937835ddb0cf1ce

Generated at Thu Feb 08 02:54:25 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.