https://bz.apache.org/bugzilla/show_bug.cgi?id=69527
--- Comment #1 from Vigneshwaran N <palanivi...@gmail.com> ---
A rare race condition occurs during cache operations as follows:
Thread 1:
1. Fetches a new resource and inserts it into the map.
2. Begins initialisation (contentLength, nextCheck, and webResource) but hasn’t
completed.
3. During this phase: contentLength and webResource are still null and
nextCheck defaults to 0.
Thread 2:
1. Fetches a new resource and inserts it into the map.
2. Begins initialisation (contentLength, nextCheck, and webResource) and
completed.
3. Triggers eviction due to cache size exceeding the limit.
4. Removes the cache entry, using resource.getNextCheck(), inserted by Thread 1
before its initialisation completes, because nextCheck is not yet initialised
by thread 1.
5. During eviction, the contentLength is checked using the following logic
(since content length is not yet initialised by thread 1, it is going to
initialise now)
code:
if (cachedContentLength == null) {
synchronized (cachedContentLengthLock) {
if (cachedContentLength == null) {
if (webResource == null) {
cachedContentLength = Long.valueOf(0);
} else {
cachedContentLength =
Long.valueOf(webResource.getContentLength());
}
}
}
}
return cachedContentLength.longValue();
6. Since webResource is uninitialised, contentLength for the thread 1 resource
is set to 0.
7. When Thread 1 resumes, the contentLength remains 0, preventing the file
content from being written to the output stream.
Reference: Cache.java, CachedResource.java, DefaultServlet.java
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
