geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <d...@iq80.com>
Subject Re: [LONG] Re: Startup Scripts - foreground and background
Date Tue, 22 Nov 2005 17:33:32 GMT
+1 to John's proposal

I think it would be nice to have "each configuration together with   
its startup time, one configuration per line" noted in the log  
geronimo.out file if possible.

-dain

On Nov 21, 2005, at 2:41 AM, David Jencks wrote:

> This all seems quite reasonable to me.
>
> I will note that I do not like the current output of the progress  
> bar startup monitor.  I would prefer that it state how many  
> configurations will be started, and then list each configuration  
> together with  its startup time, one configuration per line.  I  
> think this would work fine both foreground and background.
>
> Thanks,
> david jencks
>
> On Nov 20, 2005, at 10:24 PM, John Sisson wrote:
>
>> I am reviewing Dave's startup patches ( GERONIMO-1166 ) and have a  
>> couple of ideas for comment.
>> [1]. I propose we provide a geronimo.sh file that is modelled on  
>> Tomcat's catalina.sh file ( http://svn.apache.org/repos/asf/tomcat/ 
>> container/tc5.5.x/catalina/src/bin/ ), as a large number of users  
>> would already be familiar with its syntax and environment variable  
>> naming conventions and it would be good if we had some consistency  
>> across Apache products.
>> geronimo.sh would support options such as:
>>
>> jpda start    - Start Geronimo under JPDA debugger
>> run             - Start Geronimo in the current window (same as  
>> Dave's proposed -foreground)
>> start           - Start Geronimo in a separate window (same as  
>> Dave's proposed -background)
>>
>> Also make startup.sh consistent with Tomcat's startup.sh and move  
>> the redirection logic and foreground/background logic to geronimo.sh.
>>
>> If we are consistent with Tomcat it means that if an option isn't  
>> passed to geronimo.sh (e.g. start) then usage information will be  
>> printed to the terminal. If users invoke startup.sh, it in turn  
>> invokes geronimo.sh with the start option (consistent with Tomcat).
>>
>> I am happy to make these changes if I have no objections.
>>
>> [2]. File name used for redirected output when using startup.sh - 
>> background
>>
>>    Currently the patch redirects output to a startupProgress.log  
>> file. I am thinking the file should be renamed to geronimo.out  
>> (consistent with Tomcat's catalina.out) since it may contain more  
>> than startup messages over the life of the process.
>>
>> [3]. Improving format of progress messages in redirected output  
>> when using startup.sh -background
>>
>> For the startup output to not appear garbled in the file that  
>> output is redirected to (due to the carriage returns generated by  
>> ProgressBarStartupMonitor) we probably need a modified version of  
>> ProgressBarStartupMonitor that outputs a line when a configuration  
>> is starting/started (without the update thread that updates the  
>> line approx every 500ms that the ProgressBarStartupMonitor has).
>>
>> I initially thought we could use the -quiet option, but that  
>> results in no progress being output and it would be nice to be  
>> able to look at the geronimo.out file to see what is happening  
>> rather than having to look through possibly heaps of messages in  
>> the log4j log files.
>>
>> It would be also be helpful if the output redirected to the  
>> geronimo.out file also has the summary of listening ports and  
>> started application modules & web applications.
>> [4]. Proposed new Geronimo startup options:
>>
>> -interactive (default)
>>        Specify this when output is sent to an interactive terminal/ 
>> console.  During startup (if -quiet is not specified) the progress  
>> message for a configuration will be updated approx every 500ms  
>> (using carriage returns to move the cursor on the display to the  
>> beginning of the current line to enable the progress message to be  
>> updated.  Mutually exclusive with the -noninteractive parameter.
>>
>> -noninteractive
>>        Specify this when output is being redirected to a file or  
>> printer.  During startup, a new message (each message on a new  
>> line) will be issued during different stages startup. Mutually  
>> exclusive with the -interactive parameter.
>>
>> The above option could also be stored in case in the future we  
>> want to enhance shutdown processing to show some progress messages.
>>
>> The startup.sh script would pass -noninteractive if the process is  
>> started in the background.
>>
>> [5]. New method on StartupMonitor interface
>>
>> A new method setInteractive(boolean b) could be added to the  
>> StartupMonitor interface and invoked by the Daemon class before  
>> the systemStarted(kernel) method is called.
>>
>> Comments?
>>
>> Thanks,
>>
>> John
>>
>> Dave Colasurdo wrote:
>>
>>> Have attached the patches for both unix (.sh) and windows (.bat)  
>>> environments to GERONIMO-1166. Please test them out..
>>>
>>> Thanks
>>> -Dave-
>>>
>>>
>>> Dave Colasurdo wrote:
>>>
>>>> I've opened a JIRA for this issue and created a patch for the  
>>>> windows platform.  Still investigating the unix environment...
>>>>
>>>>  http://issues.apache.org/jira/browse/GERONIMO-1166
>>>>
>>>>
>>>>
>>>> John Sisson wrote:
>>>>
>>>>> Hi Dave,
>>>>>
>>>>> I don't think I had any objections to making the startup  
>>>>> scripts follow Tomcat as much as possible.  See the following  
>>>>> discussions on scripts, I think there were a number of issues  
>>>>> discussed that we need to cover:
>>>>>
>>>>> http://www.mail-archive.com/dev@geronimo.apache.org/msg05926.html
>>>>>
>>>>> http://www.mail-archive.com/dev@geronimo.apache.org/msg05851.html
>>>>>
>>>>> http://www.mail-archive.com/dev@geronimo.apache.org/msg06483.html
>>>>>
>>>>> Regards,
>>>>>
>>>>> John
>>>>>
>>>>>
>>>>> Dave Colasurdo wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> Jeff Genender wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Dave Colasurdo wrote:
>>>>>>>
>>>>>>>> The shutdown scripts are a step forward in usability over
 
>>>>>>>> manually killing the java process via CTL-C.  While quite
 
>>>>>>>> simple, CTL-C does not seem very user friendly and should
 
>>>>>>>> not be the default mechanism.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I really don't believe there is a default mechanism, IMHO.  I
 
>>>>>>> think we are offering multiple ways to do the same thing.   
>>>>>>> The CTRL-C would be heavily used by developers.  The shutdown
 
>>>>>>> script could be used by people using a daemon or  
>>>>>>> backgrounding the server (which is easily done on both  
>>>>>>> Windows and *nix systems) or a remote server.  The console  
>>>>>>> would/maybe be used by mouse-clicking administrators.
>>>>>>>
>>>>>>> I would surely hope that in a prod environment one is not  
>>>>>>> running the server in a terminal window ;-)
>>>>>>>
>>>>>>>>
>>>>>>>> However, it does seem strange that a user needs to open a
 
>>>>>>>> new window to shutdown the server.   Seems like the initial
 
>>>>>>>> startup command should return the  command prompt back to
 
>>>>>>>> the user so that shutdown can be issued from the same  
>>>>>>>> window.  One way to accomplish this is to have the startup
 
>>>>>>>> script launch a new window that controls the java process
 
>>>>>>>> (and output the startup messages) while the initial prompt
 
>>>>>>>> is returned to the user.  This would allow the shutdown to
 
>>>>>>>> be issued from the initial window.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> For a developer (and me being selfish), running in a terminal
 
>>>>>>> window is not strange and it seems to be the norm from a  
>>>>>>> command line perspective, rather than the exception.
>>>>>>>
>>>>>>> IMHO, ss a developer, sending the server into the background
 
>>>>>>> is not appealing.  I think if one wants control over their  
>>>>>>> terminal, they could issue a startup.sh& (notice the  
>>>>>>> ampersand) to background the process. Quite possibly we could
 
>>>>>>> also add another script called startup_background.sh (or bat)
 
>>>>>>> that could so this as well.   We could also create daemon  
>>>>>>> scripts for the different platforms.  Wasn't there a JIRA  
>>>>>>> issue for an NT Service for Windows?  We could add init.d  
>>>>>>> scripts for Unix too.
>>>>>>>
>>>>>>
>>>>>> I agree the current behavior is appropriate for a developer.   
>>>>>> I was thinking more about end users. Similar to your  
>>>>>> suggestion, should we consider adding an option to the  
>>>>>> startup.sh|bat script to put the process in background?   
>>>>>> Actually, I'm wondering if the default behavior (startup.sh| 
>>>>>> bat w/o any options) should be geared toward end users and  
>>>>>> would run the process in background.  And specifying the  
>>>>>> option (-foreground) would allow the process to be run in the  
>>>>>> current window for developers.
>>>>>>
>>>>>> Of course, windows service and init.d are also useful.  I  
>>>>>> think both proposals are worth pursuing
>>>>>>
>>>>>> Will look to see if there are current JIRAs open on these..
>>>>>>
>>>>>>
>>>>>>>>
>>>>>>>> Also, if we ever support sharing one binary installation
 
>>>>>>>> that can start multiple instances of geronimo (each with
 
>>>>>>>> it's own unique configuration) then we will also likely need
 
>>>>>>>> this behavior.
>>>>>>>>
>>>>>>>> -Dave-
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>


Mime
View raw message