Global Cache handling of WIS2 Notification Messages on refusal to cache data objects

[6a6d74]

The current behaviour of Global Cache when refusing to cache a data-object where data-policy=Core and cache=true (or cache directive missing from WNM) is to republish the WIS2 Notification Message as if the cache directive was set to false (cache=false) - i.e., the WNM is published on the cache topic branch containing links that refer back to the origin WIS2 Node.

There is a proposal to treat the refusal to cache the same as if it were an error, i.e., the Global Cache does not publish a WNM (etc.). From the WIS2 Node perspective this makes sense: they intended the data-object to be cached and it is not. It is also possible that WIS2 Nodes may not provide access for general users to download Core data directly from them. In which case, data consumers will get download failures.

On refusal to cache, should a GC republish a WNM or not?

And in the latter case, should the GC increment the (error) metric wmo_wis2_gc_downloaded_errors_total?

(See also Issue wis2-guide/8 for a discussion on publishing monitoring event messages when a GC refuses to cache an object)

[6a6d74]

ET-W2IT meeting 29-Sep-2025

Irrespective of the choice above, the GC should publish a monitor message saying that it's overriding the cache directive.

[6a6d74]

Amend Global Cache Technical Considerations in WIS2 Guide to require GC's to publish a monitor message when overriding a cache directive. WIS2 Monitoring Event Message specification will not be published until INFCOM4 release - so this amendment to the Guide also needs to be for INFCOM4.

[josusky]

As discussed today (13th of April) at WT-W2IT meeting, publishing of an WME makes sense. In addition, there was a discussion that mirrored the dichotomy of the initial description of this issue.

• For a Global Cache (GC), republishing of a WNM containing URL pointing to the original publisher is a straight forward process.
• From a data consumer point of view, the "refusal" to cache core data is an exception, and it is better if the GC does not publish a new WNM (and just uses WME to inform about the irregularity). However, if all the GC refused to cache the same data instance, this instance would become "invisible" to the data consumers as they normally subscribe only to topics that start with cache. So we are back on square one.

[josusky]

BTW, I have created PR #249 to emphasize in the WIS2 guide that the global cache shall publish a WME in this case.

[6a6d74]

@josusky - thanks for capturing the discussion. Let's aim to resolve this at the next ET-W2IT meeting on 27-APR.

Adding a little more context.

If GCs don't publish a WNM when they ignore a request to cache:

• Assuming another GC does cache the data, there is no problem; data consumers will receive a message from the cache(s) where the data is cached.
• If no GCs cache the data, there will never be a message published on the cache topic, so data consumers will never receive the message (we encourage data consumers not to subscribe to origin for Core data, so they would never get the original message).

If GCs do publish a WNM when they ignore a request to cache:

• The WNM will include a link to where the data maybe accessed - this would usually be an origin WIS2 Node (but could be another GC).
• In this case, the origin WIS2 Node may implement access control (e.g., IP whitelisting), in which case a data consumer receiving the WNM would fail to be able to download the data. (_Note: this is a different situation to where cache is set to false - here the WIS2 Node should expect direct access to their data server and must not implement access control for Core data).
• Assuming that at least one GC did cache the data, eventually a data consumer would receive a WNM with a URL from which the data could be downloaded.
• If no GCs cache the data and the origin WIS2 Node implements access control, the data would not be accessible.

Both of these cases are compromises - but which is worst? (note: the 2nd option where GCs do publish WNMs is what the spec currently says).

The refusal to cache is likely to be due to a very high number of data objects / volume of data from a WIS2 Node. So this edge case is only likely to affect big WIS Centres (e.g., model producing centres, satellite centres). Most WIS2 Nodes won't be affected.

[6a6d74]

ET-W2IT meeting 27-APR-2026

@josusky stated that PR wmo-im/wis2-guide#249, which added the requirement to publish a WIS2 Monitoring Event message when overriding a cache request, had been merged into the INFCOM-4 branch.

@josusky and @6a6d74 recapped the previous discussion on Global Cache behaviour when refusing to cache data objects: to publish a WIS2 Notification Message or not.

@hhaddouch commented that the refusal to cache a data object should clearly be seen as an exception. He added that generally, refusal to cache will be because of large file sizes or large numbers of files, which suggests that the WIS2 Node will be from a "larger" centre that will likely be able to serve its data directly. On that basis, publishing a WNM is the better option.

@6a6d74 noted that a WIS Notification Message that points to an unresolvable resource (e.g., because the WIS2 Node applies access control), Option 2, would create errors that can be trapped and resolved which is better than the messages just disappearing oif all caches decided not to cache, Option 1. A second reason that publishing a WNM is the better option.

@el4ren added that if a data consumer first tried (and failed) to download a data object from an access controlled WIS2 Node, they would be able to have subsequent attempts to download data when receiving WNMs from other Global Caches. Assuming that at least one GC cached the data object, the data consumer would get the data.

Given that Option 2 is what is already stated in the Guide, and the PR for the WME message is merged, this Issue is now resolved. Closing this issue.