Big user lists cause time-out on login

[Kays]

I don't know if the service is down or what is going on, but I cannot connect to discord at all lately (at least with mfa). I even tried removing the token from the config xml file and retry, but every time I enter in my 2FA token in discord_mfa, the lag starts and just goes up until the point it just lags itself out and bitlbee restarts. Like it will start at 1 and just keeps counting upward. I verified with my twitter account that if I don't enter in 2FA token, no lag at all. But the second I enter it, bitlbee won't work and requires a restart. This also means my other connections on bitlbee won't work during this constant lag fest.

[dequis]

Are you using the latest revision? 7fdfd182218cea5ac9cfdb8f9f1e6ef6ce3d5083 fixes something possibly relevant. If you're not sure, build the latest.

[Kays]

I updated it but the bug still remains. The second I enter in the MFA token, it just lags out. I even timed it so the token just generated via Google Auth so it shouldn't be timed out.

http://i.imgur.com/LTEkcej.png

Edit: the worst part is that as long as the token is in the config and the account is on, I cannot use bitlbee at all because the second it tries to do something with mfa, it lags and will not respond to commands in &bitlbee. I have to take out that line in the config so I can use my other accounts and just ignore discord for now.

[dequis]

You could try attaching gdb to it. Find the pid of the child process with "ps aux | grep bitlbee" (there should at least two, pick the most recent one), attach to it with "gdb -p 1234" replacing 1234 with that pid, type "bt" to get a backtrace and "c" to continue. Post results.

If you're not sure you got the right pid, try attaching it before this bug happens - that should freeze it in a similar way, and won't respond the commands. Then use "c" to continue and unfreeze it, and when the bug is happening press ctrl-c in gdb and type "bt".

[erockce]

I haven't used the plugin in a while. The last time I logged in with the plugin (and MFA enabled), It lagged for me. Although it seemed be the result of joining all the channels associated with just 3 servers. Perhaps a future feature enhancement would be to not attempt joining a channel if it is muted.

[sm00th]

It is most likely not channels, but users. I've tried joining reddit's unofficial discord api server and it has a lot of users and that timed out as well. Back then I found out that imcb_add_buddy takes too much time on big lists, so this should be fixed in bitlbee first.

[dequis]

Oh, huh, I've never actually seen that hit in real servers, only in buggy conditions when plugins added tens of thousands of repeated contacts in a loop. Too many linked lists, not enough hash tables. I'll have a look.

[dequis]

I'll have a look.

Hmm...

Sorry for the delay.

[sm00th]

That pretty much confirms the previous "not enough hashtables" statement, doesn't it?

[dequis]

Ok here's some stuff:

• [x] https://github.com/bitlbee/bitlbee/pull/113 (hash tables for bee_user_by_handle)

• [x] https://github.com/bitlbee/bitlbee/pull/114 (hash tables for irc users)

• [x] https://github.com/sm00th/bitlbee-discord/pull/165 (not actually hash tables! a way to make the linked lists within this plugin efficient enough that they stop being relevant in callgraphs) (turned out to be faster because it's wrong)

• [x] https://github.com/sm00th/bitlbee-discord/pull/164 (small low-hanging fruit optimization found after dealing with all that)

[dequis]

Everything is now merged to the master branch of the bitlbee repo.

[erockce]

Just rebuilt latest from master, tested with MFA, and successfully echoed messages back and forth between Discord Linux client and bitlbee-discord. Nice job!