[JBoss JIRA] Created: (SECURITY-22) Concurrency bug in JaasSecurityManager
by Alex Besogonov (JIRA)
Concurrency bug in JaasSecurityManager
--------------------------------------
Key: SECURITY-22
URL: http://jira.jboss.com/jira/browse/SECURITY-22
Project: JBoss Security
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: JBossSX
Affects Versions: 2.0
Reporter: Alex Besogonov
Assigned To: Anil Saldhana
JaasSecurityManager$DomainInfo.destroy calls logout() when cached entry expires, even while it is used by another thread.
Suppose we have two threads:
Thread 1:
1. 'User1' authentication
2. 'User1' is added to auth cache
3. Doing some lengthy operation
4. Checking roles of User1 - WILL FAIL, another thread has called logout()!
Thread 2 (when Thread1 is doing 'some lengthy operation' ):
1. 'User1' logs in.
2. Auth cache entry has expired.
3. Calling .logout() on stale entry
--
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
19 years, 2 months
[JBoss JIRA] Created: (JBRULES-495) Allows for automatic meta data gathering during rule/rule package saves to repository
by Marcos Tengelmann (JIRA)
Allows for automatic meta data gathering during rule/rule package saves to repository
-------------------------------------------------------------------------------------
Key: JBRULES-495
URL: http://jira.jboss.com/jira/browse/JBRULES-495
Project: JBoss Rules
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: drools-brms
Reporter: Marcos Tengelmann
Assigned To: Mark Proctor
Priority: Optional
In order to make search easy as possible, we would like to have automatic meta data collected during the process of importing rules from files or during the save process from UI, to repository back end.
The whole idea here is to keep the concept of Category only for business purposes.
Besides the category concept , we could have attributes set into the repository attached with its components. With that we mean, that we could automatically (The saver to repository is a suggesiton on doing this), to extract Columns (Could be OTN also?) from rules, and create lists of all column types a given rule uses and even other type of data could be extracted from rule files and definitions
With that we could be able to link in searches, business desciptions and categories to real implementation, giving very usefull results (A Better search engine than Google)....
--
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
19 years, 2 months
[JBoss JIRA] Created: (JBAOP-300) SecurityActions$PrincipalInfoAction missing from client jar
by Thomas Diesler (JIRA)
SecurityActions$PrincipalInfoAction missing from client jar
-----------------------------------------------------------
Key: JBAOP-300
URL: http://jira.jboss.com/jira/browse/JBAOP-300
Project: JBoss AOP
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Thomas Diesler
java.lang.NoClassDefFoundError: org/jboss/aspects/security/SecurityActions$PrincipalInfoAction
at org.jboss.aspects.security.SecurityActions.getPrincipal(SecurityActions.java:363)
at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:47)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:77)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.stateless.StatelessRemoteProxy.invoke(StatelessRemoteProxy.java:102)
--
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
19 years, 2 months
[JBoss JIRA] Created: (JGRP-387) Reduce heavily contented locks
by Bela Ban (JIRA)
Reduce heavily contented locks
------------------------------
Key: JGRP-387
URL: http://jira.jboss.com/jira/browse/JGRP-387
Project: JGroups
Issue Type: Task
Affects Versions: 2.4
Reporter: Bela Ban
Assigned To: Bela Ban
Fix For: 2.5
Identify and reduce/eliminate heavily contended locks, e.g.
NakReceiverWindow:
N threads will messages from the same receiver will hit the NRW (synchronization on NRW for inserts and removes). We can possibly replace the sorted hashmaps in NRW with their java.util.concurrent equivalents, so access is distributed across bucket (lock striping), reducing heavily contended locks. Also, replace ReentrantLock (e.g. used in add() and remove()) with the j.u.c.lock equivalent.
NAKACK:
Same as above: replace received_msgs with ConcurrentHashMap. Use equivalents from j.u.c.lock to replace the locks used.
Another big source of contention is that multiple threads with messsages from the *same* receiver will all add their message to the *same* NRW, then *only one* thread will remove them all and pass them up, causing the other threads to block (incurring context switches and possible processor cache flushes). When the delivery thread returns, all other threads wake up and all of them return after NRW.remove() returns null !
--
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
19 years, 2 months