1 2 3 Previous Next 36 Replies Latest reply on Feb 11, 2010 3:13 PM by Brian Stansberry Go to original post
      • 15. Re: Deployment of on-demand web applications
        Brian Stansberry Master

        Stan, can you create a blocker JIRA for M3 for revisting the set of profiles we ship? M3 is when some ProfileService changes will be in to make it easier to preconfigure a bunch of profiles. It's a PITA now; doing it for M2 (beyond trivial stuff like dropping admin-console from default) will waste a lot of time on something that will be thrown away.

         

        Let me be blunt here. My main motivation to spend a day working the above (which I'd say is about 50% of the effort to complete it altogether) is that a 38 second start time for the default profile in M2 just totally sucks. 20-25 secs we were seeing before admin-console was added back in is reasonable progress. 38 seconds sucks.

        • 16. Re: Deployment of on-demand web applications
          Bela Ban Master

          Excellent !

           

          One thing that would be useful though is lazy loading of an on-demand app; there should be 2 on-demand tags: on-demand which really only loads the app on first access, and on-demand-lazy which loads the app in the background and potentially blocks the caller accessing the app if it hasn't yet been completed started.

          • 17. Re: Deployment of on-demand web applications
            Bela Ban Master

            The current profiles are not going to cut it; they're much too coarse grained. And we don't want to end up with a permutation of useful profiles, e.g. if you want web + clustering, you're going to have to create a new profile, or remove lots of crap (web services, IIOP) from 'all'.

             

            Fine grained services (not related to the 'all', 'default' etc profiles) are the way to go: include all the stuff in a coarse grained profile, and then select which 'services' (for lack of a better word) you want at start time, e.g.

             

            ./run.sh -c all +service WEB +service CLUSTERING -service EJB

             

            runs JBoss with only web clustering (no EJB clustering).

             

            IIRC this is planned for JBoss anyway...

            • 18. Re: Deployment of on-demand web applications
              Brian Stansberry Master

              emuckenhuber wrote:


              There will be something like a on-demand feature, which basically only registers a profile without activating it. However if someone actually decides to include the 'admin-console' profile in his configuraiton, it will get activated. So this on-demand context activator would also have to support that this profile is getting activated when starting AS (the ordering can be controlled if neccessary). I guess that should be no problem?

               

              Are you asking about a case analogous to what would happen if in the current setup, deploy/ included both admin-console-activator-jboss-beans.xml and admin-console.war? When playing with this yesterday morning I did that by accident a couple times and it worked fine (for reasons I understand and can go into if you're interested -- basically the code detects it and handles it easily enough.)

              • 19. Re: Deployment of on-demand web applications
                Remy Maucherat Novice
                And is that stuff supposed to be in M2 ? I will put out a web build including the mapper update soon (probably on the 27th).
                • 20. Re: Deployment of on-demand web applications
                  Brian Stansberry Master

                  I don't mind continuing to debate the overall approach a bit; it's mostly a discussion of priorities. But IMHO the hooks in the Mapper class are a useful feature, whether or not we prioritize using them in M2. Having them in a JBoss Web release this week lets us go either way for M2. The rest of the implementation is in AS trunk itself, where the cutoff is 2 weeks later.

                   

                  Bela's point about 2 mechanisms for delayed deployment is a good one. The critical thing is getting the server ready to handle requests ASAP; you can offload heavy non-critical stuff off the main thread. But if you do that, JBoss Web needs to know about the webapps that will be coming on later, otherwise the server isn't really "ready to handle requests". The Mapper stuff I did provides the hooks to make that doable. A user request triggers the deploy if the background thread hasn't gotten to it yet. Some simple coordination logic in the "activator" ensures it the activation only happens once.

                  • 21. Re: Deployment of on-demand web applications
                    Stan Silvert Master

                    bstansberry@jboss.com wrote:

                     

                    Stan, can you create a blocker JIRA for M3 for revisting the set of profiles we ship? M3 is when some ProfileService changes will be in to make it easier to preconfigure a bunch of profiles. It's a PITA now; doing it for M2 (beyond trivial stuff like dropping admin-console from default) will waste a lot of time on something that will be thrown away.

                     

                    Sure.  Sounds good.

                     

                    https://jira.jboss.org/jira/browse/JBAS-7651

                    • 22. Re: Deployment of on-demand web applications
                      Remy Maucherat Novice
                      The build including the on demand API is now in trunk.
                      • 23. Re: Deployment of on-demand web applications
                        jaikiran pai Master

                        I like the idea of keeping out (selective/unwanted) applications from initial boot process of the server. As for the implementation details:

                         

                        bstansberry@jboss.com wrote:

                         


                        Usage

                         

                        First, I create a common/deploy folder.

                        Next, I move each war in server/default/deploy to common/deploy, replacing it with an XXX-activator-jboss-beans.xml file. The wars are admin-console.war, jmx-console.war, jbossws-console.war, invoker.war and ROOT.war.

                         

                        A typical XXX-activator-jboss-beans.xml looks like this:

                         

                        <?xml version="1.0" encoding="UTF-8"?>
                        <deployment xmlns="urn:jboss:bean-deployer:2.0">
                        
                            <bean name="AdminConsoleActivator" class="org.jboss.web.tomcat.service.ondemand.OnDemandContextProfileManager">
                              
                              <property name="profileService"><inject bean="ProfileService"/></property>
                              <property name="profileFactory"><inject bean="ProfileFactory"/></property>
                              <property name="onDemandContextIntegrator"><inject bean="WebServer"/></property>
                        
                              <property name="contextName">admin-console</property>
                        
                              <!-- Build a profile from the contents of this single URI -->
                              <property name="singleURI">${jboss.home.url}common${/}deploy${/}admin-console.war</property>
                        
                           </bean>
                            
                        </deployment>
                        

                         

                        The MC bean exposes some other properties in case you want to do something more sophisticated:

                         

                        <?xml version="1.0" encoding="UTF-8"?>
                        <deployment xmlns="urn:jboss:bean-deployer:2.0">
                        
                            <bean name="JmxConsoleActivator" class="org.jboss.web.tomcat.service.ondemand.OnDemandContextProfileManager">
                              
                              <property name="profileService"><inject bean="ProfileService"/></property>
                              <property name="profileFactory"><inject bean="ProfileFactory"/></property>
                              <property name="onDemandContextIntegrator"><inject bean="WebServer"/></property>
                        
                              <property name="profileDomain">default</property>
                              <property name="profileServer">default</property>
                              <property name="profileName">jmx-console</property>
                        
                              <property name="serviceName">jboss.web</property>
                              <property name="hostName">localhost</property>
                              <property name="contextName">jmx-console</property>
                        
                              <!-- Build a profile from the contents of these URIs -->
                              <property name="URIList">
                                 <list elementClass="java.net.URI">
                                    <value>${jboss.home.url}common${/}deploy${/}jmx-console.war</value>
                                 </list>
                              </property>
                           </bean>
                            
                        </deployment>
                        

                         

                        The example above doesn't actually do anything sophisticated; it shows the properties with their default values.

                         

                        I was thinking if we could avoid these n number of activator configs (one each for each on-demand app).

                         

                        1) Maybe we could have just a single activator-jboss-beans.xml which has a list of applications that need to activated on demand?

                        2) Or  maybe, we could designate a specific location within the AS deploy structure hierarchy which would be considered as the deploy folder of on-demand applications? So we could just move applications like admin-console to that location.

                         

                        In either of these 2 approaches, internally we would still create the same set of metadata as we would do with n XXX-activation-jboss-beans.xml. But from a end user point of view, the amount of configuration required/exposed would probably be far less.

                        bstansberry@jboss.com wrote:

                         


                        Issues

                         

                        I see a few issues with the above:

                         

                        1. Need for XXX-activator-jboss-beans.xml. It would be slick to somehow configure the war such that some deployer extracts relevant metadata, detects an "on-demand configuration, wires things up with JBoss Web, and then stops the deployment before anything expensive starts, with deployment continuing when the app is requested. Nice, yes, but much harder. For now I think we should stick to the KISS principle. The "profile activation" approach used here has been in use in the AS for well over a year.
                        2. Integration with mod_cluster. This is a problem, as mod_cluster will know nothing about the "on-demand" context until the war is actually deployed. So, the load balancer will not know to route requests to the server. This needs fixing, perhaps with a hook into mod_cluster to allow the MC bean to tell it about the on-demand context. I don't think this is a critical problem until AS 6.0.0.CR1 though. We already configure mod_cluster to ignore all the standard apps we deploy; users have to configure ModClusterService to expose them via the load balancer. IMHO until CR1 it's OK to force users who want to expose a standard app to move it back into the deploy/ dir.
                        3. Virtual host aliases and multiple contexts associated with the same application. The attached prototype doesn't deal with this, but that shouldn't be anything technically difficult to implement.

                        An additional point to note is related to ServletContextListeners/startup servlets. I have seen applications which tend to do heavy duty stuff within a ServletContextListener/startup servlets (for example, query a DB and loading time consuming data during the start of the application). So the first access to the on-demand application is going to be real slow. Although, it depends on which approach we take for implementing on-demand - as Bela said, either activating it in the background or activating it on first access. Anyway, this probably isn't an issue at all, because we don't set user applications as on-demand by default (does admin-console have this kind of startup servlet logic?). But i guess this is something to keep in mind.

                        • 24. Re: Deployment of on-demand web applications
                          Brian Stansberry Master

                          JIRA for the basics of this is http://community.jboss.org/thread/147220

                           

                          AS trunk currently has admin-console, jmx-console and jbossws-console starting this way. For now I left the http-invoker alone, as it's a bit of a different beast from a console.

                           

                          https://jira.jboss.org/jira/browse/JBAS-7714 is to firm up how to easily enable/disable this behavior. For M2, adding -Djboss.as.deployment.ondemand=false turns it off (i.e. causes the WARs to deploy during normal startup). I think that's OK for M2, which isn't meant to be used in production.

                           

                          Jaikiran, sorry for the slow reply. I'll think about combining in one file. The advantage of multiple files is the instructions for how to deploy the war normally is simple -- copy the war from common/deploy/ to deploy/ and delete the -activator-jboss-beans.xml. "Delete the file" is easier than "edit the file". But since each activator bean exposes a boolean property to disable the on-demand behavior, I suppose it's even easier to tell people to leave the war where it is and edit the appropriate bean in a single file.

                           

                          Re: putting all these in one special location and scanning rather than requiring config, that would be quite a bit of effort; it's not just a matter of looking at the name of a deployment archive and figuring everything out. For example, the context path for jbossws-console.war is jbossws, not jbossws-console, so we'd have to find and parse jboss-web.xml to know that.

                           

                          The admin console uses the ServletContextListener trick you mentioned. Even with that it takes a long time to deploy.

                          • 25. Re: Deployment of on-demand web applications
                            jaikiran pai Master

                            bstansberry@jboss.com wrote:

                             


                             

                            AS trunk currently has admin-console, jmx-console and jbossws-console starting this way. For now I left the http-invoker alone, as it's a bit of a different beast from a console.

                             

                            And now my "default" server starts in 22 seconds (down from yesterday's 49 seconds)

                            13:51:22,550 INFO  [org.jboss.bootstrap.impl.base.server.AbstractServer] JBossAS [6.0.0.SNAPSHOT (build: SVNTag=JBoss_6.0.0-SNAPSHOT date=r100736)] Started in 22s:374ms
                            • 26. Re: Deployment of on-demand web applications
                              Emanuel Muckenhuber Master
                              I was updating some failing profileservice tests, since basically unti the actual web deployment is getting deployed the ManagedObjects are missing. We need to check if we can improve this integration - e.g. that we can expose a "empty" MO in the case of an on-demand web-context. IMHO this is more an AS7 issue though.
                              • 27. Re: Deployment of on-demand web applications
                                Shelly McGowan Apprentice

                                With jbossas/trunk revision 100807, the admin-console.war fails to deploy when passing the argument -Djboss.as.deployment.ondemand=false starting the server.  The deployment fails due to JBSEAM-4505

                                which was previously seen in other tests but not with this .war.   This validation error is not seen and the admin-console initializes successfully if this argument is not used.

                                Another deployment exception seen when this property is passed

                                2010-02-10 11:22:46,015 DEBUG [org.jboss.resteasy.integration.deployers.ResteasyScannerDeployer] (HDScanner) Error during deploy: vfsfile:/work/TRUNK/trunk/build/target/jboss-6.0.0-SNAPSHOT/common/deploy/jmx-console.war/WEB-INF/web.xml: org.jboss.deployers.spi.DeploymentException: java.lang.ClassNotFoundException: org.jboss.jmx.adaptor.html.HtmlAdaptorServlet from BaseClassLoader@1ee7088{vfsfile:/work/TRUNK/trunk/build/target/jboss-6.0.0-SNAPSHOT/common/deploy/jmx-console.war/WEB-INF/web.xml}
                                        at org.jboss.resteasy.integration.deployers.ResteasyScannerDeployer.deployApplicationClass(ResteasyScannerDeployer.java:112)
                                        at org.jboss.resteasy.integration.deployers.ResteasyScannerDeployer.internalDeploy(ResteasyScannerDeployer.java:57)
                                        at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:55)
                                        at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:179)
                                        at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1660)
                                        at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1378)
                                        at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1319)
                                        at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:378)

                                • 28. Re: Deployment of on-demand web applications
                                  Ales Justin Master
                                  This is one strange CL root / policy name:
                                  vfsfile:/work/TRUNK/trunk/build/target/jboss-6.0.0-SNAPSHOT/common/deploy/jmx-console.war/WEB-INF/web.xml