Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Possible deadlock around pool.Close() #1

Closed
tonyghita opened this issue Sep 14, 2017 · 5 comments
Closed

Possible deadlock around pool.Close() #1

tonyghita opened this issue Sep 14, 2017 · 5 comments

Comments

@tonyghita
Copy link

Hello!

I'm seeing some deadlock behavior when closing the pool. I don't immediately see where it could be occurring, but I thought I'd raise an issue.

Will fill in details as I discover them.

@mediocregopher
Copy link
Owner

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
Copy link
Author

tonyghita commented Sep 17, 2017

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.

@mediocregopher
Copy link
Owner

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.

@tonyghita
Copy link
Author

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.

@mediocregopher
Copy link
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants