Timeout problem on slow connections.

Chat rooms for mChat with optional password protection and 1-on-1 chats
Post Reply
Bgagger
Donor
Posts: 45
Joined: 28 Nov 2018, 15:57

Timeout problem on slow connections.

#1

Post by Bgagger » 20 Jun 2019, 18:34

Some of our users have experienced problems opening rooms while on mobile devices with a slow connection.
Opening a new room times out within a few seconds and reverts back to the public channel. Preventing access to rooms most, but not all of the time.
For most users this has not been a problem. It has been confirmed to effect about 4 users so far. It seems limited to mobile users only.
Other forum pages load normally, if slowly when this occurs. Chat messages in public channel of mChat also load normally. So posting and reading messages in the public channel works normally. mChat handles the error gracefully, without crashing.
The problem seems to boil down to how quickly the request to enter a room fails.
The errors given appears to indicate that data is being cut off at some point, causing strings that never close, forcing a time-out for the room request specifically.
It has been confirmed to happen with Firefox, Edge and Chrome.

I have been unable to replicate the problem myself. I'm not sure if much can be done about this, since it's not a consistent bug, only an issue combined with slower connections. But if it can be looked into that's appreciated as our users rely heavily on rooms.

User report:
"Some other users have reported that sometimes they can't change channels in chat: it opens the window in Public, and then when attempting to open any other channel the spinning icon comes up for two to three seconds and then disappears, keeping the user in Public. This looks like it could be an issue with timeouts being set too low, or something that effectively functions like a timeout: I'm currently traveling, and my internet connection here is much slower than my usual connection. On this same device at home, I've never had an issue. Here, it happens every time without fail. Refreshing the page and re-opening the browser does not fix the problem. It's not an issue of the internet connection being too poor to run chat, it's not the best connection but it is relatively stable and can reliably interact with other real-time online applications most of the time.

When viewing the network tab in the browser, almost all refresh and whois POST requests get responses and 200 status codes. enter requests receive 200 statuses, but either do not receive a response at all, or receive invalid JSON in the response:

SyntaxError: JSON.parse: unterminated string at line 1 column 16385 of the JSON data

(16385 is the most common index I've seen for those, but I have seen others as well.)"

User avatar
kasimi
mChat developer
Posts: 968
Joined: 06 Oct 2016, 09:56
Location: Germany
Contact:

Re: Timeout problem on slow connections.

#2

Post by kasimi » 21 Jun 2019, 08:18

Bgagger wrote:
20 Jun 2019, 18:34
SyntaxError: JSON.parse: unterminated string at line 1 column 16385 of the JSON data
What values other than 16385 have you seen? That value is equal to 16KB + 1 byte, so it seems there's some kind of size limit after which the response is cut off. I assume the server generates a valid response, but it arrives on the client side in an incomplete state.

What's the number of initial messages you show in each room? Try setting it to some lower value. 16KB of mChat messages is quite a lot. It would be interesting to see the actual response body (payload).

Bgagger
Donor
Posts: 45
Joined: 28 Nov 2018, 15:57

Re: Timeout problem on slow connections.

#3

Post by Bgagger » 25 Jun 2019, 13:30

'SyntaxError: JSON.parse: unterminated string at line 1 column 49153 of the JSON data'
Has also been reported, to my knowledge. Though 16385 seems to be the most common.

We have had to raise the initial number of messages to 14, any lower and the 'infinite scroll' add-on stops working properly.

Could the number of rooms open at a time effect this? IE. could reducing the number of open rooms help when this becomes an issue?

Our 'Maximum message length:' has also been raised. Currently at 1536. I guess lowering it might also help keep the transfer size down.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest