mirror of
https://github.com/facebook/sapling.git
synced 2024-10-11 01:07:15 +03:00
0431efa7f8
Summary: This setting is bad for a few reasons 1) there is no correct value; rejecting connections is typically something you want to do when under pressure, which no fixed number of connections can indicate 2) it's not discoverable when it trips, and pretty much always confuses people 3) the effect is generally not better than the thing it is theoretically supposed to prevent, when it trips, servers crash and exhibit other weird behaviors; I don't think I've ever seen a situation where I thought this was needed, and I've seen many were it created problems where none would have existed. About a year ago, I removed almost all calls to this; however, I left some behind since they were slightly harder to clean up or had unique flag names. Since then, 2 things have happened 1) more copypasta instances have cropped up 2) More people have run into issues with this flag, notably up2x recently This removes all calls except one (realtime Pylon has some somewhat more complex config here, I'll need to talk to them). This is somewhat aggressive; some of the calls are totally safe to remove, as they're either copypasted or set it to 0 or some absurdly high number. Others are less obvious. I've decided to adopt a door-in-the-face strategy here and see if anyone tells me I should be more conservative I couldn't delete all the flags; these ones are in use zdb_thrift_max_connection thrift2_max_connections (commerce ranker) max_connections (a bunch of places) maxConnections (presence) I'll need a separate diff/set of diffs to delete those Reviewed By: eduardo-elizondo, yfeldblum Differential Revision: D6182563 fbshipit-source-id: e778edd9da582f4ca90a902621cb49f1e04ca26e |
||
|---|---|---|
| .. | ||
| config | ||
| fuse | ||
| inodes | ||
| journal | ||
| model | ||
| rocksdb | ||
| service | ||
| store | ||
| testharness | ||
| utils | ||