[GLASSFISH-15471] better error message when unable to connect to the server Created: 06/Jan/11  Updated: 07/Jan/11

Status: Open
Project: glassfish
Component/s: command_line_interface
Affects Version/s: 3.1_b36
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: jbenoit Assignee: Bill Shannon
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

request a better error message when unable to connect to the server, but the --host option is the default localhost, as shown in use case below. In this case, asadmin should be able to look at the local domain information and see what the port might be to determine if the server(s) is running.

==========
Use case:
==========
if i change domains/domain1/domain.xml
admin-listener port="46612" i get errors below. if i change admin-port back to 4848 it doesn't error.

// start domain1 on non-default port 46612
$ ./asadmin start-domain domain1
Waiting for domain1 to start ................
Successfully started the domain : domain1
domain Location: /space/glassfish3/glassfish/domains/domain1
Log File: /space/glassfish3/glassfish/domains/domain1/logs/server.log
Admin Port: 46612
Command start-domain executed successfully.

$ ./asadmin list-components
Remote server does not listen for requests on [localhost:4848]. Is the server up?
No such local command, list-components. To run remote commands, start the application server (e.g. 'asadmin start-domain').
Command list-components failed.

$ ./asadmin list-components domain
Remote server does not listen for requests on [localhost:4848]. Is the server up?
No such local command, list-components. To run remote commands, start the application server (e.g. 'asadmin start-domain').
Command list-components failed.

From this output above, I knew I did asadmin start-domain, and pieced together that it is a port problem when i saw 4848, knowing I switched my admin-port to non-default. Would be better to be explicitly told it's a port problem if we know that is cause.

can this reporting be more helpful when I'm not using default admin port? Maybe something like:

$ ./asadmin list-components
Remote server does not listen for requests on [localhost:4848]. Detected that server is up, but using non-default admin-port, so pass --port <port_number> option.
No such local command, list-components. To run remote commands, start
the application server (e.g. 'asadmin start-domain').
Command list-components failed.

Here is the motivation/use case email thread from users@glassfish.java.net reiterating as to why this is requested:

http://java.net/projects/glassfish/lists/users/archive/2011-01/message/56



 Comments   
Comment by Bill Shannon [ 06/Jan/11 ]

Let me see if I understand what you want...

If the connection fails, you want it to look in the domain
directory (assuming the domain is local? or only if the host
is "localhost"?) and find the domain.xml (only if there's only
one domain? or only looking at the domain named "domain1"?),
find the port for the admin server for that domain, find out
if that domain is actually running on localhost on that port,
and then suggest that you use that port number in the future?

Is that right?

If it did all that, would it be better to just retry the command
with the port number it found, as long as you were using the
default port, and as long as the port number it found wasn't
the default port?

Is it better to assume "you probably meant port 46612" and keep
going, even though sometimes it would be wrong?

Or is it better to say "maybe you meant port 46612? if so, try
again with that port", so as to avoid ever accidentally connecting
to the wrong server?

Comment by vince kraemer [ 06/Jan/11 ]

Bill...

I would propose a fourth way... which is a mix between your "assume --port 46612 and run the risk of being wrong" and "provide a message that tells the user: maybe you should retype the command with --port 46612"

Does the following 'output' make sense...

$ ./asadmin list-components
Remote server does not listen for requests on [localhost:4848]. Detected that a Glassfish Server is running on port 46612.
Execute the command 'asadmin --port 46612 list-components'? (Y|n) <cursor stopped here>

If the user selects 'n', the command would complete with output like that shown below.

No such local command, list-components. To run remote commands, start
the application server (e.g. 'asadmin start-domain').
Command list-components failed.

If the user chose Y, then the 'new' command would execute and the output would appear.

Comment by jbenoit [ 07/Jan/11 ]

I like Vince's idea better than what is currently implemented, and I think it addresses your questions. It's a more appropriate response being returned to user in this use case.

To see current response - "Remote server does not listen for requests on [localhost:4848]. Is the server up?"

I answer "yes" to this question, but it still doesn't help me solve the problem. Yes the server's up, so now what should I do? If the server wasn't started, I'd answer "No", and then go start the server. I'd then see if this error message went away and if the command executed properly, but it still would return the same error.

Looking at other text from response I see "Remote server does not listen for requests on [localhost:4848]." That was my clue that it's looking at default port 4848, but I know that admin-port was changed. I tried to discover how to get this port info known to this command, so it wouldn't think it was using default 4848 port. That lead to me emailing users@glassfish.java.net alias asking how to pass port to list-components command, after not finding what I was looking for in 'asadmin --help list-components', see http://java.net/jira/browse/GLASSFISH-15470

The more information given back to the user initially, of how to fix the command that isn't working, the better user's chances of solving this problem, without reading "--help list-components" or consulting users email alias.

Comment by Bill Shannon [ 07/Jan/11 ]

This is one of those cases where we have to be careful that improving the situation in
a common case doesn't mislead people or set expectations that can't be met for the
less common cases.

"Automagically" choosing the correct port number in the simple case would probably lead
to surprises later.

Doing as suggested and prompting the user (when interactive) in the simple case is
probably ok. But note that as soon as you create a second domain (e.g., for testing),
you'll no longer get a prompt because there's no way to know which domain you intended
to target. And if you ever actually do remote administration, you might be surprised
at the results in this case.

Once you leave the simple case (single local domain) you really do need to understand
the administration model and the use of host names and port numbers.

Still, we could do better in this case, although I consider it relatively low priority.

Generated at Tue May 05 12:21:04 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.