As is often the case, I agree with all of Geoff's comments.
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
>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
>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
> > > 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
>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
>One more thing -- who starts the monitor app? I'd like to see 2 options:
>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
>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