Is JAX-RS Client Thread Safe

Question

In Java EE7, the JAX-RS Client API provides a high-level API for accessing any REST resources. According to the documentation, "Clients are heavy-weight objects that manage the client-side communication infrastructure. Initialization as well as disposal of a Client instance may be a rather expensive operation. It is therefore advised to construct only a small number of Client instances in the application. "

In order to avoid create client frequently, I am going to cache the client instance and reuse it. Is the client instance thread safe since it can be used by concurrent threads? Is there any performance issue if I only create a instance of the client and reuse it for all the requests?

Answer 1

The JavaDoc is mostly answering your question already- yes it's thread-safe and you can and should reuse it. There can be a performance issue from not reusing it, i.e. if you create a Client for every HTTP request you make your performance will suck really bad.

Answer 2

I am not sure but I think this is a implementation-specific decision.

I couldn't find in the JAX-RS 2.0 specification nor in the Javadoc anything granting that javax.ws.rs.client.Client is thread-safe. But in the Resteasy (an implementor of JAX-RS) documentation I found:

One default decision made by HttpClient and adopted by Resteasy is the use of org.apache.http.impl.conn.SingleClientConnManager, which manages a single socket at any given time and which supports the use case in which one or more invocations are made serially from a single thread. For multithreaded applications, SingleClientConnManager may be replaced by org.apache.http.impl.conn.tsccm.ThreadSafeClientConnManager:

ClientConnectionManager cm = new ThreadSafeClientConnManager();
HttpClient httpClient = new DefaultHttpClient(cm);
ApacheHttpClient4Engine engine = new ApacheHttpClient4Engine(httpClient);

Source: http://docs.jboss.org/resteasy/docs/3.0.9.Final/userguide/html/RESTEasy_Client_Framework.html#transport_layer

Based in these information I guess that the answer for your question is likely to be "no".