6 Replies Latest reply on Jan 18, 2008 1:58 PM by rob.stryker

    JBoss AS - Starting, Stopping, Polling in AS 5

    rob.stryker

      Currently, AS Tools executes run.jar and shutdown.jar respectively to start and stop the server. For polling, it loads the proper classes from the AS folder and executes a JMX call to find out if the server is up or not. (An alternate "dumb" pollre is available which does no polling at all and just sets the server's state as "Started" in the tooling after a specified duration.)

      The polling, which defaults to JMX for startup, does not work with current JBoss 4.x minimal configurations, so any input on the best way to determine if the server is up is welcome.

      The design of polling currently is pretty moduler, allowing different poller types to be added and used, so if the API to determine if AS 5 is stopped, starting, started, or stopping has changed, a new poller can easily be created and can use whatever the new APIs are. So long as there *are* APIs to check.

      The currently implementation uses jmx/invoker/RMIAdaptor, searches for the object jboss.system:type=Server, and checks the "Started" attribute of that object.

      Will this MBean exist in JBoss 5? If it will, then no substantial changes will need to be made to the poller itself, though some will to find the proper jars. If it doesn't exist, then I'll need to find out which new API to use for a custom JBoss 5.0 poller.

      - Rob Stryker

        • 1. Re: JBoss AS - Starting, Stopping, Polling in AS 5
          maxandersen

          Other dependencies I can think of:

          We default to put users deployment in to /deploy. Is that a sensible default in JB5 still?

          Any api to control it externally? (JB4 has JMX control over DeploymentScanner that we haven't used yet but are planning to do...anything else in JB5 should use ?)

          We include most .jars found in to the classpath container in eclipse to allow users to compile against the runtime libraries. Is that still where .jars are located?

          How do we find the correct ports to communicate on ? e.g. http port, jmx ports etc.


          • 2. Re: JBoss AS - Starting, Stopping, Polling in AS 5
            starksm64

            run.jar is used as an executable jar without any additional startup classpath? I can't see how that would work. The run scripts setup additional classpath and endorsed library entries that are needed as well. I expect the tools server setup supports this as well. The question is, what builds the full java command to launch the server?

            Eventually I would like to have a self describing osgi like bundle for startup/shutdown.

            We should be moving to a proper javax.management.remote.JMXConnector implementation that allows access to the jdk jmx even for minimal jboss configurations without the jmx/invoker/RMIAdaptor as the way to access jmx. While we don't need a jmx kernel in jbossas5 (it is still deployed by default), we should still be mirroring key mcbeans that make up the tooling interface available via jmx for a consistent api. The jboss.system:type=Server mbean is still available in jbossas5.

            I'll create jira issues for all these to track them.


            • 3. Re: JBoss AS - Starting, Stopping, Polling in AS 5
              maxandersen

               

              "scott.stark@jboss.org" wrote:

              Eventually I would like to have a self describing osgi like bundle for startup/shutdown.


              I'm not sure I understand how that would help us. Please elaborate.





              • 4. Re: JBoss AS - Starting, Stopping, Polling in AS 5
                starksm64

                 

                "max.andersen@jboss.com" wrote:
                Other dependencies I can think of:

                We default to put users deployment in to <configuration>/deploy. Is that a sensible default in JB5 still?

                Yes.

                "max.andersen@jboss.com" wrote:

                Any api to control it externally? (JB4 has JMX control over DeploymentScanner that we haven't used yet but are planning to do...anything else in JB5 should use ?)

                Yes, there is an mc bean that controls this. The jmx access to the DeploymentScanner does not exist as that bean is gone, and it would not work across server restarts since the change would not be persisted by default. Control of the server structure is something that will need to be better defined. Right now there is some support via system properties.

                "max.andersen@jboss.com" wrote:

                We include most .jars found in <configruation> to the classpath container in eclipse to allow users to compile against the runtime libraries. Is that still where .jars are located?

                It still is currently. As we move forward, the association between the old filesystem structure and the server/deployment classpaths will be gone as the profile service can be using a repository that points to another structure, a database, etc. Related to the startup classpath, we should be providing a bundle like descriptor that defines class/resource paths and scoping rules. In an osgi environment, this could be used to create a bundle with the property class/resource imports/exports.

                "max.andersen@jboss.com" wrote:

                How do we find the correct ports to communicate on ? e.g. http port, jmx ports etc.

                This still is an undefined capability. Where we are going in jbossas5 is that services can annotate their management view to allow for cross service queries for things like all ports, files, interfaces, etc., but it does not exist today.


                • 5. Re: JBoss AS - Starting, Stopping, Polling in AS 5
                  starksm64

                   

                  "max.andersen@jboss.com" wrote:
                  "scott.stark@jboss.org" wrote:

                  Eventually I would like to have a self describing osgi like bundle for startup/shutdown.

                  I'm not sure I understand how that would help us. Please elaborate.

                  There should be a metadata description of the various class/resource paths that allow for the proper construction of class loaders so that reliance on file system structure is not needed. In an osgi environment, could be used to create bundles/bundle loaders.


                  • 6. Re: JBoss AS - Starting, Stopping, Polling in AS 5
                    rob.stryker

                    Example Full command from command line:

                    /home/rob/apps/java/jdk1.6.0_02/bin/java -Dprogram.name=run.sh -server -Xms128m -Xmx512m -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.net.preferIPv4Stack=true -Djava.endorsed.dirs=/home/rob/apps/jboss/jboss-4.2.0.GA/lib/endorsed -classpath /home/rob/apps/jboss/jboss-4.2.0.GA/bin/run.jar:/home/rob/apps/java/jdk1.6.0_02/lib/tools.jar org.jboss.Main


                    >>The question is, what builds the full java command to launch the server?

                    In the tooling? heh... as of now nothing. The closest we come to building a full command is making sure IPv4Stack is preferred where it needs to be. I'll make a JIRA to make sure I add an API for complete script mimicking.

                    >he jmx access to the DeploymentScanner does not exist as that bean is gone, and it would not work across server restarts since the change would not be persisted by default.

                    Our main use case here is to be able to stop the server from scanning, then we update our exploded deployed application incrementally without the server recognizing only half the changes, and then let the server resume scanning. If there'll be another way to do it in JBoss 5, that'd be great, but the primary goal is that the server doesn't try to reload an updating application while it's still being changed by us.

                    Also, a way, either through JMX or some other method, to determine when the application has been completely loaded by the server, so that our tools can automatically open the web page for it. RIght now we open the web page right after we deploy, but often times the server hasn't reloaded the app yet and the user gets an unchanged page or an error page.