tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tom Drake" <...@pobox.com>
Subject Distributed Sessions - integration
Date Wed, 02 Jan 2002 14:57:01 GMT
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: debugger@engineer.com


--
To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>


Mime
View raw message