My understanding (and perhaps Glenn, Brett or others from Heroku can chime in here to clarify) is that once a request hits 30 seconds, Heroku sends back a H12 exception page to the client (read: browser). I'm somewhat sure it does not terminate the request though, which continues to do its thing, just the response is ignored.
The one exception to this is streamed HTTP responses, which need to send data within the first 30 seconds, and then more data within a rolling 55 second window. https://devcenter.heroku.com/articles/request-timeout#longpolling-and-streaming-responses -- Pat On 06/12/2012, at 3:09 PM, Ben Taylor wrote: > Does Heroku forcefully timeout requests that go beyond 30 seconds? > > I've had success using Unicorn and changing my timeout time to be 60+ seconds > (hack to avoid switching to direct-to-s3 uploads). > > - Ben > > On Thursday, 6 December 2012 at 3:00 PM, Iain Beeston wrote: > >> Thanks Pat. Heroku also suggested we use rack-timeout. I hadn't thought >> about using the stacktrace to track down the cause of the problem though, >> good idea! >> >> >> >> Iain >> >> >> >> On 6 December 2012 14:25, Pat Allan <[email protected]> wrote: >>> One thing I've found tremendously helpful for increasing awareness of >>> timeouts - and then hunting down the cause - is rack-timeout. It'll ensure >>> those timeouts get raised as exceptions (and thus, you get stack traces, >>> and I think New Relic gets visibility too). >>> >>> https://github.com/kch/rack-timeout >>> >>> If you do change the default time limit (15 seconds), make sure you keep it >>> below 30 seconds when on Heroku (as that's when they'll consider a request >>> has timed out). >>> >>> -- >>> Pat >>> >>> On 06/12/2012, at 2:17 PM, Iain Beeston wrote: >>> >>> > Thanks Chris. We're not using papertrail but we are using logentries, >>> > which I believe has similar features. There's really nothing to go on in >>> > the logs other than where the timeouts are happening (we've increased the >>> > amount of logging but it hasn't helped us find the problem yet). Rather >>> > than rely on the logs for monitoring the app we use pingdom to hit the >>> > site periodically, but the end result is similar. >>> > >>> > >>> > >>> > Iain >>> > >>> > >>> > >>> > On 6 December 2012 13:46, Chris Aitchison <[email protected]> wrote: >>> > Add the Papertrail add-on to your app and you'll have a lot more logging >>> > information to work with. It can even send you an email when a log entry >>> > that matches a particular regex occurs, which sounds like it could be >>> > helpful here (assuming the logs indicate some sort of issue). And it >>> > could be free. >>> > >>> > Without more information, it would only be a guess to whether the issue >>> > lies in Heroku or the app code. If you only have one dyno, it will sleep >>> > after a few minutes of inaction, but I get the impression you are running >>> > more than one dyno so this shouldn't happen - and besides, the single >>> > dyno is still supposed to wake up. >>> > >>> > I think the log data is vital, even if you have to crank up the logging >>> > level until you find the culprit. >>> > >>> > Chris >>> > >>> > >>> > >>> > >>> > On 06/12/2012, at 13:03, Iain Beeston <[email protected]> wrote: >>> > >>> >> Lately we've had problems with the web-server processes in our rails 3.1 >>> >> app intermittently stop responding. We haven't been able to work out why >>> >> (no exceptions, high cpu or memory usage or networking calls) - it just >>> >> seems like every few days one them just randomly hangs and never >>> >> recovers. The process is still there, but not responding to requests and >>> >> everything sent to it times out. We're using heroku so our logging >>> >> options are limited. >>> >> >>> >> So, I was wondering - what do people use to keep their servers >>> >> responsive? (Especially on "hands-off" platforms like heroku) How common >>> >> is it to routinely restart processes? (Sounds like the wrong solution to >>> >> me, but some people recommend it) >>> >> >>> >> >>> >> Iain Beeston >>> >> >>> >> >>> >> -- >>> >> You received this message because you are subscribed to the Google >>> >> Groups "Ruby or Rails Oceania" group. >>> >> To post to this group, send email to [email protected]. >>> >> To unsubscribe from this group, send email to >>> >> [email protected]. >>> >> For more options, visit this group at >>> >> http://groups.google.com/group/rails-oceania?hl=en. >>> > >>> > -- >>> > You received this message because you are subscribed to the Google Groups >>> > "Ruby or Rails Oceania" group. >>> > To post to this group, send email to [email protected]. >>> > To unsubscribe from this group, send email to >>> > [email protected]. >>> > For more options, visit this group at >>> > http://groups.google.com/group/rails-oceania?hl=en. >>> > >>> > >>> > -- >>> > You received this message because you are subscribed to the Google Groups >>> > "Ruby or Rails Oceania" group. >>> > To post to this group, send email to [email protected]. >>> > To unsubscribe from this group, send email to >>> > [email protected]. >>> > For more options, visit this group at >>> > http://groups.google.com/group/rails-oceania?hl=en. >>> >>> >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Ruby or Rails Oceania" group. >>> To post to this group, send email to [email protected]. >>> To unsubscribe from this group, send email to >>> [email protected]. >>> For more options, visit this group at >>> http://groups.google.com/group/rails-oceania?hl=en. >>> >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Ruby or Rails Oceania" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/rails-oceania?hl=en. > > > -- > You received this message because you are subscribed to the Google Groups > "Ruby or Rails Oceania" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/rails-oceania?hl=en. -- You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.
