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

Config first data timeout #1111

Merged
merged 2 commits into from Jun 4, 2017

Conversation

alexlance
Copy link
Contributor

No description provided.

@alexlance
Copy link
Contributor Author

alexlance commented Oct 13, 2016

There is an issue with the AWS ELB, where if the ELB's idle timeout is larger than the instance's tcp keepalive timeout, then the ELB will sometimes report back 504s to the user client.

If you configure puma with this first_data_timeout setting to a value that is higher than the ELB's idle timeout, then you can circumvent that problem.

This patch exposes the first_data_timeout setting to the puma DSL. I have manually tested this patch and it works as intended.

@nateberkopec
Copy link
Member

I'm going to say this is probably blocking on getting test_timeout_in_data_phase fixed, otherwise we have no coverage for this.

@nateberkopec nateberkopec modified the milestone: 3.7.0 Nov 23, 2016
@alexlance
Copy link
Contributor Author

Right. I don't know how to fix that.

@nateberkopec
Copy link
Member

Heh me neither right now, sorry :) Not your fault/problem, we just need to fix that before merging.

@nateberkopec nateberkopec added the waiting-for-changes Waiting on changes from the requestor label Dec 13, 2016
@nateberkopec nateberkopec removed this from the 3.7.0 milestone Dec 13, 2016
@alexlance
Copy link
Contributor Author

So apparently if you add travis_wait in front of the bundle exec command in the .travis.yml file then you get 20 minutes of grace time instead of 10 minutes from travis ci. Would that help?

@nateberkopec
Copy link
Member

I don't think so, it's a deadlock that doesn't ever resolve.

@frodsan
Copy link
Contributor

frodsan commented Dec 14, 2016

I made some notes about that test here: 43ee6dd#commitcomment-20006908

@nateberkopec
Copy link
Member

Alright, you know what. This is just adding a config point, your use case is valid, not a big deal. Sorry this took so long to merge.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature waiting-for-changes Waiting on changes from the requestor
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants