I don't know if this is something new. I only have builds saved back to
yesterday.
Looking at DomainXmlPersistence.java, I see that if the rename fails,
the save method merely logs the error and returns. Which means that the
temporary domain.xml is left in the config directory, and the domain.xml
is not updated. Even though the save() method is declared to throw
IOException, it doesn't throw the exception in that case. From a casual
look, it seems as though the save() should throw an exception in any
case that the domain.xml isn't written with the write content.
The delete of the domain.xml.bak succeeds. Since the rename itself
fails, it appears that something has the old domain.xml open at the time
that save() is called, at least is some cases. Maybe a multithreading
issue?
Tom
On 6/17/2010 10:59 AM, Jerome Dochez wrote:
> On 6/17/10 8:52 AM, Tom Mueller wrote:
>> What is the significance of the following log message showing up in
>> server.log?
>> [#|2010-06-17T08:34:27.953-0700|SEVERE|glassfish3.1|null|_ThreadID=30;_ThreadName=Thread-1;|Could not rename C:\files\hudson\workspace\admin-devtests-v3.1\glassfishv3\glassfish\domains\domain1\config\domain.xml to C:\files\hudson\workspace\admin-devtests-v3.1\glassfishv3\glassfish\domains\domain1\config\domain.xml.bak|#]
>>
>> This is showing up on our admin devtests run on Windows (21 times).
>> We also have 15 test failures that appear to be related to not being
>> able to make changes to the domain.xml file (for example, a missing
>> <server> element when trying to start an instance) and a failed xpath
>> test that is checking the domain.xml file to see if it really got
>> changed.
>>
>> The tests pass when run manually on my Windows system (but this
>> message only shows up 3 times rather than 21 times).
>>
>> Is it possible that something is keeping a file descriptor open to
>> the domain.xml file, which causes Windows to have trouble deleting
>> the backup copy after it is renamed to domain.xml.bak?
> yes it's certainly one possibility.
>
> is it something new ?
>>
>> Tom
>>
>>
>>
>