6 Replies Latest reply on Aug 17, 2004 11:47 PM by Rob Grzywinski

    MBeans dependence on Service lifecycle state?

    Business User Newbie

      I am in the process of implementing a service (using SOP) in JBoss and I am unfamiliar with the current paradigm whereby MBean attributes and operations interact with the service state.

      In other words, there are MBean attributes and operations (henceforth called "MBean methods") that are valid only pre-startup, there are others that are only valid, post-startup, and there are others that are valid in either state. In addition, some MBean methods will behave differently based on the state in the service lifecycle. How is this contract exposed through the MBean? Are there any defined paradigms for doing this?

      For example, look at the TransactionManagerService. Through its MBean interface it exposes the transaction timeout. Because there is no explicit way to define when this attribtue may be set, it may be called at any time. Let's say that I set the timeout to be 10min before starting and then I start the service. After a time, I realize that the timeout is too long and I have a number of transactions that are "hung" (i.e. waiting to time out). I change the transaction timeout via JMX.

      Notice that the desired behavior of setting the transaction timeout requires a service state dependency. If the service has not yet started then the timeout is simply set. If the service is running, setting the timeout should determine if the new timeout is shorter than the previous timeout and if so, timeout any waiting transactions.

      Another example (more akin to what it is that I am trying to accomplish) is: imagine an echo server implemented as a service. This server has a "port" parameter (the port on which it listens for connections) that is exposed via JMX. Setting the port before startup will simply set the port. Setting the port after startup will require that the service be stopped (so that all current connections are closed) and restarted with the new port value. In setting the attribute, this restart may be implicit (i.e. stop and start are called each time the attribute is set) or it may be explicit (i.e. stop and start will need to be called via JMX for the setting of the value to have any effect). If the restart is explicit then the following needs to occur:

      A temporary variable needs to be set with the desired port value. This is necessary because the port member need to be immutable while the service is in operation; changing its value will lead to indeterminate results (e.g. logging the port on error will result in a message that is inconsistent with the current state). On stopping the service the temporary value will need to be copied to the member value.

      If the restart is implicit, then an exception may occur preventing a re-start leaving the service in a stopped (or undefined) state. Having the service in a stopped state will lead to undefined results as it appears that JBoss does not monitor a service (i.e. no other MBean will be aware of the state). This is made evident by the lack of an "isRunning()" method on Service.

      For those of you lost in the ramble, I will state my question again:

      is there a defined paradigm for handling the coupling between MBeans and the service lifecycle?

      As for any JBoss'ers out there: are you guys doing any future planning for SOP's and blowing out the Service interface? As it stands, Service is more of a "just make sure you fulfill this contract" rather than any truely useful programming model. Given the robustness of the JBoss platform, supporting a true SOP model (where in this case the "P" can be both "programming" and "platform") does not seem like a stretch. Providing for tolerant services would just be damn cool.

        • 1. Re: MBeans dependence on Service lifecycle state?
          Rob Grzywinski Newbie

          Somehow, even though I logged out and logged in as myself (rgrzywinski) a previous user was maintained. Anywho, I posted the above message (sorry about the formatting there). I didn't want any confusion.

          So much for using someone elses machine with this forum.

          • 2. Re: MBeans dependence on Service lifecycle state?
            Dimitris Andreadis Master

            As you have already pointed out, how an MBean is supposed to operate varies greatly from one MBean to the other.

            The more "dynamic" an MBean behaves, the more difficult is to code it.

            In most cases MBean are quite static, i.e. they go:


            without even allowing an MBean to be re-started. You can always re-deploy it, of course (which has more or less the same effect).

            Some MBeans allow start()-stop()-change attributes-start()-stop() cycles, in which case you can achieve the runtime dynamic reconfiguration of the MBean.

            In some extreme cases the MBean could be coded to restart itself upon configuration changes (i.e. attribute sets). But thats just to constly to code and the same result can be achieved with the must easier method described above, i.e. explicitly stoping and reconfiguring the MBean.


            • 3. Re: MBeans dependence on Service lifecycle state?
              Rob Grzywinski Newbie

              Dimitris, I appreciate your responses but you appear to be approaching all of my questions from the standpoint of a developer. Development is one very small piece of the puzzle. The much larger pieces are deployment and maintenance, specifically remote (via MBeans) deployment and maintenance.

              The whole point in my enquiring about the paradigm whereby MBean attributes and operations interact with the service state is to determine how the MBeans contract is expressed and communicated. You've essentially said: you can code the service do what whatever you want via MBeans and some things are harder than others. Fine but that's a development concern.

              Picture this: you're an administrator or a remote client and you sit down in front of your management console in which there are dozens of services each with attributes and operations. How do you know which bean uses which technique? Which attributes can be called when the service is running? Which can be called when the service is running and requires the service to be restarted? Which have to have the service stopped and restarted? How do I know if the service is stopped (yes, "StateString" identifies if the service is started, but how do I know if it's still running?)?

              Is the contract expressed solely through the limited MBean method descriptions? Are there known paradigms for throwing various exceptions based on state (say, by throwing IllegalStateException if an attribute can only be set if the service is stopped -- and I know that IllegalStateException can be thrown but I'm asking for the paradigm)?

              Now put all of this into perspective of my other question: Restart a FAILED service? And your response: by altering manually its deployment descriptor, saving, then the deployment scanner takes notice of this and re-deploys the MBean. I'm betting on the fact that there is no effective way of communicating the contract so my next thought is: so what happens when they get it wrong (i.e. a service fails). You're telling me that my MBean administrators are dead in the water.

              I hope that I'm better communicating my questions and concerns and I hope that I'm not causing friction in any way as it is not intended.

              • 4. Re: MBeans dependence on Service lifecycle state?
                Elias Ross Master

                If you're not comfortable with how administrators handle your MBeans, create your own JSP wrapper or feel free modify the JMX console to suit your requirements.

                I suggest you program your MBean to throw an exception if the service is not in the requisite state and an attribute is changed. If you want to guard all attributes or create an intrinsic behavior, you can program your own XMBean wrapper. There are some XMBean examples out there.

                • 5. Re: MBeans dependence on Service lifecycle state?
                  Dimitris Andreadis Master

                  My view is the following:

                  MBeans by themselves is just another tool that can be used in many different ways. JBoss used it primarily as a component integration/configuration bus, with the added benefit that "some" management would be possible.

                  Since MBean services can be implemented in many different ways, JBoss used the lowest common denominator as its paradigm for managing the deployment of services, i.e.:

                  CTOR -> [attribute config] -> [create] -> [start] -> [stop] -> [destroy]

                  I am using brackets to indicate that those are actually optional steps, so create() will only be called if it is implemented.

                  (Note, actually this came before jsr77, and after the jmx spec itself, that did not specify at all a lifecycle for MBeans, except of the very basic/limited MBeanRegistration interface.)

                  JBoss only guarantees the correct sequence of lifecycle events, (for those MBean that extends JBoss classes, e.g. ServiceMBeanSupport, plus making sure that any specified dependencies will be satisfied.

                  It doesn't even say that you should be able to do: start->stop->start->stop

                  So a lot of services have been implemented by many different people and the only thing that we know for sure, is that the above lifecycle paradigm works for all services.

                  I'm not really aware of the reason the ServiceController will prevend failed services from being restarted, but following this logic it may be so that it "enforces" this simple paradigm which suggests that a failed service must be re-deployed.

                  Regarding the JSR77 lifecycle there is the following note in the jboss documentation:

                  "Note that there is a J2EE management specification request (JSR 77, http://jcp.org/jsr/detail/77.jsp) that introduces a state management notion that includes a start/stop lifecycle notion. When this standard is finalized JBoss will likely support an extension of the JSR 77 based service lifecycle implementation. As of the 3.2.0 release we do support JSR77 management objects and most of the statistics, but the lifecycle operations are not supported."

                  So the start/stop notion (including transitions from fail) still needs to be done.


                  • 6. Re: MBeans dependence on Service lifecycle state?
                    Rob Grzywinski Newbie

                    Thank you for your feedback and help. The last quote was especially helpful. I will reevaluate my needs and assess my next steps.

                    I know that many people see "service" in many different lights -- just following Avalon gives some insight. I'm just curious as to how SOA with SOP used at the end points will really be able to thrive without a cohesive standard for "service" in this context. This is a question that will plague us for some time to come.