*
     * In high performance mode, expensive regex operations are avoided by doing
     * fast string contains checks first. This significantly improves performance
     * for high-frequency logging scenarios.
     *
     * @param enable true to enable high performance mode
     */
    public void setHighPerformanceModeEnabled(boolean enable) {
        this.enableHighPerformanceMode = enable;

        };
        ComponentUtil.setFessConfig(fessConfig);

        ssoManager = new SsoManager();
        assertEquals(expectedSsoType, ssoManager.getSsoType());
    }

    // Test full integration scenarios
    public void test_fullScenario_ssoEnabled() {
        currentSsoType = "saml";
        final LoginCredential expectedCredential = new TestLoginCredential("samluser");

_2014-03-17_

 * Fix bug where deleting a file that was absent from the `HttpResponseCache`
   caused an IOException.
 * Fix bug in HTTP/2 where our HPACK decoder wasn't emitting entries in
   certain eviction scenarios, leading to dropped response headers.

## Version 1.5.1

_2014-03-11_

 * Fix 1.5.0 regression where connections should not have been recycled.

## 1. Overview

Persistent handles (also known as durable handles) allow SMB3 connections to survive network disconnections, server reboots, and client reconnections. This feature is critical for enterprise reliability and seamless failover scenarios.

## 2. Protocol Specification Reference

- **MS-SMB2 Section 2.2.13.2.3**: SMB2_CREATE_DURABLE_HANDLE_REQUEST
- **MS-SMB2 Section 2.2.13.2.4**: SMB2_CREATE_DURABLE_HANDLE_REQUEST_V2

     *
     * - If the stack overflowed after set()/setValue() stored its result, then a call to
     * setException() will be a no-op because the Future is already done.
     *
     * Both scenarios are bad: The output Future might never complete, or, if it does complete, it
     * might not run some of its listeners. The likely result is that the app will hang. (And of

            verify(mockSession, times(1)).unwrap(SmbSession.class);
            verify(mockSession, times(1)).close();
        }

        @Test
        @DisplayName("Should support partial mocking scenarios")
        void shouldSupportPartialMockingScenarios() {
            SmbSession mockSession = mock(SmbSession.class);
            Configuration mockConfig = mock(Configuration.class);

        assertTrue(actual.contains("10.0.0.5"), "toString should contain the second NbtAddress string representation");
    }

    /**
     * Helper method to set common superclass fields for successful parsing scenarios.
     */
    private void setSuperclassFieldsForSuccessfulParsing() throws NoSuchFieldException, IllegalAccessException {
        Field resultCodeField = NameServicePacket.class.getDeclaredField("resultCode");

        doNothing().when(response).reset();
        response.reset();
        verify(response).reset();
    }

    @Test
    @DisplayName("Test concrete implementation with multiple scenarios")
    void testConcreteImplementation() throws SMBProtocolDecodingException {
        // Create a concrete implementation for comprehensive testing

     *
     * - If the stack overflowed after set()/setValue() stored its result, then a call to
     * setException() will be a no-op because the Future is already done.
     *
     * Both scenarios are bad: The output Future might never complete, or, if it does complete, it
     * might not run some of its listeners. The likely result is that the app will hang. (And of

OkHttp is principled and avoids being overly configurable, especially when such configuration is
to workaround a buggy server, test invalid scenarios or that contradict the relevant RFC.
Other HTTP libraries exist that fill that gap allowing extensive customisation including potentially
invalid requests.

Example Limitations

* Does not allow GET with a body.