On 2001.10.02 11:18:00 -0400 Rickard Öberg wrote: > marc fleury wrote: > > > |So many MI's would be sharing the same list, but with different > indices > > |into it. > > > > right that is even better the only state that is in the MI is the index > and > > a (static) reference to the type of flow he will see (ejb), pretty cool > > rickard. > > > It is indeed (and I would not want to get credit for this idea. You > already said it, you just didn't know it :-). > > > |Updating the list would be to simply replace it at the gates. MI's > > |already in progress using the old version get to finish with that old > > |version. > > > > yes, once you send something in it uses that stack. Do you foresee a > > problem with this? > > > Only if the change of the stack is due to MBeans in it becoming > unavailable. Then the MI's that are in progress may try to use MBeans > that are no longer running. > > You get around this by using dependencies. If the stack mgr declares > itself as depending on the interceptor MBeans, then it should get > STOPPING events before the interceptors have actually stopped, and can > then > a) wait until any current MI's using that MBean have finished > b) hold any incoming MI's wanting to use stacks with that MBean > > Of course that won't work if the reason for stopping the interceptor is > a fatal error (i.e. no way to halt the stop procedure, even > temporarily). But then you're screwed anyway. >
I would like this best if the jmx server state were transactional with versioning optimistic concurrency control, like the firebird/interbase db. In this kind of scheme, an invocation to a mbean would get a jmx "transactional" view of all the mbeans in the jmx server as of the start of the invocation. The view of mbeans would be stable until the invocation finishes. Other concurrent changes to mbean state would use "copy on write" semantics and be visible (after they were committed) to jmx transactions started after the commit of the jmx modifications. After all uses of a replaced mbean were complete the (now inacessible) old version of the mbean can be garbage collected. Presumably one could also set up externally controlled jmx transactions so several configuration changes could occur atomically within one transaction. I guess I will have to read more of the mbean spec to see if this is consistent with it ;-) Optimistic/versioning or not, I think some kind of jmx transaction to make configuration invisible until it all completes will be necessary to make on the fly reconfiguration plausible and not too disruptive. > > > We do have a "centralized" intelligence, the distributed JMX bus (you > > indirect in JMX at every point) > > > Yup. It will be more of an interesting configuration problem, than a > programming/design problem. How do you get this to work without getting > config files the size of the planet? :-) How is this much worse than we have now? Now we have standardjboss.xml with a list of interceptors: then we will have this configuration in a "endpoint" mbean as a list of mbean references, and also mbean configuration for each interceptor individually. david jencks > > /R > > -- > Rickard Öberg > Software Development Specialist > xlurc - Xpedio Linköping Ubiquitous Research Center > Author of "Mastering RMI" > Email: [EMAIL PROTECTED] > > > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
