We currently have some trouble on a productive server as it consumes way too much memory. One of the leaks could come from the jersey client. I found the following two other questions and a how to:
What I get from it, I should reuse the Client and potentially also the WebTargets? Also closing responses is advised, but how can I do this with .request()?
Code example, this is getting called about 1000 times per hour with different paths:
public byte[] getDocument(String path) {
Client client = ClientBuilder.newClient();
WebTarget target = client.target(config.getPublishHost() + path);
try {
byte[] bytes = target.request().get(byte[].class);
LOGGER.debug("Document size in bytes: " + bytes.length);
return bytes;
} catch (ProcessingException e) {
LOGGER.error(Constants.PROCESSING_ERROR, e);
throw new FailureException(Constants.PROCESSING_ERROR, e);
} catch (WebApplicationException e) {
LOGGER.error(Constants.RESPONSE_ERROR, e);
throw new FailureException(Constants.RESPONSE_ERROR, e);
} finally {
client.close();
}
}
So my question is how to properly use the API to prevent leaks for the above example?
Client
instances should be reusedClient
instances are heavy-weight objects that manage the underlying client-side communication infrastructure. Hence initialization as well as disposal of a Client
instance may be a rather expensive operation.
The documentation advises to create only a small number of Client
instances and reuse them when possible. It also states that Client
instances must be properly closed before being disposed to avoid leaking resources.
WebTarget
instances could be reusedYou could reuse WebTarget
instances if you perform multiple requests to the same path. And reusing WebTarget
instances is recommended if they have some configuration.
Response
instances should be closed if you don't read the entityResponse
instances that contain an un-consumed entity input stream should be closed. This is typical for scenarios where only the response headers and the status code are processed, ignoring the response entity. See this answer for more details on closing Response
instances.
For the situation mentioned in your question, you want you ensure that the Client
instance is reused for all getDocument(String)
method invocations.
For instance, if your application is CDI based, create a Client
instance when the bean is constructed and dispose it before its destruction. In the example below, the Client
instance is stored in a singleton bean:
@Singleton
public class MyBean {
private Client client;
@PostConstruct
public void onCreate() {
this.client = ClientBuilder.newClient();
}
...
@PreDestroy
public void onDestroy() {
this.client.close();
}
}
You don't need to (or maybe you can't) reuse the WebTarget
instance (the requested path changes for each method invocation). And the Response
instance is automatically closed when you read the entity into a byte[]
.
A connection pool can be a good performance improvement.
As mentioned in my older answer, by default, the transport layer in Jersey is provided by HttpURLConnection
. This support is implemented in Jersey via HttpUrlConnectorProvider
. You can replace the default connector if you want to and use a connection pool for better performance.
Jersey integrates with Apache HTTP Client via the ApacheConnectorProvider
. To use it, add the following dependecy:
<dependency>
<groupId>org.glassfish.jersey.connectors</groupId>
<artifactId>jersey-apache-connector</artifactId>
<version>2.26</version>
</dependency>
And then create your Client
instance as following:
PoolingHttpClientConnectionManager connectionManager =
new PoolingHttpClientConnectionManager();
connectionManager.setMaxTotal(100);
connectionManager.setDefaultMaxPerRoute(5);
ClientConfig clientConfig = new ClientConfig();
clientConfig.property(ApacheClientProperties.CONNECTION_MANAGER, connectionManager);
clientConfig.connectorProvider(new ApacheConnectorProvider());
Client client = ClientBuilder.newClient(clientConfig);
For additional details, refer to Jersey documentation about connectors.