Re: Native configuration changes.
[EMAIL PROTECTED] 08/15/01 11:19AM >>> >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. I agree, and it's a great way to get the configuration to include in a webserver configuration file. >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 :-) Again, you are right on target. >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. Most definately. As convienent as the automatic-over-the-wire is, for true perfomance, a specific configuration for the server is the way to go. Plus, you can tweak it to behave exactly as you want, (i.e. certain URI's/servlets/contexts are only available to certain virtual hosts) to make sure that you aren't opening up you site to other problems. >My proposal ( quite simple to code ): > >- add a "-serverconf XXX" to tomcat.sh. ( trivial ). It'll set XXX as a >ContextManager note/attribute. > >- uncomment , , 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. I LOVE this. One concern that some internal users have raised is that when they generate the auto-config file, and edit it for their desired configuration, they have to go back and re-edit server.xml to not regenerate it so that they don't lose it. If we could have Tomcat only generate the file when asked, it would be extremely valuable. >Long term, the confgen.sh can do few other things, like insert the >"Include" in httpd.conf, etc. >IMHO it's a decent solution. I think it's a GREAT 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 ? Again, I think this is a great idea! >Costin Mike
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 , , 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 > >
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 , , 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 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: > - 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.
>>> [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: > - 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
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: - 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
