Reset next dynamic metadata refresh when entity is unchanged.

Description

One of the gaps I think I noted in the dynamic metadata code is that it's possible for the underlying origin fetch to return a null, which causes the original resolve step to reuse the existing metadata if it's stil valid. But I believe it's not changing the underlying store metadata that governs the next refresh, which means this would cause endless repeats of the refresh attempt until it finally loads a new instance (if ever).

I would suggest repeating the orignal computation of the next refresh time as though the metadata was newly acquired to ensure this doesn't repeat over and over.

This would facilitate some of the extended behavior I'd like to see being implemented by deployer plugins at the load/store layer since they can do their own caching and selective refresh logic by just returning a null.

Environment

None

Activity

Show:

Brent PutmanSeptember 15, 2018 at 2:56 AM

Fixed in a4b4304b9bf323a217a7f012468a475c1dbbecc1, 6f570f140030c1231b9c17dc1eb963819aecf2fa 5cddddcf1fb11ac40e0bb2d767df9f02f0887f6b

Brent PutmanAugust 3, 2018 at 7:02 PM

Ok, default change to 10 min.

Scott CantorAugust 3, 2018 at 6:43 PM

SP uses the same default value and the caching is based on the minCacheDuration setting so that would be the same behavior.

I believe the way the SP works now is treating a 404 as a standard exception, same as any other error. I don't know if that's what we want or not, but for now it's good enough I guess. I would guess most people will lower the min value anyway.

Brent PutmanAugust 3, 2018 at 6:39 PM

Re our call discussion about default value for negativeLookupCacheDuration: Initially I did 30 minutes.  I checked and the default for minCacheDuration (the "positive" cache) is 10 minutes.  Does that sound like a more reasonable default than 30 minutes?

Scott CantorApril 4, 2018 at 12:43 PM

Rather than create a new issue, since it's related/dependent on this one, the plugins really need to cache failure, in particular in the HTTP remote case, since not doing so greatly limits where these can be placed in a chain (they'd have to be at the end, and there could never be more than one).

Fixed

Details

Assignee

Reporter

Components

Fix versions

Created March 27, 2018 at 6:08 PM
Updated September 15, 2018 at 2:56 AM
Resolved September 15, 2018 at 2:56 AM