Tomcat developers: Hello again, and happy new year.
I've been plugging away at the distributed session management solution. I have a question or two. I've created an RMI multicast registry. This 'registry' is how RMI services for object / session replication can be advertised and obtained cluster-wide. There only needs to be a single registry present in Tomcat. Server.java (and core.StandardServer.java) seems like the place to add this support. I've figured out how to integrate this with the commons Digester by creating a new RuleSet. Since the digester rules for Server are found in Catalina.java, it looks like I'll have to add a line to Catalina.java to pull my new RuleSet in. Perhaps I should refactor the Server digester rules into a ServerRuleSet class. I've also created a new 'object repository' package that takes care of the details of distributing objects around the cluster. All Repositories will keep a copy of all sessions in the cluster. Please note that only a subset of the TC instances need to be configured to be Repositories. The non-repository instances can retrieve sessions from other repositories if needed. As far as I can tell, there only needs to be one object repository per TC instance. I'm worried about how to deal with the classloader issues that I'm sure to encounter trying to serialize Session objects that contain webapp specific objects in them. One way around this would be to have a separate object repository for each context (that uses the classloader for that context). However, a single object repository would use fewer resources. I need to talk to someone about this. I've created a new Manager that stores sessions to and retrieves sessions from the 'object repository'. I've also created a new Valve who's job it is to notify the Manager on completion of a request (so that the Manager can then send the updated Session object to the various object repositories in the cluster). Finally, I need some support and advice with mod_webapp integration. I still have some questions about SessionID mangling. Here's the way I see it working. Assuming that the following scenarios are basically correct, mod_webapp will need to be modified to add the session affinity support and the fail-over re-routing support. Please comment on these three scenarios. New session - client sends initial request to Apache. - Apache forwards request to a tc worker of its choosing. - tc invokes the requested servlet or jsp, which creates a 'session'. A 'route-id' is appended to the end of the session id by the Manager when the session is created. - tc sends a response. This response contains the the session id as a cookie and/or as URL component - tc stores this session with the unmangled session id in the cluster object repository. The key to the session is the UN-MANGLED session id. - Apache (mod_webapp) notices the 'route-id' at the end of the session, and remembers the relationship between the worker and the route-id. - Apache sends response to client. Update session (normal case). - client sends request (including session id) to Apache - Apache, forwards the request to the worker that corresponds to the route-id at the end of the given session id. - tc invokes the requested servlet or jsp that calls 'getSession()'. - tc Manager finds the session in it's local store. It then 'locks' the object. - tc sends response (contains session id) - tc sends updated session to cluster repository (and unlocks session) - Apache sends response to client Update session (failover case) - client sends request (including session id) to Apache - Apache, attempts to forward the request to the worker that corresponds to the route-id at the end of the given session id. This attempt fails because the worker has gone off-the-air. - mod_webapp chooses another worker. If able to connect to the worker, it must 'filter' the http request replacing the route-id portion of the embedded session id's with the route-id of the 'new' worker. - tc invokes the requested servlet or jsp that calls 'getSession()'. - tc Manager fails to find the session in it's local store. - tc Manager looks in the cluster repository for the session (sans route-id) The repository finds the session and 'locks' it. It also makes the 'new' tc instance the 'owner' of the session. All other repositories are updated with this change. - tc Manager updates it's local session cache. - tc sends response (contains session id) - tc sends updated session to cluster repository (and unlocks session) - Apache sends response to client Regards, Tom Drake President, software/etc inc. Cell: 408-505-6864 Email: [EMAIL PROTECTED] -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
