influxdb/pkg/lifecycle
Jeff Wendling 59279837e5 tsi1: partition close deadlock
When a tsi1 partition closes, it waits on the wait group for compactions
and then acquires the lock. Unfortunately, a compaction may start in the
mean time, holding on to some resources. Then, close will attempt to
close those resources while holding the lock. That will block until
the compaction has finished, but it also needs to acquire the lock
in order to finish, leading to deadlock.

One cannot just move the wait group wait into the lock because, once
again, the compaction must acquire the lock before finishing. Compaction
can't finish before acquiring the lock because then it might be operating
on an invalid resource.

This change splits the locks into two: one to protect just against
concurrent Open and Close calls, and one to protect all of the other
state. We then just close the partition, acquire the lock, then free
the resources. Starting a compaction requires acquiring a resource
to the partition itself, so that it can't start one after it has
started closing.

This change also introduces a cancellation channel into a reference
to a resource that is closed when the resource is being closed, allowing
processes that have acquired a reference to clean up quicker if someone
is trying to close the resource.
2019-04-22 09:06:32 -06:00
..
resource.go tsi1: partition close deadlock 2019-04-22 09:06:32 -06:00
resource_debug.go pkg/lifecycle: resource debug tracking at runtime 2019-03-05 18:41:37 -07:00
resource_test.go storage: fix problems with keeping resources alive 2019-02-28 10:22:01 -07:00