struts-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rob Baily (JIRA)" <>
Subject [jira] [Commented] (WW-4409) Modify the TokenInterceptor not to lock the session object while handling and invalid token
Date Wed, 01 Oct 2014 12:00:37 GMT


Rob Baily commented on WW-4409:

Hmm, interesting discussion in WW-3865.  I don't understand why the actual error was coming
in that case.  You mentioned error handling which seems plausible but did anyone get to the
root of it?  It does seem though that if the invocation is in the synchronized session block
that it means a user can really only ever have 1 thread truly active but other clicks will
end up taking a thread and blocking until previous requests are done.  That would be like
handling all requests for a user serially which I guess could make sense but seems like it
might be a big issue with system stability since you could have an undefined number of threads
waiting for the object lock based on whatever the user/browser does.  Might be especially
problematic with AJAX calls where multiple things could be happening at once. 

> Modify the TokenInterceptor not to lock the session object while handling and invalid
> -------------------------------------------------------------------------------------------
>                 Key: WW-4409
>                 URL:
>             Project: Struts 2
>          Issue Type: Improvement
>          Components: Core Interceptors
>    Affects Versions: 2.3.18
>            Reporter: Rob Baily
>            Priority: Minor
>             Fix For: 2.3.x
>         Attachments: tokeninterceptor.patch
> Similar to WW-3582.  Currently in the TokenInterceptor class in the handleToken method
there is a lock on the session object and the handleInvalidToken method is called within that
block. In our environment we overrode the handleInvalidToken and it turned out that when this
method ran long that any other requests for the user were immediately blocked and the threads
were locked up and unable process any further requests.  
> I would like to see if we can change the handleToken method not to lock the session when
calling the method to handle an invalid token.  I realize that ours may not be an ideal implementation
and the base implementation should be fast but it does seem like the time an object is locked
should be minimized.  I don't know if there is a reason that the invalid method would need
to be in that block.
> I am including a patch for the change on this.  It does not affect the tests and I do
not know if there is a good way to add a test that would check the locking.

This message was sent by Atlassian JIRA

View raw message