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

Fix rare deadlock on multiple concurrent conn.Close() calls. #227

Merged

Conversation

DmitriyMV
Copy link
Contributor

Fix #226

DmitriyMV added 4 commits November 28, 2016 17:30
Return ErrClosed error if errors channel is closed (which it can only be if socket is closed too).
This will allow to use Go below 1.7
@michaelklishin
Copy link
Collaborator

So this seems to fix the same issue as #196. We'll need some time to weigh the two and merge the preferred version. Thank you.

@DmitriyMV
Copy link
Contributor Author

If I understand #196 correctly - it's about concurrent access from Channels. This fix is about sharing Connection object. Still - I agree with you, and would rather wait for other merge request to pass checks and see how this will affect the problem.

Will investigate again when #196 is green.

@michaelklishin
Copy link
Collaborator

@DmitriyMV OK, we will take a look at this PR earlier then. I've seen Travis failures that I cannot reproduce locally so it's not clear if the changes in #196 are to blame :(

}

wg := sync.WaitGroup{}
wg.Add(5)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When I change this value to something higher than 5, I cannot get the suite to pass 20 times in a row, e.g.

for i in {1..20}; do go test -v -tags integration_test.go .\/...; done

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Never mind, I figured it out.

}

wg := sync.WaitGroup{}
wg.Add(5)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Never mind, I figured it out.

@michaelklishin michaelklishin merged commit 170a3e8 into streadway:master Dec 3, 2016
michaelklishin added a commit that referenced this pull request Dec 3, 2016
If a connection.close operation fails before the connection is marked
as closed internally, it's still a reasonable error for Connection#Close to return.

Note that it only happens with a certain degree of concurrency
in this test and thus the occurrence is quite unlikely in practice.

References #227.
@michaelklishin
Copy link
Collaborator

Thank you!

@DmitriyMV DmitriyMV deleted the fix-concurrentclose-deadlock branch December 12, 2016 10:14
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

Successfully merging this pull request may close these issues.

2 participants