Taking action invocation out of synchronized block on TokenSessionStoreInterceptor to reduce contention on the session id

[lunalisk]

We recently ran into an issue with the TokenSessionStoreInterceptor due to it's synchronized block holding until the action invocation returns.

If a different action requires to check something related with the same session key, then this action must wait until the Interceptor releases the lock.

We believe the invocation should not be part of the synchronized block

[JCgH4164838Gh792C124B5]

Hello @lunalisk .

It might not be safe to move the invocation outside of the synchronized block within the interceptor. The change in this PR appears to allow for potential concurrent/duplicate submits from the form with the valid token component.

The API docs say the token-mechanism ensures one-request-per-token, but someone from the Apache Struts Team will have to evaluate this PR and comment further.

A more complex solution separating the session-related synchronization and the token-related synchronization might be needed to achieve your desired result. We'll see what they say. :)

[coveralls]

Coverage increased (+0.0009%) to 48.396% when pulling 18dc30b73c726e2a47e32fe5afc3e0c00b933c95 on lunalisk:reduce-contention-tokenSessionStoreInterceptor into ce4f192676aeb433f8aa020977b62cda0fedf27b on apache:master.

[yasserzamani]

These are historical backgrounds to study for who would cracking at this PR:

• The closed issue WW-3582 - Token Interceptor is holding HttpSession lock which can trigger deadlocks
• The closed issue WW-3865 - TokenSesion double submit sends a blank page to ie and stacktrace on server
• The discussion TokenInterceptor locking HTTP session for entire action invocation?
• The open issue WW-4409 - Modify the TokenInterceptor not to lock the session object while handling and invalid token
• The commit Solves WW-3582 - moves in call to handleValidToken() method outside of lock on session object
• The commit WW-3865 rollbacks changes to TokenInterceptor applied with WW-3582 and adds new method handleToken() to allow in different way lock session object