[jboss-jira] [JBoss JIRA] Reopened: (JBAS-8866) JBoss Cache lock UpgradeException when simultaneous requests with the same SSO create new sessions

[Jason Greene (JIRA)]

     [ https://issues.jboss.org/browse/JBAS-8866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene reopened JBAS-8866:
--------------------------------



Due to feedback from the community, I have split the AS7 and AS6 projects and reopened all unscheduled AS6 issues that are a year or less old. This will make it easier community members to find and work on them.

Future releases beyond 6.1 can be done provided a community member steps up to coordinate them.

> JBoss Cache lock UpgradeException when simultaneous requests with the same SSO create new sessions
> --------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-8866
>                 URL: https://issues.jboss.org/browse/JBAS-8866
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: JBossAS-4.2.3.GA, JBossAS-5.1.0.GA
>            Reporter: Dennis Reed
>            Assignee: Dennis Reed
>
> When more than one request with the same SSO ID creates a session at the same time, some may fail with an org.jboss.cache.lock.UpgradeException.
> The root cause is that TreeCacheSSOClusterManager.addSession/removeSession first get a read lock, then upgrade to a write lock.
> In 5.x, addSession is ok, only removeSession has this issue.
> The fix is to get a write lock up front, instead of starting with a read lock then upgrading.
> For AS 4.x, since JBoss Cache 1.4.x doesn't have Option.setForceWriteLock, adding something like the following
> before the cache.get should force a write lock:
>     cache.put ( fqn, "LOCK", null, LOCAL_OPTION );
> [org.jboss.web.tomcat.service.sso.TreeCacheSSOClusterManager] caught exception adding session C4851CD53FB091272E78A9395C0C15F1 to SSO id 821E74E80D46822B77FB774E8AEF67D8
> ...
> Caused by: org.jboss.cache.lock.UpgradeException: failure upgrading lock: fqn=/SSO/821E74E80D46822B77FB774E8AEF67D8/sessions, caller=GlobalTransaction:<10.0.0.1:61628>:4, lock=read owners=[GlobalTransaction:<10.0.0.1:61628>:4, GlobalTransaction:<10.0.0.1:61628>:5] (activeReaders=1, activeWriter=null, waitingReaders=0, waitingWriters=1, waitingUpgrader=1)
> at org.jboss.cache.Node.acquire(Node.java:517)
> ...
> Caused by: org.jboss.cache.lock.UpgradeException: acquireWriteLock(): lock upgrade failed for /SSO/821E74E80D46822B77FB774E8AEF67D8/sessions (caller=GlobalTransaction:<10.0.0.1:61628>:4, lock info: read owners=[GlobalTransaction:<10.0.0.1:61628>:4, GlobalTransaction:<10.0.0.1:61628>:5] (activeReaders=1, activeWriter=null, waitingReaders=0, waitingWriters=1, waitingUpgrader=1))
> ...
> Caused by: org.jboss.cache.lock.UpgradeException: upgradeLockAttempt(): more than one reader trying to simultaneously upgrade to write lock
> at org.jboss.cache.lock.ReadWriteLockWithUpgrade.upgradeLockAttempt(ReadWriteLockWithUpgrade.java:106)
> at org.jboss.cache.lock.LockStrategyRepeatableRead.upgradeLockAttempt(LockStrategyRepeatableRead.java:43)
> at org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:175)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira