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)