TC 5: Support for multiple Coyote JK-Pools
Am I right, that by design TC 5 only fully supports one Coyote JK pool at the moment? I enabled JMX HTTP adaptor via mx.enabled=true. Obviously org.apache.jk.common.JkMX tries to initialize the JMX HTTP adaptor not only once, but for every Coyote JK pool configured in server.xml. For the second pool I get an exception when starting tomcat (see below). When trying to stop TC, the Coyote HTTP pool is shut down correctly, and one of the two JK pools doesn't listen any more, but the second JK pool still listens and TC does not shut down. Retrying shutdown does not help, the process is still alive. Any plans (or work already done) to refactor JkMain/JkMX for 5.next? Rainer Jung Exception during start: 2004-07-26 12:37:58,929 (main) org.apache.jk.common.JkMX/ERROR: Can't load the MX4J http adapter javax.management.InstanceAlreadyExistsException: Http:name=HttpAdaptor at mx4j.server.MBeanServerImpl.register(MBeanServerImpl.java:1123) at mx4j.server.MBeanServerImpl.registerImpl(MBeanServerImpl.java:1054) at mx4j.server.MBeanServerImpl.registerMBeanImpl(MBeanServerImpl.java:1002) at mx4j.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:978) at org.apache.jk.common.JkMX.registerObject(JkMX.java:314) at org.apache.jk.common.JkMX.loadAdapter(JkMX.java:157) at org.apache.jk.common.JkMX.init(JkMX.java:268) at org.apache.jk.server.JkMain.start(JkMain.java:339) at org.apache.jk.server.JkCoyoteHandler.start(JkCoyoteHandler.java:193) at org.apache.coyote.tomcat5.CoyoteConnector.start(CoyoteConnector.java:1527) at org.apache.catalina.core.StandardService.start(StandardService.java:489) at org.apache.catalina.core.StandardServer.start(StandardServer.java:2313) at org.apache.catalina.startup.Catalina.start(Catalina.java:556) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:284) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:422) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TC 5: Support for multiple Coyote JK-Pools
Rainer Jung wrote: Am I right, that by design TC 5 only fully supports one Coyote JK pool at the moment? I enabled JMX HTTP adaptor via mx.enabled=true. Obviously org.apache.jk.common.JkMX tries to initialize the JMX HTTP adaptor not only once, but for every Coyote JK pool configured in server.xml. For the second pool I get an exception when starting tomcat (see below). When trying to stop TC, the Coyote HTTP pool is shut down correctly, and one of the two JK pools doesn't listen any more, but the second JK pool still listens and TC does not shut down. Retrying shutdown does not help, the process is still alive. Any plans (or work already done) to refactor JkMain/JkMX for 5.next? Yes: use JDK 1.5 JMX instead of this code. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TC 5: Support for multiple Coyote JK-Pools
Remy Maucherat wrote: Rainer Jung wrote: Am I right, that by design TC 5 only fully supports one Coyote JK pool at the moment? I enabled JMX HTTP adaptor via mx.enabled=true. Obviously org.apache.jk.common.JkMX tries to initialize the JMX HTTP adaptor not only once, but for every Coyote JK pool configured in server.xml. For the second pool I get an exception when starting tomcat (see below). When trying to stop TC, the Coyote HTTP pool is shut down correctly, and one of the two JK pools doesn't listen any more, but the second JK pool still listens and TC does not shut down. Retrying shutdown does not help, the process is still alive. Any plans (or work already done) to refactor JkMain/JkMX for 5.next? Yes: use JDK 1.5 JMX instead of this code. Are we going to switch to JDK1.5 ??? I missed this one. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TC 5: Support for multiple Coyote JK-Pools
Costin Manolache wrote: Remy Maucherat wrote: Rainer Jung wrote: Am I right, that by design TC 5 only fully supports one Coyote JK pool at the moment? I enabled JMX HTTP adaptor via mx.enabled=true. Obviously org.apache.jk.common.JkMX tries to initialize the JMX HTTP adaptor not only once, but for every Coyote JK pool configured in server.xml. For the second pool I get an exception when starting tomcat (see below). When trying to stop TC, the Coyote HTTP pool is shut down correctly, and one of the two JK pools doesn't listen any more, but the second JK pool still listens and TC does not shut down. Retrying shutdown does not help, the process is still alive. Any plans (or work already done) to refactor JkMain/JkMX for 5.next? Yes: use JDK 1.5 JMX instead of this code. Are we going to switch to JDK1.5 ??? I missed this one. Actually, I posted that we could consider switching to JDK 1.5, yes (I do really like that JDK). The idea is that I'm tweaking the API, so I would use the new stuff when rewriting code. I don't think it'll happen in the end, since not many people seem to be in favor of it. Here, I was mentioning that using JDK 1.5 would be a workaround (as the connector registration moves out of the JVM). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TC 5: Support for multiple Coyote JK-Pools
Remy Maucherat wrote: Costin Manolache wrote: Remy Maucherat wrote: Rainer Jung wrote: Am I right, that by design TC 5 only fully supports one Coyote JK pool at the moment? I enabled JMX HTTP adaptor via mx.enabled=true. Obviously org.apache.jk.common.JkMX tries to initialize the JMX HTTP adaptor not only once, but for every Coyote JK pool configured in server.xml. For the second pool I get an exception when starting tomcat (see below). When trying to stop TC, the Coyote HTTP pool is shut down correctly, and one of the two JK pools doesn't listen any more, but the second JK pool still listens and TC does not shut down. Retrying shutdown does not help, the process is still alive. Any plans (or work already done) to refactor JkMain/JkMX for 5.next? Yes: use JDK 1.5 JMX instead of this code. Are we going to switch to JDK1.5 ??? I missed this one. Actually, I posted that we could consider switching to JDK 1.5, yes (I do really like that JDK). The idea is that I'm tweaking the API, so I would use the new stuff when rewriting code. I don't think it'll happen in the end, since not many people seem to be in favor of it. Here, I was mentioning that using JDK 1.5 would be a workaround (as the connector registration moves out of the JVM). Well, I like JDK1.5 as well - but I think we should follow the same path of keeping the base functionality available on lower VMs, and restrict 1.5 to individual components. Not sure what you mean with connector registration moves out of jvm tough, but it sounds interesting :-) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TC 5: Support for multiple Coyote JK-Pools
Costin Manolache wrote: Remy Maucherat wrote: Costin Manolache wrote: Remy Maucherat wrote: Rainer Jung wrote: Am I right, that by design TC 5 only fully supports one Coyote JK pool at the moment? I enabled JMX HTTP adaptor via mx.enabled=true. Obviously org.apache.jk.common.JkMX tries to initialize the JMX HTTP adaptor not only once, but for every Coyote JK pool configured in server.xml. For the second pool I get an exception when starting tomcat (see below). When trying to stop TC, the Coyote HTTP pool is shut down correctly, and one of the two JK pools doesn't listen any more, but the second JK pool still listens and TC does not shut down. Retrying shutdown does not help, the process is still alive. Any plans (or work already done) to refactor JkMain/JkMX for 5.next? Yes: use JDK 1.5 JMX instead of this code. Are we going to switch to JDK1.5 ??? I missed this one. Actually, I posted that we could consider switching to JDK 1.5, yes (I do really like that JDK). The idea is that I'm tweaking the API, so I would use the new stuff when rewriting code. I don't think it'll happen in the end, since not many people seem to be in favor of it. Here, I was mentioning that using JDK 1.5 would be a workaround (as the connector registration moves out of the JVM). Well, I like JDK1.5 as well - but I think we should follow the same path of keeping the base functionality available on lower VMs, and restrict 1.5 to individual components. Not sure what you mean with connector registration moves out of jvm tough, but it sounds interesting :-) Bad sentence, it should be moves to the JVM. I don't know if you tried it, but there's a management.properties file that has all the options you could dream of to configure JMX remote :) Then you get fancy graphs without having to configure anything in Tomcat (http://mc4j.sourceforge.net/15Features_large.gif and the more classic http://mc4j.sourceforge.net/ss5_large.gif). So it's less code in Tomcat for something a lot more powerful = I like it (even if I have to remove all the enum variables from my code). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TC 5: Support for multiple Coyote JK-Pools
Remy Maucherat wrote: Costin Manolache wrote: Remy Maucherat wrote: Costin Manolache wrote: Remy Maucherat wrote: Rainer Jung wrote: Am I right, that by design TC 5 only fully supports one Coyote JK pool at the moment? I enabled JMX HTTP adaptor via mx.enabled=true. Obviously org.apache.jk.common.JkMX tries to initialize the JMX HTTP adaptor not only once, but for every Coyote JK pool configured in server.xml. For the second pool I get an exception when starting tomcat (see below). When trying to stop TC, the Coyote HTTP pool is shut down correctly, and one of the two JK pools doesn't listen any more, but the second JK pool still listens and TC does not shut down. Retrying shutdown does not help, the process is still alive. Any plans (or work already done) to refactor JkMain/JkMX for 5.next? Yes: use JDK 1.5 JMX instead of this code. Are we going to switch to JDK1.5 ??? I missed this one. Actually, I posted that we could consider switching to JDK 1.5, yes (I do really like that JDK). The idea is that I'm tweaking the API, so I would use the new stuff when rewriting code. I don't think it'll happen in the end, since not many people seem to be in favor of it. Here, I was mentioning that using JDK 1.5 would be a workaround (as the connector registration moves out of the JVM). Well, I like JDK1.5 as well - but I think we should follow the same path of keeping the base functionality available on lower VMs, and restrict 1.5 to individual components. Not sure what you mean with connector registration moves out of jvm tough, but it sounds interesting :-) Bad sentence, it should be moves to the JVM. I don't know if you tried it, but there's a management.properties file that has all the options you could dream of to configure JMX remote :) Then you get fancy graphs without having to configure anything in Tomcat (http://mc4j.sourceforge.net/15Features_large.gif and the more classic http://mc4j.sourceforge.net/ss5_large.gif). So it's less code in Tomcat for something a lot more powerful = I like it (even if I have to remove all the enum variables from my code). Yes, I know jdk1.5 has this - however I tought we want to support this for lower VMs as well, it's important enough. And the typical solution is to have a module that does this - it is in j-t-c for the simple reason that coyote is used with all tomcat versions ( 3.3, 4.x, 5.x ) - so it is easier to place it there. IMO we should stop making a strong distinction between the different plugins - connector, authenticator, logger, mapper, etc. They are all plugins, and it makes perfect sense to have a plugin that adds a jmx feature that is present in jdk1.5 and makes it available in jdk1.3 - that means easier transition to 1.5, consistent behavior, etc. BTW - I preffer the http/servlet-based jmx console, as in mx4j or jboss. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
