-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Capybara hangs with multiple drivers if there are not enough threads #2227
Comments
I'm not sure there's anything Capybara should do about this, since it seems to purely be a user configuration issue. Capybara doesn't control the number of opened requests, that's really dependent on your app and how many simultaneous requests it opens, and Capybara automatically shutting down drivers by default is a non-starter from a performance perspective (and from a user expectation perspective). If the browser/puma are keeping open connections after the browser has been reset to |
Note: another potential workaround would probably be to set |
This very much appears to be a bug or design flaw in puma - The fact that a persistent connection ties up a thread on the chance a request might come over that connection seems like not great behavior. This would really only be an issue when puma is run with no workers (which wouldn't be done in production) but it still seems a little nuts. |
Ok - setting |
Fixed via 5752b7e |
@twalpole nice find! |
Hello, After a little digging on upgrading I found this fix breaks our cucumber tests marked @javascript. Results in "This site cannot be reached"/"The connection was reset" for Chrome/Firefox. (Sorry didn't see any more useful information.) I can't see a way to pass in/override the queue_requests option - is that currently possible? |
@benht-nps Interesting - I'm guessing your app is making more than 4 simultaneous requests - You can pass any options to puma via the server setting
|
Thanks :) That fixes it. |
…sing Capybaras Puma server registration - Fix Issue #2227
Meta
Capybara Version: 3.25.0
Driver Information Latest ChromeDriver on Chrome 75
Puma: 4.0.0
Expected Behavior
I can run the test suite successfully
Actual Behavior
The test suite errors out with
Net::ReadTimeout with #<TCPSocket:(closed)>
or sometimesNet::OpenTimeout
Steps to reproduce
Create a test suite with 3 or more drivers (say one for chrome with iOS emulation, one with Android emulation and one for desktop -- you can use any drivers you want but just need to be 3 different registered drivers)
Enable SSL with Capybara using technique found here (Support configuring the puma server to use SSL #2028).
Run suite and wait for the timeouts
Example 3 drivers
Example suite
Leads
I noticed when we boot a capybara session using SSL you get this:
I also notice from time to time that Puma keeps connections open for a long time and prevents terminating the server even if the webpage is fully loaded.
I also noticed if you revert back to just HTTP this doesn't happen (at least not at 3 drivers, maybe at a higher level).
Taken together my hypothesis was that we were using up all the threads on the server (either with stale connections, or not having enough connections to begin with for the number of drivers specified for usage -- especially if we make a HTTP request, fail and then make a HTTPS request like it looks like we are doing).
Workaround
Option 1
If I shutdown the browsers after each test everything seems to work. Which lead me to believe that the server's default 4 threads might be an issue
Option 2
Increasing the max thread count also seemed to resolve the issue.
Idea
Maybe some combo of increasing the default number of threads and shutting down drivers if there are more than a few open would help resolve the issue.
The text was updated successfully, but these errors were encountered: