Monday Mar 30, 2015

How To Use Jersey Client Efficiently

While fixing a memory leak issue in JerseyClient some time ago i realised how easy it is to misuse the thing. In this blog post, i would like to introduce some tips to avoid unnecessary memory allocation and also to save some CPU cycles to achieve better throughput.

Tip 1: Be careful when updating WebTarget config!

In Jersey 1.x it was suggested to reuse Client instances (see here for details). In Jersey 2, reusing Client instances is still recommended, but as such it is not sufficient to keep things running efficiently. Application performance can easily be undermined here. Related documentation could be found in Jersey User Guide and the key sentence is quoted bellow:

The configuration principles used in JAX-RS client API apply to WebTarget as well.
The documentation does not state this explicitly, so i will write it here in bold once more: be careful when touching configuration of a web target!. What does it mean? Whenever you create a new web target with updated configuration, Jersey will effectively create a new client runtime. To keep your application performing well, you should think of reusing all such web targets.

Best practices

The following picture depicts penalty that you could pay if you do not avoid the two main anti-patterns in this area. The graph captures total time required to make 50 thousand of HTTP get requests via Jersey client calls.

Tip 2: Avoid WebTarget.register()

If you need to register some extra components, do it on the client already to prevent another client runtime creation. If you need another runtime, just try to register things once and reuse the resulting target instance.

Tip 3: Avoid

The same applies to updating properties. These you can happily set on an Invocation or its builder

Tip 4: Use response.close() to release network connections!

When i wrote a simple test to get data for the above graph, i was getting short of available network ports. The problem is well described e.g. here. To avoid this i had to close responses. So as the last tip i recommend you close coming responses as well.

Tuesday Mar 17, 2015

Jersey 2.x Client on Android - Take 2

In my earlier post i described what we did in Jersey version 2.16 in order to make Jersey client work on Android. The whole idea was that after separating JAXB providers out from the Jersey core module, things would just work out of the box. Unfortunately, it turned out the JAXB provider separation was not enough. Basic things worked (see my original post for a test case application), but Jersey was still trying to pull in some types not available in Android environment. Harish complained this caused his application to crash.

In this post i would like to share a workaround, that should hopefully help overcome the above mentioned issue. The good thing is, you do not need to upgrade your Jersey dependency (version 2.16 and 2.17 should work just fine). The bad thing is the workaround relies on certain Jersey implementation internals, and i can not guarantee it would keep working for future Jersey versions.

The workaround is quite simple and uses HK2 public API, that allows you to "unbind" components from the HK2 service locator on the fly. Here is the code:

public static class AndroidFriendlyFeature implements Feature{

  public boolean configure(FeatureContext context) {
      context.register(new AbstractBinder() {
          protected void configure() {
              addUnbindFilter(new Filter() {
                  public boolean matches(Descriptor d) {
                      String implClass = d.getImplementation();
                      return implClass.startsWith(
                       || implClass.startsWith(
      return true;
The above feature must be registered with your Jersey client in the following way:
client = ClientBuilder.newClient().register(AndroidFriendlyFeature.class);

I have tested this only locally, so i am not sure the above workaround works for everybody, thus I would like to take this as an opportunity to ask for feedback. Please let me know if you had a chance to check this workaround out and whether it worked for you. It would help us to come up with a final solution for Android environment in Jersey.

Monday Mar 16, 2015

Jersey 2.17 Has Been Released

We have just released the 2.17 version of Jersey, the open source, production quality, reference implementation of JAX-RS 2.0.

To download Jersey 2.17, please check out our download page.

You can also check out the refreshed Jersey 2.17 documentation:

This version includes mainly bug fixes. Following is a list of the most important updates:

Tuesday Mar 03, 2015

When to Use JAX-RS Class-path Scanning Mechanism

The short answer is: never!. I have seen several nasty (so called) "bugs" caused by this feature so that i felt like sharing this little advice via blog post:

Never ever use JAX-RS class-path scanning feature in a production environment

Class-path scanning looks like a handy feature. Let say you do not want bother with enumerating all the components you would like to include in your JAX-RS application. Then your JAX-RS application class could look like:


public class EasyToConfigureJaxRsApplication extends Application {

The above example works great. When started, the application just scans the actual class-path, and adds every single JAX-RS component class found there to the actual runtime configuration. Isn't is great? Frankly, this kind of configuration could work just fine. Until someone changes either the system configuration (system class-path) or the way how you application is being packaged (a new 3rd party component could be added/removed from the application class-path then). These changes could be out of your control and if one of them happens, you application configuration could break. For this reason, it is not wise to use this kind of configuration in a production environment.

One could think that for development purposes, using this cool feature would be fine. I think otherwise. You either develop an application targeted for production use, and then you want to stick with whatever will be used in production eventually (where class-path scanning is a no-go) or you just want to look around and play with things. In the latter case you still want to keep control and avoid any nasty surprise.

To end up in a positive way. Here is another advise: Should you need to use any kind of scanning (for any reason), check out Jersey package scanning feature that allows you to control the scope of scanning. See the following links for some more details:,

Friday Feb 13, 2015

Container Agnostic CDI Support In Jersey


At the time of this writing, Java SE support is being discussed as one of important additions to CDI 2.0 specification. Existing CDI implementations brought this feature already, only container bootstrapping has not yet been standardized. In Jersey version 2.15 we introduced Weld SE support, so that people could take advantage of CDI features also when running in Java SE environment. As part of this work, the old Jersey CDI module has been refactored so that it supports CDI integration in any CDI-enabled HTTP container.

Containers Known to Work With Jersey CDI Support

To stick with JAX-RS specification, Jersey has to support JAX-RS/CDI integration in Java EE environment. The two containers supporting JAX-RS/CDI integration out of the box are Oracle GlassFish and Oracle WebLogic application server.

Apache Tomcat is another Servlet container that is known to work fine with Jersey CDI support. However, things do not work there out of the box. You need to enable CDI support in Tomcat e.g. using Weld. Jersey CDI example shows how a WAR application could be packaged (see tomcat-packaging profile in the pom file) in order to enable JAX-RS/CDI integration in Tomcat with Jersey using Weld.

Another Servlet container that is supported by Weld is Jetty. Jersey CDI integration module should work there as well, but things have not been tested by Jersey team.

If not bundled already with underlying Servlet container, the following Jersey module needs to be packaged with the application or otherwise included in the container class-path:


Request Scope Binding

There is a common pattern for all above mentioned containers. Jersey CDI integration builds upon existing CDI/Servlet integration there. In other words, in all above cases, Jersey application must be deployed as a Servlet, where the underlying Servlet container has CDI integrated already and CDI container bootstrapped properly.

The key feature in CDI/Servlet integration is proper request scope binding. If this feature was missing, you would not be able to use any request scoped CDI beans in your Jersey application. To make Jersey work with CDI in containers that do not have request scope binding resolved, some extra work is required.

To allow smooth integration with Jersey request scope a new SPI, ExternalRequestScope, was introduced in Jersey version 2.15. An SPI implementation should be registered via the standard META-INF/services mechanism and needs to make sure CDI implentation request scope has been properly managed and request scoped data kept in the right context. For performance reasons, at most a single external request scope provider is allowed by Jersey runtime.

Jersey Weld SE Support

The extra work to align HTTP request with CDI request scope was already done by Jersey team for Weld 2.x implementation. In order to utilize Jersey/Weld request scope binding, you need to use the following module:


Then you could use your CDI backed JAX-RS components in a Jersey application running in Grizzly HTTP container bootstrapped as follows:

Example Bootstrapping Jersey application with Weld support on Grizzly

            Weld weld = new Weld();

            final HttpServer server = GrizzlyHttpServerFactory.createHttpServer(URI.create("http://localhost:8080/weld/"), jerseyResourceConfig);

            // ...


The above pattern could be applied also for other Jersey supported HTTP containers as long as you stick with CDI Weld 2.x implementation. You simply add the above mentioned jersey-weld2-se module into you class-path and bootstrap the Weld contatiner manually before starting the HTTP container.

Thursday Feb 12, 2015

Jersey 2 Performance

During my sabbatical week in January i have done some performance improvements in Jersey server core module. These changes are already included in Jersey version 2.16.

To make sure the changes indeed made a positive difference i have re-established continuous performance testing for Jersey server side processing. These automated tests allowed Michal Gajdoš to collect some numbers that show how performance evolved within Jersey 2.x version space. In this post i would like to share part of the outcome of this measurement. I hope to be able to reveal more numbers and details on the test setup in later posts.

The above graph shows how Jersey throughput increased with increased Jersey version. Version 2.4 is emphasised here as till that version we had a serious bottleneck in Jersey, that avoided throughput to scale with increased number of worker threads.

The above numbers capture increased throughput for regular resource methods handling plain text payload, where no sub-resource locators are involved. Sub-resource locators used to have poor throughput in Jersey versions prior to 2.16. In 2.16 Michal fixed this and i would recommend you check out his post on this topic here.

I think that the above graph clearly shows that we take performance seriously in Jersey. I hope that we will be able to further improve performance of Jersey in future versions.


Jakub Podlesak-Oracle


« February 2017