Hello,

I have set up container managed security for a servlet in a webapp, using BASIC authentication. I am using the "jbossmq" security domain, which is configured as DatabaseServerLoginModule using a local MySQL database. So I am actually using JMS_USERS and JMS_ROLES for authentication. This is convenient, because the servlet is only doing JMS related tasks.

It all works fine, but when I "bomb" the servlet with HTTP POST requests from many concurrently running instances of a little test HTTP client, the authentication sporadically (for around 5 out of 1000 requests) fails in two ways:

- When there are many concurrent requests from the same user, I sometimes get a "HTTP status 403 Access to the requested resource has been denied".

- When there are many concurrent requests from different users, sometimes getUserInRole() in the servlet fails, even though I can see that there is a match between the remote user of that particular request and the role it is tested against.

I have set the org.apache log categrory to DEBUG and I can see, that checking the roles of a user sometimes fails:

2005-10-18 21:41:17,073 DEBUG [org.apache.catalina.realm.RealmBase] Checking roles GenericPrincipal[appuser1(SOMServlet,SOMapp1,guest,)]
2005-10-18 21:41:17,073 DEBUG [org.apache.catalina.realm.RealmBase] Username appuser1 has role SOMServlet
2005-10-18 21:41:17,075 DEBUG [org.apache.catalina.realm.RealmBase] Checking roles GenericPrincipal[appuser2(SOMServlet,SOMapp1,guest,)]
2005-10-18 21:41:17,075 DEBUG [org.apache.catalina.realm.RealmBase] Username appuser2 has role SOMServlet

appuser2 gets role SOMapp1, which is definetely wrong:

mysql> select * from JMS_ROLES;
+--------------+----------+
| ROLEID | USERID |
+--------------+----------+
| guest | appuser1 |
| SOMapp1 | appuser1 |
| SOMServlet | appuser1 |
| guest | appuser2 |
| SOMapp2 | appuser2 |
| SOMServlet | appuser2 |
| guest | guest |
| guest | servlet |
| SOMAllQueues | servlet |
+--------------+----------+

Does anybody know what the reason for this behaviour could be?

Thanks,
Torsten