Kevin,
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.
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.
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]
