Hmm.... looks interesting :) There is issue opened for 2.3.x so could you post your comment there as well? I will try to investigate how to use Striped (maybe not directly) with Token interceptor
https://issues.apache.org/jira/browse/WW-4409 Regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ 2015-07-14 1:52 GMT+02:00 Ken McWilliams <ken.mcwilli...@gmail.com>: > Could a Striped lock not be used? If done, machinery would need to be > introduced which would quickly go beyond s2's prerogative. For instance an > interceptor could have this magic locking service injected and then say: > For User X, is token Y in use? Or for any user is token Y in use? But then > this brings up user management, which is outside of S2 and then security > quickly follows... > > So keeping is simple, S2 offers a reasonable solution but I think you could > develop a more narrow locking scheme that locks on the value of the token > stored in a Striped lock: > http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/util/concurrent/Striped.html > > > > > On Mon, Jul 13, 2015 at 5:26 AM, Lukasz Lenart <lukaszlen...@apache.org> > wrote: > >> 2015-07-10 20:37 GMT+02:00 rgm <str...@rgm.nu>: >> > Using Struts 2.3.20.1. >> > >> > We have a long-running token-protected (for CSRF) action that can take up >> > to about 30 seconds sometimes. When this action is running on behalf of >> > "Alice", the "List Users" page for all other people on the system such as >> > Bob and Charlie is hung, because the List Users page is trying to show >> > whether or not "Alice" is logged in by accessing properties of her HTTP >> > session. >> > >> > Is it necessary for TokenInterceptor to hold onto the session lock for >> the >> > entire action invocation? >> >> It is. It's the only way to be sure that we do not have duplicated >> submits for the same token >> >> >> Regards >> -- >> Łukasz >> + 48 606 323 122 http://www.lenart.org.pl/ >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: user-unsubscr...@struts.apache.org >> For additional commands, e-mail: user-h...@struts.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org