[GLASSFISH-17367] Default JMS host ist set to "localhost", which cannot be resolved by appclient Created: 28/Sep/11  Updated: 22/Nov/11  Resolved: 21/Nov/11

Status: Closed
Project: glassfish
Component/s: jms
Affects Version/s: 3.1.1
Fix Version/s: 3.1.2_b08

Type: Bug Priority: Critical
Reporter: mkarg Assignee: Satish Kumar
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Win7 Pro SP1 64 Bit



 Description   

glassfish-3.1.1-windows creates a default domain (domain1), which contains the following line:

<jms-host name="default_JMS_host" host="localhost" port="7676" admin-user-name="admin" admin-password="admin" lazy-init="true"/>

The problem is the word "localhost", as it gets transferred to remote appclients in an unchanged way. As soon as a client program running in ACC tries to start a JMS connection, it will fail as it tries to reach "localhost".

Obviously, the ACC should get provided the JMS server's real hostname by the server instead of "localhost", or even better, the actual IP address to which the JMS port is currently bound.



 Comments   
Comment by scatari [ 13/Oct/11 ]

We could document this, given that the none of the configuration exists for "zip" based installer. I am transferring to admin backend team to see if they can replace "localhost" with the IP address.

Comment by scatari [ 13/Oct/11 ]

Snjezana, Please work with admin team to identify the owner for this issue.

Comment by Snjezana Sevo-Zenzerovic [ 18/Nov/11 ]

Assigning to Tom and cc-ing Tim to get further input. While "localhost" needs to remain in the initial default domain shipped in zip distribution in order to make the configuration portable, maybe it would be possible to replace it with fully qualified hostname prior to the point where configuration gets used by remote appclient.

Comment by Tom Mueller [ 19/Nov/11 ]

This looks like something that the ACC needs to handle.

Comment by Tim Quinn [ 19/Nov/11 ]

I disagree that this is the responsibility of the ACC.

[The rest of this notes is IIRC - I am not very familiar with what happens internally in this process... ] One of the first steps a JMS client performs is to obtain a ConnectionFactory, either by explicit look-up using JNDI calls or by injection which itself will use JNDI look-up. The factory object will have been set up to refer to whatever host is specified in the jms-host setting. If that is localhost, then that is how the factory object will be set up, and that is what the client will get.

I think the documentation refers, at least briefly, to the need to configure the jms host's address to refer to the host's actual address if it will be used remotely. But I'm not sure about that.

I'm transferring this to the queuing folks, not because I think there is a bug in JMS or MQ that needs fixing but for them to comment on this.

One other note - Aren't there potential problems if somehow GlassFish did automatically place the system's real name into this configuration setting and then the user tries to run disconnected from the network? I think the attempt to resolve the configured, non-"localhost" name will fail because the system cannot reach a DNS server.

Comment by Satish Kumar [ 21/Nov/11 ]

The value of jms-host.host is defaulted to localhost so that it can work with the zip installer. Automatically setting this to the actual hostname is not recommended as Tim has also pointed out. A note to the effect that the user will need to manually configure this if required, is mentioned in the documentation.

Comment by mkarg [ 22/Nov/11 ]

I have to object. This issue is not talking about ZIP bundles but about solely the Windows Installer bundle. In the Windows world, people are used to get jumpstart defaults instead of reading docs since the installer is an active software that can use the complete Windows API - including the functions for checking hostnames and changing XML files. Please forget (just for one minute) all your technical constraints and watch the scene from the administrator's view. After having run the windows installer, you force him to fiddle with the JMS settings to manually provide the host name - yes, of exactly that host that just did run the installer. And, EVERYONE does that in THE EXACTLY SAME WAY. My goodness, why shall it be so impossible for the installer to just do that automatically? I mean, is it so unbelievable hard to change the installer code in a way that just replaces localhost by %HOSTNAME%? Sorry, but this is just ridiculous. I do not see anything "invalid" in this bug report and expect a solution in the next release to stop all the GF competitors out there from loughing out loudly!

Generated at Tue May 05 13:30:27 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.