Chuck Esterbrook wrote:
> At 07:14 PM 6/14/00 -0400, Jay Love wrote:
> >Since Geoff needs to use IIS, I think that helps push us toward the
> >viable answer. None of us are going to write a module for IIS.
> Regarding your last statement, how do you figure that? Certainly I won't
> write an IIS-specific module, because I deploy on UNIX. I could certainly
> see someone else taking this up.
Someone else might, but I don't have the first clue how to do it.
That's what I meant.
> >I would like to put forth the following suggestions (with reasoning):
> >1. Our focus for now should be on stability/reliability. Load
> >balancing won't be a real issue for quite some time, most likely, and it
> >will complicate things.
> I almost agree. With a little consideration, perhaps we can pave the way
> for load balancing so we don't have to tear the code apart.
That's all I'm saying.
> Another issue to consider is distributing the apps across multiple boxes
> that don't necessarily share a file system. WebObjects used to rely on the
> file system, but it was a problem for some setups, so they went to doing
> some kind of network broadcast.
I think that's a great feature and I want it later on. I just don't
think it's necessary or a priority right now.
> However, they don't support auto-starting which is something else I want. I
> doubt that I can rely on my host provider to start up WebKit after a
> reboot/crash of the machine.
We can do this easily. BUt the ease may be dtermined by how we handle
session persistence. See below.
> >2. We need a fail-over system. I can still make WebKit segfault. I
> >think this is related to the memory leak.
> >3. The fail-over system does not HAVE to be a separate process. The
> >current adaptors can just start a new AppServer if they don't get a
> >connection in x seconds.
> >So, I suggest we focus on the following.
> >1. Write a small fast persistent cgi adaptor in C for IIS, etc. This
> >will work on any webserver and can be very fast and reliable. Along
> >these lines, I'm working on a C library to handle marshaling, etc.
> If the CGI adaptor is persistent, then what's the motivation for using C as
> opposed to Python, other than a little more speed?
I say "persistent" in the Zope sense. What it really is is a small fast
adaptor that is started for each request, but written in C so it starts
very quickly. Zope uses this approach very effectively.
> >2. Find the Memory leak. This most likely will improve the stability
> >and make 3 less important.
> Finding memory leaks, always sounds good, although I think 3 will always be
Yes, but I suspect the segfaulting may go away if we find the leak.
Also, If we find the leak, it not be necessary to restart the AppServer
> >3. Think of a way to handle preserving sessions if we can't find the
> >memory leak and need to kill AppServer after X number of requests. BUT,
> >if we can't find the mem leak and segfault, any session persistence
> >mechanism won't matter, most likely, as the server could crash at any
> You don't need session storage for this. After X number of requests and/or
> hours, the AppServer stops accepting new sessions. Eventually it's current
> sessions will expire and it will die.
Well, that approach will be a bit more complicated, but not impossible.
What I was thinking as an easy way to do it is to have the Appserver
kill itself after X requests and store its sessions in a file, and when
the Adaptor can't connect, it starts a new AppServer. When the new
AppServer starts, it looks somewhere for a stored session file. This
avoids having to change any logic except that if the Adaptor can't
connect, it starts a new AppServer.
> If you think your AppServer is good for 10 hours, then set it's termination
> point for 6 hours. The sessions will probably die within an hour after that
> and you're fine. In fact, even if some of the sessions live for several
> more hours, they won't likely cause problems since the AppServer won't be
> stressed by a handful of them.
> WebObjects uses this technique and it seems to work well for them.
> >I'm not real concerned with writing custom adaptors/modules for
> >webservers. The only one we can do this for is apache, and FastCGI
> I also don't understand that statement: 'The only one we can do this for is
> apache'. AFAIK, we can do this for Apache, Netscape, MS, and Xitami (sp.),
> and probably others.
The only one we have easy access to all the documentation and examples,
etc is apache. The others can be done, but only Geoff has a need for
> >works fine there. I'm not sure how much faster a custom apache module
> >will be. We're already faster than JServe with FastCGI. We might want
> >an apache module for load-balancing, but I suggest postponing that.
> >Chuck, is there a fast cgi module for apache on Windows? Have you tried
> I believe Geoff sent a msg to this list earlier stating that either there
> wasn't or it was in alpha. I don't recall. Again, Windows is my dev machine
> and UNIX is my deployment.
It's Beta, and it's in the latest release.
> >I'm thinking we should postpone doing a monitor type process 'till 0.5
> >or 0.6. I think this will be the way to go later, as it will work with
> >a PCGI style adaptor, but it will introduce the session issues and
> >other over-head and the time spent on that might be better spent on the
> >core functionality and finding bugs for now.
> >I suggest that for now we add a way for the adaptors to start the
> >AppServer themselves if it's not there and leave it at that for now.
> I'd also like to shoot for the AppServer being able to refuse new sessions
> after some condition (X sessions, Y requests, Z hours) and then the adapter
> goes to a different one. I'll pretty much need this for the website I'm
> building now. I hope to have an alpha by the 30th.
I think that approach is fine, just a little more complicated. It
requires some logic in the Adaptor about where to send a certain
request. I was suggesting leaving that out for now, and just letting
the AppServer die on it's own when it decided not to serve any more
sessions. In other words, only one AppServer running at a time.
> I actually started writing a little white paper on all of this last week. I
> don't know how complete it is, but I'll try to clean it up tomorrow and
> share it with the group.
> It covers high level architecture including adapters, applications, URL
> mapping, Servlet factories, etc.