buffer.add(e);
        added++;
      }
    }
    return added;
  }

  /**
   * Drains the queue as {@linkplain #drain(BlockingQueue, Collection, int, Duration)}, but with a
   * different behavior in case it is interrupted while waiting. In that case, the operation will
   * continue as usual, and in the end the thread's interruption status will be set (no {@code
   * InterruptedException} is thrown).
   *

  /**
   * This is a less carefully-controlled version of {@link #testRemovalNotification_clear} - this is
   * a black-box test that tries to create lots of different thread-interleavings, and asserts that
   * each computation is affected by a call to {@code clear()} (and therefore gets passed to the

 * nullness annotations in particular will outweigh the costs. (And it's worth noting that we have
 * released multiple ListenableFuture.class files that are not byte-for-byte compatible even from
 * the beginning, thanks to using different `-source -target` values for compiling our `-jre` and
 * `-android` "flavors.")
 *
 * (We could consider releasing a listenablefuture:1.0.1 someday. But we would want to look into how

                  @Override
                  protected Set<String> create(String[] elements) {
                    checkArgument(elements.length == 3);
                    // Put the sets in different orders for the hell of it
                    return Sets.union(
                        Sets.newLinkedHashSet(asList(elements)),
                        Sets.newLinkedHashSet(asList(elements[1], elements[0], elements[2])));

         *
         * Ideally we'd have a real eviction policy, but until we see a problem in practice, I hope
         * that this will suffice. I have not even benchmarked with different size limits.
         */
        if (validClasses.size() > 1000) {
          validClasses.clear();
        }

        validClasses.add(new WeakReference<Class<? extends Exception>>(exceptionClass));
      }

 * nullness annotations in particular will outweigh the costs. (And it's worth noting that we have
 * released multiple ListenableFuture.class files that are not byte-for-byte compatible even from
 * the beginning, thanks to using different `-source -target` values for compiling our `-jre` and
 * `-android` "flavors.")
 *
 * (We could consider releasing a listenablefuture:1.0.1 someday. But we would want to look into how

```

////

## Recap

Use multiple Pydantic models and inherit freely for each case.

> certs from the server certificate chain, this is mainly to add simplicity of setup. However if you wish to terminate
> TLS certificates via a different domain for your FTP servers you may choose the above command line options.


### Custom Algorithms (SFTP)

Custom algorithms can be specified via command line parameters.
Algorithms are comma separated. 

  @AndroidIncompatible
  public void testTaskThrowsError() throws Exception {
    class MyError extends Error {}
    final CyclicBarrier barrier = new CyclicBarrier(2);
    // we need to make sure the error gets thrown on a different thread.
    ExecutorService service = Executors.newSingleThreadExecutor();
    try {
      final SequentialExecutor executor = new SequentialExecutor(service);
      Runnable errorTask =
          new Runnable() {

![SDS decision flow](docs/sds-flow.svg)

### Default CA Flow through istio-agent

![CA Flow](docs/ca.svg)

A single SDS request from Envoy goes through a few different layers in istio-agent.

1. First, the request is handled by the SDS server. This is mostly just an intermediate translation layer exposing