Re: Deployment restarts

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Deployment restarts

Thomas Diesler
I think we need to have a conversation on how this is generally supposed to work.

Option #1

Undeployment of a deployment that others dependent on (automatically) takes the transitive graph of dependent deployments down. If so, we need to look at when restart is attempted. Should this be done automatically when the named dependency reappears? This is more or less what we have today.

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.

------

The OSGi model is option #2 and can IMHO not be mapped cleanly to what we have in AS today. Even if we fix the DUP issue it will not work because bundle A that depends on bundle B should not be effected when B gets undeployed (i.e. BundleActivator.stop() must not be called for A). Some time back I suggested the notion of "lazy service dependency"

* A depends on B
* A stays up even when B goes down
* B must have come up at least once for A to come up

I suggest we wait for the outcome of the FY2014 planning in Newcastle. If it should be decided that AS is supposed to provided proper OSGi support, we can revisit this issue together with

* deployment start/stop
* deployment update
* wiring refresh

cheers
--thomas


On Mar 22, 2013, at 8:08 AM, Stuart Douglas <[hidden email]> wrote:

> I have done up a patch that should allow deployment restarts to work, basically it just detects if the deployment has already started, and forces a complete restart, rather than attempting to re-run the DUP's.
>
> https://github.com/jbossas/jboss-as/pull/4268
>
> Unfortunately this breaks DeferredResolveTestCase, because a new instance of DeferredFailActivator is created. I'm not really sure how best to solve this, as I am not sure what the allowed semantics are here with regard to OSGi.
>
> Do you have any ideas about how to deal with this?
>
> Stuart

xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx




_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Deployment restarts

Thomas Diesler

On Mar 22, 2013, at 10:47 AM, Stuart Douglas <[hidden email]> wrote:



Thomas Diesler wrote:
I think we need to have a conversation on how this is generally supposed to work.

Option #1

Undeployment of a deployment that others dependent on (automatically) takes the transitive graph of dependent deployments down. If so, we need to look at when restart is attempted. Should this be done automatically when the named dependency reappears? This is more or less what we have today.

We only have half of this today. It takes down the dependent deployments, however it is not possible to restart them.

Yes, restart is attempted but the DUPs are not designed for it.



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. 


------

The OSGi model is option #2 and can IMHO not be mapped cleanly to what we have in AS today. Even if we fix the DUP issue it will not work because bundle A that depends on bundle B should not be effected when B gets undeployed (i.e. BundleActivator.stop() must not be called for A). Some time back I suggested the notion of "lazy service dependency"

* A depends on B
* A stays up even when B goes down
* B must have come up at least once for A to come up

That would actually not be that hard to implement. I think you could implement it using a service that depends on deployment B with mode PASSIVE, and when that service comes up it simply actives the deferred deployment A. This would be an OSGi only thing though.

This is an option we can explore. You mean that module phase services for OSGi deployments would not have module service dependencies coming from other deployments? I believe that access to "removal pending" bundles is limited to resource and class loading. Services associated with the uninstalled bundle are gone. AFAIU, undeploy of an in use bundle could roll back the phases down to FIRST_MODULE_USE (i.e. the Module stays available)



I suggest we wait for the outcome of the FY2014 planning in Newcastle. If it should be decided that AS is supposed to provided proper OSGi support, we can revisit this issue together with

* deployment start/stop
* deployment update
* wiring refresh

Ok, but I would really like to get this into EAP 6.1 if at all possible, as it does make inter deployment dependencies and class loader dependencies work a lot better.

I guess the read question is other than the failing test, does this actually cause real problems for OSGi, especially given that the current behavior means that half the time restarts won't work anyway.

It does cause real problems for OSGi, because the fundamental semantics of install/start/stop/uninstall is not mapped properly to deployment management operations. Bundle update is not implemented, neither is FrameworkWiring.refreshPackages().

IMHO, the best approach would be to look at this from the perspective of deployment management ops. When the required functionality is available at that level, the OSGi layer could simply use that.

Initially, we would need proper support for start/stop operations. Undeploy, when given with a differentiator, should first stop the deployment and then depending on some criteria (i.e. in use wirings) continue the undeploy or not. If start/stop was supported properly it would be a matter of fixing individual DUPs and perhaps selectively disabling cleanup (i.e. a DUP could that needs the cleanup state to support start/stop could prevent the cleanup)


Stuart


cheers
--thomas


On Mar 22, 2013, at 8:08 AM, Stuart Douglas<[hidden email]>  wrote:

I have done up a patch that should allow deployment restarts to work, basically it just detects if the deployment has already started, and forces a complete restart, rather than attempting to re-run the DUP's.

https://github.com/jbossas/jboss-as/pull/4268

Unfortunately this breaks DeferredResolveTestCase, because a new instance of DeferredFailActivator is created. I'm not really sure how best to solve this, as I am not sure what the allowed semantics are here with regard to OSGi.

Do you have any ideas about how to deal with this?

Stuart

xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx




xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx 




_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Deployment restarts

Stuart Douglas


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 behavior.

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
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Deployment restarts

Thomas Diesler

On Mar 22, 2013, at 9:56 PM, Stuart Douglas <[hidden email]> 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.

>
> 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




_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Deployment restarts

Stuart Douglas


Thomas Diesler wrote:

> On Mar 22, 2013, at 9:56 PM, Stuart Douglas<[hidden email]>  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
>
>
>
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev