import junit.framework.TestCase;
import org.checkerframework.checker.nullness.qual.Nullable;

public final class InterruptibleTaskTest extends TestCase {

  // Regression test for a deadlock where a task could be stuck busy waiting for the task to
  // transition to DONE
  public void testInterruptThrows() throws Exception {
    final CountDownLatch isInterruptibleRegistered = new CountDownLatch(1);
    InterruptibleTask<@Nullable Void> task =

import junit.framework.TestCase;
import org.checkerframework.checker.nullness.qual.Nullable;

public final class InterruptibleTaskTest extends TestCase {

  // Regression test for a deadlock where a task could be stuck busy waiting for the task to
  // transition to DONE
  public void testInterruptThrows() throws Exception {
    final CountDownLatch isInterruptibleRegistered = new CountDownLatch(1);
    InterruptibleTask<@Nullable Void> task =

      if (compareAndSet(currentRunner, blocker)) {
        // Thread.interrupt can throw arbitrary exceptions due to the nio InterruptibleChannel API
        // This will make sure that tasks don't get stuck busy waiting.
        // Some of this is fixed in jdk11 (see https://bugs.openjdk.java.net/browse/JDK-8198692) but
        // not all.  See the test cases for examples on how this can happen.
        try {

    Future<?> possiblyIgnoredError = threadPool.submit(new Interrupter(currentThread()));
    try {
      // if waiting works, this should get stuck
      Queues.drain(q, newArrayList(), 1, MAX_VALUE, NANOSECONDS);
      fail();
    } catch (InterruptedException expected) {
      // we indeed waited; a slow thread had enough time to interrupt us
    }
  }

    Future<?> possiblyIgnoredError = threadPool.submit(new Interrupter(currentThread()));
    try {
      // if waiting works, this should get stuck
      Queues.drain(q, newArrayList(), 1, MAX_VALUE, NANOSECONDS);
      fail();
    } catch (InterruptedException expected) {
      // we indeed waited; a slow thread had enough time to interrupt us
    }
  }

    if match is found, the toolchain instance is made available to other Maven plugins.</p>
    <p>With {@code jdk} toolchain, for example, instead of being stuck with the JDK used to run Maven, all plugins can use
    the same other JDK instance without hardcoding absolute paths into the {@code pom.xml}
    and without configuring every plugin that require path to JDK tools.</p>

			newBuf := make([]byte, newSize)
			copy(newBuf, s.buf[s.start:s.end])
			s.buf = newBuf
			s.end -= s.start
			s.start = 0
		}
		// Finally we can read some input. Make sure we don't get stuck with
		// a misbehaving Reader. Officially we don't need to do this, but let's
		// be extra careful: Scanner is for safe, simple jobs.
		for loop := 0; ; {
			n, err := s.r.Read(s.buf[s.end:len(s.buf)])

- A deprecated flag `--pod-max-in-unschedulable-pods-duration` was initially planned to be removed in v1.26, but we had to change this plan. We found [an issue](https://github.com/kubernetes/kubernetes/issues/110175) in which Pods can be stuck in the unschedulable pod pool for 5 min, and using this flag is the only workaround for this issue. 

- Fixed stuck apiserver if an aggregated apiservice returned `304 Not Modified` for aggregated discovery information ([#114459](https://github.com/kubernetes/kubernetes/pull/114459), [@alexzielenski](https://github.com/alexzielenski))

- Added a return value to `QueueingHint` to indicate an error. If `QueueingHint` returns an error,
  the scheduler logs it and treats the event as a `QueueAfterBackoff` so that
  the Pod won't be stuck in the unschedulable pod pool. ([#119290](https://github.com/kubernetes/kubernetes/pull/119290), [@carlory](https://github.com/carlory))
- Added apiserver identity to the following metrics: