At 12:07 PM 11/29/01 -0500, Jeff Johnson wrote:
> > What do you think of the option we sort of outlined yesterday:
> > - Software or hardware load balancer distributes incoming
> > requests randomly
> > to a pool of machines running Apache (call them APACHE1,
> > APACHE2, etc).
> > - APACHE1, APACHE2, etc have a modified version of the WebKit adapter
> > running on them. The modification is: if no session ID is
> > found in the
> > request, it sends the request to a random machine, otherwise
> > it parses the
> > session ID to find which particular machine to send the
> > request to, from a
> > pool of available WebKit machines (WEBKIT1, WEBKIT2, etc).
> > The pool of
> > machines would be configurable in the adapter's config file.
> > - WEBKIT1, WEBKIT2, etc have a modified version of Session.py
> > that encodes
> > the machine name into the session key. This would be configured in
> > Application.config. The session key would be something like
> > "WEBKIT1_237480927".
> > The idea being to keep requests for the same session on the same
> > machine. Would this work for you? I'm interested in helping
> > to write the
> > WebKit modifications needed.
>I'm a fan of cookies (or too lazy to do it the other way) but some
>people have said they can't count on them. Would this support those
It could be made to support them -- you just have to make sure the the
logic in the adapter knows how to find the session ID, whatever method is
being used to encode it.
>One of the suggestions for multi-domains bothers me, not only would
>bookmarks be server specific but SSL certs would have to exist for each
But wouldn't the hardware load balancer make it look to the user like
there's only a single box, even though it's actually distributing the
requests to multiple back ends machines running Apache? I don't know about
the multiple SSL certs; could you just use a single cert and place it onto
all of your boxes?
> > The other option is, as you said, to write a
> > SessionSQLStore.py to store
> > sessions in a database. You have to be a little bit careful
> > about locking
> > here, since multiple requests for the same session may be coming from
> > different appservers at the same time. I'm not sure how to
> > avoid wiping
> > out one appserver's changes with another appserver's changes
> > in that case.
>I started thinking about those issues and no longer think it's trivial
>:). All reads and writes would probably have to go through a method
>that locked the SQL table. Luckily I've never had to lock tables. I
>try to avoid db vendor specific code but I think you'd have to do it for
- Geoff Talvola