[SERVER-2750] assertion failed whe using pymongo find_and_modify on sharded db Created: 12/Mar/11  Updated: 30/Mar/12  Resolved: 13/Mar/11

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

Type: Bug Priority: Major - P3
Reporter: ofer samocha Assignee: Unassigned
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Operating System: Linux
Participants:

 Description   

when using my sharded cluster of mongo I've got this error.

Traceback (most recent call last):
File "dbconnector.py", line 36, in eval_cmd
res = eval_expr(block, variables)
File "dbconnector.py", line 29, in eval_expr
return eval(expr,

{"__builtins__":None}

, variables )
File "<string>", line 1, in <module>
File "dbmodules.py", line 162, in unregister_phone
ab = mdb.addressbooks.find_and_modify(query=

{AB_UDID:udid}

, remove=True)
File "build/bdist.linux-i686/egg/pymongo/collection.py", line 1061, in find_and_modify
allowable_errors=[no_obj_error], **kwargs)
File "build/bdist.linux-i686/egg/pymongo/database.py", line 293, in command
msg, allowable_errors)
File "build/bdist.linux-i686/egg/pymongo/helpers.py", line 125, in _check_command_response
raise OperationFailure(ex_msg, response.get("assertionCode"))
OperationFailure: db assertion failure, assertion: 'DBClientBase::findOne: transport error: amdbm006:10000 query: { findAndModify: "addressbooks", query:

{ _id: "f5e58a32cc4ce39734deadf4349350269f7ab311" }

, remove: true }', assertionCode
: 10276



 Comments   
Comment by Eliot Horowitz (Inactive) [ 13/Mar/11 ]

No, retry is not safe in the general case as it depends on exaclty when/where things fail.

Comment by ofer samocha [ 13/Mar/11 ]

can you implement retry mechanism in mongos ?

Comment by Eliot Horowitz (Inactive) [ 13/Mar/11 ]

Seems to be networking issue

Comment by Eliot Horowitz (Inactive) [ 13/Mar/11 ]

That looks like a networking blip, not something we could fix.

The reason I would upgrade is that 1.7.5 is part of the ubstable series, so 1.8.0-rc2 is more stable

Comment by ofer samocha [ 12/Mar/11 ]

mongos side claimed for socket closed.
Fri Mar 11 10:36:22 [conn7] MessagingPort recv() errno:110 Connection timed out 10.78.41.204:10000
Fri Mar 11 10:36:22 [conn7] SocketException: remote: error: 9001 socket exception [1]
Fri Mar 11 10:36:22 [conn7] DBClientCursor::init call() failed

amdbm006 claimed for end connection:
Fri Mar 11 10:36:42 [conn4361] end connection 10.196.238.129:42484
Fri Mar 11 10:36:42 [initandlisten] connection accepted from 10.196.238.129:49995 #5185

was that fixed in 1.8.0 rc2 ?

Comment by Eliot Horowitz (Inactive) [ 12/Mar/11 ]

Can you check amdbm006?
Looks like it simply couldn't talk to that shard.

Also, I would recommend upgrading to 1.8.0-rc2 asap

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