|
I would like to comment that we no longer interested in this feature, since it appears that building a simple table and a set of rules is enough to cover like 98% of the cases (by frequency of occurence). So, if no one is interested in this, I believe this case can be closed.
|
|
This case is actually closely related to the http://jira.mongodb.org/browse/CSHARP-155.
I checked out the error codes, but the only list I found online (http://www.mongodb.org/display/DOCS/Error+Codes) is a bit outdated.
Is there (I'm fine with any format, including plain text) an up-to-date list of all error codes (should be a very useful thing for driver developers), or maybe some kind of predefined ranges/severity tables (like the HTTP status code ranges)?
My point that in many cases to resolve an intermittent problem, you can just repeat the call (given that you have some kind of client-side concurrency control for your updates), but there are some cases where retrying is useless and failure is permanent. If there was a mechanism that signals that "this error requires DBA/developer attention and is not a temporary failure which should be resolved automatically in a few seconds" (or the exact opposite "this error should be transient, because it looks like it's a connection problem"), the driver and/or client code could make more informed decisions about possible outcomes of retrying the operation.
My exact case is performing insers/queries on a mongos instance (using a C# driver) with several replica sets. I would like to know the difference between "cluster is destroyed, sound the alarm" and "we lost connectivity to the primary of one of shard, please come back a few seconds later" without testing for every available error message, code and exception type, since this is very much error-prone, since while MongoDB is actively developed, error messages might change, new codes can get added and old removed (also related to http://jira.mongodb.org/browse/CSHARP-153).
|