This is why no change to the original should be attempted unless a
backup file can be written *first*.
Lloyd
On Sep 21, 2007, at 6:06 PM, Kedar Mhaswade wrote:
> Lloyd,
>
> Byron's point is valid, and you should look at the scenario that
> ensues:
>
> 1- you attempt to write domain.xml whose correct size is 100 KB.
> Thus, it
> should be called correct only when it occupies 100 KB on the
> disk. The
> write operation (which is a long operation) is already
> coded to be a synchronized method call.
>
> 2- midway through flush, only 50KB of it is written. So, at the
> time the
> contents of domain.xml are invalid. This happened in Thread-1.
>
> 3- Thread-2 logs a large log statement and succeeds in flushing the
> buffers
> just in time. It so happens that now the disk is full.
>
> 4- Thread-1 gets scheduled and tries to write the remaining bytes.
> OOPS!
>
> Now what to do?
>
> Remember, disk is free to be written to, by all the threads.
>
> Again, this is not a super-saver technique, but it works although
> it has quirks.
>
> I am assuming this code change to be approved :)
>
> - Kedar
>
> Lloyd L Chambers wrote:
>> 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
>>>
>> ---------------------------------------------------------------------
>> 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
>