tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrey Kartashov <>
Subject Re: Tomcat 3.2.2 beta 4 - AJP14 continuation
Date Tue, 08 May 2001 15:59:46 GMT

On Mon, May 07, 2001 at 11:49:25PM +0200, GOMEZ Henri wrote:
> >Should it become default? I hope the answer is yes:)
> >It also has another value: "inet" is not a well-known
> >parameter. Having it in default server.xml along with a little 
> >comment about
> >what it does may compensate for the lack of proper documentation:)
> +1 for the addition in server.xml (Marc, Larry ?)

> >I don't really understand why Ajp protocol should handle 
> >shutdown command
> >at all. I agree that there may be a need for some kind of servlet that 
> >handles this operation but WHY THROUGH Ajp protocol???
> Adding shutdown in ajp14 will help a web admin to build a control
> deck to shutdown from ONE POINT some or all of its Tomcat.
Correct me if I'm wrong, but it's possible to do the same thing with
"admin" servlet. Besides, it seems to me that most of the time sys admin
wants not to shutdown servers permanently but rather update class files
or JSPs or reconfigure them and then restart. I think that having "admin"
servlet that supports all (or some of) this things will ease this task a lot.
Also it'll make Ajp protocol a tiny bit simpler which is always a "good thing"

Here is one possible "use case" I've come up with:
Sys admin has a "script" that executes "rsync" to update all the load-balanced
TC machines. He than executes another script that sends HTTP "restart" command
to all the TC's. Restart can be accomplished as following:
In JVM: System.exit(EXIT_RESTART); // EXIT_RESTART !=0 :)
In loop while exit code == EXIT_RESTART;

> >	Some people (including myself) like doing configuration 
> >manually in
> I'm like you and do by hand all my configuration, and
> set my JkMount in VirtualHost. But many starting users
> will like the autoconf features.
> Note that JkMount could still be used and JkAutoMount
> is then mandatory...
Don't get me wrong:) I'm not against JkAutoMount - it's cool.
What I'm trying to say is:
To address this group of people I'd suggest splitting distribution into
"pure java" Tomcat part + extensions. This way only NECESSARY files will
make their way to "conf" directory. If someone is (for example) interested
in running stand-alone TC - he only downloads "pure java" part. If he needs
to hook it into some Web server like Apache or IIS - he downloads "apache
extensions" or "IIS extensions", etc.

> >	Some people would prefer to use some UI tool to 
> Some Admin Servlet could do the job....
My point exactly:)

> >2) changed shutdown code to make it work correctly if "inet" 
> >parameter is used.
> Thanks to (re)send the code to list.
Do you want me to send it again?

> >4) modified file in "bin" to redirect stdout&stderr 
> >to a log file (people complained about not seeing System.out.println()
> stuff)
> Done by the official Tomcat RPM which modify to
> feed /var/log/tomcat.log
Not everyone uses Linux:) Not everyone uses RPM:)
I use linux for developiment (but I prefer getting TC as *.tgz), our production
systems are running Solaris.
I'd still suggest to modify (don't make this fix RPM-only).
There is another cross-platform way of doing the same:

> >5) modified default load balancing behavior to make use of 
> >wireless device's 
> >   "global id" (I'm not giving details on this one because 
> >it's specific to 
> >   what we are doing and probably useless for others. But I'm 
> >not hiding it:)
> >   I can describe it if anyone is interested).
> Please. I realize I must'nt be too stupid since we have done
> many common things :)
I would suggest it if it wasn't:))) I'm not proud of it:)
It's a hack and I know about it's problems and limitations.
That being said - here is what it does:

Problem: We are doing wireless ad serving. One of the business rules says that
we should support "static" URL to ad server. Ad server serves multiple ads -
hence we need to remember what we've served to whom. It can't be part of the
URL (it's static) and it can't be cookie (not all the wireless browsers
have it).

Solution: We are trying to use device's Global Id (part of the request on most
of the devices) as SessionId. The TC java code has been modified accordingly
and LB code has been modified to route based on Global Id ( "session
stickiness" ). This solution doesn't address fail over issue properly.
A better one would be to have persistent sessions (keep them in Data Base or
something ...) but it would cost more. We've made similar modifications to 
JServ and it's been up for some time. Recently we decided to switch to TC
because it supports newer API and is being developed/supported. I reimplemented
modifications in TC as well although it hasn't been tested yet.

As I said - it's not an elegant solution and If the requirement to have this
feature turns out to be not important - we'll get rid of this hack:)

> >Sorry for the long E-Mail:) Hope you've read it:)
> I read all of it. Hope to read you soon.
I'm glad you did:)

oo Andrey
"All mail clients suck. This one just sucks less."
           --  Jeremy Blosser

View raw message