[JBoss JIRA] Created: (JBAS-8866) JBoss Cache lock UpgradeException when simultaneous requests with the same SSO create new sessions
9:41 a.m.
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: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Clustering
Affects Versions: JBossAS-4.2.3.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.
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
3:04 p.m.
New subject: [JBoss JIRA] Updated: (JBAS-8866) JBoss Cache lock UpgradeException when simultaneous requests with the same SSO create new sessions
[
https://issues.jboss.org/browse/JBAS-8866?page=com.atlassian.jira.plugin....
]
Dennis Reed updated JBAS-8866:
------------------------------
Affects Version/s: JBossAS-5.1.0.GA
Description:
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)
was:
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.
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)
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: JBoss Application Server
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
1:27 p.m.
New subject: [JBoss JIRA] Reopened: (JBAS-8866) JBoss Cache lock UpgradeException when simultaneous requests with the same SSO create new sessions
[
https://issues.jboss.org/browse/JBAS-8866?page=com.atlassian.jira.plugin....
]
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
5566
days inactive
5635
days old
2 comments
2 participants
participants (2)
-
Dennis Reed (JIRA) -
Jason Greene (JIRA)