https://bz.apache.org/bugzilla/show_bug.cgi?id=69527
--- Comment #7 from Remy Maucherat <r...@apache.org> --- (In reply to Vigneshwaran N from comment #5) > (In reply to Remy Maucherat from comment #2) > > This reads like an AI generated report ... > > Hi Remy, the above content that you are mentioned as AI generated report was > added as part of explaining how the issue actually occured. Thanks. Ok, although the AI claim was bad, after having a real look at it I still don't understand. 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. 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. -- 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
