This is a cross-post from user forum (http://www.jboss.com/index.html?module=bb&op=viewtopic&t=95622). I've found a VERY curious concurrency bug in JaasSecurityManager. I'm using custom login modules and custom principal and a custom SecurityInterceptor for JNDI lookups, this interceptor checks . My DefaultCacheTimeout value was set to 0 (I wanted to turn off authentication cache). My application (remote Swing client) worked fine as long as there was only one thread doing JNDI lookups. But sometimes a second application threw exception during JNDI authorization , it turned out that authenticated Subject had an empty role set. But this is impossible, because my Subjects always have at least one role. After few hours of debugging I've found the problem: my custom login module removes its Subject roles during the logout() method. I've found that this module is called by JaasSecurityManager$DomainInfo.destroy. And that's a bug. Suppose we have two threads: Code: | Thread 1: Thread 2 (some time after Thread1): | 1. 'User1' authentication 1. 'User1' logs in. | 2. 'User1' is added to auth cache 2. Auth cache entry has expired. | 3. Doing some lengthy operation 3. Calling .logout() on stale entry | 4. Checking roles of User1 - WILL FAIL, another thread has called logout()! | This problem may be not evident with the stock JBoss login modules, because their logout() methods do not remove subject's roles. Proposed fixes: 1. Use deep cloning. That way threads 1 and 2 doesn't share any data, thus no problem. 2. Use acquire/release semantics in conjunction with SecurityAssociation. 3. Remove logout() from DomainInfo.destroy. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3992393#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...