Describe the bug After refresh endpoint, eureka client cannot work, throws exception com.sun.jersey.api.client.ClientHandlerException: java.lang.IllegalStateException: Connection pool shut down at com.sun.jersey.client.apache4.ApacheHttpClient4Handler.handle(ApacheHttpClient4Handler.java:187) ~[jersey-apache-client4-1.19.1.jar:1.19.1] at com.sun.jersey.api.client.Client.handle(Client.java:652) ~[jersey-client-1.19.1.jar:1.19.1]

Details: This error only happens when i use spring cloud version >= "Hoxton.SR3", "Hoxton SR2" still works. After some invetigation, I found eureka client commit, in this commit, when destroy resources, the connection manager will be closed.

Destroy resource will be trigger once refresh scope do refresh all(using code like: refreshScope.refreshAll()). Seems spring cloud eureka client does not start the connection manager again, then throws the exception "connection pool shut down".

Do i have some solutions to bypass this bug, or something wrong in my code?

Btw, I use custom define Discovery client options, looks like below

@Bean
public DiscoveryClient.DiscoveryClientOptionalArgs discoveryClientOptionalArgs(EurekaTlsClientProperties props)
            throws GeneralSecurityException, IOException {
        SSLContext sslContext = props.createSSLContext();

        EurekaJerseyClientBuilder builder = new EurekaJerseyClientBuilder()
                .withClientName("eureka-client")
                .withCustomSSL(sslContext)
                .withReadTimeout(30 * 1000)
                .withConnectionTimeout(30 * 1000)
                .withMaxTotalConnections(10)
                .withMaxConnectionsPerHost(10);

        DiscoveryClient.DiscoveryClientOptionalArgs args = new DiscoveryClient.DiscoveryClientOptionalArgs();
        args.setEurekaJerseyClient(builder.build());
        return args;
    }

Comment From: spencergibb

Does downgrading to v1.9.13 fix things? Hoxton.SR3 is when the version changed to 1.9.17. Maybe this needs a fix in eureka-client @troshko111?

Comment From: spencergibb

I'm unable to replicate the problem.

Can you provide a complete, minimal, verifiable sample that reproduces the problem? It should be available as a GitHub (or similar) project or attached to this issue as a zip file.

Comment From: zmssp

Sorry for the late reply. Attach the minimal sample to reproduce the bug.

Comment From: spencergibb

@RefreshScope behaves poorly when placed on @Configuration classes of with HelloClientApplication is one because @SpringBootApplication is meta-annotated with @Configuration.

Moving @RefreshScope to the @Bean definition of discoveryClientOptionalArgs() resolved the issue.

Comment From: ctylucy

I recently encountered this error also using refresh scope, and none of the solution I can find works. So after two days of investigation this is due to refresh scope will make the Eureka client shutdown and restart. The underlying Jersey client connection pool is also closed, but when restarting it always uses the closed client as defined in DiscoveryClientOptionalArgs bean. For now the only solution works for me is not to use your custom client but instead let Eureka do it for you

@Bean
public DiscoveryClient.DiscoveryClientOptionalArgs discoveryClientOptionalArgs(EurekaTlsClientProperties props)
            throws GeneralSecurityException, IOException {
        SSLContext sslContext = props.createSSLContext();

        DiscoveryClient.DiscoveryClientOptionalArgs args = new DiscoveryClient.DiscoveryClientOptionalArgs();
        args.setSSLContext(sslContext)
        return args;
    }

Then set other connection properties in environment variables.