users@jersey.java.net

[Jersey] Re: Thread safe question for Jersey client - aka Java threading 101

From: Sobieralski, Damian Michael <dsobiera_at_indiana.edu>
Date: Fri, 12 Dec 2014 14:50:22 +0000

Duly noted.

The readyConnection() was created to facilitate backend calls for other devs w/o knowing how to set this up. Our readyConection() isn’t quite this simple as outlined as we have some other things going on like auth stuff and the like. So having a central place to initialize all this allows our developers to get going w/ the backend service calls w/o knowing all the ins and outs of the details of initializing.

As I said, I THINK if readyConnection() itself returns a new WebTarget (versus the code I pointed out and worried about - sharing the class variable WebTarget) that this should be enough to guarantee thread safety. But the more eyes of what I think makes sense the better :)

- Damian


From: Mikael Ståldal [mailto:mikael.staldal_at_appearnetworks.com]
Sent: Friday, December 12, 2014 3:40 AM
To: users_at_jersey.java.net
Subject: [Jersey] Re: Thread safe question for Jersey client - aka Java threading 101

Declaring a variable and initializing it to null is a warning flag in general. Try to defer declaring a variable until you have the value for it, then the proper scope will follow.

Either have it as a final (and initialized) instance variable:
protected final Client jerseyClient = ClientBuilder.newBuilder().register(JacksonFeature.class).build();

Or a local variable in your method:
WebTarget jerseyTarget = jerseyClient.target(baseUrl).path("api").path("v1");


On Thu, Dec 11, 2014 at 5:32 PM, Sobieralski, Damian Michael <dsobiera_at_indiana.edu<mailto:dsobiera_at_indiana.edu>> wrote:
I have a question about thread safety here. This is a much lower level discussion than what have been reading here and touches on Java threading 101.

In a backend service object (we have something like this - this object sits in a servlet container):

protected Client jerseyClient = null;
protected WebTarget jerseyTarget = null;

These are class variables. This is normally a warning flag for threading issues

Then we have code like this:

        protected void readyConnection() throws Exception {
            jerseyClient = ClientBuilder.newBuilder().register(JacksonFeature.class).build();

           jerseyTarget = jerseyClient.target(baseUrl).path("api").path("v1");
        }

and methods that use jerseyTarget. Is this a bad idea thread wise? It seems like jersey client is fine being a class variable. But that jerseyTarget in this ready method instead of setting the class variable jerseyTarget should return its own jerseyTarget.

So, is it better to do this?

        protected WebTarget readyConnection() throws Exception {
            jerseyClient = ClientBuilder.newBuilder().register(JacksonFeature.class).build();

           return jerseyClient.target(baseUrl).path("api").path("v1");
        }

- Damian



--
Mikael Ståldal
Chief Software Architect
Appear
Phone: +46 8 545 91 572
Email: mikael.staldal_at_appearnetworks.com<mailto:mikael.staldal_at_appearnetworks.com>