Troubleshooting Collaborative Editing
Collaborative editing is powered by Synchrony which synchronizes data in real time. Under normal circumstances it should not need to be managed manually by an administrator.
This page will help you troubleshoot problems with Synchrony in your instance.
Troubleshooting collaborative editing problems
First steps
Check Synchrony is running
To check if Synchrony is running, go to Administration > General Configuration > Collaborative editing .
Note: if you're running Confluence Data Center, this page will only be able to tell you if the current Confluence node is connected to your Synchrony cluster. You may want to use a third party monitoring tool to help you monitor your Synchrony cluster. See How to check the status of Synchrony for Confluence Data Center for more info.
Check you can edit a page
If you see an error when you edit a page, but Synchrony is running, something is preventing your browser from connecting to Synchrony.
The most common issue is a misconfigured reverse proxy. See our proxy troubleshooting tips later in this page or head to Administering Collaborative Editing to find out more about possible proxy and SSL configurations.
Check the logs
You can find the Confluence application logs at <home-directory>/logs/atlassian-confluence.log
and Synchrony specific logs at <home-directory>/logs/atlassian-synchrony.log
.
Restart Synchrony
If Synchrony is managed by Confluence, go to Administration > General Configuration > Collaborative editing and choose Restart Synchrony.
If you run your own standalone Synchrony cluster, manually restart Synchrony on each node.
Check port 8091 is available
Synchrony runs on port 8091 by default. If this port is already in use by another application on your server you can use the the synchrony.port
system property to change it to an available port.
(If you're using Confluence 6.0.3 or earlier you'll need to use reza.port
instead of synchrony.port
.)
See Configuring System Properties to find out how to change this.
For Confluence Data Center the way you run Synchrony is a little different. See Configuring Synchrony for more information.
Reverse proxy issues
If you have configured your reverse proxy, but can't edit pages, here's some things to check in your configuration:
- Go to
installation-directory>/conf/server.xml
and check theConnector
directive. Make sure that you have correct values for<protocol>
and<proxyName>
. See the examples in the guides below for more information. - The
http
connector always needs to be present in the<installation-directory>/conf/server.xml
file, even if you're configuring SSL or using the AJP connector. The Synchrony health check uses HTTP and will fail if this connector is not present. Alternatively, if you do not want to include the http connector, you can use thesynchrony.proxy.healthcheck.disabled
system property to disable the health check. - If you're using Apache, make sure you're using Apache 2.4 (with WebSockets support) and all required modules have been enabled (
mod-proxy
,mod_rewrite
,proxy_wstunnel
). - If you're using Apache and want to connect directly to Synchrony, in your proxy config file, make sure you've included
/synchrony
and that the order of the Confluence and Synchrony directives and location blocks is correct. See the examples in the guides below for more information.
See Administering Collaborative Editing to find out more about possible proxy and SSL configurations then check out the following guides for more information on how to include Synchrony in your reverse proxy config, if you want to connect direct to Synchrony:
- Using Apache with mod_proxy
- Running Confluence behind NGINX with SSL
- Proxying Atlassian server applications with Apache HTTP Server (mod_proxy_http)
- Proxying Atlassian server applications with Microsoft Internet Information Services (IIS)
- How to configure Amazon Web Service Application Load Balancer with Confluence
Forward proxy issues
If you're using a forward or outbound proxy, you will need to add the IP that Synchrony listens on to your config to ensure it is bypassed. See Configuring Web Proxy Support for Confluence for more info.
By default, the IP is 127.0.0.1, or it will be the value of the synchrony.host
system property, if you've customized the hostname or IP that Confluence uses to connect to Synchrony.
Websocket issues
Collaborative editing works best with a WebSocket connection. If one can't be established due to a timeout, or a proxy server or firewall that doesn't allow WebSocket connections, the editor will attempt to connect via an XML HTTP Request (XHR).
You can use http://websocket.org/echo.html to perform a quick HTML5 WebSocket test against an echo server.
It's possible to verify the websocket connection using the developer tools in your browser. In the following example, we'll use Chrome to check the websocket connection:
- Open the Chrome Developer Tools (Shift + CTRL + J)
- Select the Network tab
- Select the WS filter to show only WebSocket traffic
- Edit a Confluence page
- Select the websocket connection:
ws://<confluence-url>/synchrony-proxy/v1/bayeux-sync1
- Select the Frames/Messages tab to see the traffic between browser and the WebSocket.
SSL issues
Synchrony cannot accept direct HTTPS connections, so you will need to terminate SSL at your reverse proxy or load balancer, or at Tomcat if you are not using a reverse proxy.
Memory issues
If you experience out of memory errors related to Synchrony, you can change the heap size allocated to Synchrony using the synchrony.memory.max
system property.
If you're Confluence 6.0.3 or earlier you'll need to use reza.memory.max
instead of synchrony.memory.max
.
See Configuring System Properties to find out how to change this.
For Confluence Data Center the way you run Synchrony is a little different. See Configuring Synchrony for more information.
Multiple Synchrony processes
If you see an error immediatley in the editor, but Confluence reports that Synchrony is running, check to make sure that you only have one Synchrony process running.
If you do have multiple Synchrony processes running, stop Confluence, kill the additional Synchrony processes and then restart Confluence.
You can avoid this problem by always using stop-confluence.sh
/ stop-confluence.bat
to stop Confluence, rather than simply closing the Tomcat window.
Mixed Synchrony modes in cluster
If you're running Confluence in a cluster, all of your Confluence nodes must connect to Synchrony in the same way.
If users are able to use collaborative editing on one Confluence node, but not on another Confluence node, go to Administration > General Configuration > Clustering, then on each node choose Collaborative editing.
Make sure all of your Confluence nodes are reporting the same Synchrony mode - either Managed by Confluence, or Standalone Synchrony cluster.
You can access all nodes in this way, you don't need to hit a specific node in your browser.
Incompatible browser extensions
Some third party browser extensions that interact with the editor, such as Grammarly, may not function correctly with collaborative editing. See (Archived) Confluence Collaborative Editing blocks Grammarly Extension to find out how to disable Grammarly for just your Confluence site.
Firewall or anti-virus interference
We've had a few reports of firewalls or anti-virus software blocking some requests to the server, resulting in unexpected behavior in the editor. You may need to add Confluence to your whitelist / trusted URLs if you experience issues. See Weird Page or Editor Behaviors with Kaspersky Internet Security for more information.
Too many people in the editor
A maximum of 12 people can edit a page at the same time. This means that people can't enter the editor if there are already 12 other people editing the page, and will need to wait until someone leaves.
Administrators can increase or decrease this limit using a the confluence.collab.edit.user.limit
system property.
Create feedback reports to troubleshoot content problems
If you experience problems such as data duplication, our support team may ask you to create a feedback report to help us troubleshoot the problem.
Allow users to self report problems
By default, only people with system administrator or Confluence administrator global permissions can create a feedback report report problems through the administrative interface. You can choose to allow any user with Add page space permission to create a report.
To allow users to self-report problems:
- Go to Administration > General Configuration > Collaborative editing feedback.
- Under Who can create feedback reports, select the Anyone with edit permissions radio button.
This will add the Report editing problems item to the help menu in the header, when viewing or editing a page.
Report an editing problem
To report an editing problem from a page or blog post:
- Navigate to the problematic page or blog post.
- Select Help > Report editing problems from the header.
- Enter any relevant information, such as what you were doing when the problem occurred.
- Select Send feedback.
The report will be saved to the shared home directory, and will appear in the list of available reports (only accessible to system administrators).
Report an editing problem by page ID
System administrators can also generate reports for problematic pages using the page ID. This is useful if you don't want to allow users to self-report problems.
To generate a report for a particular page or blog post:
- Go to Administration > General Configuration> Collaborative editing feedback.
- Enter the page or blogpost ID in the
- Select Create report button.
The report file will appear in the list of available reports.
Send a report to Atlassian support
If you choose to share this data with our Support team for analysis, you can transfer the files through a support ticket.
Feedback reports should ONLY be provided when requested by a Support team member. Don't share this data in any public locations, such as in Atlassian bug reports.