[Paperclips-discuss] Re: gnu-paperclips: session load balancing: invalidation

[Gokul Singh]

----- Original Message -----
From: "Nic Ferrier" <address@hidden>
To: <address@hidden>

> new session manager
> >This seems to be great. This also means that there
> >will be a primary server where all the session info will
> >be stored and there will be a backup server.
>
> Not exactly, though you could provide an implementation of my
> interfaces like that (and I hope someone will).

I would have liked it that way. Maybe I might start in that direction.


> What I'm coding right now is much more peer to peer. All servers
> co-operating in a session network rapidly end up with a copy of the
> session.

This design has a redundancy of a very high degree in the present design.


> Nic's example of session networking:
>    Imagine we have a session X in a distributed system
>    of 3 servers: A, B and C.
>
>    A request comes in for session X on server A. Server A
>    locks the session X on servers B and C and then processes
>    the request. Whilst session X is locked servers B and C
>    cannot serve requests with the session (they fail in some
>    way).

I do not like my requests failing. Why should they fail.



> Also, I'm going to use broadcasts (and later multicasts) to avoid the
> need to send the session data directly to each server,

What happens if the servers in the server farm are spread in more than one
subnet. As far as I know both websphere and iPlanet (considered to be high
end app servers) have some trouble in this area. Are we planning to
accomodate this. (please excuse if the answer is obvious as my understanding
of multicast/broadcast is limited).


> I don't think you've understood session load balancing. When an app
> is marked <distributable/> in the DD the behaviour for managing
> concurrent requests on the same session is defined by the spec: they
> fail.

Can you point me to  where the specs say this. I think this is a pretty
awful condition to impose.



> Concurrent request for a single session are NOT allowed. In fact,
> when you think about it, concurrent requests are pretty unusual
> anyway. Sessions tend to be associated with a user and user's rarely
> do two things at once.

I disagree. If there is a frameset with two or more frames, then there will
be concurrent request from the browser. Not an unusual scenario I think.


> But given the fact that concurrent requests for a single session are
> not allowed you're scenarios don't make much sense. Some more
> thoughts:
>
> "All *concurrent* request for a session go to the same server."
> How are you going to arrange this? The name service that the UA uses
> to find the server won't know what server is concurrent for a session
> or even what the session is.

Agreed. Then how are the requests going to end up on Server A/B/C ?
How are you planning to distribute the load? How are the requests going to
be distributed across the servers?
Is the distribution going to be intelligent?


 > >What was the sort of load you experienced in
> >the web mail application that you designed?
>
> Talk21 has about 7000 concurrent sessions at any one time. There are
> ~285,000 session creations per day.
>
> We don't know the request level because that is such high load we
> couldn't count it.

That is huge !!!





> - when server A has the session locked what is making requests with
> session X?

The user-agent may issue concurrent requests. I still believe it should be
supported.
Of course the browsers restrict the  no. of concurrent requests to 4 in HTTP
1.0 and 2 in HTTP1.1.


> - I've not decided on concurrent clash behaviour, holding the request
> till unlock may not be the best thing to do (but probably is)
>
> - but if session X is waiting to be served on server C then why would
> server B manage to lock the session? As soon as server A unlocks it
> server C will see the unlock and proceed with it's own lock.

Let us assume that there are three requests from the browser. ( provided we
concurrent requests are being supported)
Is then some sort of queing in progress or it is a race for the lock?
If B and C are waiting for the lock, how is it decided as to who gets the
lock.



> >Why should all the three servers have a copy of
> >the Session. when they checkin the session, they
> >should no longer have a copy of the session.
> >It will be a waste of system resources to have the
> >session info in memory at three different servers because
> >when the server sevices a request for the session,
> >it will check it out to get the latest copy.
>
> No. The session data is transmitted when a request ends not when the
> request gets checked out.

Correct. What I had in mind was  central server to hold all the session and
not a system of the type you are envisaging.
It is not relevant for the type of system you have described.




> Yes, I know about that one. It's interesting because it says "not
> required", It doesn't say "MUST NOT".

Maybe it can be changed to MUST NOT before the final release of the version
2.3.


> But it is referring to HttpSession events and not
> HttpSessionBindingEvents which is what I'm asking about. Should the
> invalidate() occur on all the servers in the session network?

Again a grey area. I think the cleanup being performed in
HttpSessionBindingEvents should also be done in
HttpSessionActivationListner.


> But under my system the sessions still exist on server A and server
> B. But perhaps you're on the right track. I'll ask Danny.

Let us know what he says.

Regds,
Gokul

>
> Nic
>


Archives: http://www.topica.com/lists/gnu-paperclips-discussion

==^================================================================
EASY UNSUBSCRIBE click here: http://topica.com/u/?b1dceT.b2Fvl0
Or send an email To: address@hidden
This email was sent to: address@hidden

T O P I C A -- Register now to manage your mail!
http://www.topica.com/partner/tag02/register
==^================================================================