Your memory and garbage collector data looks fine. Memory is nicely filled, but no reason to change anything there. The only (minor) nit is that you could switch to using the CMS collector for better throughput. That is not going to resolve your current unresponsiveness issues, though. It is something to change once you have licked this problem.
Another optimization you might want to make is to start using the server VM and not the client VM that you are using today. Again, this will not resolve your unresponsiveness. It is just a standard optimization that I can highly recommend. http://java-monitor.com/forum/showthread.php?t=552
I see that you are using MySQL. What you can do is try to enable the general log in MySQL. http://dev.mysql.com/doc/refman/5.1/en/query-log.html
Please note that that will log *every* SQL statement executed, so it will eat your disk space in for breakfast.
For a test machine that is usually fine, though. Or for a few hours on a production system. From that log you can then check the sanity of your database query volumes. From the stack dump I don't think is this the issue, though. I see no threads parked on MySQL I/O, which usually points to database interaction problems.
Anyway, on to the thread dump. I see quite some things waiting on a blocking queue. These threads have generic names (Thread-nnn) so they are probably threads you started in your own code. Are you sure these are expected to block there? They seem to be waiting to read data from somewhere.
The rest looks fine to me. You seem to be using both Derby and MySQL, which strikes me as a bit odd, but I am sure there is a good reason for that?
It is possible that your code is waiting for a time-out of some kind? Is your REST service self-contained, or does it call its own external services?