FYI: Reuse of objects can also be done on the level of targets and invocation templates, a.k.a. Invocation class: You can invoke it several times using different values (see
http://docs.oracle.com/javaee/7/api/javax/ws/rs/client/Invocation.html#property(java.lang.String, java.lang.Object)<
http://docs.oracle.com/javaee/7/api/javax/ws/rs/client/Invocation.html#property(java.lang.String,%20java.lang.Object)> and
http://docs.oracle.com/javaee/7/api/javax/ws/rs/client/Invocation.html#invoke(java.lang.Class)).
Von: Colin Vipurs [mailto:zodiaczx6_at_gmail.com]
Gesendet: Dienstag, 28. Oktober 2014 10:44
An: users_at_jersey.java.net
Betreff: [Jersey] Re: Pool for javax.ws.rs.client.Client objects?
This is exactly what we do across all our services. You should notice quite the performance improvement switching to this as well
On Tue, Oct 28, 2014 at 9:10 AM, Markus Karg <karg_at_quipsy.de<mailto:karg_at_quipsy.de>> wrote:
Did you find any official documentation which says that you must not use one single client concurrently by different threads? If not, why not just using a single instance?
Von: Rodrigo Uchôa [mailto:rodrigo.uchoa_at_gmail.com<mailto:rodrigo.uchoa_at_gmail.com>]
Gesendet: Dienstag, 28. Oktober 2014 00:12
An: users_at_jersey.java.net<mailto:users_at_jersey.java.net>
Betreff: [Jersey] Pool for javax.ws.rs.client.Client objects?
Hi guys!
I have a client web application that uses the Client API to make REST calls to a REST business layer.
The javax.ws.rs.client.Client docs clearly states that Client objects are expensive to create and dispose, and only a small number of them should be created, which makes me think they should be pooled somehow.
Our initial thought was to instantiate and then close every Client object we use, making code like this:
public void doSomething() {
Client client = ClientBuilder.newClient();
//do a bunch of stuff here
client.close();
}
Every method that needs to invoke REST services are coded like the example above. That means every time a client web request comes in, a new Client object is created and then closed. The exact opposite of what the docs advises us to do.
How should we implement a pool of Client objects in this scenario? Is there a common solution?
Regards,
Rodrigo Uchoa.
--
Maybe she awoke to see the roommate's boyfriend swinging from the chandelier wearing a boar's head.
Something which you, I, and everyone else would call "Tuesday", of course.