> Can you please file a bug ?
Ok, will do.
> I recently started caching supplemental commands instead of looking it
> up from metadata everytime - that has caused this issue and this issue
> happens only for the sequence : deploy X without target option, deploy
> Y with target option, undeploy Y from its target, undeploy X.
I see. Probably Ming could work around it by explicitly specifying the
DAS target in the QL for now.
> I will fix it
Thanks,
- Hong
>
> On 7/3/10 8:13 PM, Hong Zhang wrote:
>> 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
>>>>>
>