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

[Nic Ferrier]

>>> Gokul Singh <address@hidden> 07-Jun-01 5:15:36 AM >>>

>> More details will be nailed down soon (and 
>> I'd love some help doing it).

>I hope you can count me in as I am back to India 
>after a really hectic two month stay in Japan.

Absolutely! There's lots of areas where stuff needs to be done; one
big area is URL mapped filters. I've got to alter the URI map
structure to facilitate them and I'm not sure of the best way of doing
it.

More on that another time.



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). 

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.


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).


>this will result in a large network traffic of
>moving around of the session info from A to B to C.

Yes. But bandwidth isn't a huge problem on local nets where servers
are deployed. Incomming bandwidth for an internet server (measured in
10s of Mbps) will be much lower than available local bandwidth
(measured in 100s or 1000s Mbps).

Also, I'm going to use broadcasts (and later multicasts) to avoid the
need to send the session data directly to each server, server A sends
it once and it goes to server B and server C (or 100s of participating
servers). This is one of the key decisions that has driven my chosen
network architecture.


>I think the session Load Balancing can be done 
>in two ways
>
>- As you have suggested, send the request to different 
>  servers and process the pending requests sequentially
>  (server wise). This may be better solution if we have a 
>  usage pattern where there are a small no. of session 
>  but a large no. of requests for each session.
>
>- All *concurrent* request for a session go to the same 
>  server. The moment there is no active request for a 
>  session, the session is free to be migrated to another 
>  server. This will take out the sequential processing and 
>  I think will scale up well in the scenario when there is a 
>  large no sessions and not high a nos. of concurrent 
>  requests per session.

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. 

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.

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.

"The moment there is no active request for a session, the session is
free to be migrated to another   server."
Yes. If you go over my SLB model again that is what's happening.
Whilst the session is unlocked on server A it gets migrated to the
other servers in the network. 


>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.



>> When server A finishes serving the request it 
>> unlocks session X on servers B and C. Any one 
>> of the three servers may recieve, lock, process 
>> and unlock the next request for session X.

>In this scenario some request may take a long time 
>to get an opportunity to execute (e.g the lock on the 
>session oscillates between server A and Server B and 
>the request on Server C takes a long time to get the 
>chance to execute).

I'm not sure how you came up with this, here's some points:

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

- 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.


>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. 


>One aspect can be that we put a flag which marks 
>whether the session has become dirty (attributes 
>changed) and then only update the contents of the
>session on the VM.

Exactly. I'm not proposing to do this right now but it's a possible
optimization for the future.


>> What should be the correct semantics of
>> invalidation in that circumstance? Should 
>> session X be invalidated only on the server 
>> that created it? or should it cause invalidation on
>> all the servers?

>As per section SRV.10.6
>"In distributed web containers, HttpSession instances 
>are scoped to the particluar VM servicing session 
>requests, and the ServletContext object is scoped to
>the web container's VM. Distributed containers are not 
>required to propogate either servlet context events or 
>HttpSession events to other VMs. Listener class instances
>are scoped to one per deployment descriptor declaration 
>per Java VM."

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

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?


>Now let us take the scenario
>Requests are handled by the server A then by Server B 
>and then by Server C for the session X and then the 
>session is invalidated. Now when the session is moved 
>from the server A to Server B, then attributes implementing 
>the HttpSessionActivationListener interface will be notified 
>on Server A. The session then moves to server B and no 
>more events are then fired on server A. In a similar manner 
>sessions move from server B to Server C. Now when the 
>session X get invalidated, the events will be fired on the
>server C only.

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.


Nic