Kedar,
Thanks, that information really clarifies the issue.
I know that on some O/S's a file can be renamed even if it's open.
But I'm hearing you say that some O/S's cannot do that, and we cannot
(easily) fix our code to close the file). So I can't offer a fix to
an impossibility. It sounds like the real problem here is that we
are not able to close and reopen domain.xml (and thus make it
possible to use a temporary file). Fixing that would be a good idea
IMO. I don't understand how I can "vi" the file if that's the case--
I thought doing so was a supported feature.
What I'm not understanding is why we can't do essentially the same
thing: create a 'domain.xml.prev', do all the funny business, then
once the revised domain.xml is flushed to disk delete
'domain.xml.prev' (or just leave it would be OK IMO).
===> Am I just not understanding your proposal in lieu of the above?
Personally my strong preference would be for versioned
configuration. There are lots of things besides disk errors that can
result in problems. But I realize you are not trying to solve that
problem.
Lloyd
On Sep 21, 2007, at 4:23 PM, Kedar Mhaswade wrote:
> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>