Re: ajp13 question

[Dan Milstein <da...@shore.net>]

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 // 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

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: ajp13 question

[cm...@yahoo.com]

What about creating a directory jakarta-tomcat/src/doc/notes and
checking in all the "relevant" mail - like this one ? I'm talking about
proposals, technical notes, etc.

Searching the mail archive to find "good stuff" is hard ( given the
noise), and maybe someone could turn various mails into documentation
( but even if not - we can save the info: if it's hard to find it
almost doesn't exist )

Costin


On Mon, 30 Apr 2001, Dan Milstein wrote:

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