[SERVER-4711] Don't use masserts when getChunkManager() fails to find a current chunk manager. Created: 18/Jan/12  Updated: 11/Jul/16  Resolved: 22/Feb/12

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

Type: Bug Priority: Major - P3
Reporter: Greg Studer Assignee: Greg Studer
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-4220 refactor getChunkManager() and shardi... Closed
Duplicate
is duplicated by SERVER-4956 mongos sharding assertion in shard3.j... Closed
is duplicated by SERVER-5029 shard3.js test failure and hang Closed
Related
is related to SERVER-4732 potential segfault on full config rel... Closed
Operating System: ALL
Participants:

 Description   

Printing the stack trace takes a long time, and this really isn't a very exceptional condition. Also, running printStackTrace() isn't particularly stable - see http://buildbot.mongodb.org/builders/Linux%2064-bit/builds/4064/steps/test_3/logs/stdio/text.



 Comments   
Comment by auto [ 22/Feb/12 ]

Author:

{u'login': u'gregstuder', u'name': u'Greg Studer', u'email': u'greg@10gen.com'}

Message: SERVER-4711 use uassert not massert for sharding exceptions - these do not require a stacktrace

Core issue is that printing stack traces here is not entirely safe, also slow.
Branch: master
https://github.com/mongodb/mongo/commit/4398322121cb5a79eba7ccc67764a50181dfd27c

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