data-center: how to enable collaborative editing with internal synchrony-proxy?

Question

Hello I want to enable collaborative editing in Confluence with internal synchrony-proxy behind a reverse proxy. What I did: in setenv.sh: CATALINA_OPTS="-Dsynchrony.enable.xhr.fallback=true ${CATALINA_OPTS}" CATALINA_OPTS="-Dsynchrony.host= ${CATALINA_OPTS}" CATALINA_OPTS="-Dsynchrony.service.url=http://:8091/synchrony/v1 ${CATALINA_OPTS}" CATALINA_OPTS="-Dsynchrony.proxy.enabled=true ${CATALINA_OPTS}" in confluence.cfg.xml: true I'm not sure wich one is the right place because of https://jira.atlassian.com/browse/CONFSERVER-45728 It says, that it is already fixed, but i'm not sure, if it is really working. Although, http://:8090/synchrony-proxy/healthcheck gives me a output. synchrony is started with these options (only the relevant as far as I understand, if I'm missing some relevant, just tell me): -Dsynchrony.bind= -Dsynchrony.service.url=https:///synchrony-proxy What I'm unsure about is the context path in the synchrony.service.url that is given to synchrony. should it be /synchrony or /synchrony-proxy? It's not working in both cases. In the latter case, the collaborative editing page in confluence takes very long to load, and also for switching CE on. but editing at all is not working, there is this spinner icon forever. In synchrony log, nothing appears. When using /synchrony, I see this message in synchrony log as soon as i switch on CE: synchrony.http [warn] Secret request made from outside IP whitelist I'm not sure what this means, and if it is relevant at all, cause it's only a warning. Editing at all is not possible in this case. Also spinner forever I've checked already https://confluence.atlassian.com/doc/troubleshooting-collaborative-editing-858772087.html, and all that is mentioned there is fine. I guess I have just some misconfiguration, I can't see. Can anyone help me with that?

Lars Olav Velle · Answer

No, you will not have to make any changes to the firewall.

You simply make your existing reverse proxy also a proxy to the synchrony service.

If you were able to figure it out, please mark the question as solved.

-Lars

Christian Schneider_v83uhj · Answer

I had the wrong idea, that this would require me to open another pport on firewall. But after reading again I don't need this, as far as I understand. I will give it a try.

Lars Olav Velle · Answer

If you are using a reverse proxy, why don´t you want that proxy to also handle the upgrade the upgrade of the connection to websocket? It`s only a few lines in your apache or nxinx config. Here is mine for apache: Require all granted RewriteEngine on RewriteCond %{HTTP:UPGRADE} ^WebSocket$ [NC] RewriteCond %{HTTP:CONNECTION} Upgrade$ [NC] RewriteRule .* ws://localhost:8091%{REQUEST_URI} [P]