Class Expiry

    • Constructor Detail

      • Expiry

        public Expiry()
    • Method Detail

      • toSharpTime

        public static long toSharpTime​(long millis)
        Convert the time value to a time representing a sharp expiry. This essentially negates the time value and is provided for a more speaking coding style.
        Parameters:
        millis - expiry time since the milliseconds since epoch or ExpiryTimeValues.ETERNAL if no expiry is requested.
        Throws:
        IllegalArgumentException - if the time value is negative
      • earliestTime

        public static long earliestTime​(long loadTime,
                                        long candidate1,
                                        long candidate2)
        Helper to calculate the next expiry out of two expiry times that may be up next. Return the time value that is closest or equal to the load time. Time values in the past are ignored. If all times are in the past, returns ExpiryTimeValues.ETERNAL.
        Parameters:
        loadTime - the current time in millis since epoch
        candidate1 - candidate time for next expiry
        candidate2 - candidate time for next expiry
        Returns:
        either first or second candidate or ExpiryTimeValues.ETERNAL
      • mixTimeSpanAndPointInTime

        public static long mixTimeSpanAndPointInTime​(long loadTime,
                                                     long refreshAfter,
                                                     long pointInTime)
        Combine a refresh time span and an expiry at a specified point in time.

        If the expiry time is far ahead of time the refresh time span takes precedence. If the point in time is near, this time takes precedence. If the refresh time is too close to the requested point an earlier refresh time is used to keep maximum distance to the requested point in time, which is abs(pointInTime) - refreshAfter

        Rationale: Usually the expiry is allowed to lag behind. This is okay when a normal expiry interval is used. If sharp expiry is requested an old value may not be visible at and after the expiry time. Refresh ahead implies lagging expiry, since the refresh is triggered when the value would usually expire. The two concepts can be combined in the expiry policy, e.g. using an interval for triggering refresh ahead and requesting a sharp expiry only when needed. If effective expiry time for the lagging variant and the for the sharp variant are in proximity, conflicts need to be resolved.

        Parameters:
        loadTime - time when the load was started
        refreshAfter - time span in milliseconds when the next refresh should happen
        pointInTime - time in milliseconds since epoch for the next expiry. Can be negative if sharp expiry is requested, or ExpiryTimeValues.ETERNAL if no point in time expiry is needed.