glassfish
  1. glassfish
  2. GLASSFISH-16440

change message to user when trying to start Glassfish using same binary that started original Glassfish process

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 3.1
    • Fix Version/s: future release
    • Component/s: admin
    • Labels:
      None

      Description

      When I try to start Glassfish twice, using the same binary, it doesn't detect this, and reports generic message about some process already started:

      "There is a process already using the admin port 4848 – it probably is another instance of a GlassFish server."

      There is indeed a process already using the admin port, but this part of the message lead me to believe that it thought it was another binary starting itself to create an instance of Glassfish server - "it probably is another instance of a GlassFish server". Is there any way to know using process ID and path comparisions, along with domain.xml to detect which binary of Glassfish was started that is using port already?

      Here is what I see:

      C:\glassfish31\glassfish3\glassfish\jersey\samples>which asadmin
      c:/glassfish31/glassfish3/glassfish/bin/asadmin.bat

      C:\glassfish31\glassfish3\glassfish\jersey\samples>asadmin start-domain domain1
      Waiting for domain1 to start ...
      Successfully started the domain : domain1
      domain Location: C:\glassfish31\glassfish3\glassfish\domains\domain1
      Log File: C:\glassfish31\glassfish3\glassfish\domains\domain1\logs\server.log
      Admin Port: 4848
      Command start-domain executed successfully.

      C:\glassfish31\glassfish3\glassfish\jersey\samples>asadmin start-domain domain1
      There is a process already using the admin port 4848 – it probably is another instance of a GlassFish server.
      Command start-domain failed.

        Activity

        Hide
        Tom Mueller added a comment -

        Do you have a suggestion about what the message should say in the example that you provided at the end of the description?

        The start-domain could try to do the following:

        1. Look in the config directory of the domain that you are trying to start for a "pid" file, and if one is there, and that pid is active on the system, then the message could say, "the DAS you are trying to start is already running".

        2. If there is no pid file or the pid in that file is not active on the system, start-domain could look at the other domains in the domains directory it is using (or in the default domains directory) to see if there are any other domains that also use the same port, and if those domains have pid file and one of those pids is active, then it could print a message that says, "such and such domain is already running and it uses the same port as this domain".

        3. At this point, the process listening on port 4848 might be a GlassFish DAS for a domain from an entirely different install of GlassFish or from a non-default domains directory. Using the capabilites of "jps" we could look at the process information for the Java process running on the system to see if any ASMain classes are running, and from the command line arguments for the process, we could determine the config directory for the process, and from that determine if that process is listening on the requested port (this requires parsing the domain.xml for a potentially different version of GlassFish). Start-domain could then look for a pid directory for that server and see if it matches the pid that we are looking at and if so, print a message as in step 2. Depending on how ASMain was started, the command line information may or may not be available.

        4. If the process hasn't been found yet, start-domain could probe port 4848 by sending a message to it to see how it responds. If it responds with something that looks like GlassFish, we could print a message saying, "port 4848 is in use by a process that is very likely a GlassFish process from another install or a different domains directory". However, probing an unknown server might be considered unfriendly, so a command option might be needed to have start-domain do this.

        5. If the probe doesn't yield anything, then start-domain could print a message that says, "there is a process already using port 4848, but start-domain could not determine anything about what that process might be"

        Show
        Tom Mueller added a comment - Do you have a suggestion about what the message should say in the example that you provided at the end of the description? The start-domain could try to do the following: 1. Look in the config directory of the domain that you are trying to start for a "pid" file, and if one is there, and that pid is active on the system, then the message could say, "the DAS you are trying to start is already running". 2. If there is no pid file or the pid in that file is not active on the system, start-domain could look at the other domains in the domains directory it is using (or in the default domains directory) to see if there are any other domains that also use the same port, and if those domains have pid file and one of those pids is active, then it could print a message that says, "such and such domain is already running and it uses the same port as this domain". 3. At this point, the process listening on port 4848 might be a GlassFish DAS for a domain from an entirely different install of GlassFish or from a non-default domains directory. Using the capabilites of "jps" we could look at the process information for the Java process running on the system to see if any ASMain classes are running, and from the command line arguments for the process, we could determine the config directory for the process, and from that determine if that process is listening on the requested port (this requires parsing the domain.xml for a potentially different version of GlassFish). Start-domain could then look for a pid directory for that server and see if it matches the pid that we are looking at and if so, print a message as in step 2. Depending on how ASMain was started, the command line information may or may not be available. 4. If the process hasn't been found yet, start-domain could probe port 4848 by sending a message to it to see how it responds. If it responds with something that looks like GlassFish, we could print a message saying, "port 4848 is in use by a process that is very likely a GlassFish process from another install or a different domains directory". However, probing an unknown server might be considered unfriendly, so a command option might be needed to have start-domain do this. 5. If the probe doesn't yield anything, then start-domain could print a message that says, "there is a process already using port 4848, but start-domain could not determine anything about what that process might be"
        Hide
        jbenoit added a comment -

        I'm not sure what exact message I'd expect to see in my scenario. Your comments and messages back to user are more helpful I think than what user currently sees, and are on the right track of what I'd expect and hope to see. Maybe something like this:

        There is a process already using the admin port 4848 – it is another instance of a GlassFish server.
        Not successful in starting the domain : domain1
        Other Glassfish Domain domain1 already using this port: 4848 - domain Location: C:\another\glassfish31\glassfish3\glassfish\domains\domain1

        Command start-domain failed.

        Maybe I'm being overly verbose, but you get the idea.

        It just struck me as odd that glassfish didn't know that it was "this same glassfish" that was just started, and reported back to user that port 4848 was in use in previous command. The ouptut from the first start-domain command is clearly telling user which glassfish is started, including path information, i.e.
        "Successfully started the domain : domain1
        domain Location: C:\glassfish31\glassfish3\glassfish\domains\domain1
        Log File: C:\glassfish31\glassfish3\glassfish\domains\domain1\logs\server.log
        Admin Port: 4848"

        Than along comes this second attempt to start-domain in the same shell, using the same path to the same glassfish, yet the glassfish couldn't somehow leverage some information from some place to report back to user that "this same glassfish" is already started. Makes glassfish look like it's not maximizing the known set of information available when producing error message back to user, it doesn't match what seems to be obvious when reporting "it probably is another instance of a GlassFish server."

        My use case is this: I'm testing multiple binary installs of various Glassfish versions, both inside Netbeans and standalone. Sometimes I start Glassfish within Netbeans IDE and leave it running. I then do some other testing of another Glassfish install outside of Netbeans. When I try to start standalone Glassfish, it complains that port is already in use. Then I remember that I may have started Glassfish within Netbeans, so I stop domain running inside Netbeans. Then my standalone Glassfish domain can start. Other times Glassfish in Netbeans isn't the culprit, it's another standalone install of Glassfish started and left running, someplace, which I have to track down manually. I was hoping that Glassfish itself could be more helpful identifying the culprit process that is using default port, thus blocking another instance of Glassfish from starting. The analogy is "port in use" messages seen in server.log, which now identify which port is already in use, so user can change conflicting ports, 3700, 7676 etc. If Glassfish's asadmin start-domain domain1 command can be more helpful in helping users identify which process is using port, and if it's Glassfish process using that port, help user find path to that process, then user can more quickly stop the blocking process, or change conflicting ports, or take whatever appropriate corrective action necessary.

        Ideally, from the use case scenario/perspective I've described, I think I'd like to know what path to "other Glassfish" is running so I could stop it, if it's Glassfish, that is using port that blocks new Glassfish from starting.

        Show
        jbenoit added a comment - I'm not sure what exact message I'd expect to see in my scenario. Your comments and messages back to user are more helpful I think than what user currently sees, and are on the right track of what I'd expect and hope to see. Maybe something like this: There is a process already using the admin port 4848 – it is another instance of a GlassFish server. Not successful in starting the domain : domain1 Other Glassfish Domain domain1 already using this port: 4848 - domain Location: C:\another\glassfish31\glassfish3\glassfish\domains\domain1 Command start-domain failed. Maybe I'm being overly verbose, but you get the idea. It just struck me as odd that glassfish didn't know that it was "this same glassfish" that was just started, and reported back to user that port 4848 was in use in previous command. The ouptut from the first start-domain command is clearly telling user which glassfish is started, including path information, i.e. "Successfully started the domain : domain1 domain Location: C:\glassfish31\glassfish3\glassfish\domains\domain1 Log File: C:\glassfish31\glassfish3\glassfish\domains\domain1\logs\server.log Admin Port: 4848" Than along comes this second attempt to start-domain in the same shell, using the same path to the same glassfish, yet the glassfish couldn't somehow leverage some information from some place to report back to user that "this same glassfish" is already started. Makes glassfish look like it's not maximizing the known set of information available when producing error message back to user, it doesn't match what seems to be obvious when reporting "it probably is another instance of a GlassFish server." My use case is this: I'm testing multiple binary installs of various Glassfish versions, both inside Netbeans and standalone. Sometimes I start Glassfish within Netbeans IDE and leave it running. I then do some other testing of another Glassfish install outside of Netbeans. When I try to start standalone Glassfish, it complains that port is already in use. Then I remember that I may have started Glassfish within Netbeans, so I stop domain running inside Netbeans. Then my standalone Glassfish domain can start. Other times Glassfish in Netbeans isn't the culprit, it's another standalone install of Glassfish started and left running, someplace, which I have to track down manually. I was hoping that Glassfish itself could be more helpful identifying the culprit process that is using default port, thus blocking another instance of Glassfish from starting. The analogy is "port in use" messages seen in server.log, which now identify which port is already in use, so user can change conflicting ports, 3700, 7676 etc. If Glassfish's asadmin start-domain domain1 command can be more helpful in helping users identify which process is using port, and if it's Glassfish process using that port, help user find path to that process, then user can more quickly stop the blocking process, or change conflicting ports, or take whatever appropriate corrective action necessary. Ideally, from the use case scenario/perspective I've described, I think I'd like to know what path to "other Glassfish" is running so I could stop it, if it's Glassfish, that is using port that blocks new Glassfish from starting.
        Hide
        jbenoit added a comment -

        To clarify, in my original scenario, where I start glassfish twice using same binary from same path, proposed message could be:

        There is a process already using the admin port 4848 – it is another instance of a GlassFish server.
        Not successful in starting the domain : domain1
        Glassfish Domain domain1 already using this port: 4848 - domain Location: C:\glassfish31\glassfish3\glassfish\domains\domain1

        Command start-domain failed.

        In the case where it's a different Glassfish binary install from different location that was started and left running, thus blocking my new Glassfish from starting, then this type of message may be more appropriate and help point to location of offending Glassfish occupying conflicting port:

        There is a process already using the admin port 4848 – it is another instance of a GlassFish server.
        Not successful in starting the domain : domain1
        Glassfish Domain domain1 already using this port: 4848 - domain Location: C:\another\glassfish31\glassfish3\glassfish\domains\domain1

        Command start-domain failed.

        the key is to include path to another "domain Location" so we know where to go to stop process, or take other corrective action.

        Show
        jbenoit added a comment - To clarify, in my original scenario, where I start glassfish twice using same binary from same path, proposed message could be: There is a process already using the admin port 4848 – it is another instance of a GlassFish server. Not successful in starting the domain : domain1 Glassfish Domain domain1 already using this port: 4848 - domain Location: C:\glassfish31\glassfish3\glassfish\domains\domain1 Command start-domain failed. In the case where it's a different Glassfish binary install from different location that was started and left running, thus blocking my new Glassfish from starting, then this type of message may be more appropriate and help point to location of offending Glassfish occupying conflicting port: There is a process already using the admin port 4848 – it is another instance of a GlassFish server. Not successful in starting the domain : domain1 Glassfish Domain domain1 already using this port: 4848 - domain Location: C:\another\glassfish31\glassfish3\glassfish\domains\domain1 Command start-domain failed. the key is to include path to another "domain Location" so we know where to go to stop process, or take other corrective action.

          People

          • Assignee:
            kumara
            Reporter:
            jbenoit
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated: