Q: How can I configure the maximum number of simultaneous threads used for Jersey REST calls? I'm working on a server application that uses Jersey JAX-RS to handle REST, Shiro to handle authentication, and it's all running on a Tomcat instance.
The problem I'm experiencing is that the REST calls appear to be handled serially (or at least, with only a small number of simultaneous threads).
I've written a small test in NodeJS that logs roughly 80 users into the server within about 5 seconds.  What I've found is that the response times get progressively longer for each user.  Here's my output:
Login completed in 3256 ms
Login completed in 3752 ms
Login completed in 3830 ms
Login completed in 3957 ms
Login completed in 4304 ms
Login completed in 4528 ms
Login completed in 4724 ms
Login completed in 4814 ms
Login completed in 5072 ms
Login completed in 5171 ms

... removed some, you get the idea
Login completed in 25337 ms
Login completed in 26364 ms
Login completed in 26738 ms
Login completed in 27114 ms
Login completed in 27266 ms
Login completed in 27337 ms
Login completed in 27847 ms
Login completed in 28365 ms
Login completed in 28571 ms
Login completed in 32358 ms

The login call does some db work and then returns.  The interesting part is that I'm also timing the call on the server side, and it always reports a login time of roughly 3s - 6s.
This tells me that the requests are sitting in a queue somewhere before they ever hit my code.  I've read that Jersey is supposed to start a new thread for every request, but is there a maximum that I'm hitting?  If so, how can I increase/configure it?  Or is this a Tomcat configuration problem?
I've disabled Shiro to ensure that it is not causing the problem.

A: Well silly me.  The queuing was actually happening on the Node side.  I mistakenly thought that Node automatically sent each request in parallel but I had to increase the maxSockets value for it to work (see Nodejs Max Socket Pooling Settings).
