Unfortunately we have no success changing pool / xa-pool.
You are rigth, our problem aren't workers but we can't understand JCA behaviour, so we can't solve the bottleneck.
I would like to explain better the tests we are doing:
* We are using JMeter to stress our API with 50 threads and 30 iterations with 0 seconds "Ramp-up period"
* The tests are performed from a single host located outside the data center against our public ip
* Each thread does 5 HTTP requests
* Each HTTP request makes a few DB calls
* Due to an unknown reason our jboss only uses two "JCA threads" to enqueue all the DB requests of 150 HTTP threads
* This is a fragment of one of the two "JCA threads" (https://gist.github.com/4161046)
Thank you in advance
Your application won't use "jca threads" to handle the db requests. These are handled by your application threads.
* Connection pool size is 10.
* You have a maximum of 20 http connections.
* Handling of an http requests will involve getting a connections from the pool.
If you fire up JMeter, a maxiumum of 20 connections will be allowed, each connection will try to get a DB connection from the pool and is blocked while none is available.
Eventually a connection will become available and the blocked thread can continue.
So typically you will have 10 of your 20 http threads blocked waiting for a db connections from the pool.
The blocked threads are those named "http--0.0.0.0-8080-"x ...
Hope that helps.