Derby
  1. Derby
  2. DERBY-2426

java -jar derbyrun.jar server shutdown gives the wrong message

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Trivial Trivial
    • Resolution: Unresolved
    • Affects Version/s: 10.2.2.0
    • Fix Version/s: None
    • Component/s: Network Server
    • Urgency:
      Normal
    • Issue & fix info:
      Repro attached

      Description

      If e.g. I have a 10.3 server running and uses derbyrun.jar from 10.2.1.6 to shut down the server, like this:

      $ java -jar ../trunk/jars/sane/derbyrun.jar server start -noSecurityManager
      Apache Derby Network Server - 10.3.0.0 alpha - (516145M) started and ready to accept connections on port 1527 at 2007-03-08 21:48:56.308 GMT
      Apache Derby Network Server - 10.3.0.0 alpha - (516145M) shutdown at 2007-03-08 21:49:18.759 GMT

      $ java -jar db-derby-10.2.1.6-bin/lib/derbyrun.jar server shutdown
      Apache Derby Network Server - 10.2.1.6 - (452058) shutdown at 2007-03-08 21:49:19.269 GMT

      But the server I shutdown is 10.3.0.0 alpha! Also the client reports a different timestamp than the server.

        Activity

        Hide
        Rick Hillegas added a comment -

        Triaged for 10.5.2: assigned normal urgency and noted that a repro is attached.

        Show
        Rick Hillegas added a comment - Triaged for 10.5.2: assigned normal urgency and noted that a repro is attached.
        Hide
        John H. Embretsen added a comment -

        > Plus, the command line help for the shutdown command states:
        >
        > shutdown [-h <host>][-p <portnumber>] [-ssl <sslmode>]

        I've seen that, but I find it strange, because when I try to shutdown a server (started with -h 0.0.0.0) from a remote host using -h <hostNameOfServerHost> I get the following message:

        "DRDA_NeedLocalHost.S:host: <hostNameOfLocalHost> is not local to the server running on 0.0.0.0, so cannot be used for NetworkServerControl commands"

        Show
        John H. Embretsen added a comment - > Plus, the command line help for the shutdown command states: > > shutdown [-h <host>] [-p <portnumber>] [-ssl <sslmode>] I've seen that, but I find it strange, because when I try to shutdown a server (started with -h 0.0.0.0) from a remote host using -h <hostNameOfServerHost> I get the following message: "DRDA_NeedLocalHost.S:host: <hostNameOfLocalHost> is not local to the server running on 0.0.0.0, so cannot be used for NetworkServerControl commands"
        Hide
        Andrew McIntyre added a comment -

        > Doesn't the network server instance to be shut down have to be on the local machine?

        It looks like the setupSocket method used by NetworkServerControlImpl will use whatever hostname / portNumber was passed in on the command line. So, if invoked from the command line, this is to be expected from the code, if not necessarily intuitive.

        Plus, the command line help for the shutdown command states:

        shutdown [-h <host>][-p <portnumber>] [-ssl <sslmode>]

        I guess the real question is "can a server of a lower version be allowed to shutdown a server of higher version without authentication or authorization"? For that question, I have no immediate answer.

        Show
        Andrew McIntyre added a comment - > Doesn't the network server instance to be shut down have to be on the local machine? It looks like the setupSocket method used by NetworkServerControlImpl will use whatever hostname / portNumber was passed in on the command line. So, if invoked from the command line, this is to be expected from the code, if not necessarily intuitive. Plus, the command line help for the shutdown command states: shutdown [-h <host>] [-p <portnumber>] [-ssl <sslmode>] I guess the real question is "can a server of a lower version be allowed to shutdown a server of higher version without authentication or authorization"? For that question, I have no immediate answer.
        Hide
        John H. Embretsen added a comment -

        Andrew commented:

        > Network Server shutdown, when called from the command-line, communicates the shutdown command via a socket connection to the network server specified, which may or may not be on the local machine.

        Doesn't the network server instance to be shut down have to be on the local machine? That's how I interpret the JavaDoc for NetworkServerControl:
        "With the exception of ping, these commands can only be performed from the machine on which the server is running."
        Not that this affects the validity of the argument much, I just wanted to clarify it.

        I can see arguments going both ways here. Yet I must say I too found this to be a bit surprising (or counter-intuitive if you will) the first time I saw this behavior. This may be mainly because of the wording of the message, since a user may be thinking: I did not actually shut down the 10.2.1.6 server, since it was never started, but I used it to shut down a 10.3.0.0 server...

        Show
        John H. Embretsen added a comment - Andrew commented: > Network Server shutdown, when called from the command-line, communicates the shutdown command via a socket connection to the network server specified, which may or may not be on the local machine. Doesn't the network server instance to be shut down have to be on the local machine? That's how I interpret the JavaDoc for NetworkServerControl: "With the exception of ping, these commands can only be performed from the machine on which the server is running." Not that this affects the validity of the argument much, I just wanted to clarify it. I can see arguments going both ways here. Yet I must say I too found this to be a bit surprising (or counter-intuitive if you will) the first time I saw this behavior. This may be mainly because of the wording of the message, since a user may be thinking: I did not actually shut down the 10.2.1.6 server, since it was never started, but I used it to shut down a 10.3.0.0 server...
        Hide
        Andrew McIntyre added a comment -

        Considering what you did here, I would say it is expected behavior.

        Network Server shutdown, when called from the command-line, communicates the shutdown command via a socket connection to the network server specified, which may or may not be on the local machine. The message reporting shutdown is then printed locally by the shutdown instance, and is not a product of the server instance.

        So, the 10.2.1.6 network server sends the shutdown command to the 10.3 network server, which then happily shutsdown. The message being reported on the shutdown side is printed by the 10.2.16 network server classes, and is reporting its version correctly, and the difference in timestamp is due to the fact that you have messages being printed from two different jvm instances. The message on the shutdown side is not sent from the server, but printed by the instance that sent the shutdown command over the network after confirming shutdown close. See NetworkServerControlImpl.shutdown().

        Show
        Andrew McIntyre added a comment - Considering what you did here, I would say it is expected behavior. Network Server shutdown, when called from the command-line, communicates the shutdown command via a socket connection to the network server specified, which may or may not be on the local machine. The message reporting shutdown is then printed locally by the shutdown instance, and is not a product of the server instance. So, the 10.2.1.6 network server sends the shutdown command to the 10.3 network server, which then happily shutsdown. The message being reported on the shutdown side is printed by the 10.2.16 network server classes, and is reporting its version correctly, and the difference in timestamp is due to the fact that you have messages being printed from two different jvm instances. The message on the shutdown side is not sent from the server, but printed by the instance that sent the shutdown command over the network after confirming shutdown close. See NetworkServerControlImpl.shutdown().

          People

          • Assignee:
            Unassigned
            Reporter:
            Bernt M. Johnsen
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:

              Development