I agree. We have this issue in our system as well with large copy's or moves. Can we get some kind of indicator to the end-user about the process running.

Hi!

We are currently using Confluence 5.8.18. Since the upgrade from Conf 5.5.6 to Conf 5.8.16 and then 5.8.18, we see improvements on page moves regarding UI feedback. But still, very often our users do get a 'Problem contacting the server' message when they try to move a page (tree). However, the process itself is running in the background.

So what do the users do? They try to move the page again, no knowing that in the background the process is already running. This is causing unnecessary requests and system load on operation level and confusion on UI level.

For me, this issue is not yet resolved satisfactorily. Therefore, I would expect further improvements to make life and page moves easier and more user friendly.

This issue originally referred to page move performance. It has been superseded by the more detailed information in CONF-35396.

I have edited (repurposed) this issue to relate to ensuring concurrent slow page moves cannot be instigated and providing the user with some kind of feedback in the UI.

Upgrading Confluence from 5.5.3 to 5.5.6 resolved the issue for me.

John, that trick with disabling the Jira macros does, in fact, keep the error from popping up after 12 seconds; that's a great catch. And since we don't use Jira, this is a decent workaround for the error. Thanks a ton for sharing that.

We still have the system taking about 30 min or so to move a large tree, and there is no UI notification that the move has started, is running, or has completed (which it eventually does). CPU utilization is pretty much 100% between Java and MySQL.

I just wanted to add an observation of mine: We moved large page trees in version 5.6.3 in 10-15 minutes. In Version 5.4.4 we were used to wait for the result over night. So we are pretty happy with 15 minutes in this version.

I have found that if I disable the JIRA Macros add-on, the page moves execute without issue. Has anyone found other work-arounds for this bug?

My observations:

• it was slow in 5.4.4 as well. Especially when moving a page hierarchy.
• sometimes user move several hundred pages at once, negatively impacting the performance of the entire Confluence instance
• when moving so many pages, users expirience request timeouts and general slowness across Confluence

This might be interesting:

• CPU usage isnt particularly high, we have SQL Server running on a separate machine, the Confluence machine in general is responsive in normal OS usage
• when I manually trigger a Garbage Collection via JVM Tools (JVisual VM), the slowness stops and Confluence starts to serve http requests again. The page move operation seems to be unaffected by this.

That's our experience, exactly, as well.
We have Apache front-ending Tomcat in our environment (using mod_jk), and if we bypass apache, going directly to Tomcat, the behavior changes some:
The error after 12 seconds goes away
There is no UI update to the move screen at all.
MySQL and Java CPU utilization go through the roof (we're moving something like 800 child pages) for something like 30 minutes
Eventually CPU utilization returns to normal, and there still is no update to the web page; nonetheless, the pages have all been moved.

James, the error seems to come from https://jira.atlassian.com/browse/CONF-34233. We always receive it after 12 seconds whenever we move large page trees. Our large page trees seems to be moved anyway, after minutes, or hours or over night. We always have a bad feeling with this, but our task after upgrading to 5.6.3 is to move large page trees...