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.