MBeans dependence on Service lifecycle state?
businessu Aug 13, 2004 11:20 AMI 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:
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:
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.