Hi, yes I looked at the animation. Although I must confess, that I don't get much out of it technically. What's the reason for the need to test session validity? Is it needed to find out, if a node already got upgraded to a new app version, so the session needs to get routed to a node, still running the old app version? That's what I expect, since you introduced worker "versions" (one could also name it "generation").
OK, we are only talking about cluster (in the sense of session replication) and I assume, that we are interested in the case of an application update, which is non-compatible concerning sessions and/or URL structure. At the moment, sessions will be routed according to the routing suffix in their id. Sessions which failed over can be rewritten (get another routing suffix) by a Valve and thus be bound to another (surviving) node. But sessions which have been idle will still be called with the old suffix by the browser the next time they are used. If the node got an update in the meantime, they will get routed to an incompatible node and throw an error. As a first simple workaround one could use two sets of workers and of target (tomcat) nodes. One set would be stopped, on active at a time. The two sets use different jvmRoutes. Replication is not done across set boundaries. You upgrade the stopped set, test it via an internal connector/vhost and then change its activation to active. Also you change the activation of the formerly active set to disabled. New sessions will go to the updated set, old sessions will still go to the unchanged set. Invalid sessions will need to redirect to a start page without session information. After some (depending on session use time) you stop the disabled set, to prevent people with URL encoded bookmarks (or long running browsers with cookies cached) to still reach the old version. Now this scenario does not really help, if you want to do *many* updates. It granularity is somehow to coarse. To make it work more smoothly, we would need an automatic way of managing jvmRoute, worker.route and worker.domain consistently during application upgrade (increasing generation counter which gets appended to the route). It looks like you did something like that? Somehow I don't really see the need of checking the validity of a session by mod_jk. We only need to know, which version of the app the session belongs to, and which version of the app the various workers talk to. This could be done by a generation counter in jvmRoute and all routing related strings in mod_jk. In your original mail, you talked about additional hooks you would need inside mod_jk. What would that be? Regards, Rainer Anthony Vromant schrieb: > Hi all, > > I would like to know if you had time to look at the demonstration of our > prototype. > > We are very interested to get your feelings about that. > > Do you have ideas about our problem of testing the validity of a user > session within mod_jk ? > We're thinking about a mechanism relying on the JMX-Adaptor of Tomcat > that mod_jk can > invoke through the AJP interface. What's your opinion ? > > Thanks. > Regards > > Anthony Vromant > > Anthony Vromant wrote: >> Hi Rainer, >> >> First of all, thank you for these informations. >> >> Here is the HTTP link for the Flash demonstration of our prototype : >> https://wiki.objectweb.org/jonas/Wiki.jsp?page=JOnASClusteringSmoothUpdateWebCluster >> >> >> I am looking at the new features provided by mod_jk 1.2.20, the >> dynamic configuration reloading is quite interesting. >> We are going to bring our prototype to this new version. >> >> In our prototype, when a new request is coming with a JSESSIONID >> cookie, a request is sent to the worker (tomcat) for checking the >> validity (we need to know whether the session is still alive). >> Currently, the HTTP protocol is used for invoking tomcat rather than >> AJP. The control at the tomcat side is done through an internal >> servlet which accesses the MBean manager for getting the current >> sessions list. >> >> Do you have any suggestion for improving that ? >> >> Regards, >> Anthony > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
