Thanks for the feedback.

The logic I had in mind was to add the TTL, as a refresh_interval field in
the root metadata file.

At each query, the current time would be compared to the addition of the
modification time of the root metadata file and the refresh_interval.
If the current time is greater, it would mean the metadata may be invalid,
so the regular process would apply: recursively going through the file to
check for updates, and trig a full metadata cache refresh any change is
detected, or just touch the metadata file to align its modification time
with the current time if no change is detected.
If the current time is smaller, the root metadata would be trusted (without
additional checks) and the planning would continue.

So in most of the cases, only the timestamp of the root metadata file would
be checked. In the worst case (at most once per TTL), all the timestamps
would be checked.

Regards, Joel

On Thu, Jul 12, 2018 at 4:47 PM, Vitalii Diravka <[EMAIL PROTECTED]>
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB