A REST client that simply does a "GET /users/user.0" repeatedly on new connections will sometimes fail to get any response from the server.
Packet traces are attached of two bad examples which can be viewed in wireshark - scroll to the end of both files to see the problematic connection. Note in some cases we don't return any HTTP response at all - just TCP level ACKs (8080-port50089.pcap), and in other cases we send the first packet of a chunk encoded HTTP response but not the last packet (8080-port56429.pcap).
If the client has a socket timeout configured, a grizzly selector runner thread will start to spin as soon as the client closes the connection. It appears to be trying to read from the socket, returning -1, throwing an EOFException, and then looping. The spin can only be stopped by halting the server.
The same tests work fine with the separate REST2LDAP servlet; it might be a bug in our code but it seems more likely to be yet another bug in the grizzly connection closure code. There are several open bugs in this part of grizzly, though none match exactly what we're seeing here.
To use the load generator, edit the service parameters of the configfile.txt, and run "java -jar RestLoadGen.jar -c /path/to/configfile.txt". The other parameters work as follows:
READS: number of READs to perform on each thread
LOADTHREADS: number of threads to run
UPPERBOUNDS: reads will be randomly chosen from user.1 to user.UPPERBOUNDS
READTHRESHOLD: the socket timeout
You can trigger the issue with a pure READ load.