dev@glassfish.java.net

Re: hundreds of warnings during QL on GF 3.2 workspace

From: Bill Shannon <bill.shannon_at_oracle.com>
Date: Thu, 16 Jun 2011 13:55:10 -0700

These operations are almost never in performance critical parts of the
server. If it proves to be a performance problem, you could probably
do the mkdir and only if it fails try to figure out why it failed
(e.g., because the directory already exists), or try to create files
in the directory and only if that fails try to create the directory.

Marina Vatkina wrote on 06/15/2011 07:44 PM:
> Bill,
>
> Would the performance team complain because now with the security manager on,
> we'll do 2 permission checks instead of one?
>
> thanks,
> -marina
>
> Bill Shannon wrote:
>> I addressed this issue a few months ago; see attached.
>>
>> Byron Nevins wrote on 06/12/11 12:01 PM:
>>> See SVN 47389
>>>
>>> I've seen this before. Another REAL bug caused by trying to fix a low-level
>>> FindBugs "bug". FindBugs was complaining that the return value of mkdirs()
>>> was being ignored. I added a utility method for dealing
>>> with this exact problem. Please read and keep it in mind if you get this
>>> FindBugs issue.
>>>
>>> Here is the code from that checkin:
>>> if (!resourceFile.getParentFile().mkdirs()) {
>>> errorHere();
>>>
>>> Hmmm. What happens if the directory already exists?
>>>
>>> This is the easiest fix:
>>>
>>> *import static com.sun.enterprise.util.io.FileUtils.mkdirsMaybe;
>>>
>>> if (!mkdirsMaybe(resourceFile.getParentFile())) {
>>> errorHere();
>>> *
>>> ==========
>>> reference:
>>>
>>> /**
>>> * Wrapper for File.mkdirs
>>> * This version will return true if the directory exists when the method returns.
>>> * Unlike File.mkdirs which returns false if the directory already exists.
>>> * @param f The file pointing to the directory to be created
>>> * @return
>>> */
>>> public static boolean mkdirsMaybe(File f) {
>>> return f != null && (f.isDirectory() || f.mkdirs());
>>> }
>>>
>>>
>>> On 6/11/2011 1:37 AM, Koper, Dies wrote:
>>>> Hundreds of WEB0360 and WEB0361 messages are flooding my server.log when
>>>> I run QL on the 3.2 workspace.
>>>> Hudson continuous build has them too. Is this a known issue?
>>>>
>>>> Example of message in my server.log:
>>>>
>>>> [#|2011-06-11T16:30:36.020+1000|WARNING|glassfish3.2|javax.enterprise.sy
>>>> stem.container.web.org.glassfish.web.loader|_ThreadID=26;_ThreadName=Thr
>>>> ead-1;|WEB0360: Unable to create
>>>> D:\sources\OSS\GF\V3\v3\distributions\glassfish\target\stage\glassfish3\
>>>> glassfish\domains\domain1\generated\jsp\__admingui\loader_28513476\com\s
>>>> un\webui\jsf\suntheme\images\commontaskssection|#]
>>>>
>>>> Example from Hudson's server.log:
>>>>
>>>> [#|2011-06-11T00:22:17.132-0700|WARNING|glassfish3.2|javax.enterprise.sy
>>>> stem.container.web.org.glassfish.web.loader|_ThreadID=25;_ThreadName=Thr
>>>> ead-1;|WEB0360: Unable to create
>>>> /export/home1/java_re/BUILD_AREA/workspace/gf-trunk-build-continuous/gfv
>>>> 3-gp/glassfish3/glassfish/domains/domain1/generated/jsp/__admingui/loade
>>>> r_15638245/META-INF/resources/resources/jmaki/blockList|#]
>>>>
>>>> http://hudson.glassfish.org/job/gf-trunk-build-continuous/lastSuccessful
>>>> Build/artifact/bundles/server-gp.log
>>>>
>>>> Thanks,
>>>> Dies
>>>>
>>>
>>> --
>>> Oracle <http://www.oracle.com>
>>> Byron Nevins | Principal MTS
>>> Phone: +1 6503958992 <tel:+1%206503958992>
>>>
>>> Green Oracle <http://www.oracle.com/commitment> Oracle is committed to
>>> developing practices and products that help protect the environment
>>
>>
>> ------------------------------------------------------------------------
>>
>> Subject:
>> FindBugs errors - ignoring return value from filesystem operations
>> From:
>> Bill Shannon <bill.shannon_at_oracle.com>
>> Date:
>> Mon, 18 Apr 2011 15:07:30 -0700
>> To:
>> dev_at_glassfish.java.net
>>
>> To:
>> dev_at_glassfish.java.net
>>
>>
>> FindBugs complains if you ignore the error return value from a filesystem
>> operation, e.g.,
>>
>> f.mkdirs();
>>
>> Be careful when fixing these errors. In many cases it's ok if the operation
>> fails, e.g., if the directory already exists. The fix for the above is NOT
>>
>> if (!f.mkdirs())
>> error(); // WRONG
>>
>> A better fix is
>>
>> if (!f.isDirectory() && !f.mkdirs())
>> error();
>>
>>
>>
>> Also, be careful with filesystem operations that might behave differently
>> on Windows. I recently got bit by some permission changing code. When I
>> fixed it to fail if the permissions weren't changed, it failed on Windows.
>> The permission changing method as currently implemented always fails on
>> Windows. Ouch. In this case I chose to always ignore the return value.