You can create a File Manager class that does the I/O for you.
When DAS comes up this class carves out a 1 MB Random Access File and
keeps it open until shutdown.
Every time a copy of domain.xml is needed -- it writes it into this file
and flushes.
Another possible solution:
Have the user create a tiny, say 10 MB partition. Remove the config
directory and replace it with a link to that partition. Now config has
its own partition and is unaffected by the battle for disk space raging
on elsewhere. This WILL work on all platforms but it requires some
serious planning from the user. It is simple and requires no code
changes though.
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
>
--
Byron Nevins Work 408-276-4089, Home 650-359-1290, Cell 650-784-4123 - Sun Microsystems, Inc.