*   Solves an OOM issue on TPUs when XLA contexts use fused average updates
*   Updates `libjpeg-turbo` to `2.0.5` to handle
    [CVE-2020-13790](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-13790).
*   Updates `junit` to `4.13.1` to handle
    [CVE-2020-15250](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-15250).
*   Updates `PCRE` to `8.44` to handle

            this.keyRotationBytesLimit = bytesLimit;
        }
        if (timeMillis > 0) {
            this.keyRotationTimeLimit = timeMillis;
        }
        log.info("Key rotation limits updated - bytes: {} MB, time: {} hours", bytesLimit / (1024 * 1024), timeMillis / (60 * 60 * 1000));
    }

    /**
     * Get key rotation metrics
     *
     * @return metrics map containing rotation statistics

    // we really just want to wait for the thread to be in the failure callback so we wait for that
    // explicitly instead.
    failEnter.await();
    assertFalse("State should be updated before calling listeners", manager.isHealthy());
    // now we want to stop the services.
    Thread stoppingThread =
        new Thread() {
          @Override
          public void run() {

   * configured with. The initial value of this is the same as the {@code permitsPerSecond} argument
   * passed in the factory method that produced this {@code RateLimiter}, and it is only updated
   * after invocations to {@linkplain #setRate}.
   */
  public final double getRate() {
    synchronized (mutex()) {
      return doGetRate();
    }
  }

  abstract double doGetRate();

   * {@code factory}, and the multimap contents are all serializable.
   *
   * <p>The multimap is not threadsafe when any concurrent operations update the multimap, even if
   * {@code map} and the instances generated by {@code factory} are. Concurrent read operations will
   * work correctly. To allow concurrent update operations, wrap the multimap with a call to {@link
   * #synchronizedMultimap}.
   *

   * {@code factory}, and the multimap contents are all serializable.
   *
   * <p>The multimap is not threadsafe when any concurrent operations update the multimap, even if
   * {@code map} and the instances generated by {@code factory} are. Concurrent read operations will
   * work correctly. To allow concurrent update operations, wrap the multimap with a call to {@link
   * #synchronizedMultimap}.
   *

   *
   * <p>This is a "snapshot" based on the current topology of {@code graph}, rather than a live view
   * of the transitive closure of {@code graph}. In other words, the returned {@link Graph} will not
   * be updated after modifications to {@code graph}.
   *
   * @since NEXT
   */
  // TODO(b/31438252): Consider optimizing for undirected graphs.
  public static <N> ImmutableGraph<N> transitiveClosure(

        String result = referral.toString();

        assertTrue(result.contains("Referral["));
        assertTrue(result.contains("version=3"));
        assertTrue(result.contains("size=200")); // updated size
        assertTrue(result.contains("serverType=1"));
        assertTrue(result.contains("flags=0"));
        assertTrue(result.contains("proximity=10"));
        assertTrue(result.contains("ttl=600"));

            });
        }

        // update pager
        BeanUtil.copyBeanToBean(list, pager, option -> option.include(Constants.PAGER_CONVERSION_RULE));
        pager.setPageNumberList(list.pageRange(op -> {
            op.rangeSize(fessConfig.getPagingPageRangeSizeAsInteger());
        }).createPageNumberList());

        return list;
    }

    /**
     * Updates the pager with aggregation result information.

    - [kubeadm](#kubeadm-2)
    - [kubectl](#kubectl-1)
      - [New Commands](#new-commands)
      - [Create subcommands](#create-subcommands)
      - [Updates to existing commands](#updates-to-existing-commands)
      - [Updates to apply](#updates-to-apply)
      - [Updates to edit](#updates-to-edit)
      - [Bug fixes](#bug-fixes)
      - [Other Notable Changes](#other-notable-changes-14)
    - [Node Components](#node-components-2)