Gajim - 2023-07-21

yes

lovetox: I noticed a growing "storage" branch, is there some place I can read more about its purpose? 🙂

I have many MUCs and I've noticed that gajim 1.8.0 has a hard time fetching MAM, I've also noticed that after keeping the client running for a while, it takes a long time to switch from chat to chat, I was wondering if this branch has any intent to improve upon that, and whether it's a good time/idea to start testing it

no, its a new db layout, i dont think it will help with your problems

and no its not ready for testing

Gajim becoming slow on chat switches after long time of running, is also something i notice, but no time to track down what could be the cause

im not aware of any MAM related problems, how do they manifest?

I also see that slowdown happen for only an individual chat if someone spams it really hard or sends a really big message that ends up having "show more" or whatever at the bottom ✏

lovetox: some rooms never actually finish catching up with MAM (the new spinning icon keeps spinning forever). Could be that the server times out/fails to serve a response because the SQL server behind is under some load, I don't know if that's something the client could be made aware of

but then its not Gajim that has a problem with MAM

I suspect some rooms block others

if the catch-up is sequential

everything is sequential in xmpp

i doubt that this is the problem, except you are on a very slow connection

could gajim have a sane timeout and skip/try later a room that fails to respond?

and then it would finish, but just later

I don't have a slow connection, just a IO-starved server 🙂

soo.. then it just finishes later

why would the server never serve the request

what would it make for a difference if i send the request again 5 minutes later? then im again behind in the queue of whatever the server trys to work

> why would the server never serve the request because ejabberd cancels the query. I can configure extremely long SQL timeouts, though ↺

> what would it make for a difference if i send the request again 5 minutes later? then im again behind in the queue of whatever the server trys to work because if the server choses not to respond, the client waits indefinitely for something that will never happen. Trying it again later at least gives it a chance ↺

but I agree it's dirty

ideally the server should have a "protocol" to communicate to the client that it won't get a response ATM

sounds weird to me, i responds to a muc join, but not to the iq?

if it thinks it cannot fullfill the request, it can always send a iq back with an error

> ideally the server should have a "protocol" to communicate to the client that it won't get a response ATM

there is

<iq><error type=wait><text>server is busy try later</text></error></iq>

if the server sends this im happy to try again later

bbl

but there is no IQ timeout cancel from client side ✏

not in the xmpp protocol i mean

so yeah it would be dirty

so, in fact I should see if the erlang process crash I see as a result of the db not responding results in something like this: `<iq><error type=wait><text>server is busy try later</text></error></iq>` being sent