[twitter-dev] Streaming API question..

2010-09-27 Thread omri
hi there, I am using the streaming API (the statuses/filter), and I get a lot of tweets in spanish. I wanted to know if there is a way to get results only in English? I tried to use the geo-location of the USA only, but it didn't help much. anybody? thanks, Omri -- Twitter developer

Re: [twitter-dev] Streaming API question..

2010-09-27 Thread Taylor Singletary
Hi Omri, Sorry, there's no option currently to filter by language. Taylor On Mon, Sep 27, 2010 at 1:50 AM, omri omridek...@gmail.com wrote: hi there, I am using the streaming API (the statuses/filter), and I get a lot of tweets in spanish. I wanted to know if there is a way to get results

Re: [twitter-dev] Streaming API question

2010-02-20 Thread Marc Mims
* rob robert.bag...@gmail.com [100219 08:56]: Has anyone else ran into an issue where over time the Streaming API just stops sending results? Yes. I'm seeing the same thing. I've set up a 45 second timeout. The following entries were extracted from the application log. I'm currently following

Re: [twitter-dev] Streaming API question

2010-02-20 Thread John Kalucki
A 45 second period of inactivity is not unusual when following just 100, or even 100,000 users. The keep-alive newlines are only sent once every 10 minutes. You should not reconnect so aggressively. -John Kalucki http://twitter.com/jkalucki Infrastructure, Twitter Inc. On Sat, Feb 20, 2010 at

Re: [twitter-dev] Streaming API question

2010-02-20 Thread Marc Mims
* John Kalucki j...@twitter.com [100220 20:24]: A 45 second period of inactivity is not unusual when following just 100, or even 100,000 users. The keep-alive newlines are only sent once every 10 minutes. You should not reconnect so aggressively. I can certainly set the time out to 10 minutes.

Re: [twitter-dev] Streaming API question

2010-02-20 Thread John Kalucki
Arg. This is what I get for not checking the configuration each time. Yes, it's currently set to send a newline every 30 seconds. On Sat, Feb 20, 2010 at 8:45 PM, Marc Mims marc.m...@gmail.com wrote: * John Kalucki j...@twitter.com [100220 20:24]: A 45 second period of inactivity is not

Re: [twitter-dev] Streaming API question

2010-02-20 Thread Marc Mims
* John Kalucki j...@twitter.com [100220 21:02]: Arg. This is what I get for not checking the configuration each time. Yes, it's currently set to send a newline every 30 seconds. Ok. Sorry to drag this out, but what, then, is an appropriate timeout value for the application? @semifor

Re: [twitter-dev] Streaming API question

2010-02-20 Thread John Kalucki
60 or 90 seconds seems reasonable, but your code should also detect a socket close immediately and reconnect immediately. The common case for a connection drop -- a server restart -- should cause your socket to close, the client to detect the closure, and reconnect, all within about a second. On

[twitter-dev] Streaming API question

2010-02-19 Thread rob
Has anyone else ran into an issue where over time the Streaming API just stops sending results? We are using a Ruby library to connect (twitter-stream) which uses EventMachine to open a persistent connection to the API (we are tracking and following). The library properly handles reconnection

Re: [twitter-dev] Streaming API question

2010-02-19 Thread Atul Kulkarni
Me too! Exact same case. I am using tweepy. On Fri, Feb 19, 2010 at 10:36 AM, rob robert.bag...@gmail.com wrote: Has anyone else ran into an issue where over time the Streaming API just stops sending results? We are using a Ruby library to connect (twitter-stream) which uses EventMachine to

Re: [twitter-dev] Streaming API question

2010-02-19 Thread Dima Brodsky
Hi, Yup, I saw it the last couple of weeks, this week has been considerably better. I use the delimited stream so I do read(entry size), read(entry), repeat ... I just put a 30 second timeout on the read operation (this is all in python) and if a read fails I close the stream and

Re: [twitter-dev] Streaming API question

2010-02-19 Thread John Kalucki
This shouldn't be happening, and having developers build these sorts of workarounds saddens me. It is possible that the server side is holding dead connections open, but I doubt it -- as I've a considerable amount of data to the contrary. I suspect that the socket code does not detect a close,