Retry Feature

Summary

New for Cache release 6.8, both the Cache Macro and the Future Macro support a retry capability. This is an advanced feature where the cache and future macros can react in a more useful manner when the rendering of the macro body indicates certain types of errors that are likely caused by a temporary condition with an underlying macro or external service. The goal is to make it more likely that meanful data will be shown on the page at any point in time.

For example, the SQL macro may determine that a database is temporarily not available and indicate a retry is possible. In the case of the cache macro, it will attempt to show previously cached data, if available, instead of showing the temporary error. Then, on the next render request, the rendering will be retried. 

Related Issues

key summary type created updated due assignee reporter priority status resolution
Loading...
Refresh

Details

This feature is available when the rendering of the macro body indicates a temporary error condition has occurred during the rendering. This requires underlying macros to be enabled to report this type of error so that the cache or future macro can behave differently. For instance, the SQL macros (with release 7.0) have been enable to do this for certain temporary errors.

Cache Macro

The Cache Macro will try to use previously cached data (that may be stale) if it is available instead of showing the error from the rendering. More importantly, the next request for the cache macro managed data will result in a new request to render the macro body in the hope that the rendering will be error free and return meaningful data. Without this support being enabled, the error rendering would have been shown until the cache expired.

By default, this support is enabled. However, a new retry parameter on the Cache Macro can control this behavior. The parameter defaults to Default which recognizes a setting of an administrator controlled value that defaults to Enable.

Future Macro

The Future Macro will not show the error data and, instead, will retry rendering the body after waiting a certain amount of time specified by the retryInterval parameter on the macro. The retryInterval parameter defaults to Default which recognizes a setting of an adminstrator controlled value that sets the number of seconds to wait. This means that the loading message will continue to show until good data is retrieved. 

The retry logic is controlled by the client page and stops as soon as the page is no longer being shown.

Using Both Future and Cache

A standard, recommended approach for improving the user experience and performance of access external data is to use the Cache Macro inside of a Future Macro. This approach works extremely well when both future and cache are enabled for the retry feature! The expected (error free) data will be cached when it is available and automatically show on the page at that time. 


Find answers from the community.

Ask a question to the community.

Log a request with our support team.

Confluence®, Jira®, Atlassian Bamboo®, Bitbucket®, Fisheye®, and Atlassian Crucible® are registered trademarks of Atlassian®
Copyright © 2005 - 2024 Appfire | All rights reserved. Appfire™, the 'Apps for makers™' slogan and Bob Swift Atlassian Apps™ are all trademarks of Appfire Technologies, LLC.