From: Chuck E. <ec...@mi...> - 2000-06-16 14:22:09
|
As is often the case, I agree with all of Geoff's comments. -Chuck At 09:21 AM 6/16/00 -0400, Geoff Talvola wrote: >Jay Love wrote: > > > Geoff Talvola wrote: > > > > > > Chuck Esterbrook wrote: > > > > > > > And who's coding this? Geoff? You? Me? > > > > > > I would be happy to take a stab at it, but realistically it'll be a > couple of > > > weeks before you can expect any results. I'm kinda busy with work > right now... > > > > I'll take it on. > >OK, I can at least volunteer to test it and adapt it to run on >Windows. Starting up >processes is completely different on Windows -- you need to spawn a brand >new process >using os.spawnv instead of forking with os.fork, because there is no way >to fork on >Windows. The only ways to pass in variables to the new process are via >command-line >arguments or environment variables. Try to keep that in mind and don't >rely too much >on the fork'ed process being able to use the variables of the original >process. > > > > I question the need for a separate "watchdog" application -- why not > just have > > > the CGI adaptor start up a new appserver if the old one isn't > responding? That's > > > what I suggested in my proposal... > > > > I didn't think it was necessary at first, either. But when I started > > following the process flow in my head, I felt like it was. > > > > Keep in mind that the monitor app is a little thing that just keeps an > > eye on everything. It just seems to make the design a lot cleaner to > > use it. > > > > I think reason number one is that if the AppServer on port 7009 isn't > > reponding, then 5 new AppServers could be started on that port if the > > Adaptors are responsible for it. Multiple Adaptors could sense that at > > the same time. That implies a need for a central App that handles the > > coordination. > >This could be coordinated by file locking. But maybe that's more >complicated than a >watchdog app. > >Remember that the watchdog app needs to stay running indefinitely unlike the >appservers, so it should be kept as simple as possible. > > > The monitor process also handles writing the address.text file. This > > could be done with file locks, etc, but isn't that unix specific? > > Anyway, having a monitor do it is cleaner. > >Windows also has file locking, but you may be right that it's cleaner with >a central >application. > >One more thing -- who starts the monitor app? I'd like to see 2 options: >the monitor >app can already be running -- fine. But the adaptor should also be able >to start up >the monitor app if it's not running. This way, you don't have to start >any extra >processes when the machine reboots -- as long as the web server comes up, >on the first >WebKit request, everything else gets started automatically. > >-- > > >- Geoff Talvola > Parlance Corporation > gtalvola@NameConnector.com |