[CXX-946] mongoclient.dll assertion exception Created: 21/Jun/16 Updated: 14/Sep/16 Resolved: 14/Sep/16 |
|
| Status: | Closed |
| Project: | C++ Driver |
| Component/s: | API |
| Affects Version/s: | legacy-1.1.1 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Mariano Botta | Assignee: | J Rassi |
| Resolution: | Done | Votes: | 0 |
| Labels: | legacy-cxx | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
| Description |
|
Hi all, Each request is handled by different threads Environment: Can anyone help me? |
| Comments |
| Comment by J Rassi [ 27/Jun/16 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Yep, connection objects in the C++ driver are not thread-safe. It seems like the issue that you are running into is that application threads are accessing 'cli_' without proper synchronization in the function that is issuing queries against the server. This is consistent with the observation you report that the issue goes away when you change your application to not use threads. You can fix this issue by locking the client object before using it in your querying code. Note also that if multiple application threads need to communicate with the database at the same time, you will likely see much better performance by giving each application thread its own connection to the database, or by implementing your own connection pooling functionality. Unfortunately, the legacy C++ driver does not offer a native connection pool API. However, if you upgrade to the new C++11 driver, you will be able to use the mongocxx:pool class, which provides a thread-safe API to manage multiple connections to the same MongoDB deployment. One additional note: do consider using boost::unique_lock or boost::lock_guard for locking mutexes in your code, instead of invoking boost::mutex::lock() directly. This will help make your code exception-safe (in its current state, '_mutex' will remain locked if any exceptions thrown between the call to '_mutex.lock()' and '_mutex.unlock()' are unhandled in the insert logic). I'm resolving this ticket as "Works as Designed". Feel free to post the mongodb-user mailing list for any design questions about using the legacy C++ driver in multi-threaded applications. Best, | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Mariano Botta [ 23/Jun/16 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Hi Rassi, Yes, the threads are sharing the same client connection; actually, there The server is standalone, at localhost. There is no replica or cluster. I had a previous version of the application in a production server, Just for testing, how should I handle mongo connections in this context? This is the code to connect to mongo:
Attached you can find mongo.log file; I can’t find any reference to Thanks and regards, Mariano | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by J Rassi [ 23/Jun/16 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Hi mariano.botta@soteicavisualmesa.com, Both assertion failures you are observing are indicative of the client processing invalid messages from the server, and are unrelated to cursor timeout issues. In the first failure (dbclientcursor.cpp:228), the server is receiving an OP_GET_MORE message where the "cursor not found" result flag is set and the "cursor" field is non-zero (it's invalid for the "cursor" field to be non-zero when this flag is set). In the second failure (message_port.cpp:278), the "responseTo" header field of the message response is not equal to the "requestID" header of the corresponding message sent (they are expected to be the same). Based on the information I have available at this point (multithreaded application encountering invalid messages from the server under high load), I suspect a possible concurrency error in your application as the root cause, where one thread is reading data off of a socket owned by another thread. Otherwise, it's certainly possible that the issue is caused by a bug in the client driver, a bug in the server, or corruption of wire messages over the network. I'll need additional information to further diagnose this issue. Could you please provide answers to the following questions:
Let me know if you'd like any additional clarification on the above questions. Thanks, |