comments below...
> Excellent -- something I can actually answer! BTW, I'm cc'ing the list --
> let's try to have this conversation on the mailing list. That way, everyone
> can learn and/or participate.
>
> The jvm route, as the AJPv13 doc says:
>
> "...is used to support sticky sessions -- associating a user's sesson with a
> particular Tomcat instance in the presence of multiple, load-balancing
> servers."
>
> Let's say you have a single Apache server feeding multiple TC instances.
> Once a TC instance starts a session for a user, you want all future requests
> in that session to be forwarded to that instance (so that session data can
> be held in memory on that box).
>
> Load balancing is done by the jk_lb_worker. In jk_lb_worker.c, l 318, the
> jvm_route property of the service object is set to the "name" by which the
> load balancer knows the particular jk worker (which communicates with a
> particular TC instance). Assuming that that is then an instance of
> jk_ajp13_worker, this will then get sent over to the TC instance via
> jk_ajp13.c (ll. 456-458) (this is documented in AJPv13.html). (BTW, if it's
> an instance of ajp12, it will still work, but we won't go into that here,
> since no one is porting ajp12 to TC 4).
>
> On the Tomcat side, that jvm route is:
>
> - Read out of the packet from Apache (in Ajp13.java)
> - Stored in the request (also in Ajp13.java)
> - When the session id cookie is generated (jsessionid=...), the jvmroute is
> tacked onto the end (after a ';') (in modules/session/SessionIdGenerator, I
> believe).
> - This cookie is sent to the browser
>
> Then, when the browser sends back the session cookie, it will also be
> sending back the jvmroute, which is the name by which jk_lb_worker knows the
> right instance of TC to route to. The jk_lb_worker object then reads that
> (in get_session_route), and routes that particular request to the proper
> instance of TC.
>
> Phew.
>
> Okay, so how to make this work in TC 4? I'm not sure -- as you can see from
> the above description, it's pretty deep in the internals of TC 3 (in the
> core request object). If you could store it as an extra attribute of the
> request object, and then modify whatever code creates the session id, you
> might be in business. You might also ask the list (which has many TC 4
> experts) about the best way to handle this.
>
> Basically, though, the path is:
>
> - jk_lb_worker knows the name, passes it via the jvmroute attribute to TC.
> - TC inserts that into the session cookie, which is sent back the browser.
> - jk_lb_worker reads the name back, and uses that for routing.
>
damn! i wasn't expecting that complex of an answer ;)
> If you wanted to cheat (fine with me!), you could cut this feature out for
> now, and get ajp13 working *without* load-balancing (still useful), document
> that fact, and return to it later (or beg for help to fix it once you get
> everything else working). To do that, just have TC ignore whatever jvmroute
> is sent over. Everything but load-balancing should still work just fine.
>
that's what i've decided to do. my goal is to first get things working,
at least minimally, then i (or someone else) can address load-balancing
later. my gut feeling, though, after spending some time on ajp13 and
tomcat 4 is it's certainly possible. of course, i'm pretty new to the
whole tomcat 4 architecture, so i could be way off :)
thanks for the info.
btw, i've got ajp13/tomcat 4 about half working (probably the easy
half...).
> Have fun,
> -Dan
>
> kevin seguin wrote:
> >
> > what is the jvm route attribute for in ajp13? there doesn't appear to
> > be an equivalent to Request.setJvmRoute in catalina...
> >
> > thanks.
>
> --
>
> Dan Milstein // [EMAIL PROTECTED]
