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

Loading pages with SQL macro are slower than normal and timeout more frequently

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Highest Highest
    • 5.9.7
    • 5.9.5, 6.0.0-m22, 5.9.6
    • None

      Bob Swift's SQL Macro is loading slowly and timing out. This is due to the rendering order of macros - in the past, nested macros would render after their parent macros. In 5.9.5 however this appears to have changed, and the inner macros are rendered first. This is negating the benefits of using the Cache, Future and Run macros to wrap slow SQL macros.

      Input:

      Future -> Cache -> SQL

      New rendering flow:

      SQL -> Cache -> SQL -> Future -> Cache -> SQL

      Old rendering flow:

      Future -> Cache -> SQL

            [CONFSERVER-41003] Loading pages with SQL macro are slower than normal and timeout more frequently

            Bob Swift added a comment -

            5.9.7 appears to resolve this issue. Thanks.

            Bob Swift added a comment - 5.9.7 appears to resolve this issue. Thanks.

            This is being tracked with Bob Swift here: https://bobswift.atlassian.net/browse/SQL-423

            Denise Unterwurzacher [Atlassian] (Inactive) added a comment - This is being tracked with Bob Swift here: https://bobswift.atlassian.net/browse/SQL-423

            Sunita from Bob Swift's company has identified an issue with the rendering order. This is what she said in CACHE-190 (which is private)

            Input:

            Future -> Cache -> SQL

            New rendering flow:

            SQL -> Cache -> SQL -> Future -> Cache -> SQL

            Old rendering flow

            Future -> Cache -> SQL

            I have tried couple of ways, but Its getting tough to demonstrate because final output is "Future -> Cache -> SQL" which is common on both the old and new rendering, so both display same output.
            As you see with the new rendering, inner most SQL macro executes thrice, Cache executes twice and topmost future macro executes once, hence its taking more time and timing out.

            NOTE: both future and cache macro render their own bodies (like a number of other macros) and apparently this is being circumvented. This is done via @RequiresFormat(Format.Storage)

            Denise Unterwurzacher [Atlassian] (Inactive) added a comment - Sunita from Bob Swift's company has identified an issue with the rendering order. This is what she said in CACHE-190 (which is private) Input: Future -> Cache -> SQL New rendering flow: SQL -> Cache -> SQL -> Future -> Cache -> SQL Old rendering flow Future -> Cache -> SQL I have tried couple of ways, but Its getting tough to demonstrate because final output is "Future -> Cache -> SQL" which is common on both the old and new rendering, so both display same output. As you see with the new rendering, inner most SQL macro executes thrice, Cache executes twice and topmost future macro executes once, hence its taking more time and timing out. NOTE: both future and cache macro render their own bodies (like a number of other macros) and apparently this is being circumvented. This is done via @RequiresFormat(Format.Storage)

              rading Ran
              rbattaglin Renan Battaglin
              Affected customers:
              4 This affects my team
              Watchers:
              15 Start watching this issue

                Created:
                Updated:
                Resolved: