jdev - 2020-08-10

so im running into a problem with ejabberd since a long time

when i join many MUCs (hence much traffic)

it seems ejabberd sends me stanzas and i dont get the chance to ack them until ejabberd runs into some stream management queue limit

and aborts the connection

so back then i just thought ok maybe my network code is shitty, lets rewrite this, but its still happening, and i dont really get what i could do better

there is a outgoing connection and incoming connection, i have callbacks on both when they are "ready"

and if they are ready, i write or receive data

and if they are ready is decided by GLib

so i didnt write the socket code

i dont know why the outgoing connection does not become ready .. maybe because of the other side, but thats just a guess

does any developer here have special code that somehow handles this case

You haven't got something going on like "I'll only write to the socket once I'm done reading from it" have you?

That's what the problem sounds like.

no i definitly dont have that

GLib abstracts that

lovetox, are you sure that glib will let you alternate between read and write if both are possible?

i get a callback when the socket is ready, either to receive or to write

and when i get that callback i use it to do exactly that

no im not sure, but how do other devs tackle that problem, do you explicitly after X bytes received, send stuff?

my event loop takes care of that

but I don’t trust glib

how?

(my event loop = asyncio.whateverthedefaulteventlooponlinuxis)

but asyncio has write queues, so I *expect* it to write things from the queues when possible and only then hand me read callbacks.

ok i expect also things from GLib, so you don't handle that case yourself

lovetox, I suggest you go and read the glib source code

thing is i had that problem when i used python network code

and i only ever had it with ejabberd

prosody has no stream management queue size limits AFAIK

s/prosody/the unofficial mod_smacks/

ok, I checked asyncio; it will alternate between readers and writers. each iteration of the loop collects ready events and then processes them

I don't know what the issue is, but what you're describing is 100% the behaviour you'd get if you don't bother writing until you're done reading, and there's a lot of data to read.

So I'm aware of implementations that manually alternate to avoid reading from the queue forever.

yeah i know this sounds like that

maybe it is, maybe i should ask the GLib guys if they alternate between the streams

lovetox, just read the source

that’s the least ambiguous answer you’ll get