I don't know about streamed HTTP, but I believe your first paragraph is correct (based on conversations with heroku this week). After the 30s timeout heroku will return a timeout to the client and then start passing your process more requests, even though it's still processing the previous one...
Iain On 6 December 2012 15:17, Pat Allan <[email protected]> wrote: > 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. > > -- 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.
