On Friday, January 24, 2003, at 12:37 PM, Sacha Labourey wrote:
The ServiceContext has to exist whether or not it is currently part of an interceptor chain for a currently existing mbean, in order to record dependencies on mbeans that haven't been deployed yet. So I don't think changing the interceptor list will be a problem: you always get the ServiceContext from a centralized factory/store which returns the one it already knows about.Hello David,because otherwise, when you are in the stop state, you don't know if it is aoh yes! This problem really involves all management parts i.e. how we want to be able to store the config, modify the config, have config repositories, etc. Furthermore, we need to take in account in this new design the really-missing-"restart"-feature which is not equivalent to the stop-start semantic.Why not?
definitive stop (in which case you shouln't block the valve for example) or
a temporary stop (in which case you may want to give a way to a
service/application to provide some temporary state that the service
controller can give it back once the service is restarted for example)
Well, then you cannot update the list of the JMX interceptors as you cycleWe must really implement the restart trick for 4.0 as it is one of the
only
way to cleanly implement the "valve" trick (block the valve for new
invocations as we cycle the app/service).
I was planning to move the dependency logic from ServiceController to ServiceContext and make ServiceContext an mbean interceptor. It would also block calls when state was not started. If you change a set of attributes, it would consult the metadata to see what lifecycle state it must downgrade to, go to it, and go back to "started". Do you see something wrong with this plan?
your service, right? Otherwise, how do you cycle the "ServiceContext"
interceptor?
At one point, independently of where do you manage that, I amThe other way I can think of to handle this is with timeouts: any blocked call will eventually time out if the mbean isn't started first. Timeouts have the property that if something goes wrong in the restart the clients will be informed that there is a problem in a known amount of time. Many calls should be within a transaction anyway, which also times out...
pretty sure that you need a part of the system that thinks "I do think in a
specific way because it is a restart and not a definitive stop". You don't
think so?
david jencks
Cheers, sachay ------------------------------------------------------- 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
