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:
Connector className=org.apache.tomcat.service.PoolTcpConnector
Parameter name=handler
value=org.apache.tomcat.service.connector.Ajp12ConnectionHandler/
Parameter name=port value=8007/
Parameter name=inet value=127.0.0.1/
/Connector
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)Configureadministrate - 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 stdoutstderr 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
