RE: Tomcat 3.2.2 beta 4 - AJP14 continuation

[GOMEZ Henri <hg...@slib.fr>]

>
>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 understand your valid requirement, but why not just developp a 
>> servlet in admin which use ajp12 to send (to localhost), the ajp12
>> shutdown command.
>> 
>> >Hope this helps :)
>> 
>> Yes, and I hope you'll take a look at the ajp14 proposal.......
>I did.
>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.

>It almost sounds like merging two things that serve totally 
>different purpose
>together. What if you want to add more commands in the future? 

The AJP14 is not closed, it's just a starting point for discussion.

>Would you 
>really want to add these commands into ALL versions of 
>protocol? And how do
>you handle these commands if you don't?

The AJP15 must handle all commands from AJP14 and will
have its owns one. Also you must have notice about the
negociation at startup. Some asked to add at start of
negociation a string indicating which protocol are supported
by web-server. The servlet engine will then use the higher
common protocol :

ie: web-servlet knows about AJ14/AJP15 but servlet engine only
    AJP14. The protocol used will be AJP14.

    web-servlet knows AJ14/AJP15 and servlet engine AJP14/AJP15/AJP16.
    The discussion will use AJP15.

>IMHO there are few related but different things one wants to 
>do with TC:
>1)Serve requests - handled by Ajp protocol.
>2)Configure&administrate - this one is a bit more complex.
>
>	Some people (including myself) like doing configuration 
>manually in
>	command line interface. Hence there needs to be well 
>defined set of config
>	files and scripts one needs to care about. One of my 
>personal challenges
>	while setting up TC for the first time was to find out 
>what config files
>	are actually necessary. There is whole bunch of files 
>in config directory
>	for ALL the possible platforms/servers, etc. 

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

>	Some people would prefer to use some UI tool to 
>configure the server and
>	issue commands - here is your idea of extending 
>functionality of "admin"
>	application, add shutdown/restart commands to it as 
>well as may be some 
>	other options like configuring "connectors", including 
>configuration of 
>	ports, interfaces,  etc. There may even be some applet 
>for monitoring
>	the log files (like in Sun's JavaWebServer).
>	I think good example is configuration as it is done in 
>"Enhydra".
>	This kind of tool doesn't need any "middle man" in the 
>form of Ajp or any
>	other protocol. It can have hooks directly into server 
>API. The advantage
>	of this is that Ajp protocols remain "plugguble" unlike 
>Ajp12 that you
>	"need to have" to issue simple "shutdown" command and 
>configuration
>	may evolve without any weird dependencies on any 
>particular protocol.

Some Admin Servlet could do the job....

>	Some people MIGHT want to set up distributed 
>environment (read load
>	balancing here) where the same application is 
>physically distributed 
>	across multiple machines but configuration MUST be 
>changed synchronously.
>	This may be handled just by some *NIX scripts, etc but 
>in this case 
>	having some "administration" protocol might be usable 
>to build "centralized"
>	configuration where all the changes are made in one 
>place and communicated
>	to all the balanced servers using some protocol. There 
>are lots of 
>	complicated issues here but this is the place where 
>IMHO some protocol
>	might be NECESSERY. And even than I wouldn't add this 
>features into 
>	any Ajp?? protocols. I'd much rather define another one 
>that again may
>	evolve differently from Ajp protocols but might use Ajp 
>protocol as a
>	transport layer.

AJP13 is still present and supported, but lack some features
needed for Servlet API 2.3. My english is bad but AJP14 WILL
USE AJP13 as transport layer, there will be new commands added
and new cinematic, but AJP14 = AJP13++

>Here is the list of modifications that I've done to TC so far:
>1) changed defaults to bind to 127.0.0.1 interface in server.xml.

Will be changed in server.xml for 3.2/3.3 (Marc/larry are you agree)

>2) changed shutdown code to make it work correctly if "inet" 
>parameter is used.

Thanks to (re)send the code to list.

>3) modified mod_jk logger function to print timestamps in 
>Apache Web server style.

Allready exist in mod_jk in TC 3.3 CVS (another reason to have
web-connector)

>4) modified tomcat.sh 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 tomcat.sh to
feed /var/log/tomcat.log

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

