porting ajp13 to tomcat 4 (was Re: ajp13 question)

[kevin seguin <se...@motive.com>]

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 // danmil@shore.net

Re: porting ajp13 to tomcat 4 (was Re: ajp13 question)

[kevin seguin <se...@motive.com>]

> 
> Well, I also have it half workig, maybe we can combine our halfs :-)
> 

i'm guessing your half is better :)  perhaps you can send it to me?

> What I did was use the "real" tc3 objects, with all optimizations on the
> lower-level and create an implementation of TC4 Request, etc - that
> will redirect to the 3.3 objects.
> 
> That will support all 3.3 connectors ( including my favorite - which is
> JNI BTW :-), but of course it doesn't solve the session problem.
> 
> For session we need to change the session id generator - that requires
> changes in catalina ( I suppose they will have to implement that anyway -
> so it can wait ).
> 
> BTW, the result seems 10..20% faster than the original ( even in prototype
> state, with no tuning :-) ( probably due to the lazy evaluations we do in
> 3 )
> 

that would be cool... speed is goodness ;)

-kevin.

Re: porting ajp13 to tomcat 4 (was Re: ajp13 question)

[cm...@yahoo.com]

On Mon, 30 Apr 2001, kevin seguin wrote:

> 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...).

Well, I also have it half workig, maybe we can combine our halfs :-)

What I did was use the "real" tc3 objects, with all optimizations on the
lower-level and create an implementation of TC4 Request, etc - that 
will redirect to the 3.3 objects.

That will support all 3.3 connectors ( including my favorite - which is
JNI BTW :-), but of course it doesn't solve the session problem.

For session we need to change the session id generator - that requires
changes in catalina ( I suppose they will have to implement that anyway -
so it can wait ).

BTW, the result seems 10..20% faster than the original ( even in prototype
state, with no tuning :-) ( probably due to the lazy evaluations we do in
3 )

Costin