Twitter fails to update when Jabber reconnecting

[SynrG]

During the recent jabber.org DDoS, my Jabber account was repeatedly reconnecting with messages like:

09:35 <@root> jabber - Logging in: Connecting
09:37 <@root> jabber - Login error: Connection timeout
09:37 <@root> jabber - Logging in: Signing off..
09:37 <@root> jabber - Login error: Short write() to server
09:37 <@root> jabber - Logging in: Reconnecting in 900 seconds..

Also during that time, my Twitter account stopped receiving updates. After the DDoS was over, and I had logged out of Twitter and back in again, then logged into Jabber again, Twitter updates were restored.

To reproduce this problem after the DDoS was over, I had to DROP traffic to jabber.org with iptables at my firewall to simulate the failure in a way that would cause a soft failure (i.e. reconnection attempts are made). After that rule was in place, I logged into both Jabber and Twitter. The Jabber login attempt failed, and immediately started reconnection attempts. Now, some time elapsed before a tweet arrived on the web, so I don't know exactly when Twitter updates failed in bitlbee, but I confirmed that no further tweets arrived after this point, even though I knew they had arrived on the web. It appears, therefore, that Jabber reconnecting causes Twitter to fail to update.

It was insufficient to simply cancel the Jabber account reconnection retries to make my Twitter account work again. I had to log out of Twitter and back in again before new tweets arrived in bitlbee again.

Thanks to everyone on irc who helped me to identify this problem and patiently answered my questions and helped me set up a reproducible failing case, particularly wilmer and TigerP.

[wilmer]

Couldn't reproduce this here, strangely. :-( Will keep it running in case it takes a while..

[SynrG <synrg@…>]

On Aug 21, 2012, there was another DDoS directed at jabber.org. During this time I retested, first to see if a single failure to login would reproduce the bug (it did not) and a second test that allowed a single reconnection attempt (it did reproduce the bug). My exact steps for that second test were:

• restart bitlbee
• identify (starts connecting 6 accounts)
• after jabber account login fails (with same "Short write()" error I reported above) allow it retry 5s later
• after the retry fails, bitlbee reports it will wait 15s
• immediately log the jabber account out with "account 2 off"
• watch for tweets on the web (there were at least 2) and compare with the #twitter_bitlbee channel (none of these tweets showed up)

[SynrG <synrg@…>]

wilmer, you also asked if I use any plugins. I do not.

[wilmer]

In a way the JSON branch will fix this as it uses the streaming API instead of polling.

Unfortunately I've never managed to reproduce this and didn't have time to try harder. :-(

[anonymous]

Replying to wilmer:

In a way the JSON branch will fix this as it uses the streaming API instead of polling.

Unfortunately I've never managed to reproduce this and didn't have time to try harder. :-(

Interesting. Well, in the meantime I don't recall the last time this happened (but maybe that is due to a decrease in frequency of the conditions that cause it more than anything else).

[wilmer]

Let's just assume it's fixed then. It seemed very much like a problem on identi.ca's end. Feel free to reopen if this happens again, although I'm not sure what could be done against this other than manually deduping.

[wilmer]

D'oh. It looks like I confused this bug with another one (#998). I'm glad the problem went away for you. Reopening to fix the resolution.