5 Replies Latest reply on Oct 14, 2010 2:37 AM by bosschaert

    Multiple phase deployments


      Related to JBAS-8517


      In OSGi a set of bundles is (hot-) deployed in two phases.


      #1 Bundles are installed into the Framework

      #2 Bundes are started


      After #1 a bundle is in state INSTALLED, the Framework is free to transition the bundle to state RESOLVED at any time. This can explicitly be triggered via PackageAdmin or implicitly by a class loading operation on Bundle.loadClass(String). Bundle.start() transitions the bundle from INSTALLED to RESOLVED to ACTIVE.


      Given a set of bundles, it is important that all of them are INSTALLED (without getting started). The expected hot-deploy semantics is however that after the set of bundles got installed an attempt is made to start them.


      In AS6 I worked arround that by wrapping the AS Deployers (see JBDEPLOY-214)


      In AS7 I would need a notion of post deployment processing hook, that allows me to query the set of successful deployments (i.e. DeploymentServices) so that I can do processing step #2


      Currently I work around that by collecting the deployments in a ThreadLocal

        • 1. Re: Multiple phase deployments

          This sounds like something that should be handled by the deployers and the services they install. I.e. the #1 work is encapsulated in one or more services and the deployer attaches a listener to that service's ServiceController. When all services are started, a second set of services that handles #2 is started.


          It's possible to register a deployment with the server without starting it. But that's not what you are looking for; all that does is make the deployment content known to server and get it copied into the deployment repository; "starting" it means actually deploying it. You're looking for more of a 2 step deployment notion.

          • 2. Re: Multiple phase deployments

            If service lifecycle needs to be manually controlled, then you can have a service for each phase which is manually controlled to "NEVER" at first and then set to "IMMEDIATE" as each part becomes active.


            Basically any time a service should be manually controlled, toggle the mode to do so.  Any time you have a multi-phase start sequence you should use a separate service for each phase.

            • 3. Re: Multiple phase deployments

              (12:26:09 AM) bstansberry: what identifies a "set of bundles" ?
              (12:26:31 AM) tdiesler: I guess the ones that are part of the plan
              (12:26:47 AM) tdiesler: which might be flawed to start of with ;-)
              (12:27:34 AM) tdiesler: given that the scan can chop the physical set that the user hot-deploys in multiple scans hence multiple plans
              (12:27:53 AM) bstansberry: true
              (12:28:16 AM) bstansberry: plus it seems like what you want is more of a package notion like a sar or war
              (12:28:34 AM) bstansberry: even if it was virtual -- something that deployers could treat as a unit
              (12:28:41 AM) tdiesler: lets assume the set is the plan
              (12:29:31 AM) bstansberry: still the DeploymentPlan etc is an external client API
              (12:29:55 AM) tdiesler: in practice a user would drop a set of bundles in /deployments lets assume they all end up in a plan
              (12:30:06 AM) bstansberry: ok
              (12:30:10 AM) tdiesler: so my DUProcessors see a set of those DUCs
              (12:31:03 AM) tdiesler: my workaround relies on ThreadLocal http://github.com/jbosgi/jboss-as/blob/d853975467b33a836ac77a0f9e22976ac5bfa836/osgi/src/main/java/org/jboss/as/osgi/deployment/OSGiDeploymentService.java
              (12:31:12 AM) tdiesler: but shows the idea
              (12:32:42 AM) bstansberry: so what you're looking for is a way to associate a set of deployments with each other
              (12:33:00 AM) tdiesler: yes
              (12:33:02 AM) ***bstansberry looks at where the TL is cleared
              (12:36:19 AM) bstansberry: hmm, so this depends on all the deployments being installed in a batch
              (12:36:51 AM) bstansberry: which is how it works now but is fragile

              (12:37:32 AM) bstansberry: so some other mechanism to know that the deployments are part of a set is better
              (12:37:54 AM) tdiesler: yes, the TL counts them up when the services are created and down when they got installed/failed. If there are no more pending it starts the installed deployments
              (12:40:15 AM) tdiesler: yes, if I had access to the notion of DeploymentSet I could associate lifecycle with the set
              (12:41:29 AM) tdiesler: some other form of SetContext.start/SetContext.end would also do
              (12:42:48 AM) bstansberry: I'll think about how the DeploymentSet could be managed. The ServerDeploymentManager knows there is a plan, so could associate a DeploymentSet with each individual update.
              (12:43:00 AM) bstansberry: and the set could be attached to the DeploymentUnitContext
              (12:43:09 AM) tdiesler: right on
              (12:44:00 AM) bstansberry: but something would need to trigger the fact that all the updates in the set have been processed
              (12:44:06 AM) tdiesler: I would need to be able to associate state with the set
              (12:44:15 AM) tdiesler: perhaps attach stuff to it
              (12:44:17 AM) bstansberry: ok
              (12:45:12 AM) tdiesler: callback on the set?
              (12:45:44 AM) bstansberry: yeah
              (12:45:57 AM) tdiesler: merci (f)

              • 4. Re: Multiple phase deployments

                Been chatting a bit with Thomas. The part that wasn't clear to me is that the "set of bundles" he describes is really a number of independent deployment units. Any DeploymentUnitProcessor would see each deployment unit as an independent thing. He was seeing a DeploymentPlan as a way of processing them as a unit.


                Currently, all the deployments in a plan are installed as part of the same batch. So his ThreadLocal approach lets him use a TL to detect and count up all the deployments in a batch, and then use a listener on each service to track when they are all started, moving on to his #2 step at that point.


                We talked about instead adding a notion of a DeploymentSet. All updates associated with a DeploymentPlan would be associated with the same DeploymentSet. The DeploymentSet could be attached to the DeploymentUnitContext for each deployment, and a callback triggered when the update for each deployment in the set has been applied.


                This is similar to some things that would happen with ear deployments; it's just that instead of using packaging to determine what comprises a set of deployments, we'd be using the fact that they are in the same DeploymentPlan.


                This can use some further digestion, but it's intriguing.

                • 5. Re: Multiple phase deployments

                  Brian Stansberry wrote:


                  (12:28:16 AM) bstansberry: plus it seems like what you want is more of a package notion like a sar or war

                  Just as a side note, the notion of an OSGi 'ear' (it will most likely have the extension .eba - Enterprise Bundle Archive) is currently being standardized in the OSGi Alliance in RFC 152. Until then, we'd have to live with a bunch of bundles in the deployment folder which together happen to be a possibly coherent set.