[SERVER-7109] Errors in Writeback Listener is leaking to client's GLE Created: 21/Sep/12  Updated: 15/Feb/13  Resolved: 16/Jan/13

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: 2.2.0
Fix Version/s: None

Type: Bug Priority: Minor - P4
Reporter: Randolph Tan Assignee: Unassigned
Resolution: Duplicate Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates SERVER-4532 GetLastError on sharded cluster can r... Closed
Related
Operating System: ALL
Participants:

 Description   

Sample occurrence:
1. Assert 9517 seen by client - this should not be possible because only the writebackListener thread should be setting the reserved flag...
2. Duplicate key error in wbl seen leaked to client.



 Comments   
Comment by Randolph Tan [ 16/Jan/13 ]

Analysis:

There was a bug in getLastError in mongos that would make it call getLastError on shards that were not involved in the last write operation. This is caused by ClientConnections::checkVersions trying to connect to all shards, which in turn trigger the callback that adds the shard to the list of shards the getLastError should check. As a result, when the writeback listener calls getLastError, it can potentially end up with a getLastError object that is for multiple shards and the writeback listener does not properly parse this format (thus, bypassing the if( gle["code"].numberInt() == 9517) check) and can end up registering this gle to the _seenWritebacks data structure, which is exposed to the client connections calling getLastError.

SERVER-4532 fixed this by making sure that a shard will be added to the getLastError list only when we are explicitly creating a connection to it. To be exact, SERVER-4532 did this by moving the addShard call out of ShardingConnectionHook::onHandedOut to _ShardConnection::_init.

Comment by Adam Stacey [ 04/Dec/12 ]

We are not able to write to our cluster whilst the "MongoDB.Driver.MongoSafeModeException: Safemode detected an error 'writeback'" error is generated. Restarting the local Mongos process resolves the problem. Should this be the case? We are using the C# driver

Generated at Thu Feb 08 03:13:39 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.