Hi, Dies
> I've attached a patch to the issue that seems to fix it.
> Could you check it?
Thanks for submitting the patch! Could you use diff -u (or diff -c) and
attach the full version so it's clear where the line is now moved to?
> During a hot-redeploy, the requests from DAS to cluster instance seem
> to go as follows:
>
> stop -> stops app, removes app from <application> in domain.xml
> start -> loads app, adds app to <application> in domain.xml
>
> So while the application is being loaded, the app's information under
> <application> is not available in the object cached by the cluster
> instance. (even though it is there in the information sent to it from
> the DAS).
> After the application has been loaded the domain.xml and the cache are
> updated.
>
> ASClassLoaderUtil tries to get information about the app from this
> cached object, but because of the timing, fails.
>
> The patch will move the addition of the app's info under <application>
> to before the loading of the app.
>
The sendAssociateEvent is actually not the code to remove/add the
application element, the application element was updated in J2EECPhase
for redeployment.
if(isRedeploy) {
DeploymentServiceUtils.updateConfig(req);
} else {
DeploymentServiceUtils.addToConfig(req);
}
The sendAssociateEvent is to tell the instance about the updated
"application-ref" element.
I think there is a probably bug here of propagating the right config
context changes (the application one) to the remote instances in cluster
scenario as the current code is ok for PE scenario. I am not sure how
tricky/risky it is to fix the admin part of the code for that. I will
let Kedar chime in.
From what you observed, your change is probably ok as a work around fix
(the associate event seems to trigger the remote instance to get the
right config changes including the application element) if the real fix
is too tricky/risky which I suspect so.
Thanks,
- Hong
> Although this seems to avoid the occurrence of the problem, do you see
> any risks or impact on other processing that could break?
>
> Thanks,
> Dies
>
>
> hzhang_jn_at_dev.java.net wrote:
>
>> https://glassfish.dev.java.net/issues/show_bug.cgi?id=7524
>>
>>
>>
>> User hzhang_jn changed the following:
>>
>> What |Old value |New value
>> ================================================================================
>>
>> CC|'alexismp,dkoper,kchung'
>> |'alexismp,dkoper,kchung,km
>> | |'
>> --------------------------------------------------------------------------------
>>
>> Status|REOPENED |STARTED
>> --------------------------------------------------------------------------------
>>
>>
>>
>>
>>
>> ------- Additional comments from hzhang_jn_at_dev.java.net Thu Apr 23
>> 19:32:00 +0000 2009 -------
>> Yes, I can reproduce this problem with cluster. And when I set my
>> debugger to
>> trace the code, the config context that's used seems obsolete and did
>> not have
>> the Application config bean we are looking for. I think I need help
>> from admin
>> config expert here.
>> Kedar: what config context should we use to get the most up-to-date
>> config beans
>> as part of the deployment?
>> The code to get the Applications Config Bean is as follows (in
>> glassfish/appserv-core/src/java/com/sun/appserv/server/util/ASClassLoaderUtil.java)
>>
>>
>>
>> private static Applications getApplications() throws
>> ConfigException {
>> ConfigContext serverConfigCtx =
>> ApplicationServer.getServerContext().getConfigContext();
>> serverConfigCtx.refresh(true);
>> Domain domain = ((Domain)serverConfigCtx.getRootConfigBean());
>> return domain.getApplications();
>> }
>>
>> For some reason, this Applications Config Bean does not contain the
>> application
>> config bean that's currently being redeployed.
>> Earlier to fix the PE case, I added the code
>> serverConfigCtx.refresh(true);
>> to refresh the config context so it's in synch with the latest
>> changes, but that
>> did not seem to help with cluster case.
>> I know we have a few config context, admin config context, runtime
>> config
>> context and event config context (though we cannot get the event one
>> from the
>> code here) and maybe other ones. Which one should be used here to
>> make sure we
>> get the right information here?
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>