Possible deadlock around pool.Close()

[tonyghita]

Possible deadlock around pool.Close()

[mediocregopher]

Hmm that is really weird. The only thing I can think is that one of the pool connections is hanging on being closed? If you were able to get the trace that'd be amazingly helpful in figuring this out, otherwise I don't really know where to go. The next time if happens you can send the process a SIGABRT to have it dump the stack of every go-routine.

[mediocregopher]

I'm going to go ahead and close this issue. The Pool code has been significantly rewritten since it was opened, and apparently no one else has encountered this since. If something comes up we can absolutely reopen it.

[mediocregopher]

Hey @tonyghita, thanks for trying out v3 and submitting this. I also don't immediately see where this could be occurring, but if you could give a bit more detail about what the deadlock looks like (Close just hangs? go actually does the deadlock trace dump?) and how you're using Pool (by itself? in a cluster?) I could try and track this down further. Thanks!

[tonyghita]

Hey, sorry for the vague issue description.

The last thing I do on my application's shutdown is to call Close() on the Pool, which is connected to a single remote Redis instance.

The behavior I'm seeing is that the application does not exit, but waits indefinitely. Unfortunately we don't get the deadlock trace dump.

For added difficulty, this doesn't happen deterministically in regular usage (maybe 10% of the time).
I should also add that this is happening on Go 1.8.3.

[tonyghita]

The only thing I can think is that one of the pool connections is hanging on being closed

This seems like it may be the case. I don't see any connection leaking so it feels like maybe just one or a handful of connection is hanging on close.

In the meantime, to workaround the issue, I've wrapped the pool's close method with a timeout.