Hi John, I've had the same setup for a while now without issue, but from 17:00GMT I started getting connections dropped, then once connected they'd just hang. I'll look into the lib and make sure its not my end.
Scott. On 22 Feb 2010, at 22:25, John Kalucki wrote: > I don't believe that we've seen this issue since 15:55 UTC. If you've been > seeing hangs more often, it's possible that you are experiencing another > problem. Or, equally likely, there is another set of things going wrong. > > I've restarted the cluster twice today, but this shouldn't cause hanging -- > just closed connections. > > -John > > > On Mon, Feb 22, 2010 at 1:53 PM, Scott Wilcox <sc...@tig.gr> wrote: > Same issue here, over the past six hours more than ever. > > On 22 Feb 2010, at 19:13, John Kalucki wrote: > >> One further note: A reasonable workaround for the moment is to, if your >> client allows iotcls, set a socket timeout of about 90 seconds on your >> streaming api connection. The servers currently send a newline every 30 >> seconds. If you stop receiving newlines for 90 seconds, your connection is >> probably high and dry, and you should reconnect. Please be sure to continue >> honoring the reconnection policies as described in the wiki, however. >> >> -John Kalucki >> http://twitter.com/jkalucki >> Infrastructure, Twitter Inc. >> >> >> >> On Mon, Feb 22, 2010 at 10:51 AM, John Kalucki <j...@twitter.com> wrote: >> A number of developers have reported abandoned connection issues on the >> Streaming API starting, perhaps, about two weeks ago. The symptoms include a >> long-established TCP connection to stream.twitter.com going quiet, with the >> connection mysteriously held open for perhaps hours afterward. After sorting >> through a lot of conflicting data and chasing a few wild geese, I finally >> reproduced this problem at Feb 22 15:55 UTC (7:55am PST). I'd imagine that a >> number of streams were abandoned at this time. If you had a correlative >> experience within a minute or so of 15:55 UTC, please respond to this >> message. >> >> We currently suspect an infrequent hardware load balancer issue, perhaps >> related to a recent configuration change. The appearance is that the load >> balancer is, for whatever reason, dropping valid connections, closing the >> connection to the Streaming API servers, but not sending a TCP FIN or TCP >> RST to the client. This is bad. We're treating this as a critical production >> issue and working through the details with network operations. I'll follow >> up as we learn more. >> >> -John Kalucki >> http://twitter.com/jkalucki >> Infrastructure, Twitter Inc. >> >> >> > >
Description: S/MIME cryptographic signature