When a container died before we got into the allocation code (inside
the allocator run loop) we would not cancel the allocation since the
container death event will have been processed by the allocator before
it had any knowledge of the container.
The fix is to move the container-aliveness check inside the allocation
code. That way we still detect the death even if the event has already
flown past.
We only need to perform the check once, since any subsequent death
will result in an event that is processed by the allocator when it has
recorded the container in its state.
Fixes#1459.
There are three significant changes here:
- rewrite ring.ErrDifferentSeeds errors
- remove the pre-checking of ranges and instead rewrite
ring.ErrDifferentRange errors
- don't pruneNicknames() and signal ringUpdated() when there was an
error
We don't rewrite other errors since our current belief is that only
ErrDifferentSeeds and ErrDifferentRange can arise from user error.
This is an early detector for a multitude of other symptoms, some of
which cause panics.
When creating the ring we record the paxos-supplied normalised list of
peers used for seeding. This subsequently gets gossipped around as
part of the Ring data structure, and checked in ring.Merge that it is
the same for the recipient.
There are some subtleties due to the desire to maintain backward
compatibility and deal with empty rings
- The gossip gob decoder will ignore the Ring.Seeds field when an old
weave receives a Ring from a new weave. So everything on the old
weave will just continue to work as before.
- The gossip gob decoder will set the Ring.Seeds field to nil when a
new weave receives a Ring from an old weave. We therefore omit the
seed equivalence check when the received Seeds slice is empty.
- Our ring may not have any seeds - either because it is empty or was
created from a ring received from an old weave. We therefore a) omit
the seed equivalence check in that situation, and b) set our seeds
to those received. Note that this allows us to learn about the seeds
well after ring creation - a situation which may arise when
receiving gossip from a mixture of old and new weaves.
Fixes#1463.
If a connection gets through all the handshake and subsequent checks -
i.e. it ends up getting added to the LocalPeer's connection list - but
gets terminated within one minute (of the start of the successful
connection attempt), then we apply the existing backoff logic to
schedule a retry, instead of retrying immediately.
In order to do this we retain the 'Target' data structure for such
connections, marking it as 'connected' instead of deleting it (as we
did previously).
Fixes#953.
- On-the-wire gossip messages are sorted case sensitive, but in memory they are sorted case-insensitive.
- Add test for case insensitive match on multiple names.
Matthias Radestock