I'm using the http_upload module with the Conversations XMPP Client. With some files I having problems during the upload. The upload at the client is stuck at 100% but is not finished completely. After doing some debugging and sniffing I am quite sure, that client is missing the HTTP-response from the server after it's HTTP-PUT request. The sockets stays connected. After 30min I get an IO-Exception in the client-app (probably a socket timeout or something similar). This is *only* occurring when prosody is using libevent (use_libevent = true). Some more facts/curiosities: * I can reproduce this behaviour with a certain picture at an Galaxy S device (a 25kB screenshot). It always fails. * The upload of the same picture from another device (Nexus 5) always succeeds, while here another picture causes the same reproducible behaviour. I verified the content-length and some other things in Conversations, so that I think that this must be a bug in prosody. As I have no clue about lua I need some help here :-). My current setup: * prosody 0.9 nightly build 254 (2016-01-05, 7b0651e4534f) from prosody's apt-repository - but the problem also occurs with 0.10, trunk, etc. * current head of prosody-modules * an ubuntu 14.04 machine Here the issue for the conversations client - I firstly thought it is a conversations bug: https://github.com/siacs/Conversations/issues/1612

Hi! This sounds like this issue with lua-event: <https://github.com/harningt/luaevent/issues/6>. Try adding this in your global section: network_default_read_size = "*a"

Hi! This works :-). Thank you! As far as I understand this workaround isn't that bad, as you just read more data at once (4k is default, 8k with this option, right?) from LuaSocket's buffer. So in the worst case this could cause a higher memory footprint of the server, correct?

No, the memory usage would be the same. LuaSockets 8k buffer would still be 8k. The potential issue is if you have compression enabled, where a small amount of data can expand to become much larger. We thought that 4k would be a good value, but then this luaevent issue turned up and has been haunting us ever since. And because the buffer in LuaSocket is 8k, you can't read more than that anyways, so this is basically moot. This affects every type connection, not just http, so I'll change the title. XMPP mesages tend to be smaller than 4k tho, but I've seen vCard requests trigger this.

• title LuaEvent is unaware of LuaSocket buffers
• owner Zash

This workaround is committed as http://hg.prosody.im/0.9/rev/0386ccf20ac7 which is in the latest release. I'll mark this as fixed for now, but the underlying issue in LuaEvent is still there.

• tags Status-Fixed

If moving data over a loopback connection, it seems that despite reading '*a'-ll, connections may still get into the stalled state with remaining buffered data.

You didn't incorporate your fix in 0.9 into 0.10 (https://hg.prosody.im/0.9/rev/0386ccf20ac7) Together with your changes in https://hg.prosody.im/0.10/rev/3fc5560557a5 (0.10) the whole prosody server is unusable for me as every client gets into stalled state with the tcp read queue growing larger and larger.

Changing the local default_mode = config.get("*", "network_default_read_size") or 4096; into local default_mode = config.get("*", "network_default_read_size") or "*a"; fixes it for me.

No I intentionally set it back to 4k in https://hg.prosody.im/0.10/rev/d6f12056afda because the read size should not matter with this change.

But apparently for me it *does* matter. I Updated my prosody 0.10 server to the latest nightly yesterday and every connection but my gajim connection in the internal lan got stalled after a few stanzas.

What version of luaevent do you have?

It's a Debian Wheezy machine with lua-event 0.4.3-1.

Running two instances of prosody on Debian 8 with lua-event as well (A is prosody-0.10_1nightly334-1~jessie with lua-event 0.4.3-1, B is prosody-0.10_1nightly333-1~jessie with 0.4.3-5~wheezy). When user@A joins a small-size MUC on chat.B, the response from chat.B is over 4KB. The first 4KB are read by A (and shown by rawdebug), and then no more data arrives from chat.B to A, so the client can never complete the join (initially reported as #827). I've added `network_default_read_size="*a"` on A,restarted A and the join completes now.

I think *a should be the default. It apparently solves all sorts of libevent problems and doesn't have severe side effects.

Did not solve my problem here. Here, the upload works (prosody 0.11.9-1~bpo10, lua-event 0.4.6-1) but not viewing them. The connection is simply timing out.