[ 
https://issues.apache.org/jira/browse/WW-3576?focusedWorklogId=1004655&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1004655
 ]

ASF GitHub Bot logged work on WW-3576:
--------------------------------------

                Author: ASF GitHub Bot
            Created on: 11/Feb/26 17:39
            Start Date: 11/Feb/26 17:39
    Worklog Time Spent: 10m 
      Work Description: lukaszlenart opened a new pull request, #1577:
URL: https://github.com/apache/struts/pull/1577

   ## Summary
   - Fix race condition in `SessionMap` between null checks and synchronized 
blocks
   - Apply volatile + local variable capture + double-check locking pattern
   - Add comprehensive concurrent test cases
   
   ## Problem
   The original `SessionMap` had a thread-safety issue where a context switch 
between the null check and the synchronized block could cause 
`NullPointerException`:
   
   ```java
   // Before: Race condition exists
   if (session == null) { return; }  // Thread A checks: session is NOT null
   // ⚠️ Thread B invalidates session here, sets session = null
   synchronized (session.getId().intern()) {  // Thread A: NPE!
   ```
   
   ## Solution
   Apply the volatile + local capture + double-check pattern (already used in 
`Scope.java`):
   
   ```java
   // After: Thread-safe
   HttpSession localSession = session;  // Capture reference
   if (localSession == null) { return; }
   synchronized (localSession.getId().intern()) {
       if (session == null) { return; }  // Double-check
       // ... safe to use session
   }
   ```
   
   ## Changes
   - `SessionMap.java`: Add `volatile` to session field, apply pattern to all 
methods
   - `SessionMapConcurrencyTest.java`: 8 new concurrent tests verifying 
thread-safety
   
   ## Test plan
   - [x] All existing `SessionMapTest` tests pass (no regression)
   - [x] New `SessionMapConcurrencyTest` concurrent tests pass
   - [ ] Manual verification under load
   
   Fixes [WW-3576](https://issues.apache.org/jira/browse/WW-3576)
   
   🤖 Generated with [Claude Code](https://claude.com/claude-code)




Issue Time Tracking
-------------------

            Worklog Id:     (was: 1004655)
    Remaining Estimate: 0h
            Time Spent: 10m

> SessionMap is not thread-safe
> -----------------------------
>
>                 Key: WW-3576
>                 URL: https://issues.apache.org/jira/browse/WW-3576
>             Project: Struts 2
>          Issue Type: Bug
>          Components: Other
>    Affects Versions: 2.2.1
>            Reporter: Sylvain Veyrié
>            Assignee: Lukasz Lenart
>            Priority: Major
>             Fix For: 7.2.0
>
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> Searching for a bug after some stress test (Exception on "getAttribute": 
> already invalidated session), I reviewed SessionMap.java.
> Following WW-239, SessionMap has been made thread-safe.
> All methods are like this :
> public void doSomething() {
>       if (session == null) {
>               return;
>       }
>       
>       synchronized (session) {
>               session.doSometing();
>       }
> }
> For example:
> public void invalidate() {
>       if (session == null) {
>               return;
>       }
>       
>       synchronized (session) {
>               session.invalidate();
>               session = null;
>               entries = null;
>       }
> } 
> IMHO this is not thread-safe. With the example of invalidate(), if there is a 
> context switch just before the synchronized, the nullity is no more checked. 
> If another invalidate() is called at least a NPE can be thrown. There are 
> probably other side-effects like my exception problem.
> As now Struts 2 only supports Java 5+, there is two ways to fix it :
> * use a double-check-locking (DCL) and set session "volatile" (easy way)
> * use java.util.concurrent instead of synchronized keyword
> If you agree and choose one of those fixes, I can provide a patch.
> For the moment, I don't know if my bug is resolved if we directly use javax 
> session, without this wrapper.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to