glassfish
  1. glassfish
  2. GLASSFISH-17915

THE EXECUTION OF THE APP THAT WAS DEPLOYED TO THE NEW VIRTUAL SERVER - FAILED.

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 4.0_dev
    • Fix Version/s: 4.0
    • Component/s: web_container
    • Labels:
      None

      Description

      Was executed Admin CLI test against BG 4.0 b13. One test failed, that test
      executed such commands on the local machine:
      =====================================================
      asadmin --user admin --host jed-asqe-20 --port 4848 create-virtual-server
      --httplisteners http-listener-2 --target sa_server1 --hosts 10.133.185.1
      --state=on vs123
      Command create-virtual-server executed successfully.

      asadmin --user admin --host jed-asqe-20 --port 4848 delete-virtual-server
      --target sa_server1 vs123
      Command delete-virtual-server executed successfully.

      asadmin --user admin --host jed-asqe-20 --port 4848 create-http-listener
      --listeneraddress 0.0.0.0 --listenerport 39993 --defaultvs server --target
      sa_server1 --servername jed-asqe-20 httpls1
      Command create-http-listener executed successfully.

      asadmin --user admin --host jed-asqe-20 --port 4848 create-virtual-server
      --httplisteners httpls1 --target sa_server1 --hosts 10.133.185.1 --state=on
      vs123
      Command create-virtual-server executed successfully.

      asadmin --user admin --host jed-asqe-20 --port 4848 list-virtual-servers
      --target sa_server1
      [2011-12-01T20:51:35.82] server
      [2011-12-01T20:51:36.17] __asadmin
      [2011-12-01T20:51:36.17] vs123

      asadmin --user admin --host jed-asqe-20 --port 4848 deploy --target
      sa_server1 --virtualservers vs123 helloworld.war

      Application deployed with name helloworld.
      Command deploy executed successfully.

      /export/hudson/tools/jdk1.6.0_26-64/bin/java -jar
      /export/hudson/workspace/cli1/appserver-sqe/lib/tonga-util/hreq.jar -host
      10.133.185.1 -port 39993 -ttype Get -req helloworld/HelloWorld
      [2011-12-01T20:51:39.26] ---------- Request output #0 -------------
      [2011-12-01T20:51:39.98] java.io.FileNotFoundException:
      http://10.133.185.1:39993/helloworld/HelloWorld?
      [2011-12-01T20:51:39.98] at
      sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.j
      ava:1434)
      [2011-12-01T20:51:39.98] at Get.makeRequest(Get.java:32)
      [2011-12-01T20:51:39.98] at HttpRequest.run(HttpRequest.java:20)
      [2011-12-01T20:51:39.98] at java.lang.Thread.run(Thread.java:662)
      [2011-12-01T20:51:39.98]
      [2011-12-01T20:51:39.98] ---------- ------------------------- -------------

      ==========================================================================
      So the execution of the helloworld app - failed. I've reproduced this issue
      several times on different platforms. Please see all logs for that test
      under:
      http://agni-1.us.oracle.com/asqe-logs/export1/4.0/Results/cli_tonga/12-01-2011_13_27/hudson.Linux.amd64/se_create_vs_httplist_test/

      When the same test on the same machine was executed against GF 3.1, the
      execution of helloworld - passed:
      ===============================================================
      /export/hudson/tools/jdk1.6.0_26-64/bin/java -jar
      /export/hudson/workspace/cli1/appserver-sqe/lib/tonga-util/hreq.jar -host
      10.133.185.1 -port 40645 -ttype Get -req helloworld/HelloWorld
      [2011-07-12T22:06:12.73] ---------- Request output #0 -------------
      [2011-07-12T22:06:12.90] <html>
      [2011-07-12T22:06:12.90] <head>
      [2011-07-12T22:06:12.90] <title>HelloWorld!.</title>
      [2011-07-12T22:06:12.90] </head>
      [2011-07-12T22:06:12.90] <body>
      [2011-07-12T22:06:12.90] HelloWorld!.
      [2011-07-12T22:06:12.90] </body>
      [2011-07-12T22:06:12.90] </html>
      [2011-07-12T22:06:12.90]
      [2011-07-12T22:06:12.90] ---------- ------------------------- ------

        Activity

        Hide
        Hong Zhang added a comment -

        assign to web team for initial evaluation

        Show
        Hong Zhang added a comment - assign to web team for initial evaluation
        Hide
        Amy Roh added a comment -

        I am able to reproduce the issue using these simplified steps.

        asadmin create-http-listener --listeneraddress 0.0.0.0 --listenerport 39993 --defaultvs server --target sa_server1 --servername localhost httpls1

        asadmin create-virtual-server --httplisteners httpls1 --target sa_server1 --hosts 192.168.0.10 --state=on vs123

        asadmin deploy --target sa_server1 --virtualservers vs123 helloworld.war

        If you create http-listener without --servername, it works as expected.

        asadmin create-http-listener --listeneraddress 0.0.0.0 --listenerport 39993 --defaultvs server --target sa_server1 httpls1

        Show
        Amy Roh added a comment - I am able to reproduce the issue using these simplified steps. asadmin create-http-listener --listeneraddress 0.0.0.0 --listenerport 39993 --defaultvs server --target sa_server1 --servername localhost httpls1 asadmin create-virtual-server --httplisteners httpls1 --target sa_server1 --hosts 192.168.0.10 --state=on vs123 asadmin deploy --target sa_server1 --virtualservers vs123 helloworld.war If you create http-listener without --servername, it works as expected. asadmin create-http-listener --listeneraddress 0.0.0.0 --listenerport 39993 --defaultvs server --target sa_server1 httpls1
        Hide
        Amy Roh added a comment -

        Grizzly isn't using the servername value correctly. Assign it to Ryan as requested.

        Show
        Amy Roh added a comment - Grizzly isn't using the servername value correctly. Assign it to Ryan as requested.
        Hide
        Ryan Lubke added a comment -

        Interesting issue. It turns out, that due to a bug with MessageBytes in 1.9, the following code:

        String proxyName = connector.getProxyName();
        int proxyPort = connector.getProxyPort();
        if (proxyPort != 0) {
            req.setServerPort(proxyPort);
        }
        if (proxyName != null) {
            req.setServerName(proxyName);
        }
        

        which was invoked before the request was mapped would work. At the time this code was invoked, the
        MessageByte instance for server name had the value as parsed from the Host header. In Amy's example, this
        would be vs123.

        When the proxy handling code above was invoked, it would set the server name to localhost. At this point in time,
        MessageBytes would have two different values. The char[] content from parsing the host header, and the String value set
        above. When the request was then subsequently mapped, the char[] value was passed (vs123) and properly mapped.

        In Grizzly 2.0, this issue with MessageBytes doesn't exist. So when the proxy name was set, it would overwrite the value
        as parsed from the Host header.

        The fix here seems to be the proxy value should be set after the request has been mapped. This will result in equivalent
        behavior as 3.1.2 and previous releases.

        Show
        Ryan Lubke added a comment - Interesting issue. It turns out, that due to a bug with MessageBytes in 1.9, the following code: String proxyName = connector.getProxyName(); int proxyPort = connector.getProxyPort(); if (proxyPort != 0) { req.setServerPort(proxyPort); } if (proxyName != null ) { req.setServerName(proxyName); } which was invoked before the request was mapped would work. At the time this code was invoked, the MessageByte instance for server name had the value as parsed from the Host header. In Amy's example, this would be vs123. When the proxy handling code above was invoked, it would set the server name to localhost. At this point in time, MessageBytes would have two different values. The char[] content from parsing the host header, and the String value set above. When the request was then subsequently mapped, the char[] value was passed (vs123) and properly mapped. In Grizzly 2.0, this issue with MessageBytes doesn't exist. So when the proxy name was set, it would overwrite the value as parsed from the Host header. The fix here seems to be the proxy value should be set after the request has been mapped. This will result in equivalent behavior as 3.1.2 and previous releases.
        Hide
        Ryan Lubke added a comment -

        Changes applied (r51892).

        Show
        Ryan Lubke added a comment - Changes applied (r51892).

          People

          • Assignee:
            Ryan Lubke
            Reporter:
            easarina
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: