]
Dimitris Andreadis updated JBAS-1082:
-------------------------------------
Fix Version/s: JBossAS-4.2.1.CR1
(was: JBossAS-4.2.0.CR1)
Move minor issues to a next release.
jdbc.WrapperDataSource.getConnection is slow
--------------------------------------------
Key: JBAS-1082
URL:
http://jira.jboss.com/jira/browse/JBAS-1082
Project: JBoss Application Server
Issue Type: Task
Security Level: Public(Everyone can see)
Components: JCA service
Affects Versions: JBossAS-3.2.6 Final
Reporter: Elias Ross
Assigned To: Clebert Suconic
Priority: Minor
Fix For: JBossAS-4.2.1.CR1
SourceForge Submitter: genman .
I've been profiling JMS code. When a JMS message is
added to the server, the persistence manager locates an
appropriate DataSource.
Out of the time spent in
org.jboss.mq.Connection.sendToServer, about 28% of the
time is getting the database connection through
jdbc.WrapperDataSource.getConnection to do its work.
This is after the pool has been initialized, etc. (40%
is actual persistence, though most of it is the message
serialization.)
I suspect a lot of the work is calculating a hashCode
on the javax.security.auth.Subject. SubjectCriKey and
SubjectKey should have this value cached. Ideally,
when one is accessing the local DB, none of this auth
stuff should have to take place. Looking at the source
for Subject.java, the hash code is not kept.
BaseConnectionManager2.allocateConnection %CPU=27.949
%Time=27.963 calls=411
Allocations I've seen:
JBossManagedConnectionPool$SubjectActions
is created 3284 times (for 411 getConnection calls)
java.util.Properties (1642 times)
(Disclaimer: This was done through JBoss profiler,
which may or may not create real numbers. It does
look, though, that CX is pretty slow for some operations.)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: