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 <marc.m...@gmail.com> wrote:
> * Taylor Singletary <taylorsinglet...@twitter.com> [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

Reply via email to