Confluence Cloud to Server Migration issue with Dark Features

[Bryan Brinson]

I'm in the midst of a migration from Confluence Cloud to Server. It's going very well, except for an odd issue with two Dark Features that won't go away.

After the import of the Cloud backup, one of the issues I had was that I could not create or edit pages. The spinner would appear and spin indefinitely. After much troubleshooting and no luck, I discovered through CONF-44335 a workaround that worked great. By removing the Synchrony Dark Features as suggested in the workaround I was able to create/edit pages again.

However, and this is the odd part, two of these Dark Features return each time Tomcat/Confluence service is restarted.

To test this, I've:

1. Removed the features and confirmed they were removed be reloading the page, then confirmed the functionality I wanted by creating/editing pages again. 
2. Stop and Start the Tomcat/Confluence service. 
3. Confirm I can't create/edit pages.
4. Confirm two of the three dark features are back. 
5. Remove them again.
6. Confirm I can create/edit pages again.
7. Repeat the cycle each time the service is restarted.

Additionally, I tried removing them through startup parameters:

-Datlassian.darkfeature.site-wide.synchrony.opt-in=false
-Datlassian.darkfeature.site-wide.synchrony=false
-Datlassian.darkfeature.site-wide.shared-drafts=false

The "opt-in" option is removed, but the other two return every time the service is started and page create/edit is inoperative. And every time I remove them through the dark feature admin page, functionality is returned. 

Aside from removing these every time I restart a server/service, is there something else I can do to ensure these features remain disabled/removed? 

(Have also opened an issue with Atlassina already.)

Many Thanks!
Bryan

[Steven F Behnke]

Sorry, my team has run into this with several customers and were able to resolve it by identifying and working with Synchrony. They had the same issue, they didn't know much about the Synchrony service until I prompted them in a similar fashion. I haven't done it myself but I can try to ask what the deal was next week.

Good luck!

[Bryan Brinson]

Thanks again, Steven. Your suggestion put me on the right path. I'm currently rebuilding my AWS ELB from Classic to the new V2 to support Synchrony and I'm confident I can make this work now. 

https://confluence.atlassian.com/confkb/how-to-configure-amazon-web-service-elastic-load-balancer-with-confluence-6-0-859515417.html

Cheers!
Bryan

[Bryan Brinson]

Thanks for the feedback Steven! This makes sense. I was unfamiliar with Synchrony running as a separate process and on it's own ports. Does this mean I need to open the Synchrony port (8091 by default) through all the firewalls and through the configurations in server.xml like I have have for the main process?

[Steven F Behnke]

You should probably get Synchrony proxied correctly, or do you not care about Collaborative editing? Basically Synchrony can't communicate between Confluence and your users and the Create/Edit feature that relies on it then fails.

But the root cause here is that Synchrony can't communicate. We've run into it several times and the only problem is the fact that no one was thinking about Synchrony when setting up the newer version.