>Sorry for the long E-Mail:) Hope you've read it:)

I read all of it. Hope to read you soon.

Re: Tomcat 3.2.2 beta 4 - AJP14 continuation

[Andrey Kartashov <an...@sonatainc.com>]

Sorry for not replying back sooner. I just wanted to look at the latest stuff
from CVS ( I used to look at my local CVS repository which is based on TC3.2.1).
Couldn't do it sooner - had to to some other things first:)

In case you, guys still interested - here it goes:)
First I'd like to apologize for not looking at CVS sooner. A lot of things
have changed since 3.2.1. I know that you, guys are busy so I'll try to make
it short:)

This is what I think is still relevant:
TC binds to all interfaces. This is insecure (think of "shutdown" command for
example). Also configuration stuff has changed and I haven't found a new way
to "bind" connector to a particular interface.
I'm going to try to implement all this in current jakarta-tomcat repository.
I'll send another mail with diffs (hopefully today) for your review.


On Tue, May 08, 2001 at 10:30:36AM -0700, cmanolache@yahoo.com wrote:
> On Tue, 8 May 2001, Andrey Kartashov wrote:
> 
> > 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.
> 
> +1 on the idea - but for 3.2.2 it's out of question, and for 3.3 someone
> has to do it - and closing bugs has bigger priority.
> 
> If this is an itch for you, and you want to propose something ( and write
> some code ) - we're listening :-)
> 
> I think Henri is also considering spliting the distribution in
> "base tomcat", web applications. The connectors are already in a separate
> RPM.
> 
> BTW, I like very much the idea of keeping the WARs ( examples, admin, 
> etc) in separate distribution files. 
> 
> It was on the "goals" list to produce a minimal container, that
> implements the servlet API and nothing else, and separate the
> "features". That didn't happen so far. 
> 
> Costin
> 
> > 
> > 
> > > >	Some people would prefer to use some UI tool to 
> > [skpd]
> > > 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 tomcat.sh 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 tomcat.sh 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 tomcat.sh (don't make this fix RPM-only).
> > There is another cross-platform way of doing the same:
> > System.setOut(errorLogStream);
> > System.setErr(errorLogStream);
> > 
> > 
> > > >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
oo
oOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOo
"All mail clients suck. This one just sucks less."
           -- http://www.mutt.org/  Jeremy Blosser
oOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOo

Re: Tomcat 3.2.2 beta 4 - AJP14 continuation

[cm...@yahoo.com]

On Tue, 8 May 2001, Andrey Kartashov wrote:

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

+1 on the idea - but for 3.2.2 it's out of question, and for 3.3 someone
has to do it - and closing bugs has bigger priority.

If this is an itch for you, and you want to propose something ( and write
some code ) - we're listening :-)

I think Henri is also considering spliting the distribution in
"base tomcat", web applications. The connectors are already in a separate
RPM.

BTW, I like very much the idea of keeping the WARs ( examples, admin, 
etc) in separate distribution files. 

It was on the "goals" list to produce a minimal container, that
implements the servlet API and nothing else, and separate the
"features". That didn't happen so far. 

Costin

> 
> 
> > >	Some people would prefer to use some UI tool to 
> [skpd]
> > 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 tomcat.sh 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 tomcat.sh 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 tomcat.sh (don't make this fix RPM-only).
> There is another cross-platform way of doing the same:
> System.setOut(errorLogStream);
> System.setErr(errorLogStream);
> 
> 
> > >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:)
> 
> 

Re: Tomcat 3.2.2 beta 4 - AJP14 continuation

[Andrey Kartashov <an...@sonatainc.com>]

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 ?)
Thanks!

> >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 tomcat.sh: loop while exit code == EXIT_RESTART;


> >	Some people (including myself) like doing configuration 
> >manually in
[skpd]
> 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 
[skpd]
> 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 tomcat.sh 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 tomcat.sh 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 tomcat.sh (don't make this fix RPM-only).
There is another cross-platform way of doing the same:
System.setOut(errorLogStream);
System.setErr(errorLogStream);


> >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
oo
oOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOo
"All mail clients suck. This one just sucks less."
           -- http://www.mutt.org/  Jeremy Blosser
oOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOo