:-)
> | On 13/11/2001 04:38 pm, "Mika Goeckel" <[EMAIL PROTECTED]> wrote: > | > | > SNMP, ah ja. I've got no knowledge at all 'bout that, so fight with some > | > other lobbyists :-) > | > | Same here... > > Didn't mean to take a left turn. Sorry I mentioned it. No need to mention, nobody felt offended. I was just joking :-) > > | > | > SessionManager/ServletContainer dualism....: > | > If we don't create a separate SessionManager residing in it's own JVM, > but > | > make it an integral capability of TC, we have the following benefits: > | > - we save one copy: > | > When a new session is created and we have a separate network of SMs, it > | > needs to be copied to at least two SMs, if we have it in TC, it only > needs > | > to be copied to one other TC. (If we aim single redundance) > | > | Indeed it would save bandwidth... > > I want a distributed session store, where all sessions are known (or > are knowable) by all members of the cluster, with a built-in > fail-over mechanism? > > I want to be able to scale my web server by simply adding > more standalone Tomcats and possibly session managers. > I want to be able to use a brand-x HTTP load-balancer that > redirects web-traffic on a request-by-request basis to the tomcat > webserver that it thinks can best handle the request. I also want > to be able to bring down individual Tomcats without destroying > any user sessions. > > Apache's 'smart' approach (that remembers which JSESSIONID's > are hosted by which Tomcat Servers) doesn't let me bring down > individual Tomcat servers without losing sessions. This means > that Tomcat servers are simply not 'hot-swappable' in this configuration. > > ASFAICT, minimal redundance is all that is required. There's simply > no need to keep a gratuitous number of session copies around. > > | > | > - if one TC is the owner and the other the escrow, the owner never needs > to > | > ask if the session is uptodate or invalid, and it can't get stale. The > | > replication of changes can be done after the request, so no time burden > | > within the request itself. > | > If the escrow want's to use the session, it only needs to inform the > owner > | > and they change roles (or if possible the escrow passes the request back > to > | > the owner) > | > Frequently all servers ping their known escrows and owners to ensure > they're > | > still present. > | > | The only problem I could see with that is synchronization of accesses from > | different points, but I believe that is a solvable problem... > | > | > - deserialisation should not be a problem, because in that ClassLoader > | > Context, the user-session objects are known. (correct me if I'm wrong > here) > | > | Nope, you're right on that. > > This is only an issue in the event that the Session Manager is a seperate > entity. > > | > | > AutoConf.... what about JNDI to register cluster nodes? It is around > anyway. > | > In that case an upcoming TC would just search the JNDI service for > | > registered nodes with his own ClusterName, and register itself with it. > | > Getting back a NamingEnumeration, it could decide itself, which of the > | > others to link with. > | > | One thing that can be done with my approach of multicasting is automatic > | load balancing... To any request of "who can hold this session", each > | manager can return a load index, and the decision on where the session > | should be stored primarily and in replica should be based on that. Using > | JNDI that can be done, but I don't want to end up in a situation where a > | single host holds 80% of the sessions while the others are free... If the > | managers could update their JNDI registrations with a "load" factor every > X > | seconds, that would be acceptable... > | > > One thing to remember here is that the number of 'clients' > in our discussion is always fixed - it is the number of Tomcat > web servers in the 'cluster'. The load of the session managers > is a direct function of the load on it's clients. Hopefully, the load > balancer on the front end (either Apache round-robin, or some > firmware solution) is doing a 'reasonable' job of spreading the > load across web servers / tomcats. Therefore, as long as the > number of Tomcats served by each Session manager is > approximately the same, we can deduce that the load placed > on the session managers will ALSO be reasonably well balanced. > If my deduction is correct, then there should be no need for > posting load factors, and continual switching back and forth > between session managers. > > Lets create some more examples: > > 1) 10 Tomcat webservers (1-10). Servers 1 and 2 happen to be > identifed as 'Session Managers' as well as web servers. > Servers 3-10 are just plain web servers, not session managers. > > In this scenario, Tomcat servers 1 and 2 are burdened by satisfying > session requests (queries & updates) from the other 9 servers, as well > as handling their own web-traffic. They must also initiate communication > to the other 9 servers whenever a session is invalidated (due to update, > maxAge, or on demand). They must also communicate all session deltas > to the 'other' session manager. The best scenario, but tell me if I misunderstand something after you've reviewed case 4. > > 2) 10 Tomcat webservers, all 10 are identified as 'Session Managers' > > In this scenario each Tomcat must communicate session deltas to each > of the other 9 servers. All servers must perform significant extra work > in order to keep their Session store up-to-date. > > 3) 10 Tomcat webservers, 2 separate Session Managers. > Tomcats 1-5 point to SM1, Tomcats 6-10 point to SM 2. > > In this scenario, each Tomcat only communicates with 1 > session manager. Each session manager communicates > session deltas with the other SM, and with only the Tomcat > servers that it connect themselves to it (5 in this example) > on an as-needed basis (e.g. when the Tomcat instance asks > for the session data). Each SM must also send tell all it's clients > when sessions are invalidated. > > Fail-over could be handled in a similar manner in all scenarios. > Addition of a new SessionManager (or SessionManager capable Tomcat) > could be handled in a similar manner in all scenarios. In principle, I completely agree. All I want to express is, that I think we don't need SessionManagers as assigned responsibility and would save traffic. Scenario: 4) 10 Tomcat webservers acting as SessionManagers for Sessions initially created by themselves or being assigned responsibility afterwards for a specific session. In this scenario every Tomcat backs up sessions to a configured number of others (for simple redundancy only with one other tc) The session is primarily held on the TC which created it or most recently used it. The other instance(s) hold a passive copy for fail-savety. a) A dumb load.balancing facility passes a request to a completely different TC which needs control over the connected session. From a regularly updated list or by asking it's peers it get's the (actual) owner of that session and requests to take over ownership. The old owner drop's ownership after the session has been taken over. Alternatively the old owner becomes the backup and the old backup drops. b) A clever load-balancing facility remembers where the last request of this session went and directs the next request to the same TC. The TC has all what it needs to fulfill the request and communicates the changes of the session afterwards. In Scenario a) you have one session copy before the request and one change communication afterwards. in b) only change communication. In your scenario, the TC needs at least the certitude that the session is uptodate, so it goes asking the SessionManager. If yes, it's case 4 b) If no, it's case 4a) but in both cases the overhead of asking the SessionManager. If the primary owner goes down, the secondary becomes primary owner and has to find a new secondary. If that happens, 4a) applies because the load-balancer needs to choose another instance and the likelyhood that it finds the backup TC by chance is 1/(number of nodes - 1). Assumption: We leave the load-balancing to the load balancer. Without that assumption we could be even more clever: A TC gets a request and hasn't got the session. But from the list or by asking it's peers it get's knowledge who is the primary owner. It asks mod_webapp to go and send the request to that TC. In that case we end up at 4b) in nearly every case. No session copying during the request, only changes afterwards. After having written that I notice that we are very close in our thinking. Your approach is somewhat clearer by the sake of having one more copy of a session, instead if the SessionManager part of a TC stores it's copies in the TCs session store (memory presumably). Then we have exactly the same. I'm playing around with the TC src at the moment. I've had a look on JNDIRealm to find out how a Context is usually created. I'm missing a static service utility with a simple getInitialContext method and more than that Log4J.... and are there really JUnit tests around? I've not seen a single one. Cheers, Mika ^X^C -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
