RE: persistent DB connections (was: RE: modular database backends)

[Dirk Bergstrom <dirk@juniper.net>]

i, too, am inclined towards #3, but it does require rather a lot of
re-engineering.  under the current setup, gnatsd generally runs for only one
"transaction" (a search, a pr-edit, one gnatsweb hit, etc.).  turning it
into a persistent daemon would, to put it nicely, help us discover any
hidden memory leaks.

furthermore, while gnatsd does have the RSET command ("reset internal
settings to initial startup"), it doesn't have any of the other mechanisms
necessary to a persistent daemon.  i'm sure the code is readily available,
but it's not trivial to get everything working, stable, and leak-free...

--
Dirk Bergstrom              dirk@juniper.net
____________________________________________
Juniper Networks Inc.,  Engineering Web Guru
Tel: 408.745.3182          Fax: 408.745.8905


> -----Original Message-----
> From: Michael Richardson [ mailto:mcr@sandelman.ottawa.on.ca ]
> Sent: Wednesday, May 30, 2001 9:09 AM
> To: Dirk Bergstrom
> Subject: Re: persistent DB connections (was: RE: modular database
> backends) 
> 
> 
> 
>   You should put the database connection in gnatsd.
>   It does not have to be spawned from inetd.
> 
>   #3 is where you should go.
> 
> Canadian Commuter Challenge Project -- GNU Potato Caboose 
> Michael Richardson, Sandelman Software Works, Ottawa, ON  
> EMAIL: mcr@commuterchallenge.net
> for help, email or page at 1-866-231-8608
> 
>