[JBoss JIRA] Created: (JBAS-5451) Unclean handling of JMX registrations by ChannelFactory
by Brian Stansberry (JIRA)
Unclean handling of JMX registrations by ChannelFactory
-------------------------------------------------------
Key: JBAS-5451
URL: http://jira.jboss.com/jira/browse/JBAS-5451
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Clustering
Affects Versions: JBossAS-5.0.0.Beta4
Reporter: Brian Stansberry
Assigned To: Brian Stansberry
Fix For: JBossAS-5.0.0.CR1
First, only MuxChannels are registered. All channels should be registered. This will necessitate adding a ChannelListener to all channels so the factory gets a callback when the channel is closed, at which point it can be deregistered.
Second, the AS ChannelFactory's destroy method delegates to org.jgroups.JChannelFactory, which in turn removes everything from JMX that's registered under the jboss.jgroups domain. That includes the ChannelFactory itself. This can cause problems if the pojo factory is destroyed before the JMX proxy to the factory.
The deregistration needs to be more fine grained.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 1 month
[JBoss JIRA] Updated: (JBAS-1082) jdbc.WrapperDataSource.getConnection is slow
by Clebert Suconic (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-1082?page=all ]
Clebert Suconic updated JBAS-1082:
----------------------------------
Assignee: Jesper Pedersen (was: Clebert Suconic)
Transferring this issue to Jesper, since he is the JCA specialist
> 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: Jesper Pedersen
> Priority: Minor
>
> 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: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 1 month