Uploaded image for project: 'Confluence Data Center'
  1. Confluence Data Center
  2. CONFSERVER-24883

Moving a page can time out and leave Confluence in an inconsistent state

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Tracked Elsewhere
    • Icon: Medium Medium
    • None
    • 4.1
    • None

      Moving a large page hierarchy is slow, very slow. If you sit behind a proxy the operation will eventually timeout. Behind the scenes it is likely the instance will either run out of memory, slow down so much it is restarted, or fail for a number of reasons. This leaves Confluence in an inconsistent state with some attachments moved others not. The DB transaction is obviously rolled back so the space appears to not have been moved.

        1. CONF-24883_faster_page_move_v1.diff
          40 kB
          Matt Ryall

            [CONFSERVER-24883] Moving a page can time out and leave Confluence in an inconsistent state

            Petro Semeniuk (Inactive) added a comment -

            Tracked in https://jira.atlassian.com/browse/CONF-34870

            Petro Semeniuk (Inactive) added a comment - Tracked in https://jira.atlassian.com/browse/CONF-34870

            Matt Ryall added a comment -

            Attaching a patch of Daniel's work on this issue. This is actually the output of "git show", so might need a bit of munging to apply via a patching tool.

            Matt Ryall added a comment - Attaching a patch of Daniel's work on this issue. This is actually the output of "git show", so might need a bit of munging to apply via a patching tool.

            Daniel (Inactive) added a comment -

            The interim solution is to narrow the transaction so that each page moved is in a transaction. This would mean that an aborted move would leave some pages in one space and others in the other but it would also mean that at most one page's attachments will be missing

            That I believe is what this bug is about. IF the transaction is rolled back we need to rollback the move of the attachments as well. This is non trivial.

            Daniel (Inactive) added a comment - The interim solution is to narrow the transaction so that each page moved is in a transaction. This would mean that an aborted move would leave some pages in one space and others in the other but it would also mean that at most one page's attachments will be missing That I believe is what this bug is about. IF the transaction is rolled back we need to rollback the move of the attachments as well. This is non trivial.

            Tim Wong (Inactive) added a comment -

            If each page move is transactional, wouldn't that be a large performance hit? Granted a bulk page move is a rare occurrence, but I worry about causing people who rely on a reverse proxy having a simple page timeout when attempting the move.

            Tim Wong (Inactive) added a comment - If each page move is transactional, wouldn't that be a large performance hit? Granted a bulk page move is a rare occurrence, but I worry about causing people who rely on a reverse proxy having a simple page timeout when attempting the move.

            Eric Dalgliesh added a comment -

            The real solution is to get rid of the need for a transaction entirely (see [CONFDEV-9185]) but that is a non-trivial amount of work. The interim solution is to narrow the transaction so that each page moved is in a transaction. This would mean that an aborted move would leave some pages in one space and others in the other but it would also mean that at most one page's attachments will be missing. A nice side effect is that as the transactions are smaller, they will consume less memory and therefore be less likely to OOM the instance.

            Eric Dalgliesh added a comment - The real solution is to get rid of the need for a transaction entirely (see [CONFDEV-9185] ) but that is a non-trivial amount of work. The interim solution is to narrow the transaction so that each page moved is in a transaction. This would mean that an aborted move would leave some pages in one space and others in the other but it would also mean that at most one page's attachments will be missing. A nice side effect is that as the transactions are smaller, they will consume less memory and therefore be less likely to OOM the instance.

              Unassigned Unassigned
              dkjellin Daniel (Inactive)
              Affected customers:
              10 This affects my team
              Watchers:
              22 Start watching this issue

                Created:
                Updated:
                Resolved: