Thanks for the great job you'v done.
I'm facing unreported disconnection in the FilteredSteam.
According to this [page](https://dev.twitter.com/streaming/overview/connecting), such stalls must be expected from Twitter Streaming API, and in the same page, a best practice is provided to handle such stalls in witch:
- A newline is sent by the API every 30 seconds as a heartbeat to maintain the connection.
- If no heartbeat signal is received for 90 second, the app must disconnect and reconnect immediately according to the backoff strategies provided in the same page.
I dug into the source code and I found that streaming loop is handled in the class StreamResultGenerator, but I didn't find that best practice there.
My question is:
Is this best practice to maintain the connection with Streaming API is handled somewhere else or this is a feature yet to be provided ?
Thanks again.
Comments: ** Comment from web user: linvi **
I'm facing unreported disconnection in the FilteredSteam.
According to this [page](https://dev.twitter.com/streaming/overview/connecting), such stalls must be expected from Twitter Streaming API, and in the same page, a best practice is provided to handle such stalls in witch:
- A newline is sent by the API every 30 seconds as a heartbeat to maintain the connection.
- If no heartbeat signal is received for 90 second, the app must disconnect and reconnect immediately according to the backoff strategies provided in the same page.
I dug into the source code and I found that streaming loop is handled in the class StreamResultGenerator, but I didn't find that best practice there.
My question is:
Is this best practice to maintain the connection with Streaming API is handled somewhere else or this is a feature yet to be provided ?
Thanks again.
Comments: ** Comment from web user: linvi **
By the way, you can also use your own Timer in your code and use the _JsonObjectReceived_ event to check every call received from Twitter (blank lines included).
Linvi