Re: [5] Few major changes in JMX naming
Costin Manolache wrote: Not as major as the build breakage, I hope - but I think it is better to do it as soon as possible. Unless someone has good reasons not to do it, I'll start refactoring the JMX registration. There are few things I would like to do: - get rid of service=XXX in names. The JMX domain will correspond to one tomcat instance - there is no reason to make things more complex. The admin can just list all mbeans, search for *:type=Engine and get the domain. - The name of the Engine will be the same as the domain: foo:type=Engine will have a name attribute with value foo. I haven't looked at or played with the new JMX featuers. But I do have some thoughts on names and scopes. We need to ensure that there is a unique naming mechanism. A single monitoring tool may be used to monitor multiple instances of Tomcat. I plan on doing that some time in the future. Each instance of Tomcat running needs to have a unique name. The host name can not be used in lieu of the Engine name. I configure two Engine's which have the same host name. One for normal http, one for https. The scoping required to ensure unique names is /Service/Engine/Host/Context. - 2 major modes will be supported: JMX driven and API driven. In the first mode, tomcat will be controlled using JMX. Each component will use preRegister hook to learn it's name, and init() to register itself with the parent. For example, a Valve mbean with name: domain:type=Valve,host=myHost,name=valveName will know from the name that it must attach to host myHost in domain. The second mode tomcat will be created the old way, by using the internal APIs. The ServerLifecycleListener will be gradually removed - each component must be in control of its naming. There are 2 cases: - components that have lifecycle ( Container, Connector ) will check in init() if they already have a name. If not - they'll do the register themself. - all other components can be registered by the parent ( Valves, etc ). - the big mbeans-descriptors will be split up and each package will have an mbeans-descriptors describing its own components. Modeler can auto-discover it when registerComponent() is called, and that works for everything. I think this should be done now - or never. The main purpose is to have smarter and more flexible components, capable to support reloading, reconfiguration and work in any environment. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5] Few major changes in JMX naming
Glenn Nielsen wrote: I haven't looked at or played with the new JMX featuers. But I do have some thoughts on names and scopes. We need to ensure that there is a unique naming mechanism. A single monitoring tool may be used to monitor multiple instances of Tomcat. I plan on doing that some time in the future. Each instance of Tomcat running needs to have a unique name. The host name can not be used in lieu of the Engine name. I configure two Engine's which have the same host name. One for normal http, one for https. The scoping required to ensure unique names is /Service/Engine/Host/Context. Did you understand that JMX domain name = engine name = unique ID ? Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5] Few major changes in JMX naming
Glenn Nielsen wrote: I haven't looked at or played with the new JMX featuers. But I do have some thoughts on names and scopes. We need to ensure that there is a unique naming mechanism. That's the intention of the change. A single monitoring tool may be used to monitor multiple instances of Tomcat. I plan on doing that some time in the future. Each instance of Tomcat running needs to have a unique name. Well - I'm already working on the JMX proxy ( similar with the proxy for mod_jk2 mbeans ). And /admin and any other tool will manage clusters ( or multiple instances ) just like they manage a single instance. For example, with a bit of cleanup, /admin could display a select box with all the domains - and administer any tomcat instance ( assuming some setup is done to proxy the JMX domains ) An essential piece is indeed the unique name - and in JMX terms that will be the domain ( and will also be used as jvmRoute ). The host name can not be used in lieu of the Engine name. I configure two Engine's which have the same host name. One for normal http, one for https. Host name has nothing to do with this. The JMX domain corresponds to one Engine. An Engine can contain multiple hosts, and you can have multiple engines ( in different JMX domains ) and multiple connectors. The Engine name is the id of a tomcat instance ( even if you run multiple Engines in the same JVM - from the point of view of routing or admin, they are different ) The scoping required to ensure unique names is /Service/Engine/Host/Context. There is a one-to-one mapping between Service and Engine, and Embeded tomcat doesn't use Service ( Service is just a wrapper for 1 Engine + Connectors ). So the naming will be: Engine - Host - Context Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5] Few major changes in JMX naming
Thanks for clarifying that Costin. Just wanted to make sure. :-) Costin Manolache wrote: Glenn Nielsen wrote: I haven't looked at or played with the new JMX featuers. But I do have some thoughts on names and scopes. We need to ensure that there is a unique naming mechanism. That's the intention of the change. A single monitoring tool may be used to monitor multiple instances of Tomcat. I plan on doing that some time in the future. Each instance of Tomcat running needs to have a unique name. Well - I'm already working on the JMX proxy ( similar with the proxy for mod_jk2 mbeans ). And /admin and any other tool will manage clusters ( or multiple instances ) just like they manage a single instance. For example, with a bit of cleanup, /admin could display a select box with all the domains - and administer any tomcat instance ( assuming some setup is done to proxy the JMX domains ) An essential piece is indeed the unique name - and in JMX terms that will be the domain ( and will also be used as jvmRoute ). The host name can not be used in lieu of the Engine name. I configure two Engine's which have the same host name. One for normal http, one for https. Host name has nothing to do with this. The JMX domain corresponds to one Engine. An Engine can contain multiple hosts, and you can have multiple engines ( in different JMX domains ) and multiple connectors. The Engine name is the id of a tomcat instance ( even if you run multiple Engines in the same JVM - from the point of view of routing or admin, they are different ) The scoping required to ensure unique names is /Service/Engine/Host/Context. There is a one-to-one mapping between Service and Engine, and Embeded tomcat doesn't use Service ( Service is just a wrapper for 1 Engine + Connectors ). So the naming will be: Engine - Host - Context Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[5] Few major changes in JMX naming
Not as major as the build breakage, I hope - but I think it is better to do it as soon as possible. Unless someone has good reasons not to do it, I'll start refactoring the JMX registration. There are few things I would like to do: - get rid of service=XXX in names. The JMX domain will correspond to one tomcat instance - there is no reason to make things more complex. The admin can just list all mbeans, search for *:type=Engine and get the domain. - The name of the Engine will be the same as the domain: foo:type=Engine will have a name attribute with value foo. - 2 major modes will be supported: JMX driven and API driven. In the first mode, tomcat will be controlled using JMX. Each component will use preRegister hook to learn it's name, and init() to register itself with the parent. For example, a Valve mbean with name: domain:type=Valve,host=myHost,name=valveName will know from the name that it must attach to host myHost in domain. The second mode tomcat will be created the old way, by using the internal APIs. The ServerLifecycleListener will be gradually removed - each component must be in control of its naming. There are 2 cases: - components that have lifecycle ( Container, Connector ) will check in init() if they already have a name. If not - they'll do the register themself. - all other components can be registered by the parent ( Valves, etc ). - the big mbeans-descriptors will be split up and each package will have an mbeans-descriptors describing its own components. Modeler can auto-discover it when registerComponent() is called, and that works for everything. I think this should be done now - or never. The main purpose is to have smarter and more flexible components, capable to support reloading, reconfiguration and work in any environment. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5] Few major changes in JMX naming
Costin Manolache wrote: Not as major as the build breakage, I hope - but I think it is better to do it as soon as possible. Unless someone has good reasons not to do it, I'll start refactoring the JMX registration. There are few things I would like to do: - get rid of service=XXX in names. The JMX domain will correspond to one tomcat instance - there is no reason to make things more complex. The admin can just list all mbeans, search for *:type=Engine and get the domain. Ok, so that goes along with having only a one unique ID for engine/service/etc. - The name of the Engine will be the same as the domain: foo:type=Engine will have a name attribute with value foo. Ok. - 2 major modes will be supported: JMX driven and API driven. In the first mode, tomcat will be controlled using JMX. Each component will use preRegister hook to learn it's name, and init() to register itself with the parent. For example, a Valve mbean with name: domain:type=Valve,host=myHost,name=valveName will know from the name that it must attach to host myHost in domain. The second mode tomcat will be created the old way, by using the internal APIs. The ServerLifecycleListener will be gradually removed - each component must be in control of its naming. There are 2 cases: - components that have lifecycle ( Container, Connector ) will check in init() if they already have a name. If not - they'll do the register themself. - all other components can be registered by the parent ( Valves, etc ). - the big mbeans-descriptors will be split up and each package will have an mbeans-descriptors describing its own components. Modeler can auto-discover it when registerComponent() is called, and that works for everything. Sounds very good :) I think this should be done now - or never. The main purpose is to have smarter and more flexible components, capable to support reloading, reconfiguration and work in any environment. Please don't try to port that to 4.1.x ;-) Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5] Few major changes in JMX naming
I forgot one important thing: The main problem with supporting both registrations is the deregistration - who should unregister a component ? If the components are started by JMX - then JMX is supposed to unregister them. If they are created automatically - then whoever created them is responsible to unregister them ( and stop, etc ). Unfortunately, there is no way to guess which one - so each component will have a controller field. If the field is null - that means JMX ( or some external entity ) created the component and is in charge of its lifecycle. Whenever we create a component internally - for example valves, etc - and we register them in parent or when the component registers itself in init, it should also set the controller field with the object name of the component. On destroy() or when the component is removed - we should check the controller and unregister. It's simpler than it sounds :-) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5] Few major changes in JMX naming
Remy Maucherat wrote: - get rid of service=XXX in names. The JMX domain will correspond to one tomcat instance - there is no reason to make things more complex. The admin can just list all mbeans, search for *:type=Engine and get the domain. Ok, so that goes along with having only a one unique ID for engine/service/etc. And having simpler/cleaner names. I think this should be done now - or never. The main purpose is to have smarter and more flexible components, capable to support reloading, reconfiguration and work in any environment. Please don't try to port that to 4.1.x ;-) :-) Don't worry. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
