The dyno is still running the long request, successfully. It's only the routing mesh that's returned the timeout error back to the user. Therefore, the dynos still in your 'grid' and ready for new requests.
I blogged about something very similar a couple of weeks back: http://neilmiddleton.com/avoiding-zombie-dynos-with-heroku Neil Middleton http://about.me/neilmiddleton On Wednesday, 16 February 2011 at 16:42, Tim W wrote: > The Heroku website claims: > > http://heroku.com/how/dyno_grid_last#3 > "If a dyno is unresponsive for any reason (user bugs, long requests, > or high load), other requests will be routed around it." > > In my experience, this does not seem to be the case. We have several > admin features in our app that when requested with certain params, it > can take longer then 30s to run. (I am working on ways to get these in > check and in the background). When a user trips one of these long > running requests, Heroku appears to queue additional requests to this > dyno and those requests time out, even though there are plenty of > other dynos available to handle that request. > > Is the statement on the Heroku website true or false? It does not > appear that Heroku actively monitors the dynos to see if they are busy > with a long running request. Is there a better way to handle this > situation? > > Thanks.. > -tim > > -- > You received this message because you are subscribed to the Google Groups > "Heroku" 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/heroku?hl=en. > -- You received this message because you are subscribed to the Google Groups "Heroku" 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/heroku?hl=en.
