https://bz.apache.org/bugzilla/show_bug.cgi?id=69527
--- Comment #9 from Vigneshwaran N <palanivi...@gmail.com> --- (In reply to Remy Maucherat from comment #7) > Use of putIfAbsent in getResource should make sure your "Thread 2" uses the > same instance as "Thread 1". Then CachedResource.webResource cannot be null > unless Cache.getResources was called. And even if the two threads are not > using the same instance, evict will not reset webResource back to null or > anything so that is clearly not normal. The issue here is webResource is not yet initialized. The initialization of the webResource is done only when validate() for thread 1 is invoked, but before that thread 2 tried to delete. So, cachedContentLength() is called, webResouce is null in that case and stored value as 0 in cachedContentLength. That said, the issue described will be completely avoided with the changes proposed in the patch you mentioned. > However: > - 636017459a88befe1c5f1fd9d8f31ff2f13f74f6 looks very fishy since nothing > else is synced. Assuming I leave the sync, and since webResource being null > is basically an odd special case, I would think cachedContentLength should > not be set to 0 in that case (should simply return 0 instead, and I don't > understand why it would need to be done in the sync block), > - nextCheck being initialized to 0 is also meh. Should probably use the > value set in validateResource(s) instead. I understand that > System.currentTimeMillis() is rather expensive though. Yes, what you’ve mentioned aligns with my understanding as well. -- 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
