glassfish
  1. glassfish
  2. GLASSFISH-16932

Adding and removing virtual server for an application does not take effect

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 3.1.1_b09
    • Fix Version/s: future release
    • Component/s: deployment
    • Labels:
      None
    • Environment:

      FF5, WinXP, ogs-3.1.1-b10-06_28_2011.zip

      Description

      Adding or removing virtual servers to an already deployed application does not seem to take effect: after adding a virtual server application cannot be accessed. Once it's made accessible, after removing a virtual server from the application one can still access it on the virtual server listener port. Steps to reproduce follow.

      1. Create a cluster with one instance, e.g. cl with clin.
      2. Start cluster.
      3. Deploy an application, e.g. hello.war, to DAS and cluster.
      4. Go to cl-config, Virtual Servers and create a new virtual server: enter virtual server name only, e.g. clvs.
      5. In cl-config create a Network Listener: type name, e.g. http-listener-clvs, select Create Protocol (it should be automatically populated), select clvs for Default Virtual Server, type port, e.g. 85 and address as 0.0.0.0 and select http-thread-pool.
      6. At this point you should be able to access the new virtual server on http://<machine name>:85.
      7. Go to Applications and select previously deployed hello.war. Click on Target tab, Manage Virtual Servers link for the cluster target, cl.
      8. Add virtual server, clvs, to Selected Targets, click Save.
      9. At this point the expectation is that the hello.war application should be available under http://<machine name>:85/hello but the url brings 404 error. The domain.xml file contains the virtual server in the application-ref:

      <clusters>
      <cluster gms-multicast-port="4932" gms-bind-interface-address="$

      {GMS-BIND-IN TERFACE-ADDRESS-cl}" name="cl" gms-multicast-address="228.9.107.160" config-ref=
      "cl-config">
      <application-ref ref="hello" virtual-servers="server,clvs"></application-r
      ef>

      10. One way to force the application to work on the virtual server is to make it a Default Module: go to cl-config, clvs virtual server and select hello under Default Web Module. Save.
      11. Now we can access the app at http://<machine name>:85/hello.
      12. Go to the application targets, Manage Virtual Servers again and remove clvs from the Selected Targets, save.
      13. The reference is removed from:

      <clusters>
      <cluster gms-multicast-port="4932" gms-bind-interface-address="${GMS-BIND-INTERFACE-ADDRESS-cl}

      " name="cl" gms-multicast-address="228.9.107.160" config-ref=
      "cl-config">
      <application-ref ref="hello" virtual-servers="server"></application-ref>

      but not from the clustered instance:

      <servers>
      <server name="clin" node-ref="localhost-domain1" config-ref="cl-config">
      <application-ref ref="hello" virtual-servers="server,clvs"></application-ref>

      I'm attaching domain.xml at this point. One can still access the application via http://<machine name>:85/hello.

        Activity

        Hide
        Hong Zhang added a comment -

        Scrubbing issues for GlassFish 4.0.

        Show
        Hong Zhang added a comment - Scrubbing issues for GlassFish 4.0.
        Hide
        Hong Zhang added a comment -

        We will look at the new command in the trunk.

        Show
        Hong Zhang added a comment - We will look at the new command in the trunk.
        Hide
        Anissa Lam added a comment -

        Summary of the issue: If an application is deployed to a cluster, then adding newly created Virtual Servers to this target will not be reflected
        in the <application-ref> of the cluster's instance.

        Workaround: Remove the cluster target, and then add this cluster target back.

        Maybe there should be a command similar to create-application-ref.
        create-application-ref takes in a cluster as target, and propagating the info to all the instance of the cluster (ie, create the application-ref),
        this new command should also take in a cluster as target, and propagate the VS info to all the <application-ref> of the instance of this cluster.

        relying on user to call the 'set' command to set the VS of the <application-ref> of the cluster, and then run the set command again on all the instances of the cluster
        so that the cluster and instances <application-ref> reflects the same VS attribute is very error-prone.

        Show
        Anissa Lam added a comment - Summary of the issue: If an application is deployed to a cluster, then adding newly created Virtual Servers to this target will not be reflected in the <application-ref> of the cluster's instance. Workaround: Remove the cluster target, and then add this cluster target back. Maybe there should be a command similar to create-application-ref. create-application-ref takes in a cluster as target, and propagating the info to all the instance of the cluster (ie, create the application-ref), this new command should also take in a cluster as target, and propagate the VS info to all the <application-ref> of the instance of this cluster. relying on user to call the 'set' command to set the VS of the <application-ref> of the cluster, and then run the set command again on all the instances of the cluster so that the cluster and instances <application-ref> reflects the same VS attribute is very error-prone.
        Hide
        Hong Zhang added a comment -

        Will check with Tom to see if there is anything at admin level which handles this kind of cluster/instance config update.
        Anissa: I vaguely remembered in v2 we had similar issue, and console sends explict config update request for each cluster instance as well as the overall cluster? Maybe we need to do something similar here?

        Show
        Hong Zhang added a comment - Will check with Tom to see if there is anything at admin level which handles this kind of cluster/instance config update. Anissa: I vaguely remembered in v2 we had similar issue, and console sends explict config update request for each cluster instance as well as the overall cluster? Maybe we need to do something similar here?
        Hide
        Shing Wai Chan added a comment -

        When I run
        asadmin set servers.server.clin.application-ref.hello.virtual-servers=server,clvs

        it works. This confirms that the observation above.

        Show
        Shing Wai Chan added a comment - When I run asadmin set servers.server.clin.application-ref.hello.virtual-servers=server,clvs it works. This confirms that the observation above.
        Hide
        Anissa Lam added a comment -

        I can reproduce this following the same steps.
        To summarize the bug, adding a VS to a cluster doesn't propagate the VS info to the cluster's instance.

        I see that when adding the VS to the cluster, the application-ref of the cluster is updated correctly to include the newly added VS.

        <cluster gms-multicast-port="26825" gms-bind-interface-address="${GMS-BIND-INTERFACE-ADDRESS-ABC-TEST}" name="ABC-TEST" gms-multicast-address="228.9.5.2" config-ref="ABC-TEST-config">
              <application-ref ref="hello" virtual-servers="server,TESTvs"></application-ref>
              <server-ref ref="TEST-1"></server-ref>
              <property name="GMS_LISTENER_PORT" value="${GMS_LISTENER_PORT-ABC-TEST}"></property>
            </cluster>
        

        however, the instance itself doesn't have the VS added.

        <server name="TEST-1" node-ref="localhost-domain1" config-ref="ABC-TEST-config">
              <application-ref ref="hello" virtual-servers="server"></application-ref>
            </server>
        

        I believe whoever is listening to the addition of VS to application-ref of a cluster, should propagate this to ALL its instance. The target is the cluster for user to issue commands, not each of the instance. CLI user will have the same problem when using dotted name to set the VS of the cluster's application-ref.

        I am not sure who should be responsible to this part of the code, whether it is admin or deployment.

        Show
        Anissa Lam added a comment - I can reproduce this following the same steps. To summarize the bug, adding a VS to a cluster doesn't propagate the VS info to the cluster's instance. I see that when adding the VS to the cluster, the application-ref of the cluster is updated correctly to include the newly added VS. <cluster gms-multicast-port= "26825" gms-bind- interface -address= "${GMS-BIND-INTERFACE-ADDRESS-ABC-TEST}" name= "ABC-TEST" gms-multicast-address= "228.9.5.2" config-ref= "ABC-TEST-config" > <application-ref ref= "hello" virtual-servers= "server,TESTvs" ></application-ref> <server-ref ref= "TEST-1" ></server-ref> <property name= "GMS_LISTENER_PORT" value= "${GMS_LISTENER_PORT-ABC-TEST}" ></property> </cluster> however, the instance itself doesn't have the VS added. <server name= "TEST-1" node-ref= "localhost-domain1" config-ref= "ABC-TEST-config" > <application-ref ref= "hello" virtual-servers= "server" ></application-ref> </server> I believe whoever is listening to the addition of VS to application-ref of a cluster, should propagate this to ALL its instance. The target is the cluster for user to issue commands, not each of the instance. CLI user will have the same problem when using dotted name to set the VS of the cluster's application-ref. I am not sure who should be responsible to this part of the code, whether it is admin or deployment.
        Hide
        Anissa Lam added a comment -

        I believe console is doing the right thing and domain.xml reflects what user done correctly.
        Transferring to web container for evaluation.
        Please reassign if needed.

        I changed the affected version to b09 since b10 is not out yet.

        Show
        Anissa Lam added a comment - I believe console is doing the right thing and domain.xml reflects what user done correctly. Transferring to web container for evaluation. Please reassign if needed. I changed the affected version to b09 since b10 is not out yet.
        Hide
        lidiam added a comment -

        Attaching domain.xml after the virtual server is added as target to the application: cluster app reference is updated but clustered instance is not.

        Show
        lidiam added a comment - Attaching domain.xml after the virtual server is added as target to the application: cluster app reference is updated but clustered instance is not.

          People

          • Assignee:
            Hong Zhang
            Reporter:
            lidiam
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated: