Hi Hong, Kedar,
I've attached a patch to the issue that seems to fix it.
Could you check it?
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.
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?