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
>