At 03:24 PM 6/15/00 +0000, Jay Love wrote:
> > Um, then I still don't get the use of "persistent". Making something small
> > and fast doesn't make it persistent.
>Are you trying to be a pain in the ass? <g> I didn't make up the Zope
I never try. It comes naturally.
>terminology. Nothing about Zope is quite what it seems is it?
Well HTTP 1.1 can handle more than one request per connection and I see a
"Keep-Alive" value in one of the env values that goes to the CGI adapter.
So I thought maybe it had something to do with that.
> > When my website is out there, I'm not going to be comfortable running the
> > app server for 100 days in a row and hoping that all goes well. For one
> > thing, I would be the first person to run it that long and for another,
> > getting them to cycle shouldn't be hard.
>You're not gonna have it running for 100 days anytime soon. You'll be
I want to fiddle on my own terms rather than at 3 in the morning.
> > > > You don't need session storage for this. After X number of requests
> > > > hours, the AppServer stops accepting new sessions. Eventually it's
> > > > 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.
> > I don't know that that's any simpler and if we're going to support
> > instances for performance, we need to be able to deal with them anyway.
> > -Chuck
>You miss my original point. I don't think we should focus on supporting
>multiple instances at the moment.
No, I didn't miss your point. :-)
>But, See my other post for my concession suggestion.