[jboss-as7-dev] Deployment restarts

[Stuart Douglas]

Thomas Diesler wrote:
> On Mar 22, 2013, at 9:56 PM, Stuart Douglas<stuart.w.douglas at gmail.com>  wrote:
>
>>
>> Thomas Diesler wrote:
>>
>>>>> Options #2
>>>>>
>>>>> Undeployment of a deployment that others dependent on does not effect
>>>>> existing wiring. Dependent deployments continue to work and reference
>>>>> a stale deployment with associated module/classloader. Only if there
>>>>> are no users/wires to the undeployed - it can be removed completely.
>>>>> User interaction is needed to cause a rewiring.
>>>>>
>>>> I think this is very problematic, as dependencies are not just class
>>>> loading dependencies but can also be dependencies on EJB's,
>>>> EntityManagers etc.
>>> Yes, OSGi uninstall is more like an intension to undeploy. We would need
>>> to look at whether this approach can be adopted for all deployment types
>>> or whether we need a differentiator that deployments can use if
>>> intension to undeploy is the the desired behaviour.
>> For non-OSGi dependencies undeploy is the correct behavior. It is the only way to get anything close to consistent behaviour.
>
> Is this really true? The thing that gets undeployed will have its services stopped other stuff should track these services and react accordingly. Most likely taking the services down that depend on the services that are now not available anymore. This would guarantee service consistency. Classloading is different - its possible that a component has a wire to the undeployed module and should be able to continue to use that module. A class loader dependency is not equivalent to a service dependency IMHO. Think of a utility class in the undeployed module that is being used. Going through an alternative code path nay require to load more classes from that Module - this should work.
>
> I'd say a module/classloader should only get removed if it has no users any more. At implementation level it would require an undeploy to wait in the module phase until its usage count drops to zero.

The way that it is implemented at the moment this is the only way to 
handle this case. If a deployment has a dependency on another deployment 
they are often depending on more than just the class loader, but also 
other resources such as EntityManagers, EJBs etc.

In theory we could do a fine grained restart, and a lot of the framework 
services can handle this ok, but the deployment unit phase services 
can't, and can't be easily modified to make them restartable.

The main problems are:

- Deployment time metadata takes up a lot of heap memory for large 
deployments, so we clear it to save memory. Without running through the 
full DUP chain again (i.e. a full redeploy) we cannot get this data back.

- DUP's modify mutable data that is attached to the DUP, and do not 
reverse this modification on undeploy. In theory we could change all the 
DUP's to do this, however in practice this would likely prove extremely 
error prone. There is a good chance that some DUP's would not work 
correctly, and unless we had full test coverage we are unlikely to 
discover this. For every test in the test suite we would basically need 
to write a duplicate test that tests the behavior on redeploy.

For the non-OSGi case a full restart is by far the best way to handle 
this, as it does not suffer from either of these problems. It should 
also take about the same amount of time, because most of the expensive 
stuff happens after the Module is created.

Stuart


>
>> For now I will re-work my patch so that the deployment only restarts if the re-deployment is a result of an inter-deployment dependency, rather than an OSGi deferred resolve.
>>
>> Stuart
>
> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
> Thomas Diesler
> JBoss OSGi Lead
> JBoss, a division of Red Hat
> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
>
>