-
Bug
-
Resolution: Fixed
-
Low
-
2.10.2
-
None
A lot of entries of the following error message being logged in the Confluence log file:
2009-08-05 05:57:53,778 ERROR [TP-Processor125] [confluence.pages.thumbnail.DefaultThumbnailManager] getThumbnailsFolder Containing folders /sbclocal/confluence-data/xldn1324pap/confluence-2.10.2-home/thumbnails/147733919 for the attachment FXLM TB.jpeg could not be created
The thumbnail folders referenced in the error messages do exist on the server and contain the thumbnails.
As per Don's comment:
The code producing the error message is like this:
//... File thumbnailsFolder = new File(getThumbnailPath() + attachment.getContent().getId()); if (!thumbnailsFolder.exists()) { boolean result = thumbnailsFolder.mkdirs(); if (!result) log.error("Containing folders " + thumbnailsFolder.getAbsolutePath() + " for the attachment " + attachment.getFileName() + " could not be created"); }
I've noticed that in at least some cases of the error message there are multiple occurrences, for different files, in the same page. Note that the folder for the attachment is the folder for the page the attachment is on not necessarily the page being viewed.
My theory is that there's a race condition happening here and hence a spurious error message. I'll comment the code appropriately.
//... // Two threads get here at about the same time. File thumbnailsFolder = new File(getThumbnailPath() + attachment.getContent().getId()); // Both threads get here and the folder doesn't exist. if (!thumbnailsFolder.exists()) { // So both threads get here and the folder doesn't exist. So they both try to create the directory. boolean result = thumbnailsFolder.mkdirs(); // One thread creates the folder successfully, so we never hear about that one. // The other thread hasn't created the folder though. It was already created before it tried. So it logs an error. if (!result) log.error("Containing folders " + thumbnailsFolder.getAbsolutePath() + " for the attachment " + attachment.getFileName() + " could not be created"); }
The spurious error message could be dropped by modifying the code to :
//... File thumbnailsFolder = new File(getThumbnailPath() + attachment.getContent().getId()); if (!thumbnailsFolder.exists()) { boolean result = thumbnailsFolder.mkdirs(); if (!result && !thumbnailsFolder.exists()) log.error("Containing folders " + thumbnailsFolder.getAbsolutePath() + " for the attachment " + attachment.getFileName() + " could not be created"); }
Or it could just be dropped. Note that this error would not be given if the confluence user had no filesystem permission. A SecurityException would be thrown instead.
- causes
-
ADM-30917 Failed to load
[CONFSERVER-16765] Spurious error message in the logs when generating thumbnails
we're running on v5.1.4 and seeing lot's of the same error message in our logs. . . I'm reading through this bug but is still unsure what my options are to eliminate the beside upgrading to v5.3.1 or later. Can someone advise? Thanks.
Don's assessment that it was a race condition was spot on.
Easiest way to reproduce this was to insert 2 or more resized images into a page, delete the Confluence thumbnails folder, and refresh the page. On localhost (where network latency isn't a concern) this reproduced the issue pretty much 100% for me. Just to be sure, I also put a breakpoint on the thumbnailsFolder.exists() check and set the breakpoint to suspend the thread only. I then let one thread through at a time (human-powered mutex. it's web scale) and confirmed that the error wouldn't occur.
Slapping the extra thumbnailsFolder.exists() check after the mkdirs() call fixes the issue.
Michael Rieger
added a comment - We are still experiencing this behaviour with Confluence 3.5.13. We are also experiencing that some cache files are not removed properly from tomcat6 cache folder (/var/cache/tomcat6/temp) in our environment. Those files are named image-io* and they all have a size of 4096 bytes.
Is there any relations between those two events?
Michael Rieger
added a comment - We are still experiencing this behaviour with Confluence 3.5.13. We are also experiencing that some cache files are not removed properly from tomcat6 cache folder (/var/cache/tomcat6/temp) in our environment. Those files are named image-io* and they all have a size of 4096 bytes.
Is there any relations between those two events? 
Karola Schaeuble
added a comment - Just wanted to mention that this error can indeed point to an issue where thumbnails cannot be created any more.
We just discovered this some weeks ago. When I looked at the thumbnail folder there was this ominious number of 31,999 folders in it. That way we found out that on our Linux system a folder cannot have more that this amount of subfolders.
Now from time to time we delete the contents of the thumbnail folder.
Karola Schaeuble
added a comment - Just wanted to mention that this error can indeed point to an issue where thumbnails cannot be created any more.
We just discovered this some weeks ago. When I looked at the thumbnail folder there was this ominious number of 31,999 folders in it. That way we found out that on our Linux system a folder cannot have more that this amount of subfolders.
Now from time to time we delete the contents of the thumbnail folder. 
Chad Frew
added a comment - needed for Confluence 3.5.13 as well 
Ernest Denys
added a comment - need fix for Confluence 3.2.1_01 A patched DefaultThumbnailManager.class has been attached to the ticket, which should stop logging these spurious errors to the logs.
The fix has an additional check in place to ensure the existence of the thumbnails folder, prior to reporting the error messages.
To apply the patch, please stop Confluence and copy the attached class file to your <Confluence-Installation-Folder>/confluence/WEB-INF/classes/com/atlassian/confluence/pages/thumbnail folder. If this directory structure does not exist already, please create it. More details on applying patches is here.
Then restart and check if the problem persists.
knguyen This fix will only be applied to 5.3.1 onwards. Alternatively you can squelch this message by changing the log level for com.atlassian.confluence.pages.thumbnail.DefaultThumbnailManager to FATAL, rather than ERROR.