Looks like it is working as normal again now... Horrid way to find out our internal poller has a 10 minute timeout on a request though :D
On Feb 28, 7:30 pm, Marc Mims <[email protected]> wrote: > * Taylor Singletary <[email protected]> [110228 06:57]: > > > Thanks for the reports -- we're looking into the timeout issue. > > I've been seeing this, too. To combat it, I've set my request timeout to > 8 seconds and I use with Net::Twitter's RetryOnError trait (perl). > > Last year, at Chrip, one of the speakers said Twitter's internal > strategy is to timeout quickly and re-queue. From my tests, it appears > requests normally fail in 4-5 seconds with a 502 if they can't be > fulfilled in that amount of time by the backend. > > Taylor, can you confirm that? What is Twitter's internal cutoff? That > would help me set an optimum request timeout on my end. > > FWIW, the Net::Twitter RetryOnError strategy is to retry any request > that fails with an HTTP status code >= 500. It delays 250ms before the > first retry and doubles the retry delay until it gets to 4 seconds. If > it still can't get a successful return, it throws an error at that > point. > > -Marc -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk
