Jersey non blocking client

Although Jersey already have support for making asynchronous requests, it is implemented by standard blocking way - every asynchronous request is handled by one thread and that thread is released only after request is completely processed. That is OK for lots of cases, but imagine how that will work when you need to do lots of parallel requests. Of course you can limit (and its really wise thing to do, you do want control your resources) number of threads used for asynchronous requests, but you'll get another maybe not pleasant consequence - obviously processing time will increase.

There are few projects which are trying to deal with that problem, commonly named as async http clients. I didn't want to "re-implement a wheel" and I decided I'll use AHC - Async Http Client made by Jeanfrancois Arcand. There is also interesting implementation from Apache - HttpAsyncClient, but it is still in "very early stages of development" and others haven't been in similar or better shape as AHC.

How this works? Non-blocking clients allow users to make same asynchronous requests as we can do with standard approach but implementation is different - threads are better utilized, they don't spend most of time in idle state. Simply described - when you make a request (send it over the network), you are waiting for reply from other side. And there comes main advantage of non-blocking approach - it uses these threads for further work, like making other requests or processing responses etc.. Idle time is minimized and your resources (threads) will be far better used.

Who should consider using this? Everyone who is making lots of asynchronous requests. I haven't done proper benchmark yet, but some simple dumb tests are showing huge improvement in cases where lots of concurrent asynchronous requests are made in short period.

Last but not least - this module is still experimental, so if you don't like something or if you have ideas for improvements/any feedback, feel free to comment this blog post, send mail to or contact me personally. All feedback is greatly appreciated!

maven dependency (will be present in maven 2 repo by the end of the day):



code snippet:

 ClientConfig cc = new DefaultNonBlockingClientConfig();
 cc.getProperties().put(NonBlockingClientConfig.PROPERTY_THREADPOOL_SIZE, 10); // default value, feel free to change
 Client c = NonBlockingClient.create(cc);

 AsyncWebResource awr = c.asyncResource("");

 Future<ClientResponse> responseFuture = awr.get(ClientResponse.class);

 // or
 awr.get(new TypeListener<ClientResponse>(ClientResponse.class) {
     public void onComplete(Future<ClientResponse> f) throws InterruptedException {

javadoc (temporary location, won't be updated):


fantastic !

I've bean waiting for this feature

Posted by walec51 on June 30, 2011 at 03:52 AM CEST #

Now that there is true non-blocking http client, the next logical step might be trying non-blocking processing. Fortunately for XML there is Aalto (, so parsing can be done in non-blocking way (and very fast, at that!).
But I don't know if there is a non-blocking data-binding lib available: JAXB might not be awfully hard to change, since it uses event-based approach (due to starting with SAX), but it won't work without some changes.

Posted by guest on June 30, 2011 at 11:26 AM CEST #

Hi Pavel,
Did the implementation of the non blocking client moved from experimental to production?

It does not look like that the onComplete called from within the client. Or it does require an additional settings of the client?

Best regards,

Posted by Pavel on October 11, 2012 at 10:55 PM CEST #

Hi Pavel,

i am wondering why after i implemented your client codes, my server always return HTTP 400.

i am using these following codes on my client code:
FormDataMultiPart part = new FormDataMultiPart();
part.field("max_accepted_LTT", max_accepted_LTT.toString(), MediaType.APPLICATION_XML_TYPE);
part.field("hasAttachments", hasAttachments.toString(), MediaType.APPLICATION_XML_TYPE);
GenericType<InputStream> genericType = new GenericType<InputStream>() {};
Future<InputStream> lttResult = asr.path("getDALTT").type(MediaType.MULTIPART_FORM_DATA_TYPE).post(genericType, part);

and for the server side, im using these codes:
public InputStream getDALTT(@FormDataParam("max_accepted_LTT") String max_accepted_LTT, @FormDataParam("hasAttachments") String hasAttachments) throws IOException {"request accepted");

Kindly advise

Posted by guest on November 23, 2012 at 11:50 AM CET #

Hi Pavel,

non-blocking client is already moved to contribs and few related issues were fixed since then, can you please retest with Jersey 1.15?

Posted by Pavel on November 23, 2012 at 12:16 PM CET #


can you please strip down multipart from your code and try again? I'm not sure whether it is handled well when async client is used.

Posted by Pavel on November 23, 2012 at 12:30 PM CET #

Hi Pavel,

I sent you a message through jersey forum.
Thanks in advance


Posted by guest on November 23, 2012 at 01:08 PM CET #

Hi Pavel,
I only experienced the issue while running Unit Tests. It works fine outside of the Unit Test.

Best regards,

Posted by Pavel on November 27, 2012 at 02:36 AM CET #

Hi Pavel!
I found that you one of authors of com.sun.jersey.client.impl.CopyOnWriteHashMap. It takes 30 seconds to look at the code to understand that the class in not multithreaded and can throw ConcurrentModificationException. You can modify the "copy" field collection having an iterator on the object. I don't know where to submit bugs against the code, so writing here, please fix.

Posted by guest on March 25, 2013 at 10:21 PM CET #

Hi guest,

please file new issue against Jersey: , ideally with a (failing) testcase.


Posted by Pavel on April 02, 2013 at 04:01 PM CEST #

Post a Comment:
  • HTML Syntax: NOT allowed

Pavel Bucek


« April 2014