if the ban list grows quickly, it can have a negative impact on performance as varnish needs to perform more cpu cycles to invalidate the cache properly. One of the ways around this, is the xkey module which can speed this up.

More discussion on this found here

a dependency for dlcs/protagonist#251

Acceptance criteria

• A side-process that listens to the same Asset Deletion notification as dlcs/protagonist#251
• When it receives an asset deletion message, uses varnishadm BAN command to clear matching stored entries. e.g., ban req.url ~ /iiif-img/wellcome/5/b33062055
• iiif-img, iiif-manifest, thumbs, file, iiif-av are "wildcard" paths to clear matching asset IDs under (single assets)

Based on this comment:

One thought - it might be good to allow this to work if INCOMING_QUEUE is missing. E.g. if we scale out for 4hours to cope with a known load we might want additional varnish instances running without worrying about bans.

Currently, the varnish cleanup handler requires an INCOMING_QUEUE to be set, meaning that the application will fail to run if the cleanup handler isn't correctly set up. This could be an issue if we want to run the varnish cache separately from the cleaner. This ticket is to make it so that these applications can be run separately