1 2 Previous Next 20 Replies Latest reply on Oct 4, 2010 7:36 AM by emuckenhuber

    separating deployers from other services?

    emuckenhuber

      While looking a bit into web deployment i noticed when having 2 batches (subsystems and deployments) the web server / connector actually gets started before deployment processing begins - which does not make much sense, since it's not needed until the Install phase.

      So maybe we want have a separate Batch for services and deployers (or beforeDeploymentBatch) - that deployment only requires the deployers to be installed and the deployment process can start? Which means that adding a deployer service would require to use a different batch. I hacked that together locally and seems to work. The other option would be to only start connectors when there is a web deployment, where i'm not sure if that makes much sense either. Thoughts?

        • 1. Re: separating deployers from other services?
          brian.stansberry

          I think there are two issues here. One is starting services on demand. When the web subsystem starts, can't some constituent services can be made Mode.ON_DEMAND, and others (i.e. the deployers Mode.IMMEDIATE). And then war deployers add a dependency on the ON_DEMAND services.

           

          Making some services ON_DEMAND would need to be controllable though; there is a PRD requirement to allow turning that off. That could be configurable at the subsystem level, although I think users would prefer a more global configuration option (maybe on the profile element???).

           

          The other aspect is getting connectors to start at the end of the overall startup, a la what the JBW connectors do in AS 4/5/6. That seems like it will involve having connectors depend on some service that encapsulates the overall startup.

          • 2. Re: separating deployers from other services?
            brian.stansberry

            https://jira.jboss.org/browse/MSC-21, which David wants to get done in the next week or so will probably have a big impact on how this gets solved. So any thinking about this needs to assume MSC-21 is in place.

            • 3. Re: separating deployers from other services?
              emuckenhuber

              Well i just thought it might be interesting in general to have this separation, as it's not specific to web or connectors. For the deployment process to start you only need the deployers (and whatever they depend on) - regardless of the mode of other services the subsystems install. So there is no need to wait for the web service or transaction manager to start parsing the xml of a deployment...  So if all services defined in subsystems are on-demand and only get activated through the deployment process this is not a big deal. If that's not the case then separation between deployers and service could make sense. Well at least in the current prototype it was obviously faster

              • 4. Re: separating deployers from other services?
                brian.stansberry

                An issue is you don't know that the deployment chain is complete until all the subsystems are started. The web service subsystem may inject a deployer into the deployer chain, but if you start doing deployments before that's done, that deployer may not get applied even though it should.

                • 5. Re: separating deployers from other services?
                  emuckenhuber

                  Hmm, i'm attaching the patch what i prototyped - where i basically created a separate batch for deployers (or any other service which need to be started before deployment)... Plus a listener kicking off the deployment process when the services in this batch are started. It's not really clean, but should show what i have in mind.

                  • 6. Re: separating deployers from other services?
                    brian.stansberry

                    It took me a few looks over a few days to understand what this was about. Your comment above explains it just fine, but I didn't get it.   You're basically discriminating between deployers and other subsystem services so the deployment batch building phase can start without waiting for those other services. The deployment batch building phase only depends on the deployers, so waiting for things like web connectors to start before beginning that phase is wasteful.

                     

                    This makes sense to me as a general idea -- David, John, care to comment? Even if the entire server start gets redone and MSC-21 results in batching being eliminated, the idea of tracking when all deployers instead of when all subsystems are available, and then allowing deployments to proceed as soon as the deployers are done makes sense.


                    How much start time improvement did this allow? What was your config -- web container plus a ROOT.war?


                    I don't like the cast to ModelServiceActivatorContext. If we use this approach the param the subsystem activation API exposes should be ModelServiceActivatorContext (a better name would be good).


                    All this stuff (existing code included) needs a lot of javadoc; I had to think way too hard to understand what was going on!

                    • 7. Re: separating deployers from other services?
                      emuckenhuber

                      Brian Stansberry wrote:

                       

                      Even if the entire server start gets redone and MSC-21 results in batching being eliminated, the idea of tracking when all deployers instead of when all subsystems are available, and then allowing deployments to proceed as soon as the deployers are done makes sense.

                      Hmm, ok not sure how this will look like  - in the end the different batch basically just has the purpose of identifying deployers.

                       

                      Brian Stansberry wrote:

                       

                      How much start time improvement did this allow? What was your config -- web container plus a ROOT.war?

                      The configuration was basically what's in standalone plus the web container and a ROOT.war. The startup time was something around 1250ms (plus something) before and 950 (plus something) after separating deployers and services. Where the startup time without deployment is around 850ms. However those are really wall clock timings...

                      Brian Stansberry wrote:

                       

                      I don't like the cast to ModelServiceActivatorContext. If we use this approach the param the subsystem activation API exposes should be ModelServiceActivatorContext (a better name would be good).


                      All this stuff (existing code included) needs a lot of javadoc; I had to think way too hard to understand what was going on!

                      Yeah, sorry - i fully agree. I did that quickly and did not want to change too much before discussing the general idea.

                      • 8. Re: separating deployers from other services?
                        emuckenhuber

                        Hmm, actually what i want to do in the end is to introduce some "phases" if you want to call it that way. Which could basically look like

                         

                        1) separate deployers from other services

                        2) once all deployers are installed, we should be able to concurrently start the deployment chains for all deployments

                        3) once all chains are finished, we install all the services from the deployments

                        4) once deployment is complete we start the connectors

                         

                        So 1,2,3 that would be most likely be listeners and for connectors we might need to do it differently, since they would be registered in the subsystems. Where the important piece is that deployers don't inject services directly rather in the services they deploy. Since parsing most likely does not need a transaction manager or web container... I really would like to do something like that, so any feedback on that would be appreciated.

                        • 9. Re: separating deployers from other services?
                          jesper.pedersen

                          What do you mean ? That a deployer can't depend on a service ? Or that can't depend on a service created based on information from domain.xml ?

                           

                          Use-case: JCA needs to keep a copy of the parsed metadata (+ merged with annotations) in a repository. So the parsing deployer needs to depend on the 'MDR' service to be available.

                          • 10. Re: separating deployers from other services?
                            emuckenhuber

                            They definitely can depend on other services (in the end it would be just a normal service), however they should not if it's not really needed. It's more about there is no need to wait until the web engine, transaction manager and hornetQ is started before starting with the deployment process.

                            • 11. Re: separating deployers from other services?
                              brian.stansberry

                              Emanuel Muckenhuber wrote:

                               

                              Where the important piece is that deployers don't inject services directly rather in the services they deploy.

                               

                              I think what you are saying here is, say we have a mythical WebServer service that's the entire runtime webserver. A mythical WarDeployer service should not have that injected into it and programatically inject it into a mythical WarDeploymentService it's working on. Rather WarDeploymentService should expose an Injector<WebServer> and  WarDeploymentService should do something like this:

                               

                              BatchServiceBuilder<WarDeploymentService> builder = .... came from somewhere

                              WarDeploymentService warService = .... came from somewhere

                              builder.addDependency(WebServer.SERVICE_NAME, WebServer.class, warService.getWebServerInjector());

                               

                              Agreed on this.

                               

                              Your 300 ms improvement by doing deployments and non-deployer services in parallel is good evidence that your basic idea is correct. The trick is we need to sort out how to do it. Your patch impl works with the current way things are done, buy David is looking at ditching batches as a result of MSC-21. That needs to be discussed in full before we do it and the implications fully understood. Seems that discussion needs to happen right now.

                              • 12. Re: separating deployers from other services?
                                dmlloyd

                                Yeah I'm stuck at an implementation roadblock with MSC-21.  In the meantime I'm working on changing XML parsing to create updates instead of creating the models, which is enough to divert the issue for a while...

                                 

                                In principle, MSC-21 will allow us to install services in any order without batches, and they'll start up as soon as their dependencies are all resolved.  However there's a big gray area around optional dependencies.  I won't hijack this thread with that discussion though.

                                • 13. Re: separating deployers from other services?
                                  brian.stansberry

                                  To summarize discussion we had on this:

                                   

                                  1) The key thing that needs to happen is some controlling logic needs to know when *all* deployers are started. It can then wait for them all to be started before moving on to installing deployments. The tricky thing is finding out what "all" is.

                                  2) Emanuel's patch above uses BatchBuilder and a listener to do that. But that's an implementation detail.

                                  3) MSC-21 is only directly relevant because it *may* impact that particular implementation choice. Otherwise it's a red herring.

                                  4) Activating subsystems is moving to an "update" class, e.g. draft at

                                   

                                  http://github.com/dmlloyd/jboss-as/blob/domain-updates/domain/src/main/java/org/jboss/as/model/AbstractSubsystemUpdate.java

                                   

                                  5) Instead of using a BatchBuilder/listener, David is going to add a method to AbstractSubsytemUpdate, something like

                                   

                                  registerDeployers(SomeAppropriateContext)

                                   

                                  That will be invoked during the bootup. When that has been called for all subsystems, and all deployers that were registered are started, then installing deployments can begin.

                                  • 14. Re: separating deployers from other services?
                                    dmlloyd

                                    Brian Stansberry wrote:

                                     

                                    To summarize discussion we had on this:

                                     

                                    [...]

                                    5) Instead of using a BatchBuilder/listener, David is going to add a method to AbstractSubsytemUpdate, something like

                                     

                                    registerDeployers(SomeAppropriateContext)

                                     

                                    Still need to figure out what SomeAppropriateContext is.  Also, does registerDeployers run concurrently with general activation?  If so, what is the mechanism by which a dependency is expressed on deployers - or should there not be one?

                                    1 2 Previous Next