Hi, Marina
> These are the calls that use DC:
>
> EjbDeployer: clean() & Deployment.APPLICATION_PREPARED event -
> DeploymentProperties.PREVIOUS_TARGETS
The DeploymentProperties.PREVIOUS_TARGETS transient metadata will only
have non-null value for redeployment (which was populated earlier in
this deployment), in other cases it will be read from the domain.xml.
> EjbDeployer.load() - EJB_APP_MARKED_AS_STARTED_STATUS &
> CONTAINER_LIST_KEY
> EjbApplication.loadContainers()
> "org.glassfish.ejb.startup.SingletonLCM" & CONTAINER_LIST_KEY
From what I read from the code, this is sharing data between different
stages of the same deployment. As the transient metadata only gets
cleaned up at the end of the deployment, it should not affect this sharing.
I don't think the proposed changes will affect the above but Tim can run
the relevant tests to be sure. Tim probably plans to run ejb dev tests
for his changes anyways, are there any additional tests that he should
also run?
Thanks,
- Hong
>
> Hong Zhang wrote:
>> Hi, Marina
>> I just replied to Mitesh for a similar question. :-)
>> I believe in the these cases, the states are stored as transient
>> metadata of the ApplicationInfo object instead of DeploymentContext
>> object (please do double check your use cases). The ApplicationInfo
>> object lives in memory until the undeployment so it's possible to
>> transfer state using that.
>> The DeploymentContext is intended to a transient object which
>> only lives for certain operation and then disappear. We use different
>> instances of DeploymentContext for deployment, undeployment etc. So
>> we could not use it to transfer states in the first place.
>> So Tim's changes should not affect these use cases as it only
>> cleans up DeploymentContext.
>>
>> Thanks,
>>
>> - Hong
>>
>> On 6/6/2011 6:37 PM, Marina Vatkina wrote:
>>> Tim,
>>>
>>> EJB container uses transientAppMetaData on load/unload and clean on
>>> undeploy. From my previous discussions with Hong, undeploy can be
>>> done on a disabled application, when none of the DOL data is
>>> processed. Unless something has changed, several EJB features won't
>>> be available with the change.
>>>
>>> Best,
>>> -marina
>>>
>>> Tim Quinn wrote:
>>>> If you are responsible for a GlassFish module container, please
>>>> read on.
>>>>
>>>> The deployment framework makes available the DeploymentContext to
>>>> all deployers that need to work with a given application. The
>>>> intent has always been that the scope of a DeploymentContext is
>>>> limited to deployment (or undeployment) processing only, not to the
>>>> running application container.
>>>>
>>>> As part of our work to improve the memory footprint, beginning very
>>>> soon (later today or within a day or so) the deployment framework
>>>> will clear out the DeploymentContext's transient application
>>>> metadata (accessible using the
>>>> DeploymentContext.getTransientAppMetadata methods) at the end of
>>>> deployment. No code should have been relying on this data past
>>>> that point anyway.
>>>>
>>>> So far testing has not revealed any problems caused by clearing out
>>>> that data, but you should double-check that your module will not be
>>>> affected.
>>>>
>>>> We are adding this clean-up step because there are lingering
>>>> references - after deployment - to the DeploymentContext which
>>>> keeps it reachable after it should be eligible for GC. The DC's
>>>> references to the transient app metadata consumed quite a bit of
>>>> memory. Eventually we plan to make sure there are no such
>>>> lingering references to the DC itself, in which case the DC and all
>>>> referenced objects can be GCed. But that might be too risky for
>>>> 3.1.1, so as a first step we are clearing out the transient app
>>>> metadata.
>>>>
>>>> In the future you might need to change any container code that
>>>> relies on a saved reference to the DC in order to improve further
>>>> the memory footprint. We might not make this change right away,
>>>> but please be aware that this could be very likely for some release
>>>> past 3.1.1 if not for 3.1.1 itself, depending on the work we are
>>>> continuing to do on improving the memory footprint.
>>>>
>>>> Please let me know if you have any questions.
>>>>
>>>> - Tim
>>>>