- Sometimes, the scheduler incorrectly placed a pod in the "unschedulable" queue instead of the "backoff" queue. This happened when some plugin previously declared the pod as "unschedulable" and then in a later attempt encounters some other error. Scheduling of that pod then got delayed by up to five minutes, after which periodic flushing moved the pod back into the "active" queue. ([#120334](https://github.com/kubernetes/kubernetes/pull/120334), [@pohly](https...

                }
                ex = e;
            }
        }

        if (ex != null) {
            throw ex;
        }
        throw new TransportException("All connection attempts failed");
    }

    /**
     * Checks if the specified transport is contained in the connection pool
     * @param trans the transport to check for
     * @return whether (non-exclusive) connection is in the pool

    return Synchronized.multimap(multimap, null);
  }

  /**
   * Returns an unmodifiable view of the specified multimap. Query operations on the returned
   * multimap "read through" to the specified multimap, and attempts to modify the returned
   * multimap, either directly or through the multimap's views, result in an {@code
   * UnsupportedOperationException}.
   *

  }

  private fun runWriter() {
    assertLockHeld()

    val writerTask = writerTask
    if (writerTask != null) {
      taskQueue.schedule(writerTask)
    }
  }

  /**
   * Attempts to remove a single frame from a queue and send it. This prefers to write urgent pongs
   * before less urgent messages and close frames. For example, it's possible that a caller will

   *
   * <p>The returned {@code BiMap} iterates over entries in the same order as the {@code entrySet}
   * of the original map.
   *
   * <p>Despite the method name, this method attempts to avoid actually copying the data when it is
   * safe to do so. The exact circumstances under which a copy will or will not be performed are
   * undocumented and subject to change.
   *

     */
    long getDurableHandleTimeout();

    /**
     * Property {@code jcifs.smb.client.handleReconnectRetries}, defaults to 3
     *
     * @return maximum number of retry attempts for handle reconnection
     */
    int getHandleReconnectRetries();

    /**
     * Enable SMB3 Multi-Channel support
     *
     * Property {@code jcifs.smb.client.useMultiChannel} (boolean, default true)

        : copyOf(elements.iterator());
  }

  /**
   * Returns an immutable list containing the given elements, in order.
   *
   * <p>Despite the method name, this method attempts to avoid actually copying the data when it is
   * safe to do so. The exact circumstances under which a copy will or will not be performed are
   * undocumented and subject to change.
   *

 * }
 *
 * <p>changes the entries iteration order to {@code [key2=bar, key1=baz]} and the key iteration
 * order to {@code [key2, key1]}. The {@link #entries()} iterator returns mutable map entries, and
 * {@link #replaceValues} attempts to preserve iteration order as much as possible.
 *
 * <p>The collections returned by {@link #keySet()} and {@link #asMap()} iterate through the keys in

          helper = new SynchronizedHelper();
        }
      }
    } else {
      /*
       * We avoid Unsafe, since newer JVMs produce warnings or even errors for attempts to use it.
       *
       * In guava-jre, we avoid Unsafe by using VarHandle instead. But if we have references to
       * VarHandle in guava-android, even if they're unused under Android, we cause errors under

  /**
   * Returns an immutable multimap containing the same mappings as {@code multimap}, in the
   * "key-grouped" iteration order described in the class documentation.
   *
   * <p>Despite the method name, this method attempts to avoid actually copying the data when it is
   * safe to do so. The exact circumstances under which a copy will or will not be performed are
   * undocumented and subject to change.
   *