{"push_id":913539293,"size":5,"distinct_size":2,"ref":"refs/heads/cleaner-gossip-sender","head":"8d0e4b706b93c4d812839da6fb8baabb7d6f8e90","before":"cf3248febf0df82c08b46ea494d9dcec10ff50e9","commits":[{"sha":"d7835eabfbfcf10bfdba7eefe544cdbb51dcd7b7","author":{"email":"ac8fcaf748b7189c49a384a5580dc9e80633299a@gmail.com","name":"Matthias Radestock"},"message":"lazy route calculation\n\nInstead of calculating all routes in one go, we calculate them when\nneeded.\n\nExcept for unicast routes, and broadcast routes from ourself. We still\ncalculate those eagerly because they are needed to route locally\ncaptured/fdp-missed packets, and performing route calculcations in\nthat critical path increases the chances of dropping packets due to\nnot keeping up.\n\nWell, technically only the established & symmetric routes are needed\nfor the data plane, but we might as well calculate the equivalent\nroutes for the control plane - it keeps the code simple and uniform.\n\nCalculating all routes is O(n_peers^2), so this change represents a\nhuge saving in situations where not all of them are needed, which is\nquite common, especially when the topology is evolving rapidly.\n\nOne downside of this new approach is that we can no longer suppress\nOnChange callbacks when the data plane routes remain unchanged. This\nmeans we will be purging the FDP flows more frequently than before,\ne.g. when only the control plane topology changed, e.g. new\nconnections appeared that haven't been marked as 'established'\nyet. It's a small price to pay, fixable if we really care, and in any\ncase making FDP flow invalidation more fine-grained would be a better\napproach.\n\nFixes #1761.","distinct":false,"url":"https://api.github.com/repos/weaveworks/weave/commits/d7835eabfbfcf10bfdba7eefe544cdbb51dcd7b7"},{"sha":"b1cb0c298dd63ea0c1e63e34d2bb2913536e07bd","author":{"email":"ac8fcaf748b7189c49a384a5580dc9e80633299a@gmail.com","name":"Matthias Radestock"},"message":"refactor","distinct":false,"url":"https://api.github.com/repos/weaveworks/weave/commits/b1cb0c298dd63ea0c1e63e34d2bb2913536e07bd"},{"sha":"1796582032f270cf6b851741f3eb554dcec4b371","author":{"email":"de652539b24efdf404b95def4635bf3dbfd846aa@gmail.com","name":"Bryan Boreham"},"message":"Merge pull request #1773 from weaveworks/1761-lazy-route-calculation-1\n\nlazy route calculation; LGTM","distinct":false,"url":"https://api.github.com/repos/weaveworks/weave/commits/1796582032f270cf6b851741f3eb554dcec4b371"},{"sha":"03eb63c323fdfdd3066a803b3871bead87f9b171","author":{"email":"ac8fcaf748b7189c49a384a5580dc9e80633299a@gmail.com","name":"Matthias Radestock"},"message":"clean up GossipSender and make it more self-contained\n\nIn particular don't require Send() to be serialised by the caller.\n\nWe split up the triple(!) purpose 'cell' channel into:\n\n1) a 'cell' member, holding pending GossipData or nil\n2) a 'more' channel, for signalling that 'cell' has been filled\n3) a 'stop' channel, for requesting termination","distinct":true,"url":"https://api.github.com/repos/weaveworks/weave/commits/03eb63c323fdfdd3066a803b3871bead87f9b171"},{"sha":"8d0e4b706b93c4d812839da6fb8baabb7d6f8e90","author":{"email":"ac8fcaf748b7189c49a384a5580dc9e80633299a@gmail.com","name":"Matthias Radestock"},"message":"we no longer need the GossipChannel lock around GossipSender.Send","distinct":true,"url":"https://api.github.com/repos/weaveworks/weave/commits/8d0e4b706b93c4d812839da6fb8baabb7d6f8e90"}]}