assertEquals(Integer.MAX_VALUE, negotiationResponse.getReceiveBufferSize());
        assertEquals(Integer.MAX_VALUE, negotiationResponse.getTransactionBufferSize());

        // Test negative values (though not typical, should be tested)
        when(negotiationResponse.getSendBufferSize()).thenReturn(-1);
        when(negotiationResponse.getReceiveBufferSize()).thenReturn(-1);

        assertNotNull(compressed);
        assertTrue(compressed.length > 0);
        // Compressed size should typically be smaller (though not guaranteed for all data)

        byte[] decompressed = compressionService.decompress(compressed, CompressionService.COMPRESSION_LZ77);
        assertArrayEquals(testData, decompressed);
    }

    @Test

 *
 * <p><b>Note:</b> {@code ComparisonChain} instances are <b>immutable</b>. For this utility to work
 * correctly, calls must be chained as illustrated above.
 *
 * <p>Performance note: Even though the {@code ComparisonChain} caller always invokes its {@code
 * compare} methods unconditionally, the {@code ComparisonChain} implementation stops calling its

   * abruptly. In other cases, a test may put a thread into an uninterruptible operation
   * intentionally, so there is no other way to clean up these threads. (The better solution,
   * though, would be to run the tests that use TestThread in separate VMs so that their threads
   * don't hang around during other tests.)
   */
  @Override
  public void tearDown() throws Exception {
    try {

 *
 * <pre>
 * new SmbNamedPipe("smb://server/IPC$/foo", SmbNamedPipe.PIPE_TYPE_RDWR, context);
 * </pre>
 *
 * </td>
 * <td>
 * Open the Named Pipe foo for reading and writing. The pipe will
 * behave as though the <code>CreateFile</code>, <code>ReadFile</code>,
 * <code>WriteFile</code>, and <code>CloseFile</code> interface was
 * being used.
 * </td>
 * </tr>
 * </table>
 *
 * <p>

    //
    // All this makes me really wonder if there's any value in queueing here at all. A dispatcher
    // that simply loops through the subscribers and dispatches the event to each would actually
    // probably provide a stronger order guarantee, though that order would obviously be different
    // in some cases.

    /** Global event queue. */

        // Only second directory should be invalidated
        assertFalse(entry2.isComplete());
        // First directory should still be cached (though modified by previous change)
        assertNotNull(directoryLeaseManager.getCacheEntry(dir1));
    }

    @Test
    public void testCacheExpiration() throws Exception {

        // arrays of one lock and one unlock range
        LockingAndXRange lock = new LockingAndXRange(false);
        lock.encode(new byte[20], 0); // initialise fields by encoding to set pid etc (though not needed)
        setField(lock, "pid", 123);
        setField(lock, "byteOffset", 100L);
        setField(lock, "lengthInBytes", 200L);
        LockingAndXRange unlock = new LockingAndXRange(false);

 *
 * <p>The {@link #get}, {@link #removeAll}, and {@link #replaceValues} methods each return a {@link
 * SortedSet} of values, while {@link Multimap#entries()} returns a {@link Set} of map entries.
 * Though the method signature doesn't say so explicitly, the map returned by {@link #asMap} has
 * {@code SortedSet} values.
 *
 * <p><b>Warning:</b> As in all {@link SetMultimap}s, do not modify either a key <i>or a value</i>

   *     neither fast nor secure. As of January 2017, we suggest:
   *     <ul>
   *       <li>For security:
   *           {@link Hashing#sha256} or a higher-level API.
   *       <li>For speed: {@link Hashing#goodFastHash}, though see its docs for caveats.
   *     </ul>
   */
  @Deprecated
  public static HashFunction md5() {
    return Md5Holder.MD5;
  }

  private static final class Md5Holder {