Can Jersey Client be used in multithreaded environment for consuming rest api?

Question

I want to create a Jersey Client for a multithreaded project. Do i need to create a connection pool for the Client ?

There is 500 TPS traffic on the server .How to calculate the below parameters for best performance.

ConnectionTimout,SocketTimeout,ReadTimeout,MaxConnectionPerHost,MaxConnections.

What is concept of reset connection pool and when to use it?

Answer 1

Jersey Client is thread-safe for multiple request executions. Documentation

Methods to create instances of WebResource are thread-safe. Methods that modify configuration and or filters are not guaranteed to be thread-safe.

The creation of a Client instance is an expensive operation and the instance may make use of and retain many resources. It is therefore recommended that a Client instance is reused for the creation of WebResource instances that require the same configuration settings.

It is recommended that the same instance of Client class is reused for multiple request executions. Changing Client configuration is not thread save and must be handled appropriately.

Do I need to create a connection pool for the Client ?
Short answer Yes.
By default Jersey Client use BasicHttpClientConnectionManager. Documentation

It is a simple connection manager that maintains only one connection at a time. Even though this class is thread-safe it ought to be used by one execution thread only. BasicHttpClientConnectionManager will make an effort to reuse the connection for subsequent requests with the same route. It will, however, close the existing connection and re-open it for the given route, if the route of the persistent connection does not match that of the connection request. If the connection has been already been allocated, then java.lang.IllegalStateException is thrown.

For multithread application, you need to override the default value with PoolingHttpClientConnectionManager.

It is a more complex implementation that manages a pool of client connections and is able to service connection requests from multiple execution threads. Connections are pooled on a per route basis. A request for a route for which the manager already has a persistent connection available in the pool will be serviced by leasing a connection from the pool rather than creating a brand new connection.

PoolingHttpClientConnectionManager maintains a maximum limit of connections on a per route basis and in total. Per default this implementation will create no more than 2 concurrent connections per given route and no more 20 connections in total. For many real-world applications these limits may prove too constraining, especially if they use HTTP as a transport protocol for their services.

For details Apache Connection Management

Configuration
The general recommendation is to avoid the infinity timeouts, which Jersey set by default. It can produce threads stuck in case of problems. See Best practices for web service timeouts choose the correct value. There are no specific values, they should be set based on services and environment performance. The correct timeouts and connection size will come thru the time after performance testing or real-time usage.
Just implement it flexible, add the ability to adjust settings on the fly.

Read Timeout

Read timeout interval property, in milliseconds. The value MUST be an instance of Integer. If the property is absent then the default value is an interval of infinity. A value of zero 0 is equivalent to an interval of infinity

You can set 1 minute like the initial value. Also, you can override timeout per request in case of exceptional cases.

Connection Timeout

Connect timeout interval property, in milliseconds. The value MUST be an instance of Integer. If the property is absent then the default value is an interval of infinity. A value of 0 is equivalent to an interval of infinity

Set 500 - 1000 milliseconds like the initial value.

MaxConnectionPerHost
Set 20 connections like initial value.

MaxConnections
Set 200 connections like initial value.