10 Replies Latest reply on Nov 3, 2009 2:48 PM by Russ Egan

    Depending on Tomcat connectors started fails

    henk de boer Master

      Hi,

      In my EAR application running on Jboss AS 5.01 I'm trying to define a quartz service that may only start when the web module in the ear has completely started.

      At first I just tried to use the following in my quartz service:


      <depends>jboss.web:service=WebServer</depends>
      


      But for some reason this just hangs the server during startup.

      I then tried to use BarrierController as per the advice found here: http://www.jboss.org/file-access/default/members/jbossas/freezone/docs/Server_Configuration_Guide/4/html/Additional_Services-The_BarrierController_Service.html

      My quartz service now looks as follows:

      <server>
      
       <!--
       In this example we have the BarrierController controlling a Barrier
       that is started when we receive the "jboss.tomcat.connectors.started"
       notification from the Tomcat mbean, and stopped when we receive the
       "org.jboss.system.server.stopped" notification from the server mbean.
      
       The dependent services need only define a dependency on the Barrier mbean!
       -->
       <mbean code="org.jboss.system.BarrierController"
       name="jboss:service=BarrierController">
      
       <!-- Whether to have the Barrier initially started or not -->
       <attribute name="BarrierEnabledOnStartup">false</attribute>
      
       <!-- Whether to subscribe for notifications after startup -->
       <attribute name="DynamicSubscriptions">true</attribute>
      
       <!-- Dependent services will depend on this mbean -->
       <attribute name="BarrierObjectName">jboss:name=TomcatConnector,type=Barrier</attribute>
      
       <!-- The notification subscription handback that starts the barrier -->
       <attribute name="StartBarrierHandback">start</attribute>
      
       <!-- The notification subscription handback that stops the barrier -->
       <attribute name="StopBarrierHandback">stop</attribute>
      
       <!-- The notifications to subscribe for, along with their handbacks -->
       <attribute name="SubscriptionList">
       <subscription-list>
       <mbean name="jboss.web:service=WebServer" handback="start">
       <filter factory="NotificationFilterSupportFactory">
       <enable type="jboss.tomcat.connectors.started"/>
       </filter>
       </mbean>
       <mbean name="jboss.system:type=Server" handback="stop">
       <filter factory="NotificationFilterSupportFactory">
       <enable type="org.jboss.system.server.stopped"/>
       </filter>
       </mbean>
       </subscription-list>
       </attribute>
       </mbean>
      
      
      
       <mbean code="org.quartz.ee.jmx.jboss.QuartzService"
       name="user:service=myQuartzService,name=myQuartzService">
      
       <depends>jboss.jca:service=DataSourceBinding,name=MyPostgresDS</depends>
       <depends>jboss.jca:service=DataSourceBinding,name=MyPostgresDS_NOTX</depends>
      
       <!-- The BarrierObjectName configured in the BarrierController -->
       <depends>jboss:name=TomcatConnector,type=Barrier</depends>
      
       <!-- rest omitted for brevity -->
       </mbean>
      
      </server>
      


      However, I now get the following error when starting up Jboss AS:

      DEPLOYMENTS MISSING DEPENDENCIES:
       Deployment "user:name=myQuartzService,service=myQuartzService" is missing the following dependencies:
       Dependency "jboss:name=TomcatConnector,type=Barrier" (should be in state "Start", but is actually in state "Create")
      
      DEPLOYMENTS IN ERROR:
       Deployment "jboss:name=TomcatConnector,type=Barrier" is in error due to the following reason(s): Create
      
      18:23:16,979 INFO [Http11Protocol] Starting Coyote HTTP/1.1 on http-127.0.0.1-8081
      18:23:17,008 INFO [AjpProtocol] Starting Coyote AJP/1.3 on ajp-127.0.0.1-8082
      18:23:17,024 INFO [ServerImpl] JBoss (Microcontainer) [5.0.1.GA (build: SVNTag=JBoss_5_0_1_GA date=200902232048)] Started in 56s:550ms
      


      I don't understand why this is happening. It seems like the quartz service finds that the barrier has not started yet and then it immediately throws the error since the barrier has not started. However, wasn't the entire idea that it should be waiting for the barrier to have started? That was basically the whole point of adding the barrier.

      Does someone knows how to actually let it wait?

        • 1. Re: Depending on Tomcat connectors started fails
          jaikiran pai Master

           

          "henk53" wrote:
          I'm trying to define a quartz service that may only start when the web module in the ear has completely started


          You mean you want your service to be started after your WAR (i.e. the web module) in the EAR is started? In that case, the dependency looks incorrect - you are adding a dependency on the WebServer which is responsible for deploying application. As far as i know, you don't need a BarrierControllerService for this. All we need to determine is the correct MBean name of your web module. Can you post the contents of the application.xml?




          • 2. Re: Depending on Tomcat connectors started fails
            henk de boer Master

             

            "jaikiran" wrote:

            You mean you want your service to be started after your WAR (i.e. the web module) in the EAR is started?


            Yes, that's indeed exactly what I want.


            In that case, the dependency looks incorrect - you are adding a dependency on the WebServer which is responsible for deploying application.


            I see, but I don't yet fully understand. Isn't the WebServer the part of the AS that is actually responsible for serving and executing the WAR? I understand that I'm obviously incorrect, but after reading the documentation and by just looking at the names of everything, it really looked like I needed a dependency on the WebServer.


            As far as i know, you don't need a BarrierControllerService for this. All we need to determine is the correct MBean name of your web module. Can you post the contents of the application.xml?


            It's this:

            <?xml version="1.0" encoding="UTF-8"?>
            <application xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             version="5" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/application_5.xsd">
            
             <display-name>my_app</display-name>
            
             <module id="myeclipse.1214751067793">
             <web>
             <web-uri>my_web.war</web-uri>
             <context-root>/my_web</context-root>
             </web>
             </module>
            
             <module id="myeclipse.1214743299348">
             <ejb>my_EJB.jar</ejb>
             </module>
            
            </application>
            




            • 3. Re: Depending on Tomcat connectors started fails
              jaikiran pai Master

              Based on that application.xml, i think the dependency should be either on:

              jboss.web:J2EEApplication=none,J2EEServer=none,j2eeType=WebModule,name=//localhost/my_web
              

              OR
              jboss.web.deployment:war=/my_web


              Try playing with those values.

              I see, but I don't yet fully understand. Isn't the WebServer the part of the AS that is actually responsible for serving and executing the WAR?

              That's correct. The WebServer will be responsible for deploying the WARs. But note that the WebServer is started before your deployment will be processed. Which means that the -service.xml will see the WebServer started (but your WAR is still not deployed) and hence will not wait for your WAR to be deployed.

              • 4. Re: Depending on Tomcat connectors started fails
                henk de boer Master

                 

                "jaikiran" wrote:
                Based on that application.xml, i think the dependency should be either on:

                jboss.web:J2EEApplication=none,J2EEServer=none,j2eeType=WebModule,name=//localhost/my_web
                

                OR
                jboss.web.deployment:war=/my_web




                I tried the last one first, and it worked perfectly :) Thank you so much!

                I added a ServletContextListener to the web module's web.xml and added a break point there in Eclipse so I could perfectly monitor that the Quartz service is waiting for the web module to be fully deployed. It indeed did so.

                Until now I'm very impressed with the power and elegance that Jboss AS offers. Many things are possible because of the flexible deployment model Jboss AS seems to offer.

                I do wonder though how I could have found out about depending on jboss.web.deployment:war=/my_web for instance. Is there documentation somewhere that explains more about this?


                That's correct. The WebServer will be responsible for deploying the WARs. But note that the WebServer is started before your deployment will be processed. Which means that the -service.xml will see the WebServer started (but your WAR is still not deployed) and hence will not wait for your WAR to be deployed.


                I see, that makes perfect sense. The documentation I quoted more or less suggested though that the deployment would be fully operational. I think it described the use case for calling a Servlet in the web module.

                Also, I still don't fully understand the error message Jboss first gave me. I now understand that I don't want to wait for the WebServer, but why was this first error message complaining about the state being "Create"? Shouldn't the service wait for the state to be "Start" anyway?

                • 5. Re: Depending on Tomcat connectors started fails
                  jaikiran pai Master

                   

                  "henk53" wrote:

                  I do wonder though how I could have found out about depending on jboss.web.deployment:war=/my_web for instance. Is there documentation somewhere that explains more about this?

                  I usually use the wiki for looking for such documentation. For this specific one, i used this wiki http://www.jboss.org/community/wiki/FAQJBossJMX (i guess you have already visited it) which gives you an idea of how to add dependencies. The next step is to figure out the exact name of the MBean you have to depend on. I just booted the AS and checked the jmx-console to see what the MBean names look like for a normal war deployment. In short, there's documentation available, but it may not always be addressing the exact usecase that you are looking for :)


                  "henk53" wrote:

                  Also, I still don't fully understand the error message Jboss first gave me. I now understand that I don't want to wait for the WebServer, but why was this first error message complaining about the state being "Create"? Shouldn't the service wait for the state to be "Start" anyway?

                  Looking at those error messages:
                  DEPLOYMENTS MISSING DEPENDENCIES:
                   Deployment "user:name=myQuartzService,service=myQuartzService" is missing the following dependencies:
                   Dependency "jboss:name=TomcatConnector,type=Barrier" (should be in state "Start", but is actually in state "Create")


                  This states that the deployment myQuartzSerive is in error because its dependency TomcatConnector was expected to be in "Start" state but is in "Create" state. The reason why the dependency is in Create state instead of Start is usually explained in the later part of the error message:

                  DEPLOYMENTS IN ERROR:
                   Deployment "jboss:name=TomcatConnector,type=Barrier" is in error due to the following reason(s): Create
                  

                  But this one looks weird. The error message does not mention why TomcatConnector is stuck at Create state. Ideally, there would be a root cause in the error message. And sometimes the real reason for the error is printed as an exception stacktrace way before this message.


                  • 6. Re: Depending on Tomcat connectors started fails
                    Ray DeCampo Newbie

                     

                    "jaikiran" wrote:
                    Based on that application.xml, i think the dependency should be either on:

                    jboss.web:J2EEApplication=none,J2EEServer=none,j2eeType=WebModule,name=//localhost/my_web
                    

                    OR
                    jboss.web.deployment:war=/my_web


                    Try playing with those values.

                    I see, but I don't yet fully understand. Isn't the WebServer the part of the AS that is actually responsible for serving and executing the WAR?

                    That's correct. The WebServer will be responsible for deploying the WARs. But note that the WebServer is started before your deployment will be processed. Which means that the -service.xml will see the WebServer started (but your WAR is still not deployed) and hence will not wait for your WAR to be deployed.


                    Someone ought to update the following pages in the wiki then, because they advocate the approach taken by the OP:

                    http://www.jboss.org/community/wiki/BarrierController
                    http://www.jboss.org/community/wiki/BarrierControllerExample

                    I'd do it but I don't completely understand it yet.

                    • 7. Re: Depending on Tomcat connectors started fails
                      henk de boer Master

                       

                      "RayDeCampo" wrote:
                      "jaikiran" wrote:

                      Someone ought to update the following pages in the wiki then, because they advocate the approach taken by the OP:

                      http://www.jboss.org/community/wiki/BarrierController
                      http://www.jboss.org/community/wiki/BarrierControllerExample

                      I'd do it but I don't completely understand it yet.


                      That would indeed be a good idea. I figure that with the introduction of Jboss 5 many things changed. Since Jboss 4 had been the current version for many years, I'll guess this takes some time. Maybe the best thing would be to just add a link in the wiki that references this thread?

                      Something like:

                      NOTE: In JBoss AS 5 the approach outlined here possibly doesn't work anymore. See ... for more details.


                      • 8. Re: Depending on Tomcat connectors started fails
                        jaikiran pai Master

                        This wiki http://www.jboss.org/community/wiki/BarrierController has now been updated to point to this thread. Since i haven't tried any of this personally, i did not update the wiki with any other details.

                        • 10. Re: Depending on Tomcat connectors started fails
                          Russ Egan Newbie

                          So...it sounds like the use of the BarrierController is not itself a problem, it's just not working because of the bug where the tomcat service isn't emitting an expected notification.

                          Otherwise, is the BarrierController still a viable solution for dependency/startup ordering in JBoss 5?

                          I ask, because we use a BarrierController ourselves, and its causing an error message in Jboss 5, but actually I think startup is basically working correctly. Our barrier waits for the jboss server to start up. then a bunch of our services start. We get the DEPLOYMENTS MISSING DEPENDENCIES message from the ProfileServiceBootstrap because at the point when Jboss server is started, some of our deployments have not yet started, so it seems like the server didn't start up correctly. ProfileServiceBootstrap assumes that jboss server start == all deployments are started, which is not necessarily the case.

                          Maybe I can work around this by making ProfileServiceBootstrap depend on our barrier too, but it does make barriers awkward to use with jboss 5. And they are still discussed as a recommended solution in ha clusters in the documentation.