Nearly all, if not all, HTTP error codes returned by the Streaming API
require either human intervention to fix, or waiting many minutes for
a triggered rate limit to cool off. There's little difference in 3xx
codes and the 4xx codes returned, I think you can safely treat them
all equivalently.
Retry immediately, or nearly so, for network layer issues. For HTTP
error codes, your proposed algorithm is fine, but may be more
complicated than is needed. I do something akin to:
var sleepMs = 250
val maxSleepMs = 64 * 1000
while (errorCondition) {
DampedNotifyOperatior()
Thread.sleep(sleepMs)
sleepMs = Math.min(sleepMs * 2, maxSleepMs)
}
-John Kalucki
http://twitter.com/jkalucki
Services, Twitter Inc.
On Jul 27, 7:46 am, Joseph <northwest...@gmail.com> wrote:
> Thanks for the answer. A follow up: assuming there's no problem with
> my code, but I am getting errors opening up a socket due to twitter
> updates, acts of god, etc., would this be acceptable behavior (to keep
> the socket open):
>
> on > 400 errors: make my retry interval 10 seconds, for the next 4
> minutes, then switch to 1 minute for the next hour, then switch to 10
> minutes from that point on.
>
> on < 400 errors: make my retry interval 250ms for the next 16 seconds,
> then switch to 1 second for the next minute, then switch to 1 minute
> for the next hour, finally switching to 10 minutes from that point on.
>
> On Jul 27, 7:11 am, John Kalucki <jkalu...@gmail.com> wrote:
>
> > This would be considered abusive because you are circumventing the per-
> > connection keyword and rate limits by opening a second connection. The
> > system may force the first connection to disconnect. If your
> > application needs to track more keywords or a higher rate than the
> > default /track level, contact us.
>
> > -John Kaluckihttp://twitter.com/jkalucki
> > Services, Twitter Inc.
>
> > On Jul 27, 6:31 am, Joseph <northwest...@gmail.com> wrote:
>
> > > Using the streaming API, is it possible to open up more than one
> > > stream using the same login credentials, or would that be a considered
> > > bad behavior? For instance, I would like to open up a stream to track
> > > one set of keywords, and another to track another set of keywords.
