title: Jersey Client non-blocking
body: <p>Spawning lots of threads is never a good idea (and when you create too many, you may run out of memory anyway).</p>
  
  <p>Usually, Jersey needs to create one thread per request. And this seems to be the case, whether I use <code>async()</code> <sup>(where Jersey creates the threads for me - I've investigated this in a debugger)</sup>, or not <sup>(where I obviously have to create the threads myself)</sup>.</p>
  
  <p>So here's one concrete situation where this is not good enough: </p>
  
  <p>I'm HTTP posting to remote servers, at a rate of up to 500 requests/second. But as the response may take some time to arrive (I calculate up to 30 seconds), the total number of threads can reach several thousands easily (at which point, a JVM process usually crashes). Moreover, it's just insane to create so many threads. It should actually be a piece of cake for the available processor/network/OS-resources to deal with that load.</p>
  
  <p>So what I'd like to do, is to just fire off the requests - and be informed by the OS, when the HTTP response arrives. </p>
  
  <ul>
  <li>As said above, simply using <code>target.request(...).async()....</code>doesn't do the trick (because then, Jersey just spawns its own threads).</li>
  <li>Also, limiting the number of threads via <code>new ClientConfig().property(ClientProperties.ASYNC_THREADPOOL_SIZE, 10)</code> is not helpful at all, because it means, that at most 10 requests will be sent at a time, which is clearly not what I want (it would just pile-up the queue).</li>
  </ul>
  
  <p>I experimented with <code>new ClientConfig().connectorProvider(new GrizzlyConnectorProvider())</code>to get NIO support - but didn't see any difference in behaviour at all.</p>
  
  <p>So is there any way to fire off a request without having to create one extra thread per request?</p>