[SERVER-9041] proactively detect broken connections detected by the network Created: 20/Mar/13 Updated: 11/Jul/16 Resolved: 13/May/13 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Internal Client, Sharding |
| Affects Version/s: | None |
| Fix Version/s: | 2.5.0 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Greg Studer | Assignee: | Unassigned |
| Resolution: | Done | Votes: | 1 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
All OSes except 32-bit windows, which has a different polling interface. |
||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||||||||||||||||||||||
| Description |
|
When a host fails cleanly or connections are broken by keepalive failures, we should respond to OS-level info about connection state and clear these connections before using from the pool. |
| Comments |
| Comment by Brett Kiefer [ 17/Oct/13 ] |
|
I'd like to clarify what this fix does. It looks like the current situation (in mongodb 2.4) is that if a replica set primary loses its network connectivity (we simulate that by doing 'sudo ifdown eth0' on the primary), then reelection happens normally and mongos detects the new primary, BUT existing client connections via that mongos instance will not be terminated, and will continue in their hanging state. Is that what this is meant to fix? If so, might it be eligible for backporting, since this puts an odd responsibility on the client to detect a replica set failure when connected through mongos, and causes effective downtime even though failover has occurred? |
| Comment by auto [ 22/Jul/13 ] |
|
Author: {u'username': u'milkie', u'name': u'Eric Milkie', u'email': u'milkie@10gen.com'}Message: This is a partial backport of |
| Comment by auto [ 13/May/13 ] |
|
Author: {u'date': u'2013-05-13T23:04:53Z', u'name': u'Greg Studer', u'email': u'greg@10gen.com'}Message: |
| Comment by auto [ 13/May/13 ] |
|
Author: {u'date': u'2013-05-13T19:48:34Z', u'name': u'Greg Studer', u'email': u'greg@10gen.com'}Message: Revert " Can't use db variable in sharding tests without instantiating it first. This reverts commit 24fd0ec8b02ee86f9d11bf4a6cbf04aae42ccf65. |
| Comment by auto [ 13/May/13 ] |
|
Author: {u'date': u'2013-05-13T19:04:30Z', u'name': u'Greg Studer', u'email': u'greg@10gen.com'}Message: |
| Comment by auto [ 10/May/13 ] |
|
Author: {u'date': u'2013-05-10T14:16:20Z', u'name': u'Greg Studer', u'email': u'greg@10gen.com'}Message: |
| Comment by auto [ 09/May/13 ] |
|
Author: {u'date': u'2013-03-28T20:26:16Z', u'name': u'Greg Studer', u'email': u'greg@10gen.com'}Message: |