Re: FW: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service
On Tuesday, January 28, 2003, at 12:45 AM, David Jencks wrote: On Tuesday, January 28, 2003, at 12:47 AM, Dain Sundstrom wrote: On Monday, January 27, 2003, at 09:36 PM, David Jencks wrote: On Monday, January 27, 2003, at 07:39 PM, Dain Sundstrom wrote: Wow, I had no idea it was this complicated. Anyway the real problem is a Dynamic MBean has a setAttributes method to group together an entire set of attribute changes in one operator, but when we go to standard mbeans we lose that concept because we only have a bunch of setters. That sucks. ??? You still have the setAttributes method on the mbean server, which is the only way you can get at the stuff. Ya sure, but the implementation just calls some setters. There implementation doesn't understand that this is a group of changes. If the setAttributes was implemented by hand it could understand that host, port and back log were all changed and only create the new listener socket once. So we need to fix the jmx implementation. My point is there is nothing to fix. In the end all the implementation does not have the code to handle a block of setters. I suppose you could call adding a state change (life cycle interceptor) a fix, but I wouldn't. It is simply additional frame work to deal with a deficiency in the implementation. You're not fixing the problem but coding around it. Anyway I say potato and you say potatoe :) -dain --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: FW: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service
Wow, I had no idea it was this complicated. Anyway the real problem is a Dynamic MBean has a setAttributes method to group together an entire set of attribute changes in one operator, but when we go to standard mbeans we lose that concept because we only have a bunch of setters. That sucks. What you have detailed looks like a good solution to me. In the end, I just want to make the admins happy. BTW, I believe we do have an orthogonal problem with MBeans being implemented incorrectly. We have a ton of beans that simply don't do what they say they will. I see no reason why an bean that has a port setting can't remove the existing socket and create a new one. Hey I just thought of something. We implement our own MBean spec... XMBean right? We could have additional state for attributes that says these attributes are only writable while the bean is stopped. Then in the MBeanMetaData getter we check the state and only return the attributes that are editable at that state. This will work since we don't cache MBean MetaData. What do you think? I also think we should extend the MBeanMetaData objects to support jboss specific stuff like the above attributes. Then we can display these in our consoles. -dain On Friday, January 24, 2003, at 08:00 PM, David Jencks wrote: Yes, that's the idea. It goes like this when jboss instantiates an mbean from a *-service.xml file: (create mbean) state: instantiated (set attributes) state: configured (call create method) ~(call destroy method) state: created (call start method) ~(call stop method) state: started where the ~() methods go backwards from the other methods. Personally I think the create and destroy methods could be safely removed as useless, but I lost the argument the last time we had it. Anyway, to see why this might be useful, lets hypothesize an mbean that takes a long time to create (just as an object) and has a socket. You want to set the ip address and port on the socket as separate attributes on the mbean. Well, creating a new socket whenever you change the host or port is not very satisfactory since there's a good chance you want to change both. Changing just one will leave the mbean in a unusable state, pointing to the right host but wrong port. You don't want to replace the mbean object with a new one because it takes a long time to create. So , the service lifecycle lets you: stop (mbean is now theoretically unusable: this should be implemented in an interceptor, but is not right now)(this would discard the old socket) change both attributes (while the mbean is off) start (this creates a new socket with all correct parameters)(mbean is now usable again). There are also mbean dependencies, whereby if your mbean has an ObjectName valued attribute, and you tell jboss, your mbean can't start until the referenced mbean has started. This is used to get most of jboss to start in an order that will work. The code that does this is now spread over ServiceController, ServiceConfigurator, and ServiceContext with a little bit of ServiceCreator thrown in. Hope this clarifies what is going on a little bit. There are no attributes that have no effect... its just that say a port number may not get into the socket until you cycle the mbean, in case you want to change the host also. I also mentioned earlier that there's an xmbean attribute indicating what the effect on service lifecycle should be of changing an attribute value. The idea behind this (unimplemented) is that if you set several attributes at once, jboss should be able to cycle the lifecycle state for you. david jencks On Friday, January 24, 2003, at 05:07 PM, Matt Munz wrote: David, We are miscommunicating. In all the mbeans I have written and seen in jboss, aside from egregious bugs, if setting an attribute doesn't have an immediate effect, it does have the desired effect if you run through the service lifecycle (usually stop, start, occasionally stop, destroy, create, start). My view is that mbeans in jboss can take advantage of the service lifecycle. If you don't want to, make all your attribute changes have their effects immediately. All our mbeans are pretty much jboss specific and most heavily use the service lifecycle. They just won't run without it. I still think it is a really convenient extension to vanilla jmx and don't see why we should replace it. I barely know what the service lifecycle is. I have not used it. I am not arguing to replace it. I never said that. You said that. How do I set an attribute correctly, step by step, for a Bean that uses the service lifecycle? It helps me to use a state metaphor when considering lifecycle issues. It sounds like there are several states a lifecycle-oriented bean can be in: destroyed, created, running. In which state is it safe to set RW attributes on lifecycle-oriented beans? Is the following the appropriate way to set values on
Re: FW: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service
On Monday, January 27, 2003, at 07:39 PM, Dain Sundstrom wrote: Wow, I had no idea it was this complicated. Anyway the real problem is a Dynamic MBean has a setAttributes method to group together an entire set of attribute changes in one operator, but when we go to standard mbeans we lose that concept because we only have a bunch of setters. That sucks. ??? You still have the setAttributes method on the mbean server, which is the only way you can get at the stuff. What you have detailed looks like a good solution to me. In the end, I just want to make the admins happy. BTW, I believe we do have an orthogonal problem with MBeans being implemented incorrectly. We have a ton of beans that simply don't do what they say they will. I see no reason why an bean that has a port setting can't remove the existing socket and create a new one. I'm not sure if you are complaining about mbeans that don't actually undo the start in stop (i.e. if it creates a socket in start, it should forget it in stop, then make a new one when start is called again), or saying you think socket creation should be done immediately when you change the port, irrespective of mbean state. I hope it's the first. Hey I just thought of something. We implement our own MBean spec... XMBean right? We could have additional state for attributes that says these attributes are only writable while the bean is stopped. Then in the MBeanMetaData getter we check the state and only return the attributes that are editable at that state. This will work since we don't cache MBean MetaData. What do you think? For info-- we have this in the xmbean dtd, but we don't have any interceptor support for it yet, and I won't work on it until the aop stuff has settled down. I think some kind of icon indicating the lifecycle state needed for the change would be best. For hiding attributes, No thanks, then you can't tell what you might be able to set until you stop the mbean. I also think we should extend the MBeanMetaData objects to support jboss specific stuff like the above attributes. Then we can display these in our consoles. modelmbean metadata is already generically extensible, and we have extended it with stuff like the lifecycle level and (actually implemented thanks to Matt Munz) persistence. Right now I don't know of a generic way to display arbitrary metadata like this, AFAIK each item would have to be hardcoded. Maybe someone who can actually design usable interfaces could suggest something:-) david -dain On Friday, January 24, 2003, at 08:00 PM, David Jencks wrote: Yes, that's the idea. It goes like this when jboss instantiates an mbean from a *-service.xml file: (create mbean) state: instantiated (set attributes) state: configured (call create method) ~(call destroy method) state: created (call start method) ~(call stop method) state: started where the ~() methods go backwards from the other methods. Personally I think the create and destroy methods could be safely removed as useless, but I lost the argument the last time we had it. Anyway, to see why this might be useful, lets hypothesize an mbean that takes a long time to create (just as an object) and has a socket. You want to set the ip address and port on the socket as separate attributes on the mbean. Well, creating a new socket whenever you change the host or port is not very satisfactory since there's a good chance you want to change both. Changing just one will leave the mbean in a unusable state, pointing to the right host but wrong port. You don't want to replace the mbean object with a new one because it takes a long time to create. So , the service lifecycle lets you: stop (mbean is now theoretically unusable: this should be implemented in an interceptor, but is not right now)(this would discard the old socket) change both attributes (while the mbean is off) start (this creates a new socket with all correct parameters)(mbean is now usable again). There are also mbean dependencies, whereby if your mbean has an ObjectName valued attribute, and you tell jboss, your mbean can't start until the referenced mbean has started. This is used to get most of jboss to start in an order that will work. The code that does this is now spread over ServiceController, ServiceConfigurator, and ServiceContext with a little bit of ServiceCreator thrown in. Hope this clarifies what is going on a little bit. There are no attributes that have no effect... its just that say a port number may not get into the socket until you cycle the mbean, in case you want to change the host also. I also mentioned earlier that there's an xmbean attribute indicating what the effect on service lifecycle should be of changing an attribute value. The idea behind this (unimplemented) is that if you set several attributes at once, jboss should be able to cycle the lifecycle state for you. david jencks On Friday, January 24, 2003, at
Re: FW: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service
On Monday, January 27, 2003, at 09:36 PM, David Jencks wrote: On Monday, January 27, 2003, at 07:39 PM, Dain Sundstrom wrote: Wow, I had no idea it was this complicated. Anyway the real problem is a Dynamic MBean has a setAttributes method to group together an entire set of attribute changes in one operator, but when we go to standard mbeans we lose that concept because we only have a bunch of setters. That sucks. ??? You still have the setAttributes method on the mbean server, which is the only way you can get at the stuff. Ya sure, but the implementation just calls some setters. There implementation doesn't understand that this is a group of changes. If the setAttributes was implemented by hand it could understand that host, port and back log were all changed and only create the new listener socket once. What you have detailed looks like a good solution to me. In the end, I just want to make the admins happy. BTW, I believe we do have an orthogonal problem with MBeans being implemented incorrectly. We have a ton of beans that simply don't do what they say they will. I see no reason why an bean that has a port setting can't remove the existing socket and create a new one. I'm not sure if you are complaining about mbeans that don't actually undo the start in stop (i.e. if it creates a socket in start, it should forget it in stop, then make a new one when start is called again), or saying you think socket creation should be done immediately when you change the port, irrespective of mbean state. I hope it's the first. No I mean the second. If you change the port, it should close the existing socket and create a new one. I see no reason why the service should have to be stopped, as I can do this today... it is just an implementation decision. Hey I just thought of something. We implement our own MBean spec... XMBean right? We could have additional state for attributes that says these attributes are only writable while the bean is stopped. Then in the MBeanMetaData getter we check the state and only return the attributes that are editable at that state. This will work since we don't cache MBean MetaData. What do you think? For info-- we have this in the xmbean dtd, but we don't have any interceptor support for it yet, and I won't work on it until the aop stuff has settled down. I think some kind of icon indicating the lifecycle state needed for the change would be best. For hiding attributes, No thanks, then you can't tell what you might be able to set until you stop the mbean. Sorry, I ment to say that the attribute is read only in the running state with an icon that says you must stop the service to edit this attribute. I also think we should extend the MBeanMetaData objects to support jboss specific stuff like the above attributes. Then we can display these in our consoles. modelmbean metadata is already generically extensible, and we have extended it with stuff like the lifecycle level and (actually implemented thanks to Matt Munz) persistence. Right now I don't know of a generic way to display arbitrary metadata like this, AFAIK each item would have to be hardcoded. Maybe someone who can actually design usable interfaces could suggest something:-) Cool. I personally have no problem with hard coding our web jmx console to support the attributes we use. -dain --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: FW: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service
On Tuesday, January 28, 2003, at 12:47 AM, Dain Sundstrom wrote: On Monday, January 27, 2003, at 09:36 PM, David Jencks wrote: On Monday, January 27, 2003, at 07:39 PM, Dain Sundstrom wrote: Wow, I had no idea it was this complicated. Anyway the real problem is a Dynamic MBean has a setAttributes method to group together an entire set of attribute changes in one operator, but when we go to standard mbeans we lose that concept because we only have a bunch of setters. That sucks. ??? You still have the setAttributes method on the mbean server, which is the only way you can get at the stuff. Ya sure, but the implementation just calls some setters. There implementation doesn't understand that this is a group of changes. If the setAttributes was implemented by hand it could understand that host, port and back log were all changed and only create the new listener socket once. So we need to fix the jmx implementation. What you have detailed looks like a good solution to me. In the end, I just want to make the admins happy. BTW, I believe we do have an orthogonal problem with MBeans being implemented incorrectly. We have a ton of beans that simply don't do what they say they will. I see no reason why an bean that has a port setting can't remove the existing socket and create a new one. I'm not sure if you are complaining about mbeans that don't actually undo the start in stop (i.e. if it creates a socket in start, it should forget it in stop, then make a new one when start is called again), or saying you think socket creation should be done immediately when you change the port, irrespective of mbean state. I hope it's the first. No I mean the second. If you change the port, it should close the existing socket and create a new one. I see no reason why the service should have to be stopped, as I can do this today... it is just an implementation decision. I think if you change several attributes at once the (not yet written) state change interceptor should change the lifecycle state, change the attribute values, and restore the lifecycle state. You shouldn't have to explicitly stop the mbean, but it is stopped by the machinery. Hey I just thought of something. We implement our own MBean spec... XMBean right? We could have additional state for attributes that says these attributes are only writable while the bean is stopped. Then in the MBeanMetaData getter we check the state and only return the attributes that are editable at that state. This will work since we don't cache MBean MetaData. What do you think? For info-- we have this in the xmbean dtd, but we don't have any interceptor support for it yet, and I won't work on it until the aop stuff has settled down. I think some kind of icon indicating the lifecycle state needed for the change would be best. For hiding attributes, No thanks, then you can't tell what you might be able to set until you stop the mbean. Sorry, I ment to say that the attribute is read only in the running state with an icon that says you must stop the service to edit this attribute. I also think we should extend the MBeanMetaData objects to support jboss specific stuff like the above attributes. Then we can display these in our consoles. modelmbean metadata is already generically extensible, and we have extended it with stuff like the lifecycle level and (actually implemented thanks to Matt Munz) persistence. Right now I don't know of a generic way to display arbitrary metadata like this, AFAIK each item would have to be hardcoded. Maybe someone who can actually design usable interfaces could suggest something:-) Cool. I personally have no problem with hard coding our web jmx console to support the attributes we use. me too david -dain --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: FW: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service
Yes, that's the idea. It goes like this when jboss instantiates an mbean from a *-service.xml file: (create mbean) state: instantiated (set attributes) state: configured (call create method) ~(call destroy method) state: created (call start method) ~(call stop method) state: started where the ~() methods go backwards from the other methods. Personally I think the create and destroy methods could be safely removed as useless, but I lost the argument the last time we had it. Clustering needed this at least because of the state transfer algorithm: services must first be able to register with the HAPartition and once everyone has done that, the next step can be used to actually exchange the initial state. It was not (at that time, maybe it has changed) possible to make micro-state-transfer on a service-by-service basis. I think another service had a similar needs but I don't remember which one. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: FW: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service
David, Thanks so much. To paraphrase, there's basically a JBoss-specific MBean type that requires invoking stop() before setting any attributes and start() after doing so. This sounds quite reasonable. Thanks again. - Matt -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED]] Sent: Fri 1/24/2003 9:00 PM To: [EMAIL PROTECTED] Cc: Subject: Re: FW: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service Yes, that's the idea. It goes like this when jboss instantiates an mbean from a *-service.xml file: (create mbean) state: instantiated (set attributes) state: configured (call create method) ~(call destroy method) state: created (call start method) ~(call stop method) state: started where the ~() methods go backwards from the other methods. Personally I think the create and destroy methods could be safely removed as useless, but I lost the argument the last time we had it. Anyway, to see why this might be useful, lets hypothesize an mbean that takes a long time to create (just as an object) and has a socket. You want to set the ip address and port on the socket as separate attributes on the mbean. Well, creating a new socket whenever you change the host or port is not very satisfactory since there's a good chance you want to change both. Changing just one will leave the mbean in a unusable state, pointing to the right host but wrong port. You don't want to replace the mbean object with a new one because it takes a long time to create. So , the service lifecycle lets you: stop (mbean is now theoretically unusable: this should be implemented in an interceptor, but is not right now)(this would discard the old socket) change both attributes (while the mbean is off) start (this creates a new socket with all correct parameters)(mbean is now usable again). There are also mbean dependencies, whereby if your mbean has an ObjectName valued attribute, and you tell jboss, your mbean can't start until the referenced mbean has started. This is used to get most of jboss to start in an order that will work. The code that does this is now spread over ServiceController, ServiceConfigurator, and ServiceContext with a little bit of ServiceCreator thrown in. Hope this clarifies what is going on a little bit. There are no attributes that have no effect... its just that say a port number may not get into the socket until you cycle the mbean, in case you want to change the host also. I also mentioned earlier that there's an xmbean attribute indicating what the effect on service lifecycle should be of changing an attribute value. The idea behind this (unimplemented) is that if you set several attributes at once, jboss should be able to cycle the lifecycle state for you. david jencks On Friday, January 24, 2003, at 05:07 PM, Matt Munz wrote: David, We are miscommunicating. In all the mbeans I have written and seen in jboss, aside from egregious bugs, if setting an attribute doesn't have an immediate effect, it does have the desired effect if you run through the service lifecycle (usually stop, start, occasionally stop, destroy, create, start). My view is that mbeans in jboss can take advantage of the service lifecycle. If you don't want to, make all your attribute changes have their effects immediately. All our mbeans are pretty much jboss specific and most heavily use the service lifecycle. They just won't run without it. I still think it is a really convenient extension to vanilla jmx and don't see why we should replace it. I barely know what the service lifecycle is. I have not used it. I am not arguing to replace it. I never said that. You said that. How do I set an attribute correctly, step by step, for a Bean that uses the service lifecycle? It helps me to use a state metaphor when considering lifecycle issues. It sounds like there are several states a lifecycle-oriented bean can be in: destroyed, created, running. In which state is it safe
FW: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service
this one didn't make it either... -Original Message- From: Matt Munz Sent: Fri 1/24/2003 12:18 PM To: [EMAIL PROTECTED] Cc: Subject: RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service David, If you will, take a step back with me. Think JMX and not JBoss-JMX. You are writing a tool to do generic operations on MBeans. This is the purpose of JMX in the first place. Your tool encounters a RW attribute. What assumptions can be made, reasonably? Here are my assumptions: 1. get the value of the attribute and store it in an object. Do not modify the object. Set the value of the attribute to the object. No error will occur. 2. set the attribute to a given value that is not equivalent to the current value. The behavior / state of the MBean will change in a meaningful way. Does the JMX spec enforce these? Perhaps not. Is it nevertheless reasonable to expect this behavior? I think so. Neither of these assumptions are upheld, however, in the current use of MBeans in JBoss. I realize that re-writing mbeans might cause pain for the project. I'm not suggesting that it should even be done, necessarily, at least not right away. I am, however, trying to reconcile the notion of a RW attribute where writing the value has no effect. Can this be explained simply? BTW, I don't see how the lifecycle is related to this particular issue. Perhaps you could explain this in more depth? - Matt -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED]] Sent: Fri 1/24/2003 11:44 AM To: [EMAIL PROTECTED] Cc: Subject: Re: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service On Friday, January 24, 2003, at 11:07 AM, Matt Munz wrote: Sacha, I follow you fine. The RW attributes you describe should be RO. Another mechanism should be used to designate a default value. This (mis)use of the MBean interface results in an inconsistent view of the server configuration capabilities. It may be convenient to describe a write-once at a very-specific time attribute as RW, but this is fitting a round peg in a square hole (it may fit, but it rattles around a lot and could break as a result). I think our current lifecycle based approach is quite workable as long as you use it as described in my previous post. As I understand it you are suggesting replacing the jboss lifecycle idea with the following: 1. All attributes that currently require lifecycle state changes should be made read only and set in the mbean constructor. 2. There should be some easy to use way to recreate an mbean with the same object name, some unchanged attributes, but new constructor arguments, at least as easy as the current stop-change-start technique. 3. No lifecycle methods. This might work, I haven't thought of any fatal problems with it. +: Currently most of our mbeans are probably insufficiently synchronized. By setting all arguments in the constructor, such problems could perhaps be reduced. -: This would require rewriting nearly every jboss mbean. I'd like to see more advantages before undertaking such an enormous project. david jencks What you need is an Object-creation descriptor that says pass these arguments to the constructor of object X. Then the value will be set *before* the object is loaded into the MBean server, and there is no need to name any attributes RW spuriously. I think that it is possible that the XMBean descriptor has something like this -- perhaps this is the best option. The take-home message here is that MBean Persistence is a cross-cutting concern. As such, I expect it to pull some skeletons out of the closet re: MBeans with
Re: FW: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service
While I'm sure what you are proposing can be made to work, it would be a really big redesign of how mbeans are thought of in jboss. Something you can do today, in just a few minutes, and will make your proposal work with jboss as it is currently written is to use the service lifecycle methods as I outlined. david On Friday, January 24, 2003, at 03:24 PM, Matt Munz wrote: The third message that didn't make it the first time... -Original Message- From: Matt Munz Sent: Fri 1/24/2003 11:51 AM To: [EMAIL PROTECTED] Cc: Subject: RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service David, This sounds good, but is it possible to KIS? I think that interrelated attributes can be avoided in most cases. For the exceptional cases, we could provide a mechanism for declaring an order in which the attributes on a given bean should be set. As for inter-Bean dependencies, I suppose this is what the Notification API is for. The MBean interface will never be able to show the multitude of complex behaviors that an Object can present. What about the methods setValueButOnlyIfTodayIsTuesday(Object value) or setValueButOnlyIfValueFooOnMBeanBarIsAlsoSet(Object value). JMX, as it is, is nice and simple. The lifecycle feature might help, though--I'm on the fence. This is one of my beefs with generalized architectures -- it is so easy to think up ways to break the system! - Matt -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED]] Sent: Fri 1/24/2003 10:52 AM To: [EMAIL PROTECTED] Cc: Subject: Re: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service JMX lacks a service lifecycle, which IMO is needed for this to make sense. For most jboss mbeans with attributes like port number etc, changing the attribute value will have an effect if you: stop change attribute values start Often there are several interrelated attributes so going through the lifecycle on an individual attribute change doesn't make sense. There is an unimplemented feature described in the xmbean dtd where you specify for an attribute what state of service lifecycle you need to go to when you change an attribute. The idea is if you call setAttributes() some interceptors should bring the lifecycle state to the least started level required of any attribute in the list. For your master configuration feature, I think for each mbean calling stop destroy set attributes create start will work. We will probably find plenty of bugs in lots of mbeans whose lifecycle is broken: fixing these will greatly improve jboss's stability IMO. david jencks On Friday, January 24, 2003, at 09:59 AM, Matt Munz wrote: Sacha, I don't really understand. What good is a RW attribute if changing it has no effect? If this is really the case, then I think a lot of those RW attributes should be changed to RO. The whole idea of JMX is Management. The interface means something, right? - Matt -Original Message- From: [EMAIL PROTECTED] on behalf of Sacha Labourey Sent: Fri 1/24/2003 9:45 AM To: [EMAIL PROTECTED] Cc: Subject: RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service Oh, no, nothing wrong at all. It is just that while I can easily see an advantage to take a snapshot of a server config for future reference or analysis, re-loading a previous seems as hazardous to me because the configuration should really be applied when the mbeans are created, not afterwards because many settings would then have no effects at all (such as port numbers, etc.) Thank you. cheers, Sacha -Message d'origine- De : Matt Munz [mailto:[EMAIL PROTECTED]]De la part de Matt Munz Envoyé : vendredi, 24 janvier 2003 15:35 À : [EMAIL PROTECTED] Objet : RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service Sacha, No. Nothing fancy going on here. Just a quick one-off proof-of-concept deal. What it does is make text-file-based mbean persistence available today, in a format perhaps more amenable to vi hackers. It's pretty simple to use -- why don't you just drop it in deploy and try it out... Basically, it takes and loads snapshots. Simple and useable. I suppose it could be modified to do other things... What is wrong with the jboss-service.xml files? I'm curious -- What are you getting at? - Matt -Original Message- From: Sacha Labourey [mailto:[EMAIL PROTECTED]]
Re: FW: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service
On Friday, January 24, 2003, at 03:23 PM, Matt Munz wrote: this one didn't make it either... -Original Message- From: Matt Munz Sent: Fri 1/24/2003 12:18 PM To: [EMAIL PROTECTED] Cc: Subject: RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service David, If you will, take a step back with me. Think JMX and not JBoss-JMX. You are writing a tool to do generic operations on MBeans. This is the purpose of JMX in the first place. Your tool encounters a RW attribute. What assumptions can be made, reasonably? Here are my assumptions: 1. get the value of the attribute and store it in an object. Do not modify the object. Set the value of the attribute to the object. No error will occur. 2. set the attribute to a given value that is not equivalent to the current value. The behavior / state of the MBean will change in a meaningful way. Does the JMX spec enforce these? Perhaps not. Is it nevertheless reasonable to expect this behavior? I think so. Neither of these assumptions are upheld, however, in the current use of MBeans in JBoss. I realize that re-writing mbeans might cause pain for the project. I'm not suggesting that it should even be done, necessarily, at least not right away. I am, however, trying to reconcile the notion of a RW attribute where writing the value has no effect. Can this be explained simply? BTW, I don't see how the lifecycle is related to this particular issue. Perhaps you could explain this in more depth? In all the mbeans I have written and seen in jboss, aside from egregious bugs, if setting an attribute doesn't have an immediate effect, it does have the desired effect if you run through the service lifecycle (usually stop, start, occasionally stop, destroy, create, start). My view is that mbeans in jboss can take advantage of the service lifecycle. If you don't want to, make all your attribute changes have their effects immediately. All our mbeans are pretty much jboss specific and most heavily use the service lifecycle. They just won't run without it. I still think it is a really convenient extension to vanilla jmx and don't see why we should replace it. david jencks - Matt -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED]] Sent: Fri 1/24/2003 11:44 AM To: [EMAIL PROTECTED] Cc: Subject: Re: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service On Friday, January 24, 2003, at 11:07 AM, Matt Munz wrote: Sacha, I follow you fine. The RW attributes you describe should be RO. Another mechanism should be used to designate a default value. This (mis)use of the MBean interface results in an inconsistent view of the server configuration capabilities. It may be convenient to describe a write-once at a very-specific time attribute as RW, but this is fitting a round peg in a square hole (it may fit, but it rattles around a lot and could break as a result). I think our current lifecycle based approach is quite workable as long as you use it as described in my previous post. As I understand it you are suggesting replacing the jboss lifecycle idea with the following: 1. All attributes that currently require lifecycle state changes should be made read only and set in the mbean constructor. 2. There should be some easy to use way to recreate an mbean with the same object name, some unchanged attributes, but new constructor arguments, at least as easy as the current stop-change-start technique. 3. No lifecycle methods. This might work, I haven't thought of any fatal problems with it. +: Currently most of our mbeans are probably insufficiently synchronized. By setting all arguments in the constructor, such problems could perhaps be reduced. -: This would require rewriting nearly every jboss mbean. I'd like to see more advantages before undertaking such an enormous project. david jencks What you need is an Object-creation descriptor that says pass these arguments to the constructor of object X. Then the value will be set *before* the object is loaded into the MBean server, and there is no need to name any attributes RW spuriously. I think that it is possible that the XMBean descriptor has something like this -- perhaps this is the best option. The take-home message here is that MBean Persistence is a cross-cutting concern. As such, I expect it to pull some skeletons out of the closet re: MBeans with inconsistent interfaces. - Matt -Original Message- From: [EMAIL PROTECTED] on behalf of Sacha Labourey Sent: Fri 1/24/2003 10:30 AM To: [EMAIL PROTECTED] Cc: Subject: RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service Not exatly. Take a
RE: FW: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service
David,
We are miscommunicating.
In all the mbeans I have written and seen in jboss, aside from
egregious bugs, if setting an attribute doesn't have an immediate
effect, it does have the desired effect if you run through the service
lifecycle (usually stop, start, occasionally stop, destroy, create,
start). My view is that mbeans in jboss can take advantage of the
service lifecycle. If you don't want to, make all your attribute
changes have their effects immediately. All our mbeans are pretty much
jboss specific and most heavily use the service lifecycle. They just
won't run without it. I still think it is a really convenient
extension to vanilla jmx and don't see why we should replace it.
I barely know what the service lifecycle is. I have not used it. I am not
arguing to replace it. I never said that. You said that.
How do I set an attribute correctly, step by step, for a Bean that uses the
service lifecycle?
It helps me to use a state metaphor when considering lifecycle issues. It
sounds like there are several states a lifecycle-oriented bean can be in: destroyed,
created, running. In which state is it safe to set RW attributes on
lifecycle-oriented beans?
Is the following the appropriate way to set values on a lifecycle-oriented
bean (pseudo-code)?
if(bean.isLifecycleOriented())
{
if(bean.isRunning())
{
bean.stop();
}
bean.setAttribute(newValue);
bean.start();
}
I'm here to learn :)
- Matt
N¬HSDMéX¬²'²Þu¼¢êÜxZ+á'µêé®+ Øþ .)îÅj+Ô¨ëax6I硶Úÿ
0½«(~Üç(è²Ç^½éh¦g§¶f¢)à+-%º,±×¯zZ)éí+-²Ê.Ç¢¸ ëa¶Úlÿùb²Û,¢êÜyú+éÞ·ùb²Û?+-wèþ6è²Ç^½éh¦g§
Re: FW: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service
Yes, that's the idea. It goes like this when jboss instantiates an
mbean from a *-service.xml file:
(create mbean)
state: instantiated
(set attributes)
state: configured
(call create method) ~(call destroy method)
state: created
(call start method) ~(call stop method)
state: started
where the ~() methods go backwards from the other methods.
Personally I think the create and destroy methods could be safely
removed as useless, but I lost the argument the last time we had it.
Anyway, to see why this might be useful, lets hypothesize an mbean that
takes a long time to create (just as an object) and has a socket. You
want to set the ip address and port on the socket as separate
attributes on the mbean. Well, creating a new socket whenever you
change the host or port is not very satisfactory since there's a good
chance you want to change both. Changing just one will leave the mbean
in a unusable state, pointing to the right host but wrong port. You
don't want to replace the mbean object with a new one because it takes
a long time to create. So , the service lifecycle lets you:
stop (mbean is now theoretically unusable: this should be implemented
in an interceptor, but is not right now)(this would discard the old
socket)
change both attributes (while the mbean is off)
start (this creates a new socket with all correct parameters)(mbean is
now usable again).
There are also mbean dependencies, whereby if your mbean has an
ObjectName valued attribute, and you tell jboss, your mbean can't start
until the referenced mbean has started. This is used to get most of
jboss to start in an order that will work.
The code that does this is now spread over ServiceController,
ServiceConfigurator, and ServiceContext with a little bit of
ServiceCreator thrown in.
Hope this clarifies what is going on a little bit. There are no
attributes that have no effect... its just that say a port number may
not get into the socket until you cycle the mbean, in case you want to
change the host also.
I also mentioned earlier that there's an xmbean attribute indicating
what the effect on service lifecycle should be of changing an attribute
value. The idea behind this (unimplemented) is that if you set several
attributes at once, jboss should be able to cycle the lifecycle state
for you.
david jencks
On Friday, January 24, 2003, at 05:07 PM, Matt Munz wrote:
David,
We are miscommunicating.
In all the mbeans I have written and seen in jboss, aside from
egregious bugs, if setting an attribute doesn't have an immediate
effect, it does have the desired effect if you run through the
service
lifecycle (usually stop, start, occasionally stop, destroy, create,
start). My view is that mbeans in jboss can take advantage of the
service lifecycle. If you don't want to, make all your attribute
changes have their effects immediately. All our mbeans are pretty
much
jboss specific and most heavily use the service lifecycle. They just
won't run without it. I still think it is a really convenient
extension to vanilla jmx and don't see why we should replace it.
I barely know what the service lifecycle is. I have not used it. I
am not arguing to replace it. I never said that. You said that.
How do I set an attribute correctly, step by step, for a Bean that
uses the service lifecycle?
It helps me to use a state metaphor when considering lifecycle
issues. It sounds like there are several states a lifecycle-oriented
bean can be in: destroyed, created, running. In which state is it
safe to set RW attributes on lifecycle-oriented beans?
Is the following the appropriate way to set values on a
lifecycle-oriented bean (pseudo-code)?
if(bean.isLifecycleOriented())
{
if(bean.isRunning())
{
bean.stop();
}
bean.setAttribute(newValue);
bean.start();
}
I'm here to learn :)
- Matt
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
