admin@glassfish.java.net

Re: Code Review: Bug fix for: 6505045 ...

From: Lloyd L Chambers <Lloyd.Chambers_at_Sun.COM>
Date: Fri, 21 Sep 2007 14:31:30 -0700

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
>