users@glassfish.java.net

Re: GlassFish v2 problem with localhost

From: Pete Ehlke <pdehlke_at_gmail.com>
Date: Tue, 7 Oct 2008 14:26:53 -0500

On Tue, Oct 7, 2008 at 12:58 PM, Dick Davies
<rasputnik_at_hellooperator.net> wrote:
>
> On Tue, Oct 7, 2008 at 4:46 PM, <glassfish_at_javadesktop.org> wrote:
>
> > In addition, and since I am part of a network, I added the name of my pc on the network, and the fully qualified name to the 127.0.0.1 line. It ended up being something like this:
> >
> > 127.0.0.1 localhost myPcNetworkName myPcNetworkName.MyNetworkDnsName.FullName.com orwhatever
>
> Sorry, sysadmin. Can't let this one go :)
>
> please:
>
> Don't Do That.
>
> 127.0.0.1 is localhost, it's really not your network hostname.
> This will almost always bite you down the line.
>

Sorry, another sysadmin. In a Solaris 10 container, this is the
default, and correct, behavior. Local containers cannot manipulate
their network interfaces, so /etc/hosts only contains a single entry
for each of ipv4 and ipv6. Those entries are for 127.0.0.1 and ::1.
The global zone configures the network for the local containers when
they start.

As others have noted, this causes JMS brokers of type LOCAL and
EMBEDDED to fail, because the brokers in an app server cluster
automatically create a broker cluster. loopback is not an appropriate
interface on which to run a broker cluster, since the cluster nodes
must communicate with each other, and the broker refuses to
initialize.

I work around this by using REMOTE brokers.

glassfish could work around this by working out the machine's FQDN and
then adding -Dimq.hostname=<fqdn> to the broker's JAVA_ARGS when it
gets forked.

-Pete