Then we should fail, and not update or change domain.xml under those
conditions.
There is nothing wrong with failing when the disk is full. I don't
think it does anyone a favor to attempt that.
Lloyd
On Sep 21, 2007, at 5:02 PM, Byron Nevins wrote:
> That won't work because step 1 will fail (no disk space)
>
>
> Lloyd L Chambers wrote:
>
>> I see no need to reserve disk space. Why can't we use the same
>> technique I used for PasswordAdapter eg a temporary file? The
>> only foolproof technique I see is:
>>
>> 1. Write the new version to a temp file.
>> 2. Rename the old copy to something
>> 3. Rename the temp file to domain.xml.
>>
>> Worse case: no domain.xml, but the old version remains intact.
>>
>> This is the time-proven approach. On Mac, there is even an
>> atomic call to do 2 and 3 together.
>>
>> Lloyd
>>
>> On Sep 21, 2007, at 1:57 PM, Kedar Mhaswade wrote:
>>
>>>
>>>
>>> Mark A. Basler wrote:
>>>
>>>> Hi Kedar,
>>>> For the people who don't utilize this mechanism, shouldn't we
>>>> also add a check of the disk space before domain.xml is
>>>> flushed? If there isn't enough disk space to write domain.xml
>>>> out, then don't allow an update.
>>>
>>>
>>> That will affect every write operation, which, I am not sure is
>>> desirable.
>>> If this is a reasonable overhead that is required to have even when
>>> we have ample disk space, we can do it.
>>>
>>> Also, do you know an API in Java that tells us if one has disk
>>> space of a given
>>> size?
>>>
>>> Another problem is, even if such API returns "true", by the time
>>> actual flush
>>> occurs, the disk might be occupied, as you have no control over
>>> what threads
>>> use the disk for what purposes and which write succeeds.
>>>
>>> So, a "reactionary" approach where we attempt to protect the
>>> domain.xml only
>>> when we fail to do write it sounds reasonable.
>>>
>>> Again, this technique does have flaws and it is not fool-proof.
>>> But it is better
>>> than nothing, given the constraints. The only other technique
>>> that can help is
>>> using RandomAccessFile, but I have to explore it.
>>>
>>> Please let me know if this needs to be ported to UR1 and if yes,
>>> kindly add
>>> the hook that allows me do that.
>>>
>>> Thanks,
>>> Kedar
>>>
>>>> This way you always have the current running domain.xml on disk.
>>>> My 2 cents...
>>>> Thanks - Mark
>>>> Kedar Mhaswade wrote:
>>>>
>>>>> Finally, I have been able to fix this problem (reasonably).
>>>>>
>>>>> All about it can be found at:
>>>>> http://wiki.glassfish.java.net/attach/GlassFishAdminReferences/
>>>>> 6505045.html
>>>>>
>>>>> Please go through the background and code changes if you have
>>>>> time and let me
>>>>> know if you have any comments, by tomorrow 12.00 noon, pacific.
>>>>>
>>>>> I am planning to check this in then, on GlassFish trunk.
>>>>>
>>>>> Mark Basler: I leave it up to you to approve the fix for 9.1
>>>>> UR1. If you do
>>>>> want to do that, let me know and I can port the changes there.
>>>>>
>>>>> I have run the tests on my 128M Zip-drive on Mac OS X by
>>>>> observing domain.xml go
>>>>> to zero-bytes and domain.xml.protect coming to rescue, making
>>>>> every attempt
>>>>> to persist the domain.xml.
>>>>>
>>>>> Regards,
>>>>> Kedar
>>>>
>>>> -------------------------------------------------------------------
>>>> --
>>>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>>>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>>>
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>>
>
> --
> Byron Nevins Work 408-276-4089, Home 650-359-1290, Cell
> 650-784-4123 - Sun Microsystems, Inc.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>