[omniORB] Starting omninames with -start option

[Christian Laroque]

Thanks for your input.

I would like to underline the following points:

1/ When the option -start is used, omninames checks if the log file is 
present. If yes, then omninames issues an error and exit.
I don't really understand why.
If the user wants to start omninames with the option -start, he does not 
want to keep the contexts possibly created before, and omninames should 
then simply remove the log file (if any) and create a new one.

2/ When the option -start is not used, omninames checks if the log file 
is present. If not, then omninames issues an error and exit.
Here also, omninames could simply makes the assumption that if the log 
file is not present, then it should simply be created (as if the option 
-start was used) and no context recovered, and a warning could possibly 
be issued.


I need to install omninames on several windows 2003 machines in an 
automatic way.
I want to start omninames as a windows service using srvany.
The service is started when the machine is booted.
This means that I always want to start omninames with the option -start 
(I don't need to recover any context after reboot).
But if I start omninames with the option -start and the log file already 
exists, omninames refuses to start ...

Regards,

Christian



Visscher, Bruce wrote:
>>Why not simply overwriting the log file if the log file is already 
> 
> 
>>present? (that is however what is done when the log file is 
> 
> 
>>opened - it 
> 
> 
>>is always opened with the TRUNC option !)
> 
> 
> 
> 
> No.  It reads the log file into memory if it exists and you don't use
> 
> "-start".  Then it appends to the end everytime there is a transaction
> 
> that modifies the naming tree.  Periodically, it checkpoints (renames
> 
> ..log -> .bak and creates a new .log, etc.).  That doesn't sound much
> 
> like overwriting.  I'm not sure where the TRUNC option comes into play.
> 
> I'm guessing it is only used during check pointing to create a new
> 
> *.log file from scratch (which would actually be the *.chk (sp?) file
> 
> which eventually is renamed to *.log).
> 
> 
> 
> 
> 
>>This would allow starting the naming service with the option 
> 
> 
>>-start in 
> 
> 
>>all cases (first time or not).
> 
> 
> 
> 
>>Note: at the moment, I am starting the naming service via a 
> 
> 
>>batch file 
> 
> 
>>which first delete the log file and then always start the 
> 
> 
>>naming service 
> 
> 
>>with the -start option.
> 
> 
>>This works fine, but I would prefer to use a windows service.
> 
> 
> 
> 
> You can certainly start it as a windows service.  Just take the
> 
> "-start" option off.  You really don't want to do that unless
> 
> there's a problem.  If you do you will loose all of your
> 
> contexts.  The whole point of maintaining the *.log and *.bak
> 
> files is that you want these contexts to "persist" between
> 
> incarnations of the server.
> 
> 
> 
> It might be nice not to have to run omniNames with -start the first
> 
> time (i.e., have a -start-if-needed or something). But then again,
> 
> I kind of like having the sanity check that the *.log file should
> 
> always exist under normal operation.
> 
> 
> 
> Bruce
> 
> 
> 
> -----------------------------------------
> 
> CONFIDENTIALITY NOTE:  This e-mail message, including any  attachment(s),
> 
> contains information that may be confidential,  protected by the attorney-
> 
> client or other legal privileges, and/or  proprietary non-public
> 
> information.  If you are not an intended  recipient of this message or an
> 
> authorized assistant to an intended  recipient, please notify the sender by
> 
> replying to this message and  then delete it from your system.  Use,
> 
> dissemination, distribution,  or reproduction of this message and/or any of
> 
> its attachments (if  any) by unintended recipients is not authorized and
> 
> may be unlawful.
> 
> 
> 
> _______________________________________________
> omniORB-list mailing list
> omniORB-list at omniorb-support.com
> http://www.omniorb-support.com/mailman/listinfo/omniorb-list
> 
> 
> 

-- 
----------------------------------------------------
Christian Laroque
Darmstadt, Germany
----------------------------------------------------
E-Mail: Christian.Laroque at vega.de