SourceForge Submitter: iprigg .
I am operating Jboss 3.2.3 on an Athlon XP 1400+
machine with 512 MB of RAM running Windows 2000
server. I am using JDK 1.4.1.I would like to report a bug
in the jbossSX framework. In fact I don't know if it is
actually a bug or just an implementation approach, that
restricts the performance of the framework. I think it is
the second, but I would like to know, whether it has
been noticed and If there are plans for changing it.So
lets continue with the description of the problem:
What I have tried lately to do was to perform some
benchmark testing of a service access control data
model I have created. In order to do that I decided to
use the jbossSX framework for performing access control
on 200 stateless EJBs. The security data was stored in
an LDAP server, so I have created 3 login modules that
perform specific searches in it, retrieving roles and
assigning them to users. All Login modules were specified
as required.The benchmark involved thousand of
invocations of these EJBs (they all belong in the same
security domain), within a few minutes, through a
stateless client EJB, using
the "org.jboss.security.ClientLoginModule" in order to
pass the security credentials (username and password)
to the server. The ldap server contains the credentials
of 1000 users. So in practice I had 1000 users randomly
performing calls on the methods provided by 200
stateless EJBs. Each EJB contained 5 methods, each
secured with a different role. Generation of invocation
requests was extremely fast (about 3000 requests in a 3
minutes period).
What I noticed, straight from the begining was that the
whole process was extremely slow. For example 3000
invocations of the secured EJBs (notice that the
business logic included in the EJB is minimal, just printing
a string), consumes the following time:
1) if JAAS cache is disabled 50 minutes
2) if JAAS cache is enabled 15 minutes (notice however
that we have at maximum 1000 security checks the
same with the total number of users)
Finally I have performed the same invocations without
specifying a security domain for the EJBs and the testing
was completed almost with the post of the final request
(3 minutes).At first I suspected that the delay was due
to the searches and the actual processing that takes
place inside the Login Modules. However by measuring
the actual time of each operation, I found out that less
than 1% percent of the total execution time is spent
there.After several tests, I found out that the actual
problem was imposed by
the "JAASSecurityManager.class" and speciffically its
boolean method "isValid(Principal principal, Object
credential, Subject activeSubject)", which is defined as
synchronized. This results to all execution threads
freezing upon accessing the method and ceasing their
execution for very large periods of time. The more the
threads accessing the class the more the experienced
delay.
Is that something that would be taken care in the
future? or it just needs to be done on this way, so no
possible solution is foreseen?