I have XWiki instance with the real-time collaboration feature enabled. Different users report the same issue from time to time. When they are editing a page for a longer time (lets say 10min +) they see multiple “sessions” of them self (see screenshot below)
We are using the official XWiki 17.10.4 docker image behind a nginx reverse proxy. I can not see any relevant stack traces or error logs in the output of the application container.
The “NO_SUCH_CHANNEL” error indicates that the realtime collaboration session was closed. This happens when:
the (XWiki) server is restarted
the session remains empty because all users have left (either intentionally, or because they were disconnected)
In your case, the second cause is more probable. The reason the users get disconnected can be:
some networking issue on their side
inactivity (e.g. the user switches to a different task leaving the editor open in a background browser tab; the browsers are known to throttle timers in inactive tabs, leading to Loading... which causes the user to get disconnected)
On my side I wasn’t able to reproduce the issue by faking the network disconnect. I was able to reproduce something somewhat similar by canceling the editing after I got disconnected and then editing again. This lead to a duplicate toolbar. I can try to fix this along with Loading... , hoping this will fix your issue as well.
Since I do not see any issues in my network monitoring system (e.g. packet bursts, drops, …) for the client(s) or the server (which is a VM on a Proxmox cluster) I also assume it has something to do with a timeout.
I see this issue in my environment only with Chrome browsers so far. Users with Firefox, Safarie, … did not report this issue so far.
The linked JIRA ticket Loading... was a good hint. I will apply the patch from the linked pull request manually in my environment and observe if this solves the problem.
I did not know that certain browsers throttle inactive tabs that much. Crazy …
We have a similar problem, but not depending to Chrome browser/engine.
With the upgrade to XWiki 16, we enabled realtime editing. It worked out of the box.
But very often there are hiccups in the network and after that, XWiki is not able to reestablish the connection.
I reproduced the behavriour in a current firefox browser.
Opening a page, edit the page, set the network to offline via dev tools, wait 5 seconds, set it to unthrottled. After that, the XWiki page is not able to connect to server any more and the done button is gray forever.
I tested the changes from the PR https://github.com/cryptpad/netflux-websocket/pull/5 for a while now. After some further adjustments of the timeout values, the issue seems to be gone for most of the pages / users.
However, there is one specific page where the issue still occurs. The page is quit a large and contains a lot of links to other XWiki pages or other external sites. The initialization of the editor always takes around 6-7 seconds. Even before we enabled the collab. feature. …
I was able to reproduce your observation partwise. I started to edit a page in FF. Then I disabled the network connection via the dev tools window. Waited ~10 seconds. Enabled the network connection again. My editor needed a while until the connection was established again
@H4nn3
Thank you for your response.
Unfortunately this differs from our behaviour. I can wait forever, XWiki will never reactivate the connection and/or the done button.
Althoug the network seems similar:
Perhaps it depends on our XWiki version.
But in the meantime I found another workaround: Just enable the done button in the dev tools (delete “disabled” from button in dom tree) and I can successfully save the page
We have XWiki running as debian packages behind an apache 2.4. No problems so far … but also no logs on server side about the lost connection
Next steps will be to disable realtime editing, so we have a good usability again.
After that we plan an upgrade to XWiki 17 on a different infrastructure so things can change from any reasons.
