420 codes on sample endpoint?

johndburger · 2013-06-13T02:17:52.000Z

Hi -

I’m trying to switch my codebase over to the 1.1 Streaming API. I’m using the Tweepy Python library to access the sample endpoint:

https://stream.twitter.com/1.1/statuses/sample.json

I am consistently getting 420 status codes after getting 3-400 tweets, after 30 seconds or so. I don’t understand why I’m getting rate-limited. I only have one instance of my app, i’m not running it very often, etc. I’ve waited a while before trying again, with the same result. What could explain this?

Edit: with some debugging, I now see that I’m getting lots of disconnect messages (code 4). However, I know that no other connections are happening, what could be causing all of the admin logouts?

Thanks for any insight.

JB

kurrik · 2013-06-13T17:10:02.000Z

The 420 response code means that you’re connecting too frequently and have been rate limited. Maybe you have a connection attempt in a loop? You only get one HTTP response code per stream connection, so if you’re consistently getting 200 responses until the 420, you’re making a new connection each time.

johndburger · 2013-06-13T20:14:21.000Z

Yeah, as I said in my edit above, I see multiple disconnect messages (code 4, “admin logout”) before the 420. When these occur, does the API actually disconnect the stream? If so, Tweepy must be re-connecting, which explains the final 420 status code.

So my real question is, why am I getting all of these code 4 “admin logouts” disconnects? I know that I am not making simultaneous connections. Can code 4 happen for any other reason?

Thanks for your reply.

johndburger · 2013-06-14T01:36:22.000Z

I’ve now tried to access the sample endpoint with a completely different library, with the same result. I get some tweets for a few seconds, and then I’m cut off.

This is very frustrating, any advice would be much appreciated.

kurrik · 2013-06-14T01:44:08.000Z

Admin logout means that those credentials connected to the same streaming cluster at the same time and the oldest connection was kicked off. There’s a reconnect for each of those messages, so if you’re getting a lot, the client is too aggressively reconnecting.

If your client is attempting to open up more than one connection, you might see that, or if you connect from multiple machines using the same oauth codes, etc. Or if you’re opening a new connection inside of a loop.

johndburger · 2013-06-14T03:06:49.000Z

I’m doing this from only one machine, and I’m positive there are not concurrent connections.

I’ve tried this with two unrelated libraries that lots of other people use and gotten the same results. Is there any other possibility? Could it have something to do with my app’s auth credentials?

kurrik · 2013-06-14T05:56:39.000Z

The only reason you would get admin logout is because you were logged in twice with the same credentials.

Can you post more information? Code snippets of your connection setup? What endpoint and service are you querying?

johndburger · 2013-06-14T12:11:25.000Z

Aha, I just found an errant process that might explain this. Part of my confusion is that the docs seem to indicate that the OLDEST connection gets kicked off, so I thought any long-lived process would have died.

Sigh, very sorry for being one of THOSE people and wasting your time.

kurrik · 2013-06-14T18:58:22.000Z

Hm, it should be the oldest connection. If your errant process attempted reconnects, it might have been transparently reconnecting and kicking off the connection you saw getting rate limited. I’ll make a note to verify this behavior though - it’s been a while since I tested it.

Certainly not a waste of time