Well stated. If the module loads at start time, it should NOT fatal out later because a DB goes down, or some other resource is temporarily unavailable. If the resource is unavailable at start time, having daemontools in inittab restart the server until the resource *is* available makes sense to me. There is no right or wrong answer here, just a decision as to whether handling this in an admin-changeable fashion will add more complexity to the code than benefits obtained.
/s. > -----Original Message----- > From: AOLserver Discussion > [mailto:AOLSERVER@;LISTSERV.AOL.COM] On Behalf Of Dossy > Sent: Friday, October 18, 2002 1:48 PM > To: [EMAIL PROTECTED] > Subject: Re: [AOLSERVER] Module arrogance > > > On 2002.10.18, Jim Wilcoxson <[EMAIL PROTECTED]> wrote: > > > > What is the point of having the DB module load, if it can't > connect to > > the DB server? > > While I personally agree with you, the point (I think) that > Pete is making is that for DB modules, this behavior should > be up to the admin's control. > > If the DB driver loads successfully, but the database is > unavailable, one should be able to trap it. > > If you want to validate that the database is available at > start-up, you /should/ be allowed to do a ns_db gethandle > from nsd.tcl to try and connect and ns_exit on failure, if > you DESIRE that behavior. But to kill the whole server at > runtime because the DB's inaccessible leaves no choice to > website developers, which is a design flaw. > > My position: ANY module that fails to load should cause a > hard fatal at start-up. There are very few, if any, reasons > for a module to deliver a hard fatal to a system at runtime though. > > -- Dossy > > -- > Dossy Shiobara mail: [EMAIL PROTECTED] > Panoptic Computer Network web: http://www.panoptic.com/ > "He realized the fastest way to change is to laugh at your own > folly -- then you can let go and quickly move on." (p. 70) > >
