Is there any reason why it doesn't try localhost first? Using localhost before anything else would have the following benefits;
a) Would ensure that only really strange network configs would be affected (i.e. those where localhost is not the local host). b) Make use of the speed advantage some OS's have in their implementation of the loopback address. c) Avoid any wacky differences in the implementation of InetAddress.getLocalHost() between JVMs/OSs/etc.
Off the top off my head I can't see the advantages of using the result of InetAddress.getLocalHost() first.
What do you mean by 'try localhost first' ? The name 'localhost', or '127.0.0.1' or whatever the number is in IPV6 ? I guess the reason for InetAddress.getLocalHost() is the wacky differences between OSes :-),
and if it's broken on a platform - it should be fixed ( by Sun or OS vendor )
Costin
Al.
-----Original Message----- From: Bill Barker [mailto:[EMAIL PROTECTED] Sent: 03 February 2005 19:11 To: Tomcat Developers List Subject: Re: The FIX - Shutdown not working under SLES8 and FC2
If no address is configured, ChannelSocket attempts the shutdown on InetAddress.getLocalHost(). Personally, I'm not inclined to change this as it points to a network configuration problem if this is unreachable. However, you might try complaining to Sun about how they have implemented getLocalHost on SLES8.
----- Original Message ----- From: <[EMAIL PROTECTED]> To: "Tomcat Users List" <tomcat-user@jakarta.apache.org> Cc: <tomcat-dev@jakarta.apache.org> Sent: Thursday, February 03, 2005 2:14 AM Subject: The FIX - Shutdown not working under SLES8 and FC2
After some playing around I think I've tracked down what the fix is, and I'd like to throw an idea out as to what could be happening.
First the fix. The fix is to explicitly state in the AJP13 connector that the connector should ONLY bind to the loopback address (i.e. add address="127.0.0.1"). Maybe this should be made the default because;
a) it's a fix to the issue. and b) it also enhances security.
Those people who are using AJP13 between machines should have the knowlege to re-configure the connector to allow connections between different machines.
Now the suggestion as to why this is happening.
My machine is behind a firewall, and therefore has non-routable IP addresses (192.168.x.x). If you lookup the full hostname (a.b.c.d) on the machine the hosts file resolves it to the private IP, if you look it up using DNS it resolves to the public IP address of the firewall. If you lookup the machine name only (a) from on the machine or anywhere else it resolves via DNS to the public IP of the firewall.
From what I can tell the AJP13 connector looks up the hostname only, (which resolves it to the public IP address), then tries to connect to the AJP13 port on the public IP address, and because the firewall blocks this traffic, does not connect, and then gives up.
To back this up I have put the hostname on it's own into the hosts file (i.e. a resolves to the private IP), and everything worked again.
Before everyone shouts "you've got a strange config, it's your problem", I'd like to re-iterate that this issue can be avoided in many ways, and my personal beleif is that the order of preference of fixes would be;
1) Add the address="127.0.0.1" to the default server.xml (which also has the side effect of increasing security). 2) If no address is specified then make the shutdown system start by trying to connect to localhost as opposed to what seems to be the current behaviour of attempting to resolve to an external address first. 3) Require everyone to have the short hostname configured to resolve to their local IP.
The reasons for this ordering is that 1 is the least effort by the fewest people, 2 is more effort but by a small group, 3 has a potential impact on all users and no matter where you document it will still be missed by those who beleive in unpack and run.
Regards,
Al.
Al Sutton <[EMAIL PROTECTED]> wrote on 03.02.2005, 07:58:16:
Ben,
Thanks for this. I'm not using any settings in JAVA_OPTS as shown below;
[EMAIL PROTECTED] al]$ env | grep -i JAVA JRE_HOME=/usr/java/jdk1.4/jre
PATH=/usr/java/jdk1.4/bin:/home/al/utils/apache-ant-1.6.2/bin:/usr/kerberos/
bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin JAVA_HOME=/usr/java/jdk1.4 [EMAIL PROTECTED] al]$
I've tried this on two machines, one an Athlon XP 2400+ running FC2, and
the
other a Dual Xeon 2.8 GHz running SLES 8, both showed the same problem, so I'm pretty sure it's not hardware. The machines are also geographically seperated and do not operate on the network (ones on my LAN at home, the others on a LAN at work), so I'm pretty sure it's not related to the environment external to the machine.
I'm going to upgrade to _07 and get the latest kernel and try again, as currently the only difference seems to be that your execting startup and shutdown from within the bin directory and I'm executing it from the top level (i.e. doing bin/startup.sh and bin/shutdown.sh).
Thanks again,
Al.
-----Original Message----- From: Ben Souther [mailto:[EMAIL PROTECTED] Sent: 02 February 2005 23:32 To: Tomcat Users List Subject: RE: Shutdown not working under SLES8 and FC2
On Wed, 2005-02-02 at 17:11, Ben Souther wrote:
On Wed, 2005-02-02 at 16:43, Al Sutton wrote: Hmmm The latest updates gives me;
Linux host 2.6.10-1.9_FC2 #1 Thu Jan 13 17:54:57 EST 2005 i686 athlon
i386
GNU/Linux
and I'm on JDK 1.4.2_06 as opposed to _05.
Would it be possible for you to upgrade?, I'd like to have the exact
same
environment, but please don't put yourself out or risk a critical environment.
OK, here you go. It turns out that I did have _06 on this machine. I also have 2.6.10-1.9_FC2 (which is no longer the latest BTW ;)).
Once again, I started and stopped without a problem. Here is the screen dump: --------------------------------------------------------------------------
--
---- [EMAIL PROTECTED] bin]$ uname -a Linux bsouther 2.6.10-1.9_FC2 #1 Thu Jan 13 17:54:57 EST 2005 i686 athlon i386 GNU/Linux [EMAIL PROTECTED] bin]$ export JAVA_HOME=/usr/local/j2sdk1.4.2_06 [EMAIL PROTECTED] bin]$ ./startup.sh Using CATALINA_BASE: /home/bsouther/tc_test/jakarta-tomcat-5.5.7 Using CATALINA_HOME: /home/bsouther/tc_test/jakarta-tomcat-5.5.7 Using CATALINA_TMPDIR: /home/bsouther/tc_test/jakarta-tomcat-5.5.7/temp Using JRE_HOME: /usr/local/j2sdk1.4.2_06 [EMAIL PROTECTED] bin]$ ./shutdown.sh Using CATALINA_BASE: /home/bsouther/tc_test/jakarta-tomcat-5.5.7 Using CATALINA_HOME: /home/bsouther/tc_test/jakarta-tomcat-5.5.7 Using CATALINA_TMPDIR: /home/bsouther/tc_test/jakarta-tomcat-5.5.7/temp Using JRE_HOME: /usr/local/j2sdk1.4.2_06 Created MBeanServer with ID: e94e92:101d55eb6c4:-8000:bsouther:1 [EMAIL PROTECTED] bin]$ ps -ef | grep java bsouther 4714 4595 0 18:19 pts/0 00:00:00 grep java [EMAIL PROTECTED] bin]$ --------------------------------------------------------------------------
--
----
This matches your configuration exactly. I also tried with _07 and the latest kernel (as of this afternoon ***.12 I believe).
And you definitely aren't running with any JAVA_OPT settings? Maybe you have a hardware issue. Have you tried on another machine?
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments.
In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
