-
Suggestion
-
Resolution: Fixed
-
1
-
A feature request for async job executor for reconciliation when a page is submitted for a content reconciliation. This would allow us to have merge multiple calls to reconciliation if they are for same content and result in eventual consistency.
Currently, reconciliation runs as a post-commit task for a attachment CRUD operation in a listener and when a lot of linked pages are there to a container of the attachment, it could require a lot of Synchrony recons, which turns into a big transaction in the listener.
So, it would be great to either:
- Break the reconciliation into multiple transaction, and/or
- Perform this reconciliation with a worker pool in async manner rather than keeping the attachment request blocked.
Customers with the following warning message in their logs will benefit from this request:
WARN [https-jsse-nio2-443-exec-7] [confluence.util.profiling.DurationThresholdWarningTimingHelperFactory] logMessage Execution time for post-commit task com.atlassian.confluence.internal.content.collab.AttachmentRelatedContentReconciliationListener$$Lambda$2945/0x00000001033df040@42a5575b took 148279 ms (warning threshold is 5000 ms)
Impact on apps
ConfiForms - Data Forms & Workflows
The ConfiForms app is affected by the lack of this feature. In particular, a timeout might occur when submitting a form via the app when the forms are configured to move attachments between pages.
Workaround
Reducing the number of items (linked pages or attachment) that are processed as part of the reconciliation request will help preventing this in the first place.
- causes
-
CONFSERVER-99157 Error during linked content reconciliation (triggered by an attachment) causes some linked pages content to be duplicated
-
- Closed
-
- relates to
-
- Gathering Interest
- incorporates
-
DEVHELP-13494 Failed to load
[CONFSERVER-78239] Make reconciliation transaction in async executor
Hello,
We are currently experiencing this issue and it has delayed our migration efforts by months. We have had to disable collaborative editing in order to make progress.
Please consider this request with a little more urgency as this continues to create persistent difficulties for scroll version users trying to migrate to confluence cloud.
Best regards,
Taiwo.
Hi there,
this is David from K15t, developers of Scroll Versions for Confluence. We'd like to let you know that this issue has a massive impact on the user base of the app.
Scroll Versions adds space-wide versioning and publishing these versions to other spaces is one of its core features. Publishing is a long-running task that creates or updates an entire Confluence space with the content of a space version of a Scroll Versions-managed space. The introduction of reconciliation transactions has had a drastic effect on publishing performance and reliability. For spaces that use a lot of attachment links, we've observed an increase of publishing time by a factor of up to 10 (from 10 minutes to 2 hours), with some larger customers reporting system outages.
Executing the reconciliation in an async manner would prevent these transactions from blocking our publishing task while it's running.
We'd really like to see this being addressed, as this is likely to affect most of the ~1400 instances currently using Scroll Versions, especially as they're updated to recent later Confluence 7 versions.
Cheers,
David
I would like an update as well.
We will soon reach the milestone of "1 year without Collaborative Editing" because of this issue.
Please make a solution for this a high priority in your roadmap.
Hi
Any update on this may be? This is really a blocker for our customers who use ConfiForms to create and move pages and have collaborative editing enabled.
Performance starts to degrade with each use, until it starts to throw timeout issues (ConfiForms awaits (blocking) for Confluence to finish the reconciliation process)
Alex
Briefly on how this affects ConfiForms forms (and which ones are affected)
- Collaborative editing in Confluence is enabled
- Your ConfiForms form accepts files and has a rule to move attachment(s) to some other page (or pages) as a part of a form submit
- This works fine for some time
- When the number of "moved attachments" reaches some threshold (number of attachments moved) the mentioned warning starts to appear in the logs
- This is synchronous task and form submission is blocked by this and it looks like the form submission gets stuck and never completes
- The form is actually submitted and the data is saved, but the user is warned about the error on form submission after some timeout (2 mins)
This issue can be reproduced without ConfiForms.
Basically you need to create a page in Confluence ands develop a simple p2 plugin with just one xwork action (or servlet) that uses https://docs.atlassian.com/ConfluenceServer/javadoc/7.1.0/com/atlassian/confluence/pages/AttachmentManager.html#moveAttachment-com.atlassian.confluence.pages.Attachment-java.lang.String-com.atlassian.confluence.core.ContentEntityObject- to move an attachment from one page to another;
then have a REST API calls to upload attachments and to your plugin's xwork/servlet to move uploaded attachment (does not matter if you move them on one page or multiple)
You will see the performance of your test will start to degrade at some point, as reconciliation job will start to have troubles getting the job done
A fix for this issue is available in Confluence Server and Data Center 8.1.0.
Upgrade now or check out the Release Notes to see what other issues are resolved.