Ajp12 vs Ajp13
I'm confused. When editing the server.xml file to use Ajp13 support should I delete the AJP12 support or leave it in? Is there a way to find out which Ajp is running on my server? I.E should my server.xml be: Connector className=org.apache.tomcat.service.PoolTcpConnector Parameter name=handler value=org.apache.tomcat.service.connector.Ajp12ConnectionHandler/ Parameter name=port value=8007/ Parameter name=max_threads value=200/ Parameter name=max_spare_threads value=20/ Parameter name=min_spare_threads value=20 / /Connector !-- Apache AJP13 support.-- Connector className=org.apache.tomcat.service.PoolTcpConnector Parameter name=handler value=org.apache.tomcat.service.connector.Ajp13ConnectionHandler/ Parameter name=port value=8009/ Parameter name=max_threads value=200/ Parameter name=max_spare_threads value=20/ Parameter name=min_spare_threads value=20 / /Connector Ta Andy C
Re: Ajp12 vs Ajp13
At 04:37 PM 5/30/2001 +0100, you wrote: I'm confused. When editing the server.xml file to use Ajp13 support should I delete the AJP12 support or leave it in? You have to leave ajp12 in because tomcat uses it in its wind down procedure, at least in 3.x versions. You can run everything else on 13 though. I do.
Re: Ajp12 vs Ajp13
Tim O'Neil wrote: At 04:37 PM 5/30/2001 +0100, you wrote: I'm confused. When editing the server.xml file to use Ajp13 support should I delete the AJP12 support or leave it in? You have to leave ajp12 in because tomcat uses it in its wind down procedure, at least in 3.x versions. You can run everything else on 13 though. I do. I'm considering a patch to allow ajp13 to handle the wind-down as well. Security-wise, it's much better for ajp13 to be able to do it, but StopTomcat.java has ajp12 hardwired -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ Hell is hot, that's never been disputed by anybody.
Re: Ajp12 vs Ajp13
At 02:19 PM 5/30/2001 -0400, Jim Jagielski wrote: I'm considering a patch to allow ajp13 to handle the wind-down as well. Security-wise, it's much better for ajp13 to be able to do it, but StopTomcat.java has ajp12 hardwired So Jim- in 4.0 and beyond setting p13 to that task wasn't in the must-do category? Curious as to why...
Re: Ajp12 vs Ajp13
Scratching an itch... I've heard a number of resistant movements in wider TC acceptance due to the fact that the shutdown procedure is as open as it is, even using the 'inet' hack to ensure a local command. Tim O'Neil wrote: At 02:19 PM 5/30/2001 -0400, Jim Jagielski wrote: I'm considering a patch to allow ajp13 to handle the wind-down as well. Security-wise, it's much better for ajp13 to be able to do it, but StopTomcat.java has ajp12 hardwired So Jim- in 4.0 and beyond setting p13 to that task wasn't in the must-do category? Curious as to why... -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ Hell is hot, that's never been disputed by anybody.
Performance of AJP12 vs. AJP13
I've been developing/testing/staging with Apache 1.3.14 / mod_jk / Tomcat 3.2.1 for the last several months (started with Tomcat 3.1 and upgraded to 3.2.1 soon after its release). I had not seen any performance problems (of course!) until I hit production and saw my CPU utilization go through the roof and my app's response time slow to a crawl. After cruising through the mailing list archives, I tried using mod_jk as a handler (instead of a filter) and tried upgrading to JDK1.3 from JDK1.2. Neither of these gave much of a performance increase. The one thing that gave me a dramatic increase in speed was to change my JkMount directives to use AJP12 workers instead of AJP13. Using the Apache benchmark tool (ab), I saw an increase of 5-fold or more for the number of requests per second I could handle. Does this surprise anyone out there? I saw advice for speeding mod_jk, but did not come across using AJP12 instead of AJP13. In addition to a increased rate of requests per second, my application server hardware also seems to be spending less cycles on individual httpd processes as well as the Java process which owns the running Tomcat. Particulars: + Solaris 2.6 + Apache 1.3.14 + Tomcat 3.2.1 binary drop + mod_jk compiled as shared object from Tomcat 3.2.1 source -mahaffey
Re: Performance of AJP12 vs. AJP13
Yeah, it surprises me a little. All the docs say ajp13 is faster due to it's connection re-use. I tested mod_jserv (ajp12) against mod_jk (ajp13) in my own tests and found mod_jk to be about 40% faster. It also scaled more smoothly and handled the load less erratically. I was doing simple inserts into a MySQL database from my servlet. However, I didn't test mod_jk (ajp12) vs. mod_jk (ajp13). I might have to go back and try that... --jeff - Original Message - From: "Tom Mahaffey" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, April 10, 2001 5:48 AM Subject: Performance of AJP12 vs. AJP13 I've been developing/testing/staging with Apache 1.3.14 / mod_jk / Tomcat 3.2.1 for the last several months (started with Tomcat 3.1 and upgraded to 3.2.1 soon after its release). I had not seen any performance problems (of course!) until I hit production and saw my CPU utilization go through the roof and my app's response time slow to a crawl. After cruising through the mailing list archives, I tried using mod_jk as a handler (instead of a filter) and tried upgrading to JDK1.3 from JDK1.2. Neither of these gave much of a performance increase. The one thing that gave me a dramatic increase in speed was to change my JkMount directives to use AJP12 workers instead of AJP13. Using the Apache benchmark tool (ab), I saw an increase of 5-fold or more for the number of requests per second I could handle. Does this surprise anyone out there? I saw advice for speeding mod_jk, but did not come across using AJP12 instead of AJP13. In addition to a increased rate of requests per second, my application server hardware also seems to be spending less cycles on individual httpd processes as well as the Java process which owns the running Tomcat. Particulars: + Solaris 2.6 + Apache 1.3.14 + Tomcat 3.2.1 binary drop + mod_jk compiled as shared object from Tomcat 3.2.1 source -mahaffey
Re: Performance of AJP12 vs. AJP13
At 03:35 PM 4/10/2001 -0700, you wrote: Yeah, it surprises me a little. All the docs say ajp13 is faster due to it's connection re-use. I can tell the connections are being re-used (by monitoring with netstat). But it hasn't turned out to be a time saver for me. I tested mod_jserv (ajp12) against mod_jk (ajp13) in my own tests and found mod_jk to be about 40% faster. It also scaled more smoothly and handled the load less erratically. I was doing simple inserts into a MySQL database from my servlet. However, I didn't test mod_jk (ajp12) vs. mod_jk (ajp13). I might have to go back and try that... That would be great if you have a chance. I was just hitting a "hello world" servlet in my tests. Although I found mod_jk/ajp12 to be faster than mod_jk/ajp13, nothing beat the speed of hitting the HttpConnectionHandler running on port 8080 or whatever. -mahaffey --jeff - Original Message - From: "Tom Mahaffey" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, April 10, 2001 5:48 AM Subject: Performance of AJP12 vs. AJP13 I've been developing/testing/staging with Apache 1.3.14 / mod_jk / Tomcat 3.2.1 for the last several months (started with Tomcat 3.1 and upgraded to 3.2.1 soon after its release). I had not seen any performance problems (of course!) until I hit production and saw my CPU utilization go through the roof and my app's response time slow to a crawl. After cruising through the mailing list archives, I tried using mod_jk as a handler (instead of a filter) and tried upgrading to JDK1.3 from JDK1.2. Neither of these gave much of a performance increase. The one thing that gave me a dramatic increase in speed was to change my JkMount directives to use AJP12 workers instead of AJP13. Using the Apache benchmark tool (ab), I saw an increase of 5-fold or more for the number of requests per second I could handle. Does this surprise anyone out there? I saw advice for speeding mod_jk, but did not come across using AJP12 instead of AJP13. In addition to a increased rate of requests per second, my application server hardware also seems to be spending less cycles on individual httpd processes as well as the Java process which owns the running Tomcat. Particulars: + Solaris 2.6 + Apache 1.3.14 + Tomcat 3.2.1 binary drop + mod_jk compiled as shared object from Tomcat 3.2.1 source -mahaffey
ajp12 vs ajp13 for Tomcat 3.2.1
Could someone please clarify the following for me? Besides SSL via JSSE, what else do I lose if I use ajp12 instead of ajp13? (ajp13 is supposed to be faster, right?). The reason that I would like to stay with ajp12 is ajp13 can not handle POST with object. Thanks, Peter
Re: Aliases/Rewrites (was: ajp12 vs ajp13 mod_jk.conf-auto
--- Jan Labanowski [EMAIL PROTECTED] wrote: It is my (and others) experience that mod_jk has to be loaded BEFORE mod_rewrite for it to act responsibly. In your case the mod_rewrite is linked statically, i.e., loaded before mod_jk. I would suggest to make both mod_jk and mod_rewrite DSO, and load/add module mod_jk before mod_rewrite. Remember to comment out the # LoadModule jk_module libexec/mod_jk.so in mod_jk.conf Ya know, I'm almost 100% positive I tried this before to no affect, but being in a mad dash to fix things, I may spoiled that test by simultaneously changing something else. At any rate, with mod_jk loaded before mod_rewrite (in my case, I am able to simply perform the include of mod_jk.conf-auto before I do any rewrites) it seems to work. I also had a stupid syntax error in my rewrite expression so maybe that was it. Amazin' how much time one can spend fixin' somethin' that ain't broke... Mel __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Aliases/Rewrites (was: ajp12 vs ajp13 mod_jk.conf-auto
Filip,
--- Filip Hanik [EMAIL PROTECTED] wrote:
Now, if I could just get someone to tell me why
apache
Alias and Rewrites are not working with tomcat...
tell us what you are trying to do and send us some
sample config files and
how your environment is setup. is becomes much
easier than to answer the
question above, because alias works very well for me
:)
Well, actually, I've twice posted detailed
descriptions of what I'm trying to accomplish on this
topic and gotten zero replies, but here goes another
attempt...
I'm using Apache 1.3.14 and tomcat 3.2.1 with
mod_jk.c. I don't know if the latter is the 'latest'
version of mod_jk.c - I grabbed it from the tomcat
download site two weeks ago. I am running this on
WinNT using downloaded binary versions of the relevant
software.
I have setup my application ("myapp") as a directory
inside the webapps/ directory, complete with WEB-INF
subdirectory and such.
I have apache configured to apply an alias or a
rewrite rule to a reqest:
#--
IfModule !mod_rewrite.c
LoadModule rewrite_module
n:/opt/local/apache/modules/ApacheModuleRewrite.dll
/IfModule
RewriteEngine On
RewriteLog log/apache_logs/rewrites.log
RewriteLogLevel 9
RewriteOptions inherit
RewriteRule ^/myapp/(.*)/common/(.*) /myapp/common/$2
#-
I can tell from the rewrites.log that it is indeed
getting applied:
(2) init rewrite engine with requested uri
/myapp/folder1/common/mypage.jsp
(3) applying pattern '^/myapp/(.*)/common/(.*)' to
uri '/myapp/folder1/common/mypage.jsp'
(2) rewrite /myapp/folder1/common/mypage.jsp -
/myapp/common/mypage.jsp
(2) local path result: /myapp/common/mypage.jsp
(1) go-ahead with /myapp/common/mypage.jsp [OK]
The idea here is simple: the request
/myapp/folder1/common/mypage.jsp
should result in a request for
/myapp/common/mypage.jsp
The rewrite rule works great. This works great for
static stuff (i.e. html) served up by Apache.
The *problem* is that Tomcat is not getting the
translated request, it is getting the original one:
/myapp/folder1/common/mypage.jsp
Since no file in that path actually exists, naturally
it returns a file not found error. Tomcat DOES
happily find, compile and execute requests for
servlets and jsp pages that are in paths that do exist
such as
/myapp/folder1/myother.jsp
I have apache configured to send requests to tomcat
via ajp13 by including mod_jk.conf-auto just after the
above rewrite rule:
# include configuration for tomcat servlet engine:
#
Include n:/opt/demo/conf/mod_jk.conf-auto
#
I've configured server.xml very minimally, no custom
contexts or anything. About the only thing changed
here is I've enabled ajp13 and then setup
workers.properties to map requests to it. I doubt any
of this is relevant because I see the exact same
behavior even with 'raw' server.xml and
worker.properties files.
Note that I get the same behavior if I use an Alias
instead of a rewrite:
#--
Alias (.*)/myapp/(.*)/common/(.*) $1/myapp/common/$3
#--
This rewrites static requests served by Apache, but
just like with rewrites, gets ignored by tomcat.
That's pretty much it.
Any suggestions as to what is (or is not) going on?
Basically, what I want to happen is that, after a
rewrite rule has been applied, that Tomcat should be
processing the modified URL, not the original.
Thanks in advance for any help!
Mel
__
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35
a year! http://personal.mail.yahoo.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: Aliases/Rewrites (was: ajp12 vs ajp13 mod_jk.conf-auto
It is my (and others) experience that mod_jk has to be loaded BEFORE
mod_rewrite for it to act responsibly. In your case the mod_rewrite is
linked statically, i.e., loaded before mod_jk. I would suggest to
make both mod_jk and mod_rewrite DSO, and load/add module mod_jk before
mod_rewrite. Remember to comment out the
# LoadModule jk_module libexec/mod_jk.so
in mod_jk.conf
Jan
On Thu, 15 Feb 2001, Mel Martinez wrote:
Filip,
--- Filip Hanik [EMAIL PROTECTED] wrote:
Now, if I could just get someone to tell me why
apache
Alias and Rewrites are not working with tomcat...
tell us what you are trying to do and send us some
sample config files and
how your environment is setup. is becomes much
easier than to answer the
question above, because alias works very well for me
:)
Well, actually, I've twice posted detailed
descriptions of what I'm trying to accomplish on this
topic and gotten zero replies, but here goes another
attempt...
I'm using Apache 1.3.14 and tomcat 3.2.1 with
mod_jk.c. I don't know if the latter is the 'latest'
version of mod_jk.c - I grabbed it from the tomcat
download site two weeks ago. I am running this on
WinNT using downloaded binary versions of the relevant
software.
I have setup my application ("myapp") as a directory
inside the webapps/ directory, complete with WEB-INF
subdirectory and such.
I have apache configured to apply an alias or a
rewrite rule to a reqest:
#--
IfModule !mod_rewrite.c
LoadModule rewrite_module
n:/opt/local/apache/modules/ApacheModuleRewrite.dll
/IfModule
RewriteEngine On
RewriteLog log/apache_logs/rewrites.log
RewriteLogLevel 9
RewriteOptions inherit
RewriteRule ^/myapp/(.*)/common/(.*) /myapp/common/$2
#-
I can tell from the rewrites.log that it is indeed
getting applied:
(2) init rewrite engine with requested uri
/myapp/folder1/common/mypage.jsp
(3) applying pattern '^/myapp/(.*)/common/(.*)' to
uri '/myapp/folder1/common/mypage.jsp'
(2) rewrite /myapp/folder1/common/mypage.jsp -
/myapp/common/mypage.jsp
(2) local path result: /myapp/common/mypage.jsp
(1) go-ahead with /myapp/common/mypage.jsp [OK]
The idea here is simple: the request
/myapp/folder1/common/mypage.jsp
should result in a request for
/myapp/common/mypage.jsp
The rewrite rule works great. This works great for
static stuff (i.e. html) served up by Apache.
The *problem* is that Tomcat is not getting the
translated request, it is getting the original one:
/myapp/folder1/common/mypage.jsp
Since no file in that path actually exists, naturally
it returns a file not found error. Tomcat DOES
happily find, compile and execute requests for
servlets and jsp pages that are in paths that do exist
such as
/myapp/folder1/myother.jsp
I have apache configured to send requests to tomcat
via ajp13 by including mod_jk.conf-auto just after the
above rewrite rule:
# include configuration for tomcat servlet engine:
#
Include n:/opt/demo/conf/mod_jk.conf-auto
#
I've configured server.xml very minimally, no custom
contexts or anything. About the only thing changed
here is I've enabled ajp13 and then setup
workers.properties to map requests to it. I doubt any
of this is relevant because I see the exact same
behavior even with 'raw' server.xml and
worker.properties files.
Note that I get the same behavior if I use an Alias
instead of a rewrite:
#--
Alias (.*)/myapp/(.*)/common/(.*) $1/myapp/common/$3
#--
This rewrites static requests served by Apache, but
just like with rewrites, gets ignored by tomcat.
That's pretty much it.
Any suggestions as to what is (or is not) going on?
Basically, what I want to happen is that, after a
rewrite rule has been applied, that Tomcat should be
processing the modified URL, not the original.
Thanks in advance for any help!
Mel
__
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35
a year! http://personal.mail.yahoo.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Jan K. Labanowski|phone: 614-292-9279, FAX: 614-292-7168
Ohio Supercomputer Center|Internet: [EMAIL PROTECTED]
1224 Kinnear Rd, |http://www.ccl.net/chemistry.html
Columbus, OH 43212-1163 |http://www.osc.edu/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
RE: ajp12 vs ajp13 mod_jk.conf-auto
-Message d'origine- De: Mel Martinez [mailto:[EMAIL PROTECTED]] Date: mardi 13 fvrier 2001 23:33 : [EMAIL PROTECTED] Objet: ajp12 vs ajp13 mod_jk.conf-auto Question: what determines whether ajp12 or ajp13 will be specified for a jkmount statement in the auto-generated mod_jk.conf-auto file? I.E., it always generates statements like: JkMount /myapp/servlet/* ajp12 JkMount /myapp/*.jsp ajp12 I've even tried disabling all reference to ajp12 from server.xml and workers.properties but that had no effect. Is the only way to force the use of Ajp13 to manually edit the mod_jk.conf file? as told here you can tweak things, but the most clean is to use a separate my-mod_jk.conf include file that you derivate from the generated mod_jk.conf-auto if you really want all to be automatic add a conversion script (sed or perl script) to generate the my-mod_jk.conf from the .conf-auto with cocoon and HTTPS I had to tweak thos .conf-auto much more and nothing is better than manual config when things are stable... changing the ajp12 alias to point to ajp13 is really anti-documentation... on unix try something like #!/bin/sh launch_tomcat sleep 5 # wait for tomcat to generate the .conf-auto sed -e 's/ajp12/ajp13/g' conf/mod_jk.conf-auto conf/my-mod_jk.conf launch_apache don't forget to adapt apache conf/httpd.conf to include the my-mod_jk.conf instead of the conf-auto - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
ajp12 vs ajp13 mod_jk.conf-auto
Question: what determines whether ajp12 or ajp13 will be specified for a jkmount statement in the auto-generated mod_jk.conf-auto file? I.E., it always generates statements like: JkMount /myapp/servlet/* ajp12 JkMount /myapp/*.jsp ajp12 I've even tried disabling all reference to ajp12 from server.xml and workers.properties but that had no effect. Is the only way to force the use of Ajp13 to manually edit the mod_jk.conf file? Should I even be worrying about this? Thanks, mel __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: ajp12 vs ajp13 mod_jk.conf-auto
yes, the JkMount command looks like this JkMount context workername so the autogenerated ajp12 is just the worker name "ajp12" in the workers.properties file you can change the protocol that the worker is using. the property file has the following format worker.workername.propertyname=value worker.ajp12.port=8007 worker.ajp12.host=localhost worker.ajp12.type=ajp13 so just change the last line to use ajp13. now you have to modify server.xml to start a ajp13 connector on the port 8007 and change the port for ajp12. the nice thing with the autogenerated file is that your webapps can be dynamic. but if you need to do a lot of fancy stuff, you should create your own file for the mod_jk configuration. try playing around with it, and if you have a specific problem let me know and I can help you out. Filip ~ Namaste - I bow to the divine in you ~ Filip Hanik Software Architect [EMAIL PROTECTED] www.filip.net - Original Message - From: "Mel Martinez" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, February 13, 2001 2:32 PM Subject: ajp12 vs ajp13 mod_jk.conf-auto Question: what determines whether ajp12 or ajp13 will be specified for a jkmount statement in the auto-generated mod_jk.conf-auto file? I.E., it always generates statements like: JkMount /myapp/servlet/* ajp12 JkMount /myapp/*.jsp ajp12 I've even tried disabling all reference to ajp12 from server.xml and workers.properties but that had no effect. Is the only way to force the use of Ajp13 to manually edit the mod_jk.conf file? Should I even be worrying about this? Thanks, mel __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: ajp12 vs ajp13 mod_jk.conf-auto
Thanks, Filip. I'll try the changes you suggested. Now, if I could just get someone to tell me why apache Alias and Rewrites are not working with tomcat... Mel --- Filip Hanik [EMAIL PROTECTED] wrote: yes, the JkMount command looks like this JkMount context workername so the autogenerated ajp12 is just the worker name "ajp12" in the workers.properties file you can change the protocol that the worker is using. the property file has the following format worker.workername.propertyname=value worker.ajp12.port=8007 worker.ajp12.host=localhost worker.ajp12.type=ajp13 so just change the last line to use ajp13. now you have to modify server.xml to start a ajp13 connector on the port 8007 and change the port for ajp12. the nice thing with the autogenerated file is that your webapps can be dynamic. but if you need to do a lot of fancy stuff, you should create your own file for the mod_jk configuration. try playing around with it, and if you have a specific problem let me know and I can help you out. Filip ~ Namaste - I bow to the divine in you ~ Filip Hanik Software Architect [EMAIL PROTECTED] www.filip.net - Original Message - From: "Mel Martinez" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, February 13, 2001 2:32 PM Subject: ajp12 vs ajp13 mod_jk.conf-auto Question: what determines whether ajp12 or ajp13 will be specified for a jkmount statement in the auto-generated mod_jk.conf-auto file? I.E., it always generates statements like: JkMount /myapp/servlet/* ajp12 JkMount /myapp/*.jsp ajp12 I've even tried disabling all reference to ajp12 from server.xml and workers.properties but that had no effect. Is the only way to force the use of Ajp13 to manually edit the mod_jk.conf file? Should I even be worrying about this? Thanks, mel __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: ajp12 vs ajp13 mod_jk.conf-auto
Now, if I could just get someone to tell me why apache Alias and Rewrites are not working with tomcat... tell us what you are trying to do and send us some sample config files and how your environment is setup. is becomes much easier than to answer the question above, because alias works very well for me :) Filip ~ Namaste - I bow to the divine in you ~ Filip Hanik Software Architect [EMAIL PROTECTED] www.filip.net - Original Message - From: "Mel Martinez" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, February 13, 2001 3:11 PM Subject: Re: ajp12 vs ajp13 mod_jk.conf-auto Thanks, Filip. I'll try the changes you suggested. Now, if I could just get someone to tell me why apache Alias and Rewrites are not working with tomcat... Mel --- Filip Hanik [EMAIL PROTECTED] wrote: yes, the JkMount command looks like this JkMount context workername so the autogenerated ajp12 is just the worker name "ajp12" in the workers.properties file you can change the protocol that the worker is using. the property file has the following format worker.workername.propertyname=value worker.ajp12.port=8007 worker.ajp12.host=localhost worker.ajp12.type=ajp13 so just change the last line to use ajp13. now you have to modify server.xml to start a ajp13 connector on the port 8007 and change the port for ajp12. the nice thing with the autogenerated file is that your webapps can be dynamic. but if you need to do a lot of fancy stuff, you should create your own file for the mod_jk configuration. try playing around with it, and if you have a specific problem let me know and I can help you out. Filip ~ Namaste - I bow to the divine in you ~ Filip Hanik Software Architect [EMAIL PROTECTED] www.filip.net - Original Message - From: "Mel Martinez" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, February 13, 2001 2:32 PM Subject: ajp12 vs ajp13 mod_jk.conf-auto Question: what determines whether ajp12 or ajp13 will be specified for a jkmount statement in the auto-generated mod_jk.conf-auto file? I.E., it always generates statements like: JkMount /myapp/servlet/* ajp12 JkMount /myapp/*.jsp ajp12 I've even tried disabling all reference to ajp12 from server.xml and workers.properties but that had no effect. Is the only way to force the use of Ajp13 to manually edit the mod_jk.conf file? Should I even be worrying about this? Thanks, mel __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
