Al Sutton wrote:
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]



Reply via email to