// have no idea.
          // TODO(lukes): consider building everything in terms of ListenableScheduledFuture then
          // the AbstractService could monitor the future directly. Rescheduling is still hard...
          // but it would help with some of these lock ordering issues.
          scheduleFailure = e;
          toReturn = new FutureAsCancellable(immediateCancelledFuture());
        } finally {

      }
    } else {
      checkArgument(keyEntry == ABSENT, "Key already present: %s", key);
    }

    // insertion point for new entry is after predecessor
    // note predecessor must still be a valid entry: either we deleted an entry that was *not*
    // predecessor, or we didn't delete anything

    ensureCapacity(size + 1);
    keys[size] = key;
    values[size] = value;

 *
 * <p>Lookups by row key are often faster than lookups by column key, because the data is stored in
 * a {@code Map<R, Map<C, V>>}. A method call like {@code column(columnKey).get(rowKey)} still runs
 * quickly, since the row key is provided. However, {@code column(columnKey).size()} takes longer,
 * since an iteration across all row keys occurs.
 *

   * <p>Whenever possible, it is preferable to test directly for some observable change resulting
   * from GC, as with {@link #awaitClear}. Because there are no guarantees for the order of GC
   * finalization processing, there may still be some unfinished work for the GC to do after this
   * method returns.
   *
   * <p>This method does not create any memory pressure as would be required to cause soft
   * references to be processed.
   *

 *
 * Be advised that short/NetBIOS name usage is not supported with this authenticator. Always specify full FQDNs.
 * This can be a problem if using DFS in it's default configuration as they still return referrals in short form.
 * See <a href="https://support.microsoft.com/en-us/kb/244380">KB-244380</a> for compatible server configuration.
 * See {@link jcifs.Configuration#isDfsConvertToFQDN()} for a workaround.
 */

* API usage monitoring systems
* response data injection systems
* etc.

## Simple and Powerful { #simple-and-powerful }

Although the hierarchical dependency injection system is very simple to define and use, it's still very powerful.

You can define dependencies that in turn can define dependencies themselves.

        it.close();

        // Assert
        assertFalse(it.hasNext());
        verify(tree, times(1)).release();
    }

    @Test
    @DisplayName("doCloseInternal throwing still releases exactly once and next() recovers")
    void closeInternalThrowsButReleases() throws Exception {
        // Arrange
        stubAcquireReturnsSelf();
        FileEntry initial = entry("first");

        // The normalization removes all duplicate backslashes, so \\\\server becomes \server
        // This test validates that paths which should be UNC but aren't detected due to normalization
        // still pass validation (which is the current behavior, though not ideal)

        // These paths normalize to \server\share which is NOT detected as UNC due to normalization

        // Verify we get a copy, not the original
        rawKey[0] = (byte) ~rawKey[0];
        byte[] rawKey2 = keyManager.getRawKey(sessionId);
        assertArrayEquals(testKey, rawKey2, "Should still match original");
    }

    @Test
    public void testRemoveSessionKey() {
        String sessionId = "test-session-3";
        keyManager.storeSessionKey(sessionId, testKey, "AES");

    // ... trigger server failover ...
    
    // Verify that witness notification was received and handled
    assertTrue(listener.waitForNotification(30000));  // 30 second timeout
    
    // Verify file is still accessible after failover
    assertTrue(file.exists());
}

@Test
public void testWitnessServiceDiscovery() throws Exception {
    CIFSContext context = getTestContext();