Mitigating performance issues from registering new WebTargets or properties on WebTarget

Nick Vaidyanathan
 

After researching several reports of developers facing issues with using the Jersey client which seem to align with the guidance given in https://blogs.oracle.com/japod/how-to-use-jersey-client-efficiently, including:
 

if you have something like myWebTarget.property("some property", "some property value")...request()...invoke(), then the setting of the property value actually erases the whole internal configuration of the WebTarget object. And so when the WebTarget object is used to make a request, the whole configuration needs to be rebuilt, which apparently requires searching for several properties files on the classpath…I'd expect there to not be a significant performance penalty for setting properties on webtargets, which we do in order to set timeout values.

 

And

 

 registering features on targets still has a big performance impact…creates new runtime, which triggers a classpath scan for resources and annotated components

 

I’ve found some discussion about this on the Nabble:

http://jersey.576304.n2.nabble.com/Jersey-client-inefficiency-td7582618.html

 

I haven’t found a design document/blog/anything in the user guide detailing why “creating a new ClientRuntime every time a Feature or property is registered” is desirable.

 

It seems to me like this implementation class behavior is not prescribed by the spec. I’m a big fan of the intention of the immutability, but it seems very hard to do with internal State marked as “shared” and copied on every change.

 

Has there been any consideration to using a FLYWEIGHT to minimize the cost of creating ClientRuntime? Would the community be open to a pull request along these lines?

 

 

 

 

 

Join jersey@javaee.groups.io to automatically receive all group messages.