On Mon, May 07, 2001 at 02:11:35PM +0200, GOMEZ Henri wrote:
> You're right. TC still use ajp12 at its default connector so it
> listen all interface (which I agree could rise problem). I'm
> using in my prod systems, ajp13 to connect webservers and
> ajp12 only for the shutdown purpose (and listen only on localhost)
>
> >Here is the same test but with slightly modified server.xml:
> >
> > value="org.apache.tomcat.service.connector.Ajp12ConnectionHandler"/>
> >
> >
> >
>
> Thanks to mention this one. The "inet" is not a well know and used param.
>
> >Please note that port 8007 is bound to 127.0.0.1 interface _ONLY_.
>
> The secure way.
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:)
> 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???
It almost sounds like merging two things that serve totally different purpose
together. What if you want to add more commands in the future? Would you
really want to add these commands into ALL versions of protocol? And how do
you handle these commands if you don't?
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.
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 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.
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.
2) changed shutdown code to make it work correctly if "inet" parameter is
used.
3) modified mod_jk logger function to print timestamps in Apache Web server
style.
4) modified tomcat.sh file in "bin" to redirect stdout&stderr to a log file
(people complained about not seeing System.out.println() stuff)
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).
Sorry for the long E-Mail:) Hope you've read it:)
--
oo Andrey
oo
oOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOo
"All mail clients suck. This one just sucks less.
