Hi Lloyd,
I appreciate your perseverance.
Can you tell me a *reliable* way of doing atomic move of domain.xml.backup
to domain.xml, on all platforms?
Domain.xml's file handle is held by app server process *all the time*.
So, renaming does not work, unless there is help from native code, which
we don't have.
The solution proposed is to take care of (normally) rare situation that
we have here. I wanted to reduce the impact and did not want to suggest
something different and unreliable. The user wants *some* protection of
domain.xml and is willing to do it consciously (meaning is willing to
define system properties for the protection).
Do you have a solution that works given the situation.
Thanks,
Kedar
Lloyd L Chambers wrote:
> Kedar,
>
> The only reliable way I know of to do this with minimal risk is to use a
> temporary file.
>
> Why use an alternative with the complexity of two system properties? Is
> that approach superior in some way? If I'm missing something here,
> please explain.
>
> You asked for a review. I vote "no" unless you can explain why your
> solution is as good or better than the alternative of using a temporary
> file.
>
> (And if in fact a decision was made to risk data loss in lieu of using a
> temporary file, then we should reverse that malfeasance ASAP).
>
> Lloyd
>
> On Sep 21, 2007, at 2:56 PM, Kedar Mhaswade wrote:
>
>> We got rid of backup file a while ago.
>>
>> - Kedar
>>
>> 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
>>
>> ---------------------------------------------------------------------
>> 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
>