-
Bug
-
Resolution: Fixed
-
Low
-
6.8.1, 6.9.1
-
1
-
Severity 2 - Major
-
Summary
Pages with broken macros will experience slower load times if Confluence has individual gadgets or gadget feed added from a system with network latency.
Environment
- Confluence 6.8 and 6.9
- Gadget feed or individual gadgets added to confluence from another system, such as Jira.
Steps to Reproduce
- Create a blank Confluence page
- Add a broken macro to the instance by one of two methods:
- Via Source Editor
- Install Confluence Source Editor
- Edit existing page and add a non-existing macro to it via Source Editor:
<p> <ac:macro ac:name="testmacro"/> </p>
- Save page
- Via third-party plug-in
- Install a Third-Party plug-in, for example, view tracker
- Add a view tracker macro to a page
- Go to add-on manager and disable the plug-in
- Macro will appear as "Unknown macro: macro name" on the page
- Go to General Configuration > External Gadgets
- Either add a large number of gadgets individually or add gadgets feed with a large number of gadgets in it
- Go back and load the page with broken macro
Expected Results
Page loads quickly, considering there is no other content except for a broken gadget
Actual Results
Page takes a long time to load, the more gadgets exist in the feed and the slower the connection to them, the longer page will be loading.
Notes
- It appears that gadgets metadata is being pulled in the background by a macro browser on pages with broken macros.
- The issue is caused by a
CONFSERVER-55620bug - On consecutive re-load, page load is significantly faster, but clearing Gadget Metadata Cache from General Configuration > Cache Management will result in page taking a long time to load again.
- On our test instance with 48 gadgets in gadgets feed, the page with a broken macro took about 40 seconds to load, when it took milliseconds without the feed.
- Loading times are proportional to the number of gadgets, so although connection might seem fast to individual gadgets, each new gadget will stack and increase loading times:
Workaround
- The issue is fixed with 6.10.0, 6.6.7, 6.8.5, 6.9.3
- Make sure no broken macros are present on a page
- Removing Gadget feed and only adding individual gadgets that are required should help reduce load times
- is caused by
-
CONFSERVER-55620 CachingGadgetsMacroMetadataProvider shouldn't do http request for every macro
- Closed