> > In order to handle AppSevers limiting the number of requests they can
> > handle and killing themselves, we'll have to add some more complicated
> > logic, I think. My first thought on this is that we add a status
> > check to the initial communication between the Adaptor and the
> > AppServer. Maybe before sending a request, the Adaptor connects to
> > the AppServer and asks for the AppServer's status. The AppServer
> > responds with OK or DYING. If it responds with DYING, the Adaptor
> > won't send it any new requests, only requests that have gone there
> > before. (this would work for both cgi and persistent adaptors) (This
> > could also be the communication mechanism for the monitor process).
>
> Dying is a rare event, so instead of asking every time, what if the
> information was pushed back by the AppServer to the address.text file? You
> might get a couple requests that slip through between the time the
> AppServer decides it's dying and the time it updates the file, BUT there's
> not a big difference if you have appserver's with a lifetime of 10 hours
> and they take a couple more requests at the very end.
>
I think just asking every time would be faster than a filesystem read. Plus, this is an easy way to have a monitor app check the status of the servers. The protocol could be extended later to provide the monitor process with info on each process.
> > I think this method will have the lowest impact on the rest of the
> > code. (Which I consider important) Really the only addition below the
>
> Why is low impact on the code important? This project is still pretty young
> and certainly I don't want to tear things up that are already done the
> right way, but the rest is fair game.
>
Well, the more I think about it, the more I like this approach. But I want low impact so we don't introduce more bugs.
> >
> > SECURITY ISSUES:
> >
> > I'm worried about putting the port and machine in a cookie. Then any
> > hacker can get at that port, unless there's a decent firewall set up,
> > and we can't rely on that, can we? The obvious solution (to me) is to
> > encode only a count in the cookie, like 2, and have the Adaptor know
> > to add that number to some configuration parameter to get the actual
> > port number. Maybe put that configuration number in address.text. How
> > about that? (We can't use some encoding scheme that relies only on
> > the cookie value (ie the cookie value is the actual port plus 5
> > divided by 3 times 7), because this is open source.)
>
> I think even with open source it's safe to use things like md5 and such,
> but I forget how that works. :-)
Hadn't thought of that.
>
> You didn't mention it, but the config should say what the max # of app
> servers are.
>
> So if this is a concession proposal, what is that we're leaving out? It
> looks like you have everything but load balancing...? Yes/no?
Uh, this is the load balancing. It's unintelligent load balancing, but most load balancing schemes are random.
It's a concession 'cause I don't think we need to do this yet. But this is a pretty low impact approach, so I'm cool with it.
>
> And who's coding this? Geoff? You? Me?
>
> -Chuck
Whoever wants. I suspect Geoff is off trying to his version of this, whicj is very cool, two approaches. So it's probably either you or me. After two days of coding with C, I could use some python time. I'll do it if you're working on "something else".
Jay
|