[SERVER-12041] retry logic for read preferences should also apply on lazy recv() network failure Created: 11/Dec/13 Updated: 11/Jul/16 Resolved: 16/Dec/13 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Internal Client, Networking |
| Affects Version/s: | None |
| Fix Version/s: | 2.4.9, 2.5.5 |
| 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: |
|
||||||||
| Operating System: | ALL | ||||||||
| Steps To Reproduce: | If data is sent over a connection to a replica set member who previously closed the return connection (without being tested first by the connection pool), retries will only occur if slaveOk is set, read prefs are ignored. |
||||||||
| Participants: | |||||||||
| Description |
|
Issue Status as of January 8th, 2014 ISSUE SUMMARY This issue is part of 4 related issues which impact cluster availability when there is no primary available for a shard. See USER IMPACT It is present in versions of MongoDB prior to and including v2.4.8. SOLUTION In v2.4.9 only (this is set by default in v2.6.0 and later), it is necessary to use the following two startup parameters for mongos:
These parameters can also be set on a MongoS after launch with the following commands
WORKAROUNDS PATCHES Original DescriptionCurrently network-failure-retries-on-recv() only occur when the slaveOk flag is explicitly set. This is difficult to trigger but can cause spurious errors to propagate back up to the caller, since the connection pool itself tries to clear bad connections and most failures are detected when say() fails. Workaround is to set slaveOk flag for non-primary read preference. |
| Comments |
| Comment by Githook User [ 20/Dec/13 ] |
|
Author: {u'username': u'gregstuder', u'name': u'Greg Studer', u'email': u'greg@10gen.com'}Message: |
| Comment by Githook User [ 11/Dec/13 ] |
|
Author: {u'username': u'gregstuder', u'name': u'Greg Studer', u'email': u'greg@10gen.com'}Message: |