[
https://jira.jboss.org/browse/EJBTHREE-2042?page=com.atlassian.jira.plugi...
]
Maros Bajtos edited comment on EJBTHREE-2042 at 12/3/10 3:32 AM:
-----------------------------------------------------------------
I've added blocking hotspots from my yesterday's profiling. Please see also my
thread about terrible performance with concurrent ejb calls (which is more descriptive) -
http://community.jboss.org/message/574096 . To sum it up, I've found out that if there
is lot of (hundreds) concurrent ejb calls, they'll start to block each other on
ClassLoader.loadClass method which is called from hotspots I've attached.
ClassLoader.loadClass is synchronized method - so only one thread at given time may be
executing it. Sample trace calling it:
org.jboss.ejb3.security.RoleBasedAuthorizationInterceptorv2.invoke
SecurityHelperFactory.getEJBAuthorizationHelper
SecurityActions.loadClass
ClassLoader.loadClass
The application I profiled is composed of lot of ejbs and most of the ejb calls are really
fast - therefore with one request from web, there is maybe hundreds fast ejb calls - as
soon as more users start to use application, these small concurrent ejb calls start to
block each other because of synchronized method.
was (Author: maros.bajtos):
blocking hotspots
Investigate performance issue related to use of @SecurityDomain on
EJB
----------------------------------------------------------------------
Key: EJBTHREE-2042
URL:
https://jira.jboss.org/browse/EJBTHREE-2042
Project: EJB 3.0
Issue Type: Task
Reporter: jaikiran pai
Assignee: jaikiran pai
Attachments: hotspots.tar.gz, ProfilingHotSpots.zip
A user has reported that the use of @SecurityDomain shows a relatively poor performance
(even when a @PermitAll) is applied to the bean. See the referenced forum thread for
details.
Although, it can't be guaranteed that the performance of a bean method invocation
with a @SecurityDomain will be same as that without a @SecurityDomain, the difference in
the timings as reported in that thread looks a bit too high. This JIRA is to track to
investigate the issue and see if there's any genuine performance bug.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira