Connection timeout too short on poor connections #2097

Closed
brauliobo opened this Issue Feb 26, 2014 · 16 comments

Comments

Projects
None yet
3 participants

Hello all,

I'm getting a lot of "Force reconnect" errors on etherpad-lite when the connection is pretty slow and or reconnect to the PPP server. That makes the pad unusable.

The pad version is 1.3.0. I have upgraded it to develop branch with no better result.

The pad is behind an apache 2.2 (debian wheezy) reverse proxy, using the configuration found on the wiki.

The same connection with Google Docs works ok. Does etherpad-lite uses a permanent tcp connection?

Is there a option that resumes the connection and don't need a force reconnect reloading the entire pad (which here takes a lot of time and sometimes stop on a error)? Maybe multiple requests is better?

bráulio

Owner

JohnMcLear commented Feb 26, 2014

Define pretty slow...

Bráulio Bhavamitra notifications@github.com wrote:

Hello all,

I'm getting a lot of "Force reconnect" errors on etherpad-lite when the connection is pretty slow and or reconnect to the PPP server. That makes the pad unusable.

The pad version is 1.3.0. I have upgraded it to develop branch with no better result.

The pad is behind an apache 2.2 (debian wheezy) reverse proxy, using the configuration found on the wiki.

The same connection with Google Docs works ok. Does etherpad-lite uses a permanent tcp connection?

Is there a option that resumes the connection and don't need a force reconnect reloading the entire pad (which here takes a lot of time and sometimes stop on a error)? Maybe multiple requests is better?

bráulio


Reply to this email directly or view it on GitHubhttps://github.com/ether/etherpad-lite/issues/2097.

A less than 500kbps (kilobits per second) with frequent (~1 hours) PPP reconnect

Owner

JohnMcLear commented Feb 26, 2014

Speed is fine, i assume your issue is on the 1 hour reconnect?

What transports do you have enabled in settings.json?

Bráulio Bhavamitra notifications@github.com wrote:

No, actually it drops more frequently than that, mainly when I'm doing a lot of editing. Going to check settings.json

The standard from template:

"socketTransportProtocols" : ["xhr-polling", "jsonp-polling", "htmlfile"],

Are timeouts used? It seems that dropping may be related to them, as some requests take much more time than others (I see that when loading websites)

Owner

JohnMcLear commented Feb 26, 2014

Yep but your connection should be fine. Try add websocket to your transports.

J

Bráulio Bhavamitra notifications@github.com wrote:

added in the first position. will conduct tests on the next few days. thanks for the support!

Owner

marcelklehr commented Feb 27, 2014

According to this, a disconnect should only happen if it takes longer than 20 seconds (!) to get your change accepted by the server.

@marcelklehr that makes a lot of sense marcel... for my connection and many others, this should be higher. could this be made configurable? my internet is very unstable, and sometimes it takes a much longer time to load a simple thing

Owner

marcelklehr commented Feb 27, 2014

What would be a more reasonable value? 50s?

certainly much better, but still a configuration would adapt more to each case. your pad is used by people from Brazil, where ISP companies are really dominating and making a bad job, but in other places this situation can be rather different

marcelklehr referenced this issue Feb 27, 2014

Merged

Release 1.4.0 #2069

6 of 8 tasks complete

This problem is really making the use of etherpad-lite unbearable. Add the websocket transport didn't make things any better

Using nginx instead of apache2.4 seems to make things a lot better. Still testing...

the problem was completely fixed using nginx. closing this!

where could I document this problems with apache?

brauliobo closed this May 20, 2014

Owner

JohnMcLear commented May 20, 2014

If apache is the cause it will have been a config issue with apache that should be solvable by modifying the config of the site. So documenting it would be modifying the reverse proxy wiki page with the correct config or at least adding a disclaimer to the config saying it causes X issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment