FWIW, I'm using the tweetstream ruby gem also, I've started to see
similar problems in production in the last few weeks with streams just
'stalling', typically during the morning PST. The gem does seem to
handle dropped connections just fine.
Also of note is that I see the same problem of the
Hi John,
I've had similar experiences for the past 2 weeks, and have been using
EM::Connection#set_comm_inactivity_timeout, which piggy backs of EventMachine's
reactor heartbeat
mechanism to circumvent this issue - no starved streaming clients thus far.
http://github.com/methodmissing/twitter-s
I've got my "tweetstream" test started - filter keyword is "haiti" -
it's delivering tweets about 2 - 5 per minute at the moment.
On Feb 20, 10:16 pm, John Kalucki wrote:
> I have a hunch that this doesn't happen on sample, or, if it does so, it
> happens much more rarely.
>
> On Sat, Feb 20, 201
I have a hunch that this doesn't happen on sample, or, if it does so, it
happens much more rarely.
On Sat, Feb 20, 2010 at 9:26 PM, M. Edward (Ed) Borasky wrote:
> I've got the "tweetstream" Ruby gem installed and I have a test driver
> program. I can fire this up if it will give anything useful
I've got the "tweetstream" Ruby gem installed and I have a test driver
program. I can fire this up if it will give anything useful. Is this
happening just on "filter" or would it happen on "sample" too?
On Feb 20, 9:02 pm, John Kalucki wrote:
> Arg. This is what I get for not checking the confi
I was looking at Gist's Java code the other day
(http://gistinc.github.com/TwitterClient/) and they had a similar
coding - they were
seeing newlines every 30 seconds so they set the timeout to one
minute.
// HttpClient has no way to set SO_KEEPALIVE on our
// socket, and ev
I don't doubt that this is happening, but, whenever I've looked into this in
the past, the issue boiled down to a poorly written client that didn't
detect a TCP Close or TCP Reset when the server, for whatever reason, ended
the connection.
However, it appears that something different is happening
Sorry, John but this is really happening and I am having it on a daily
basis in the last 2 weeks on both dev machine and production. I am
using Apache httpClient and this code was working fine for months
before this started to happen 2 weeks ago. I have a java call "String
line =reader.readLine();
On Feb 19, 2:55 pm, John Kalucki wrote:
> 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 suspe
I have had it get stuck with 'track' after around 16-20 hours. I am going to
try and reproduce it and then post details.
On Sat, Feb 20, 2010 at 2:38 AM, M. Edward (Ed) Borasky wrote:
>
>
> On Feb 19, 7:36 am, rob wrote:
> > Has anyone else ran into an issue where over time the Streaming API
> >
On Feb 19, 7:36 am, rob 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 open a persistent connection to the API (we are
> tracking and following).
>
11 matches
Mail list logo
