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. > 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? :-) /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
