You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@struts.apache.org by "Lucy (JIRA)" <ji...@apache.org> on 2011/03/01 01:53:36 UTC
[jira] Created: (WW-3582) Token Interceptor is holding HttpSession
lock which can trigger deaklocks
Token Interceptor is holding HttpSession lock which can trigger deaklocks
-------------------------------------------------------------------------
Key: WW-3582
URL: https://issues.apache.org/jira/browse/WW-3582
Project: Struts 2
Issue Type: Bug
Components: Core Interceptors
Affects Versions: 2.2.1
Environment: Any (windows/Linux)
Reporter: Lucy
In class TokenInterceptor::doIntercept() function, it was using HttpSession lock when check tokens, it should release the lock before calling invocation.invoke().
Because invocation.invoke() was called inside the httpsession lock, it will hold the lock until all the other intercetors listed after the token interceptor have been processed.
(This triggered a dead lock in our software environment.)
It should release the lock before it calls invocation.invoke();
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WW-3582) Token Interceptor is holding
HttpSession lock which can trigger deadlocks
Posted by "Hudson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WW-3582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13470217#comment-13470217 ]
Hudson commented on WW-3582:
----------------------------
Integrated in Struts2 #536 (See [https://builds.apache.org/job/Struts2/536/])
WW-3865 rollbacks changes to TokenInterceptor applied with WW-3582 and adds new method handleToken() to allow in different way lock session object (Revision 1394422)
Result = SUCCESS
lukaszlenart :
Files :
* /struts/struts2/trunk/core/src/main/java/org/apache/struts2/interceptor/TokenInterceptor.java
* /struts/struts2/trunk/core/src/main/java/org/apache/struts2/interceptor/TokenSessionStoreInterceptor.java
> Token Interceptor is holding HttpSession lock which can trigger deadlocks
> -------------------------------------------------------------------------
>
> Key: WW-3582
> URL: https://issues.apache.org/jira/browse/WW-3582
> Project: Struts 2
> Issue Type: Bug
> Components: Core Interceptors
> Affects Versions: 2.2.1
> Environment: Any (windows/Linux)
> Reporter: Lucy
> Assignee: Lukasz Lenart
> Fix For: 2.2.3
>
>
> In class TokenInterceptor::doIntercept() function, it was using HttpSession lock when check tokens, it should release the lock before calling invocation.invoke().
> Because invocation.invoke() was called inside the httpsession lock, it will hold the lock until all the other intercetors listed after the token interceptor have been processed.
> (This triggered a dead lock in our software environment.)
> It should release the lock before it calls invocation.invoke();
> {code:java}
> protected String doIntercept(ActionInvocation invocation) throws Exception {
> if (log.isDebugEnabled()) {
> log.debug("Intercepting invocation to check for valid transaction token.");
> }
> //see WW-2902: we need to use the real HttpSession here, as opposed to the map
> //that wraps the session, because a new wrap is created on every request
> HttpSession session = ServletActionContext.getRequest().getSession(true);
> synchronized (session) {
> if (!TokenHelper.validToken()) {
> return handleInvalidToken(invocation);
> }
> return handleValidToken(invocation);
> }
> }
> protected String handleValidToken(ActionInvocation invocation) throws Exception {
> return invocation.invoke(); <------------------------- this line needs to be moved out of the session lock.
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (WW-3582) Token Interceptor is holding HttpSession
lock which can trigger deadlocks
Posted by "Lukasz Lenart (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WW-3582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Lukasz Lenart resolved WW-3582.
-------------------------------
Resolution: Fixed
Fix Version/s: 2.2.2
Assignee: Lukasz Lenart
Solved, thanks!
> Token Interceptor is holding HttpSession lock which can trigger deadlocks
> -------------------------------------------------------------------------
>
> Key: WW-3582
> URL: https://issues.apache.org/jira/browse/WW-3582
> Project: Struts 2
> Issue Type: Bug
> Components: Core Interceptors
> Affects Versions: 2.2.1
> Environment: Any (windows/Linux)
> Reporter: Lucy
> Assignee: Lukasz Lenart
> Fix For: 2.2.2
>
>
> In class TokenInterceptor::doIntercept() function, it was using HttpSession lock when check tokens, it should release the lock before calling invocation.invoke().
> Because invocation.invoke() was called inside the httpsession lock, it will hold the lock until all the other intercetors listed after the token interceptor have been processed.
> (This triggered a dead lock in our software environment.)
> It should release the lock before it calls invocation.invoke();
> protected String doIntercept(ActionInvocation invocation) throws Exception {
> if (log.isDebugEnabled()) {
> log.debug("Intercepting invocation to check for valid transaction token.");
> }
> //see WW-2902: we need to use the real HttpSession here, as opposed to the map
> //that wraps the session, because a new wrap is created on every request
> HttpSession session = ServletActionContext.getRequest().getSession(true);
> synchronized (session) {
> if (!TokenHelper.validToken()) {
> return handleInvalidToken(invocation);
> }
> return handleValidToken(invocation);
> }
> }
> protected String handleValidToken(ActionInvocation invocation) throws Exception {
> return invocation.invoke(); <------------------------- this line needs to be moved out of the session lock.
> }
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (WW-3582) Token Interceptor is holding HttpSession
lock which can trigger deadlocks
Posted by "Lucy (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WW-3582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Lucy updated WW-3582:
---------------------
Description:
In class TokenInterceptor::doIntercept() function, it was using HttpSession lock when check tokens, it should release the lock before calling invocation.invoke().
Because invocation.invoke() was called inside the httpsession lock, it will hold the lock until all the other intercetors listed after the token interceptor have been processed.
(This triggered a dead lock in our software environment.)
It should release the lock before it calls invocation.invoke();
protected String doIntercept(ActionInvocation invocation) throws Exception {
if (log.isDebugEnabled()) {
log.debug("Intercepting invocation to check for valid transaction token.");
}
//see WW-2902: we need to use the real HttpSession here, as opposed to the map
//that wraps the session, because a new wrap is created on every request
HttpSession session = ServletActionContext.getRequest().getSession(true);
synchronized (session) {
if (!TokenHelper.validToken()) {
return handleInvalidToken(invocation);
}
return handleValidToken(invocation);
}
}
protected String handleValidToken(ActionInvocation invocation) throws Exception {
return invocation.invoke(); <------------------------- this line needs to be moved out of the session lock.
}
was:
In class TokenInterceptor::doIntercept() function, it was using HttpSession lock when check tokens, it should release the lock before calling invocation.invoke().
Because invocation.invoke() was called inside the httpsession lock, it will hold the lock until all the other intercetors listed after the token interceptor have been processed.
(This triggered a dead lock in our software environment.)
It should release the lock before it calls invocation.invoke();
> Token Interceptor is holding HttpSession lock which can trigger deadlocks
> -------------------------------------------------------------------------
>
> Key: WW-3582
> URL: https://issues.apache.org/jira/browse/WW-3582
> Project: Struts 2
> Issue Type: Bug
> Components: Core Interceptors
> Affects Versions: 2.2.1
> Environment: Any (windows/Linux)
> Reporter: Lucy
>
> In class TokenInterceptor::doIntercept() function, it was using HttpSession lock when check tokens, it should release the lock before calling invocation.invoke().
> Because invocation.invoke() was called inside the httpsession lock, it will hold the lock until all the other intercetors listed after the token interceptor have been processed.
> (This triggered a dead lock in our software environment.)
> It should release the lock before it calls invocation.invoke();
> protected String doIntercept(ActionInvocation invocation) throws Exception {
> if (log.isDebugEnabled()) {
> log.debug("Intercepting invocation to check for valid transaction token.");
> }
> //see WW-2902: we need to use the real HttpSession here, as opposed to the map
> //that wraps the session, because a new wrap is created on every request
> HttpSession session = ServletActionContext.getRequest().getSession(true);
> synchronized (session) {
> if (!TokenHelper.validToken()) {
> return handleInvalidToken(invocation);
> }
> return handleValidToken(invocation);
> }
> }
> protected String handleValidToken(ActionInvocation invocation) throws Exception {
> return invocation.invoke(); <------------------------- this line needs to be moved out of the session lock.
> }
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (WW-3582) Token Interceptor is holding HttpSession
lock which can trigger deadlocks
Posted by "Lukasz Lenart (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WW-3582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Lukasz Lenart updated WW-3582:
------------------------------
Description:
In class TokenInterceptor::doIntercept() function, it was using HttpSession lock when check tokens, it should release the lock before calling invocation.invoke().
Because invocation.invoke() was called inside the httpsession lock, it will hold the lock until all the other intercetors listed after the token interceptor have been processed.
(This triggered a dead lock in our software environment.)
It should release the lock before it calls invocation.invoke();
{code:java}
protected String doIntercept(ActionInvocation invocation) throws Exception {
if (log.isDebugEnabled()) {
log.debug("Intercepting invocation to check for valid transaction token.");
}
//see WW-2902: we need to use the real HttpSession here, as opposed to the map
//that wraps the session, because a new wrap is created on every request
HttpSession session = ServletActionContext.getRequest().getSession(true);
synchronized (session) {
if (!TokenHelper.validToken()) {
return handleInvalidToken(invocation);
}
return handleValidToken(invocation);
}
}
protected String handleValidToken(ActionInvocation invocation) throws Exception {
return invocation.invoke(); <------------------------- this line needs to be moved out of the session lock.
}
{code}
was:
In class TokenInterceptor::doIntercept() function, it was using HttpSession lock when check tokens, it should release the lock before calling invocation.invoke().
Because invocation.invoke() was called inside the httpsession lock, it will hold the lock until all the other intercetors listed after the token interceptor have been processed.
(This triggered a dead lock in our software environment.)
It should release the lock before it calls invocation.invoke();
protected String doIntercept(ActionInvocation invocation) throws Exception {
if (log.isDebugEnabled()) {
log.debug("Intercepting invocation to check for valid transaction token.");
}
//see WW-2902: we need to use the real HttpSession here, as opposed to the map
//that wraps the session, because a new wrap is created on every request
HttpSession session = ServletActionContext.getRequest().getSession(true);
synchronized (session) {
if (!TokenHelper.validToken()) {
return handleInvalidToken(invocation);
}
return handleValidToken(invocation);
}
}
protected String handleValidToken(ActionInvocation invocation) throws Exception {
return invocation.invoke(); <------------------------- this line needs to be moved out of the session lock.
}
> Token Interceptor is holding HttpSession lock which can trigger deadlocks
> -------------------------------------------------------------------------
>
> Key: WW-3582
> URL: https://issues.apache.org/jira/browse/WW-3582
> Project: Struts 2
> Issue Type: Bug
> Components: Core Interceptors
> Affects Versions: 2.2.1
> Environment: Any (windows/Linux)
> Reporter: Lucy
> Assignee: Lukasz Lenart
> Fix For: 2.2.3
>
>
> In class TokenInterceptor::doIntercept() function, it was using HttpSession lock when check tokens, it should release the lock before calling invocation.invoke().
> Because invocation.invoke() was called inside the httpsession lock, it will hold the lock until all the other intercetors listed after the token interceptor have been processed.
> (This triggered a dead lock in our software environment.)
> It should release the lock before it calls invocation.invoke();
> {code:java}
> protected String doIntercept(ActionInvocation invocation) throws Exception {
> if (log.isDebugEnabled()) {
> log.debug("Intercepting invocation to check for valid transaction token.");
> }
> //see WW-2902: we need to use the real HttpSession here, as opposed to the map
> //that wraps the session, because a new wrap is created on every request
> HttpSession session = ServletActionContext.getRequest().getSession(true);
> synchronized (session) {
> if (!TokenHelper.validToken()) {
> return handleInvalidToken(invocation);
> }
> return handleValidToken(invocation);
> }
> }
> protected String handleValidToken(ActionInvocation invocation) throws Exception {
> return invocation.invoke(); <------------------------- this line needs to be moved out of the session lock.
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (WW-3582) Token Interceptor is holding HttpSession
lock which can trigger deadlocks
Posted by "Lucy (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WW-3582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Lucy updated WW-3582:
---------------------
Summary: Token Interceptor is holding HttpSession lock which can trigger deadlocks (was: Token Interceptor is holding HttpSession lock which can trigger deaklocks)
> Token Interceptor is holding HttpSession lock which can trigger deadlocks
> -------------------------------------------------------------------------
>
> Key: WW-3582
> URL: https://issues.apache.org/jira/browse/WW-3582
> Project: Struts 2
> Issue Type: Bug
> Components: Core Interceptors
> Affects Versions: 2.2.1
> Environment: Any (windows/Linux)
> Reporter: Lucy
>
> In class TokenInterceptor::doIntercept() function, it was using HttpSession lock when check tokens, it should release the lock before calling invocation.invoke().
> Because invocation.invoke() was called inside the httpsession lock, it will hold the lock until all the other intercetors listed after the token interceptor have been processed.
> (This triggered a dead lock in our software environment.)
> It should release the lock before it calls invocation.invoke();
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira