scswarga wrote :
| All our profiling has pointed the hotspot as getting the connection from
the datasource. I wonder if anyone will look into the issue.
|
http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossHelp
If you are not going to provide this information, you are just wasting people's
After all the tuning we applied to JBoss 4.0.3SP1, it was 7 times slower and
the throughput was about 7 times lesser when compared to to using Tomcat alone.
We will now be using Servlets with our own JDBC Connection Pooling.
All our profiling has pointed the hotspot as getting the connection from
Here is the rest of the stack trace.
I had profiled the application using OptimizeIt earlier and it was spending
80-90% of its time in trying to acquire a connection from the datasource.
I had even bumped up min/max connection to be more than the concurrent requests
and it still did not help.
Thanks for your response, Scott.
The only other place the connection from the datasource is being used is in our
Custom Login Module. The connection from the datasource is being used for
authenticating the user as part of the methods that need to be overridden to
use JBossSX.
We get the
The bottleneck is in waiting for getting the connection from the datasource
when accessing an Enity Bean finder method which is the first call in the
corresponding session bean.
The below stack is just one of the waits in the thread dump.
http-0.0.0.0-80-81 daemon prio=5 tid=0x27101890
That is not an interesting trace as this just says there are too many
connection attempts for the pool configuration. A thread waiting for a
connection because there are not enough is not really a bottleneck on our side.
Show some other traces.
View the original post :
We have identified some locking issues with Datasource that we have fixed into
head/4.0. However I need your threadDump to determine if you are hitting the
same locking pattern or not.
Can you call kill -3 during your load test, and look for Waiting to lock
patterns in your test?
If you have
We have identified some locking issues with Datasource that we have fixed into
head. However I need your threadDump to determine if you are hitting the same
locking pattern or not.
Can you call kill -3 during your load test, and look for Waiting to lock
patterns in your test?
If you have
