Native configuration changes.
Hi, Playing with the JNI connector, I found few simple ways to make it easier to set it up. Larry, Mike - let me know if you're ok ( and if you can take care of the doc part ). 1. JniConnector will be included in server.xml ( un-commented ). I added code inside to detect if tomcat is started in jni mode, and will stay silent if not. 2. If we place all DLLs/SOs in TOMCAT_HOME/bin/native, I've added code that will set the library path automatically ( including so/dll/nlm extensions ). Also cleaner messages if the file is not there. 3. Same can be used to simplify mod_jk config, it's easier for ApacheConfig to generate this location instead of ApacheHome/libexec ( or modules/, depends on apache version ). 4. The user will configure: - conf/jk/workers.properties: add 'inprocess' to the list of workers, set workers.java_home, ps, etc. ( quite easy IMHO ) - conf/server.xml: ApacheConfig jkProtocol=inprocess / - start tomcat ( so it can regenerate auto-config files in jni mode ) - start apache IMHO it's much simpler and cleaner - Larry, it's your call, the changes are easy on the java side - but docs need to be synchronized and we're quite late. Is it worth it ? Costin
Re: Native configuration changes.
[EMAIL PROTECTED] 08/15/01 09:51AM Hi, Playing with the JNI connector, I found few simple ways to make it easier to set it up. Larry, Mike - let me know if you're ok ( and if you can take care of the doc part ). 1. JniConnector will be included in server.xml ( un-commented ). I added code inside to detect if tomcat is started in jni mode, and will stay silent if not. I'm ok with this. It would make it easier for users to be able to confiure if they only had to go to one place. 2. If we place all DLLs/SOs in TOMCAT_HOME/bin/native, I've added code that will set the library path automatically ( including so/dll/nlm extensions ). Also cleaner messages if the file is not there. Another great idea. 3. Same can be used to simplify mod_jk config, it's easier for ApacheConfig to generate this location instead of ApacheHome/libexec ( or modules/, depends on apache version ). See comments below. 4. The user will configure: - conf/jk/workers.properties: add 'inprocess' to the list of workers, set workers.java_home, ps, etc. ( quite easy IMHO ) - conf/server.xml: ApacheConfig jkProtocol=inprocess / - start tomcat ( so it can regenerate auto-config files in jni mode ) - start apache The problem with this is that when you start tomcat outside of Apache, it isn't really doing anything but generating the auto-config files. They whole idea of the JNI connector is that the web server starts its own version of Tomcat by instantiating a JVM inprocess. Even if you have an external Tomcat process running, the webserver wouldn't be talking to that one via JNI. This also means that you basically have to kill the Tomcat process that you start up by hand, plus, when Apache starts up it's version of Tomcat, it would probably overwrite the auto-config file as it came up which might cause some additional headaches. IMHO it's much simpler and cleaner - Larry, it's your call, the changes are easy on the java side - but docs need to be synchronized and we're quite late. Is it worth it ? Other than the auto-config stuff, I think changes you've proposed are valid, and I could try to sync the docs with these changes. Since we haven't heard any complaints about the JNI connector yet, and it hasn't worked until just now, I'm not sure if we want to mess with it at this point, or wait until we can look at some of the auto-configuration work being done with ajp14 and/or mod_webapp that would allow a lot more dynamic configuration with the plugin handling determining which url's it should be handling dynamically. Costin Mike
RE: Native configuration changes.
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 15, 2001 11:51 AM To: [EMAIL PROTECTED] Subject: Native configuration changes. Hi, Playing with the JNI connector, I found few simple ways to make it easier to set it up. Larry, Mike - let me know if you're ok ( and if you can take care of the doc part ). 1. JniConnector will be included in server.xml ( un-commented ). I added code inside to detect if tomcat is started in jni mode, and will stay silent if not. 2. If we place all DLLs/SOs in TOMCAT_HOME/bin/native, I've added code that will set the library path automatically ( including so/dll/nlm extensions ). Also cleaner messages if the file is not there. 3. Same can be used to simplify mod_jk config, it's easier for ApacheConfig to generate this location instead of ApacheHome/libexec ( or modules/, depends on apache version ). 4. The user will configure: - conf/jk/workers.properties: add 'inprocess' to the list of workers, set workers.java_home, ps, etc. ( quite easy IMHO ) - conf/server.xml: ApacheConfig jkProtocol=inprocess / - start tomcat ( so it can regenerate auto-config files in jni mode ) - start apache +1 IMHO it's much simpler and cleaner - Larry, it's your call, the changes are easy on the java side - but docs need to be synchronized and we're quite late. Is it worth it ? There is still a lot of documentation that isn't synchronized, so I think there is time. I still plan on not releasing beta2 until the documentation is reasonable. I'm currently working on tomcat_ug.html. I am in favor of adding minor feature improvements if it will simplify the documentation and make usage easier. Cheers, Larry
Re: Native configuration changes.
On Wed, 15 Aug 2001, Mike Anderson wrote: The problem with this is that when you start tomcat outside of Apache, it isn't really doing anything but generating the auto-config files. They whole idea of the JNI connector is that the web server starts its own version of Tomcat by instantiating a JVM inprocess. Even if you have an external Tomcat process running, the webserver wouldn't be talking to that one via JNI. This also means that you basically have to kill the Tomcat process that you start up by hand, plus, when Apache starts up it's version of Tomcat, it would probably overwrite the auto-config file as it came up which might cause some additional headaches. The auto-config files are intended to avoid manual configuration - we have web.xml, and we can generate the informations about the mappings. That's how ajp12, ajp13 work. Ajp14 can work without this ( AFAIK mod_webapp still requires to manually add each web application ). But in this mode there are serious reasons to believe we'll affect the performance ( except maybe Apache2.0 where it seems to be possible to alter the server config at runtime ). This is a long-term discussion, not important for the current release, but we should keep it in mind :-) IMHO generating config files is not going to go away, even in 1.4, as it provides extremely important benefits - it gives the user a chance to fine tune the process ( which is extremely difficult when the config is sent over the wire ). And it's faster, as it doesn't duplicate the mapping stage ( and uses the server mapper, probably better than jk's ). Now the question is how do we want to deal with this configuration mode. For most users it will not matter after ajp14, since automatic-over-the-wire will cover most common cases. For advanced users - it will matter. My proposal ( quite simple to code ): - add a -serverconf XXX to tomcat.sh. ( trivial ). It'll set XXX as a ContextManager note/attribute. - uncomment ApacheConfig/, IISConfig, etc in server.xml, and alter the modules to do nothing unless serverconf note matches. ( XXX==apache to generate apache configs, etc ). That means - no server.xml changes for common use. - starting tomcat will not generate any configs. - running tomcat -serverconf apache will generate the configs for apache. Alternative: a new script confgen.sh apache that will just generate the scripts. The new rules: - install the DLLs. - run confgen - start apache. Long term, the confgen.sh can do few other things, like insert the Include in httpd.conf, etc. IMHO it's a decent solution. The user must expect that in order to deploy/undeploy webapps ( or change configs ), they must run something to let the server know about it. Or we can detect that and run confgen from tomcat. There are many choices and ways to improve if we go this path. What do you think ? Costin
RE: Native configuration changes.
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 15, 2001 1:20 PM To: [EMAIL PROTECTED] Subject: Re: Native configuration changes. On Wed, 15 Aug 2001, Mike Anderson wrote: The problem with this is that when you start tomcat outside of Apache, it isn't really doing anything but generating the auto-config files. They whole idea of the JNI connector is that the web server starts its own version of Tomcat by instantiating a JVM inprocess. Even if you have an external Tomcat process running, the webserver wouldn't be talking to that one via JNI. This also means that you basically have to kill the Tomcat process that you start up by hand, plus, when Apache starts up it's version of Tomcat, it would probably overwrite the auto-config file as it came up which might cause some additional headaches. The auto-config files are intended to avoid manual configuration - we have web.xml, and we can generate the informations about the mappings. That's how ajp12, ajp13 work. Ajp14 can work without this ( AFAIK mod_webapp still requires to manually add each web application ). But in this mode there are serious reasons to believe we'll affect the performance ( except maybe Apache2.0 where it seems to be possible to alter the server config at runtime ). This is a long-term discussion, not important for the current release, but we should keep it in mind :-) IMHO generating config files is not going to go away, even in 1.4, as it provides extremely important benefits - it gives the user a chance to fine tune the process ( which is extremely difficult when the config is sent over the wire ). And it's faster, as it doesn't duplicate the mapping stage ( and uses the server mapper, probably better than jk's ). Now the question is how do we want to deal with this configuration mode. For most users it will not matter after ajp14, since automatic-over-the-wire will cover most common cases. For advanced users - it will matter. My proposal ( quite simple to code ): - add a -serverconf XXX to tomcat.sh. ( trivial ). It'll set XXX as a ContextManager note/attribute. - uncomment ApacheConfig/, IISConfig, etc in server.xml, and alter the modules to do nothing unless serverconf note matches. ( XXX==apache to generate apache configs, etc ). That means - no server.xml changes for common use. - starting tomcat will not generate any configs. - running tomcat -serverconf apache will generate the configs for apache. Alternative: a new script confgen.sh apache that will just generate the scripts. The new rules: - install the DLLs. - run confgen - start apache. Long term, the confgen.sh can do few other things, like insert the Include in httpd.conf, etc. IMHO it's a decent solution. The user must expect that in order to deploy/undeploy webapps ( or change configs ), they must run something to let the server know about it. Or we can detect that and run confgen from tomcat. There are many choices and ways to improve if we go this path. What do you think ? I'm fine with this as long as there is a simple way to have ApacheConfig, IISConfig, etc. always write the auto-generated files. If I'm running Tomcat out-of-process, I'd prefer to simply start Tomcat first and then Apache to pick up configuration changes. Costin
