Tim,
Can you also run ee/timer tests under devtests/ejb? This will cover
cluster deployments...
thanks,
-marina
Tim Quinn wrote:
> With the proposed changes in 3.1.1 Quicklook passed as did the deployment and EJB detests.
>
> - Tim
>
> Sent from my iPhone
>
> On Jun 6, 2011, at 8:26 PM, Hong Zhang <hong.hz.zhang_at_oracle.com> wrote:
>
>
>> 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
>>>>>>
>>>>>>