I can get 29 weaves running on my laptop, and once all connections are
established, the avg cpu load is ~10%. 30 runs into difficulty because
the concurrent connection establishment does create a very high load,
resulting in some timeouts. But that wouldn't happen when running each
weave in a separate machine (with more CPU resources overall than my
single laptop).
Stop gap solution for #426.
which allows launching of several weave routers on the same machine,
by invoking this multiple times with different WEAVE_CONTAINER_NAMEs.
The routers are not connected to the bridge and do not perform any
capture/injection. So this is mainly intended for testing of
administrative and control plane functionality, rather than routing.
- make Zone, Iface and Upstream public - this is safe and makes sense
since all are immutable, and the former two are passed to the
constructor and are thus known anyway, and the latter is derived
from external information
- remove IfaceName - we can just use Iface instead
- log Upstream on startup
same purpuse as WEAVE_DOCKER_ARGS, except for weavedns
This allows us to get rid if the -fallback option since
WEAVEDNS_DOCKER_ARGS="--dns=..." has the same effect.
Closes#487.
we simply reset the vars controlling backoff for that address
Note that we do not interrupt any current connection attempt, since
that is hard.
Closes#499.
d5eb76f32 replaced (*Peer)ForEachConnection into (*Peer)Connections(),
and consequently converted some nested functions into for loops. But
the "return" statements in those nested functions were left as-was,
and so exited the outer function rather than moving on to the next
iteration.
Fixes#497
The previous scheme set the reference to main channel to nil and then
drained it. That was racy and hence could lead to deadlock in the
following scenario:
1. multiple senders obtain the main channel from the stored reference
2. main channel reference is set to nil
3. main channel is drained
4. multiple senders send to main channel
So the issue here is that the entire forwarder stopping sequence
occurs between senders obtaining of the reference to the main channel,
and then sending on that channel. If more senders sent than there is
capacity in the channel then this leads to deadlock.
Matthias Radestock