twit
twit copied to clipboard
ttezel
Stream reconnects after calling stop
I noticed that at times a reconnection is scheduled even though the stream has already been stopped. I tried as a workaround to subscribe to the reconnect event and to issue another stop there, but it doesn't seem to prevent the stream from resuming. Ideas?
Are you having this issue on the latest version of twit? If not, can you try updating your version of twit? npm update twit gets the latest version.
Yup I'm using 2.2.2. I actually need to correct my statement, if I call once again stop in the reconnect event listener it prevents the stream from resuming, but it seems that it still attempts reconnecting even after I called stop on the stream. A brief look at the persistent connection code does not show any obvious issues, but I'm pretty sure about the behavior I'm experiencing. I call stop on the stream, no one calls start on it, but it reconnects at some point. Not always, but often.
Can you post your code reproducing this issue please?
On Mon, Feb 15, 2016 at 2:29 PM, Simone Busoli [email protected] wrote:
Yup I'm using 2.2.2. I actually need to correct my statement, if I call once again stop in the reconnect event listener it prevents the stream from resuming, but it seems that it still attempts reconnecting even after I called stop on the stream. A brief look at the persistent connection code does not show any obvious issues, but I'm pretty sure about the behavior I'm experiencing. I call stop on the stream, no one calls start on it, but it reconnects at some point. Not always, but often.
— Reply to this email directly or view it on GitHub https://github.com/ttezel/twit/issues/241#issuecomment-184424219.
It's extracted from an app using angular, but the workings should be straightforward. The stream is not exposed so there shouldn't be any other piece of code messing with it. You can see also my workaround in there.
Further investigation shows that the unexpected reconnection attempts come from _resetStallAbortTimeout
I think I can see where the issue potentially is. I see that _resetStallAbortTimeout is called in several places, especially when a response is received. This method unconditionally calls _scheduleReconnect, which unconditionally tries to start the persistent connection. Assuming that my analysis is correct I think that this can happen if, after stopping the stream, you receive a response (which I would say is quite likely), and I guess this can be solved by checking the value of _abortedBy, somewhere, as it is done in _onClose. Makes sense?
I imagine we can be simply replace the _scheduleReconnect's with the _onClose handler, which checks _abortedBy and does rescheduling promptly.
@ttezel have you try reproducing the issue? I can reproduce it fairly consistently, but I may be failing to see the issue in my code, although it's very simple. My explanation above is just a speculation, I haven't really followed the code carefully to check that it's really what's happening.
@simoneb @andreapozzetti Did you ever get a solution for this problem? I believe I am having the same issue. I push handled tweets to a message queue but after some time I start to get duplicate tweets show up in the queue and this usually occurs right after a manual stream restart.
@SeanEire sounds like the same issue. I haven't made any attempts at fixing it.
If this is still a problem, twitter-lite provides a different stream implementation, and I haven't seen this issue when using stream.destroy().
