[GLASSFISH-16932] Adding and removing virtual server for an application does not take effect Created: 01/Jul/11  Updated: 12/Dec/12

Status: Open
Project: glassfish
Component/s: deployment
Affects Version/s: 3.1.1_b09
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: lidiam Assignee: Hong Zhang
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

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


Attachments: File domain.xml.after.vs.remove     File domain.xml.vs.added     File hello.war    
Tags: 3_1_1-scrubbed, 3_1_x-exclude

 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.



 Comments   
Comment by lidiam [ 01/Jul/11 ]

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

Comment by Anissa Lam [ 01/Jul/11 ]

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.

Comment by Anissa Lam [ 01/Jul/11 ]

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.

Comment by Shing Wai Chan [ 01/Jul/11 ]

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

it works. This confirms that the observation above.

Comment by Hong Zhang [ 05/Jul/11 ]

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?

Comment by Anissa Lam [ 06/Jul/11 ]

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.

Comment by Hong Zhang [ 18/Oct/11 ]

We will look at the new command in the trunk.

Comment by Hong Zhang [ 12/Dec/12 ]

Scrubbing issues for GlassFish 4.0.

Generated at Sun Feb 07 15:39:39 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.