[jira] [Created] (CAMEL-24269) DefaultStreamCachingStrategy.updateSpool calls lock.lock() in finally instead of lock.unlock()

["Guillaume Nodet (Jira)" <ji...@apache.org>]

Guillaume Nodet created CAMEL-24269:
---------------------------------------

             Summary: DefaultStreamCachingStrategy.updateSpool calls lock.lock() in finally instead of lock.unlock()
                 Key: CAMEL-24269
                 URL: https://issues.apache.org/jira/browse/CAMEL-24269
             Project: Camel
          Issue Type: Bug
          Components: camel-core
            Reporter: Guillaume Nodet


Found by oscerd during review of PR #24985 (CAMEL-24227). This is a *live bug* in existing code, not introduced by the PR.

h3. Problem

In {{DefaultStreamCachingStrategy.UtilizationStatistics.updateSpool()}}, the {{finally}} block calls {{lock.lock()}} instead of {{lock.unlock()}}:

{code:java}
void updateSpool(long size) {
    lock.lock();
    try {
        spoolAverageSize.set(spoolSize.addAndGet(size) / spoolCounter.incrementAndGet());
    } finally {
        lock.lock();     // BUG: should be lock.unlock()
    }
}
{code}

{{updateMemory()}} directly above it correctly calls {{lock.unlock()}}.

h3. Impact

Because {{lock}} is a {{ReentrantLock}}, the calling thread does not self-deadlock — it just leaves the hold count at 2 permanently. However, any *other* thread entering {{updateSpool()}} will block forever. This is reachable whenever stream-caching statistics are enabled and spooling to disk occurs on multiple threads.

h3. Suggested fix

Change {{lock.lock()}} to {{lock.unlock()}} in the {{finally}} block.

h3. References

* PR [#24985|https://github.com/apache/camel/pull/24985] review comment by oscerd
* {{core/camel-base-engine/src/main/java/org/apache/camel/impl/engine/DefaultStreamCachingStrategy.java}}



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