Thanks for your response. But please let me clarify to ensure that I understand clearly.
1)
I soak tested for 24 hours. I had logging which logs started and stop events. I also made a note of the time that the start event began and checked it in the stop event. This allowed me to check for short sessions.
You did not intentionally created short sessions, you just listened to the events in order have a good overview of the disconnect.
2)
What I saw in normal use was a startsession event logged, followed 90s later by a stopsession event logged.
Again this was not intentional, you were disconnected from the stream by Twitter?
3)
In some cases though the stopsession fired before the 90 timer had fired which made me conclude that this was something else in the twitter API which was stopping the session early.
Can you have a look 2 messages above, the reply to StfSki. Do you think it might be what you experienced?
4)
The problem I had of course without adding more code to work around that was that the "anti stall" code was actually stalling and remained stalled until the rest of the 90s window expired to restart the session. Not nice. We are throwing away data.
Here I think I got lost, but from what I understand, the code that you created to ensure that your stream was kept alive was causing it to stall.
Final Question
5)
What do you think I could do to improve Tweetinvi and help you with these issues?
Thanks for the help and this detailed answer.
1) No I wanted to keep the sessions open always, the only closing I did was when the 90 timer elapsed. So something else in Twitter was closing the session. There was virtually no data expected based on the filter, so the cause was not that there was too much data, and I was falling behind. Something else was causing twitter to close it. I have most if not all the events implemented with logging and I could see no other problems being reported.
2) Yes Twitter unexepectedly disconnected. On the soak test there were around 50 short sessions detected, some as short as 10s. This represented about 6% of the 90s sessions over that period.
3) No. I dont believe that was the cause. See answer 1,
4) No. I dont think my code was causing it to stall. Events for a normal session were as follows
A. Stream Start
B. 90 s timer fires and stops and restarts stream
C. Stream Stop
D. Stream Start
Events for a problem session were
A. Stream Start
X. Stream Stop (unexpected)
B. 90 s timer fires and stops and restarts stream
C. Stream Stop
D. Stream Start
So what I am saying that for the window between X and B there was no session open. And data which would have appeared would have been thrown away.
5) To have the Tweetinvi layer do the job of maintaining the session up all the time, whatever it takes, so that the application does not necessarily need to worry about it. If there are any occasions when then cant happen then better error reporting / event firing would be good (Note: I if this detail is already these, sorry but I have missed it).
Thanks !
1)
I soak tested for 24 hours. I had logging which logs started and stop events. I also made a note of the time that the start event began and checked it in the stop event. This allowed me to check for short sessions.
You did not intentionally created short sessions, you just listened to the events in order have a good overview of the disconnect.
2)
What I saw in normal use was a startsession event logged, followed 90s later by a stopsession event logged.
Again this was not intentional, you were disconnected from the stream by Twitter?
3)
In some cases though the stopsession fired before the 90 timer had fired which made me conclude that this was something else in the twitter API which was stopping the session early.
Can you have a look 2 messages above, the reply to StfSki. Do you think it might be what you experienced?
4)
The problem I had of course without adding more code to work around that was that the "anti stall" code was actually stalling and remained stalled until the rest of the 90s window expired to restart the session. Not nice. We are throwing away data.
Here I think I got lost, but from what I understand, the code that you created to ensure that your stream was kept alive was causing it to stall.
Final Question
5)
What do you think I could do to improve Tweetinvi and help you with these issues?
Thanks for the help and this detailed answer.
1) No I wanted to keep the sessions open always, the only closing I did was when the 90 timer elapsed. So something else in Twitter was closing the session. There was virtually no data expected based on the filter, so the cause was not that there was too much data, and I was falling behind. Something else was causing twitter to close it. I have most if not all the events implemented with logging and I could see no other problems being reported.
2) Yes Twitter unexepectedly disconnected. On the soak test there were around 50 short sessions detected, some as short as 10s. This represented about 6% of the 90s sessions over that period.
3) No. I dont believe that was the cause. See answer 1,
4) No. I dont think my code was causing it to stall. Events for a normal session were as follows
A. Stream Start
B. 90 s timer fires and stops and restarts stream
C. Stream Stop
D. Stream Start
Events for a problem session were
A. Stream Start
X. Stream Stop (unexpected)
B. 90 s timer fires and stops and restarts stream
C. Stream Stop
D. Stream Start
So what I am saying that for the window between X and B there was no session open. And data which would have appeared would have been thrown away.
5) To have the Tweetinvi layer do the job of maintaining the session up all the time, whatever it takes, so that the application does not necessarily need to worry about it. If there are any occasions when then cant happen then better error reporting / event firing would be good (Note: I if this detail is already these, sorry but I have missed it).
Thanks !