[SERVER-5642] Make mongobridge work with ShardingTest to facilitate testing network partitions in a sharded system Created: 18/Apr/12  Updated: 19/May/14  Resolved: 07/Nov/12

Status: Closed
Project: Core Server
Component/s: Sharding, Testing Infrastructure
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: Spencer Brody (Inactive) Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-4505 Don't assume old primary is still pri... Closed
is depended on by SERVER-4661 Mongos doesn't detect primary change ... Closed
Duplicate
duplicates SERVER-7573 Add tests for network connectivity lo... Closed
Participants:

 Description   

This will require changing mongobridge to rewrite the output of replicaset commands to hide the real host/port behind the bridge address so that mongos doesn't see an inconsistent view of the replica set configuration. This will also require changes to the ShardingTest class in the shell so that it can set up a bridged sharded cluster.



 Comments   
Comment by Spencer Brody (Inactive) [ 07/Nov/12 ]

Closing this out in favor of using failpoints to test network connectivity problems (SERVER-7573)

Comment by Spencer Brody (Inactive) [ 06/Aug/12 ]

Never mind, that wouldn't help with the way things currently work as there can be multiple bridges (each on a different port) routing to the same mongod

Comment by Spencer Brody (Inactive) [ 30/Jul/12 ]

Another idea would be to provide a hidden option to mongod, something like --proxyPort, that allows you to specify another port that mongod will still recognize as itself. That would eliminate the need to do any command rewriting in mongobridge, and would simplify the existing code around bridging replica sets as the members of the set wouldn't have to have different views of the replica set configuration, they could all just use the bridge ports.

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