After some investigation, it seems the command framework caches the
target information from the previous operations and inject the cached
target to the later command (instead of injecting the user specified
target). Details as follows:
I was able to find a smaller set of the steps to reproduce the problem:
1) export ENABLE_REPLICATION=true
2) asadmin start-domain
3) asadmin deploy webapps-simple.war
4) asadmin create-cluster cluster1
5) asadmin create-local-instance --cluster cluster1 --systemproperties
HTTP_LISTENER_PORT=18080:HTTP_SSL_LISTENER_PORT=18181:IIOP_SSL_LISTENER_PORT=13800:IIOP_LISTENER_PORT=13700:JMX_SYSTEM_CONNECTOR_PORT=17676:IIOP_SSL_MUTUALAUTH_PORT=13801:JMS_PROVIDER_PORT=18686:ASADMIN_LISTENER_PORT=14848
instance1
6) asadmin start-local-instance instance1
7) asadmin deploy --target cluster1 stateless-simple.ear
8) asadmin undeploy --target cluster1 stateless-simple
9) asadmin stop-local-instance instance1
10) asadmin delete-instance instance1
11) asadmin delete-cluster cluster1
12) asadmin undeploy webapps-simple
When executing command 12), the target param injected to the
PreUndeployCommand (the before supplemental command of the undeploy
command) has the value "cluster1" instead of "server".
And I noticed if I remove step 7) and 8) from the above steps, step 12)
will be executed fine. Looks to me like after deploying to the cluster
target, the target "cluster1" was cached somewhere and later injected to
the command in 12) even though the user specified target is "server".
I will let Vijay do some further investigation on this...
Thanks,
- Hong
On 7/3/2010 10:39 PM, Hong Zhang wrote:
> Hi, Ming
> I have fixed the NPE in the server.log (there was a bug in the
> application loading during server restart). However, I am still seeing
> the undeploy failure at the end of the QL test run. I don't understand
> why yet and will look into it. In the meantime, is there a set of
> simpler steps for me to reproduce this than running the whole QL?
>
> Thanks,
>
> - Hong
>
> On 7/3/2010 8:48 PM, Ming Zhang wrote:
>> Yes, I was able to reproduce the undeploy failure on my local
>> machine. But it seems a v3.1 bug. I let the QL stopped before
>> undeployment and did some debugging. After the cluster testing, the
>> undeployment of the apps failed in first time but if you run the same
>> undeployment command again, it successed. I copied the logs dir of
>> v3.1 to here:
>> http://javaweb.sfbay/~mzh777/v31/ql/4802/logs/
>> If I comment out the cluster testing, the QL undeployment will
>> success in the first run. Please let me know if anyone knows the cause.
>>
>> Ming
>>
>> On 7/3/2010 7:40 AM, Sanjeeb Sahoo wrote:
>>> I am not sure if this is related to your check in, but I now see
>>> undeploy failing at the end of QL tests. It is there in hudson log
>>> [1] as well. Again I don't understand why QL has failed to detect this.
>>>
>>> undeploy-v3-impl-unix:
>>> [exec] Command undeploy failed.
>>> [exec] remote failure: A supplemental command failed; cannot
>>> proceed further
>>> [exec]
>>> [exec] Result: 1
>>>
>>> Looks like all app remain deployed after QL is done.
>>>
>>> [1]
>>> http://hudson.glassfish.org/job/gf-trunk-build-continuous/4802/consoleText
>>>
>>> On Saturday 03 July 2010 05:11 AM, Ming Zhang wrote:
>>>> I have just added cluster tests to QL. As of m2, the 3.1 requires
>>>> to set environment variable:
>>>> ENABLE_REPLICATION=true
>>>>
>>>> The cluster tests are now running under the default QL profile
>>>> against glassfish distribution. To run the cluster tests alone, you
>>>> can do:
>>>> ant -Dglassfish.home={V3 Installation Dir} all_cluster
>>>> at quicklook top level.
>>>>
>>>> I have updated the quicklook doc
>>>> (quicklook/QuickLook_Test_Instructions.html) for these info.
>>>>
>>>> Thanks,
>>>> Ming
>>>