Re: AJP Connector issue
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 André, On 3/19/20 10:57, André Warnier (tomcat/perl) wrote: > For example : - if all your pairs of httpd server/tomcat server are > running on the same host, then you do not really have a security > issue, and adding a secret will not really bring any additional > security - if all your pairs of httpd server/tomcat server are > communicating only over an internal (presumed to be fairly safe) > network, then you do have a limited security issue (limited by how > "safe" your internal network really is), and a secret may help a > bit in reducing this already limited security issue - if you have > pairs of httpd/tomcat which communicate over a public network, then > you do have a security issue, and adding a secret will help, but it > is not going to make that security issue really disappear (*). If you have naked AJP traversing a public network then you are very much doing it wrong and have zero privacy or security. Adding a secret will only expose the secret to anyone who cares to look. > (*) the secret, if correctly implemented, will block any other host > than your own hosts from connecting to the tomcat AJP Connector, > and thus from "abusing" your tomcats by sending them invalid or > malicious requests. AJP allows the client to present a secret to the server, but it does so insecurely. Any attacker who can see your AJP traffic can also see the secret. So adding a secret doesn't really add security in any meaningful way. Instead of adding a door lock, it instead adds a note saying "please don't open this door unless you are allowed to do so." - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5zxW8ACgkQHPApP6U8 pFgjyQ//ZrfYJS2LtqKBrZt0Zj3UlzuclNkZJ+48hcbKuaNo9oUHoUS9HtJG+vqv id2kwQZYfgWXtsJiEGLqPL6OytULqTMYW7TOj5WqxIqYtlIvwMis4eB8qvql3W08 cQex0qpGWIaxmw05hxN8hg8VABpG5blKmQfTJ6KyDY0G5xSHZXBMyXn0WMth6zNp xgNXksTEu/CMWOr8rgIH5x6+0/mjv5XM7VA4mBxUuk6HZhJ1+62GMR7Ame5pjbKF lyT85eU4Qhe1zZPyMoVbabLvNg2U44iC3rAqXGgQ5ZEr/Ky8EQMePQazgDpBKeG0 Kpsxb7HY3Z/O6+kY3S15tbt2b/A9DgbR41MJnw3KcUzR0/3wq/5lOHyBSV8N63ug qvQdycBrb2pxfZPBBGPI0XvG3IqzdKqtWpmQAq6SBmZ0JAHGp2go9l4eE9kDxcDU h7KeiNrE8LKO6Ijnth4FbmZOWNkMWwF22fAIeDrE1eQJL2SLE3h2+UHbK+qR8Bk3 Sby9FTSZ+2SoIXgSwc+jQyfpn7HtIqmYqPHhzSlIQJtz/ANHkiG59X+g3epgdnn/ GyBTFrOsirWaQGOJHh/nAE/z6YbhHhTl0hmxNKG1EBwyfDH7+zHRtl+E4Nk1Mkzu dBNGM2clPrGwDLXTEc44OGpsgaU4QZqhGY29g2qt1xN9r0O40A0= =GSne -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AJP Connector issue
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Florian, On 3/19/20 07:43, Fritze, Florian wrote: > since the Tomcat release with the Ghostcat security fix (Tomcat > 8.5.51) me as an admin have the problem using the > https://httpd.apache.org/docs/2.4/mod/mod_proxy_ajp.html module to > connect the Apache HTTPD with the Tomcat running on localhost. The > attribute secretRequired must be set to „true“ or „false“ with > „false“ set the connection is not possible between Tomcat and > Apache HTTPD. When you have set secretRequired="false", it's not possible to connect? When you try to connect, what DOES happen? > With „true“ the Apache development is not ready in the current > version to work with the „secret“ attribute. Only the next version > of Apache 2.4 supports this attribute. Correct. Support for secret= in mod_proxy_ajp was evidently never really a priority for anybody until now. > So I want to use the newest Tomcat version and an AJP connector > but after the Ghostcat fix release there is this attribute which > does not work in my configuration. > > Are there any suggestions or solutions available that you can > deliver me (links or documentation, etc.) secretRequired="false" should be all you need. Of course, to be truly secure, you need to make sure that not just anybody can make requests through your AJP interface. Have you secured that interface from potential evildoers? - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5zxHsACgkQHPApP6U8 pFjf7Q/+Ixbc10KYI07Wb1pdzQajVtw88BcfSZ3dfam2Q9aj2IhZJD5GUTzszAGC bs6eySKEh5vqaHq+oy2ZOuv2f1xxukPQ3/XfmIEUb83G7QScwlMf0r5dth9uslcq cUgHFkpGhSQghB2yhZSzKMzF7gjRY9QI0S5EpEHTQ45CUvREWr4GRyLndkjTbu2C rhdB+8ud4iErWJe1Er0NEqOgoVL8Ceed4BGRYzoT7+lN1dRE4MFIn8ALdVzAvo4L 9ZIm+zawSkx7jUTAGDi4wHd2KrewR9kqJybovZaACx/yc6IF1Sv+DaWlTUDdabE2 qrSl45mA4EdLCeH1wfbZ62IhErbxvLahygAwgYSeMfhv02vzBbmn8bXY4yg359ln aO2AV3xNbxFrF56XatRGIJ+3/ETh2oIv0PLnJEr8xc3CcwdJ+rn8c9i84ZZLnHb6 iTl+Gx9pCUbtH0qCILzLzj7Js9yl13o9AVu3UQ9UxY9BNxkFiKKBe4YfGUev2iiB Vx1Zw6S6/ByjhUpzaSEciSYCkr+pR61iOJpCN9B3tnpv4cRgkqwPWEPgMFDtvFT9 ciwpDuN+O2YPPE0Z39tSy64Ge2QWyPkvb8hVZUEZGVMRmQ1W5LhDJhNxECklxKOh sZPFkji5aVOxj6TT5vwqQDov+FyU2pV5/HRD4fe/vr8vdKj+vec= =CYi0 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AJP Connector issue
On 19.03.2020 12:43, Fritze, Florian wrote: Dear Tomcat users, since the Tomcat release with the Ghostcat security fix (Tomcat 8.5.51) me as an admin have the problem using the https://httpd.apache.org/docs/2.4/mod/mod_proxy_ajp.html module to connect the Apache HTTPD with the Tomcat running on localhost. The attribute secretRequired must be set to „true“ or „false“ with „false“ set the connection is not possible between Tomcat and Apache HTTPD. With „true“ the Apache development is not ready in the current version to work with the „secret“ attribute. Only the next version of Apache 2.4 supports this attribute. So I want to use the newest Tomcat version and an AJP connector but after the Ghostcat fix release there is this attribute which does not work in my configuration. Are there any suggestions or solutions available that you can deliver me (links or documentation, etc.) Hello. It all depends on your configuration, and how your front-end Apache httpd server(s) connect to your back-end tomcat server(s). For example : - if all your pairs of httpd server/tomcat server are running on the same host, then you do not really have a security issue, and adding a secret will not really bring any additional security - if all your pairs of httpd server/tomcat server are communicating only over an internal (presumed to be fairly safe) network, then you do have a limited security issue (limited by how "safe" your internal network really is), and a secret may help a bit in reducing this already limited security issue - if you have pairs of httpd/tomcat which communicate over a public network, then you do have a security issue, and adding a secret will help, but it is not going to make that security issue really disappear (*). But if you want to add a secret anyway, then it depends on how httpd communicates with its corresponding tomcat, and there are 2 options : - using the httpd mod_proxy_ajp module or - using the httpd mod_jk module As I understand from your message, the current mod_proxy_ajp module released with the current httpd 2.4, does not support that "secret" yet. But the currently available mod_jk module does support that option, and the current mod_jk module is compatible with any httpd 2.4 version. And, functionally, mod_proxy_ajp and mod_jk can do the same things. It is just the setup and configuration (at the httpd level) that is somewhat different between the two. (there is no difference at the tomcat level). So if you are currently using mod_proxy_ajp (**), then if you want to implement this "secret" option, you would have to change your httpd configuration, to use mod_jk instead of mod_proxy_ajp (temporarily, until the appropriate version of mod_proxy_ajp is released). (*) the secret, if correctly implemented, will block any other host than your own hosts from connecting to the tomcat AJP Connector, and thus from "abusing" your tomcats by sending them invalid or malicious requests. But it would not block someone from intercepting the traffic between your httpds and your tomcats and reading it, because the AJP protocol is not encrypted, and because there is no implementation available that makes this traffic be encrypted. (**) If you are currently using mod_proxy_ajp, then it is also likely that you are not using the option whereby httpd can do the user authentication, and then pass the authenticated user-id along to tomcat, for tomcat to use it. That means that you are already avoiding one possible security issue. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: ajp connector issue - getting Unable to get the free in mod_jk.log file.
Can anyone throw more light on this issue? We are being plagued by this problem and the only way we can resolve this is by HUP'ing the thread. - Shekar On 12/19/06, Shekar Tippur [EMAIL PROTECTED] wrote: Rainer, One another change we noticed was that response is cut off for a particular transaction on a thread. For every other thread, we see marshelling and un-marshelling messages in the mod_jk.log file. There is no issue of load [Fri Dec 08 01:16:25 2006] [18477:] [debug] ajp_connection_tcp_send_message::jk_ajp_common.c (909): 03f032 34 34 35 30 31 26 74 65 72 6D 49 64 3D 37 35 - 244501termId=75 .. This is where it looks like the response was cut off. The next occurance of this process id is a new request! ... [Fri Dec 08 01:23:03 2006] [18477:] [debug] map_uri_to_worker::jk_uri_worker_map.c (449): Attempting to map URI '/ui/ac/loadSummary.do' from 11 maps Thanks, Shekar On 12/19/06, Shekar Tippur [EMAIL PROTECTED] wrote: Rainer, We upgraded mod_jk to 1.2.19 and we are still getting the same error in mod_jk. [Tue Dec 19 11:35:36 2006] [31691:] [warn] ajp_get_endpoint::jk_ajp_common.c (2258): Unable to get the free endpoint for worker myWorker from 1 slots [Tue Dec 19 11:35:36 2006] [31691:] [info] ajp_get_endpoint::jk_ajp_common.c (2272): can't find free endpoint [Tue Dec 19 11:35:36 2006] myWorker gorgon 0.99 [Tue Dec 19 11:35:36 2006] [31691:] [info] jk_handler::mod_jk.c (1986): Service error=0 for worker=myWorker I would really apperciate if anyone could help me on this. Shekar On 12/17/06, Shekar Tippur [EMAIL PROTECTED] wrote: Hello, Thanks for replying back. I cannot see any specal requests but there maybe high load. I can see 193 active threads. We are in the process of upgrading mod_jk version to 1.2.19. Here is some of the information you wanted. Please let me know if you need more information. cat /proc/version Linux version 2.6.9-34.ELsmp ([EMAIL PROTECTED] ) (gcc version 3.4.5 20051201 (Red Hat 3.4.5-2 )) worker.properties worker.list=jkstatus,consWorker,myWorker # Configure Load Balancer status manager. worker.jkstatus.type=status worker.consWorker.port=8009 worker.consWorker.host=localhost worker.consWorker.type=ajp13 worker.consWorker.socket_timeout=120 # Define first worker for failover worker.myWorker.port=8010 worker.myWorker.host=localhost worker.myWorker.type=ajp13 worker.myWorker.socket_timeout=120 apache_mod_jk.conf file # conf/include/apache_mod_jk.conf # global settings files for the mod jk connector LoadModule jk_module libexec/apache_mod_jk.so # Where to find workers.properties JkWorkersFile /home/apache/conf/apache/mod_include/worker.properties # Where to put jk logs JkLogFile logs/apache/mod_jk.log # Set the jk log level [debug/error/info] JkLogLevel info # Select the log format JkLogStampFormat [%a %b %d %H:%M:%S %Y] # JkRequestLogFormat set the request format JkRequestLogFormat %w %V %T # JkOptions indicate to send SSL KEY SIZE, JkOptions +ForwardURICompat -ForwardDirectories # Configure Load Balancer status manager. #JkWorkerProperties worker.jkstatus.type=status # status for later load balancing Location /jkmanager/ JkMount /jkstatus/* Order deny,allow Deny from all Allow from 127.0.0.1 /Location JkMount /jkmanager/* jkstatus On 12/16/06, Rainer Jung [EMAIL PROTECTED] wrote: Hi, this looks strange. Could you please post your config and give a couple of details about your environment (OS+Version). Is there any pattern related to the problem (special requests, high load, ...)? It would be really good, if you could update mod_jk to 1.2.19 or 1.2.20 which will most likely be available middle of next week. Regards, Rainer Shekar Tippur schrieb: Hello We are getting unable to get the free endpoint and eventually resulting in a 500 (internal server error). We are using apache 1.3.37 and mod_jk version is 1.2.15. Due to many reasons, we are not in a position to upgrade wither of these packages. [Fri Dec 08 01:34:09 2006] [18477:] [warn] ajp_get_endpoint::jk_ajp_common.c (2138): Unable to get the free endpoint for worker myWorker from 1 slots [Fri Dec 08 01:34:09 2006] [18477:] [info] ajp_get_endpoint::jk_ajp_common.c (2152): can't find free endpoint [Fri Dec 08 01:34:09 2006] [18477:] myWorker 0.88 Under these situations, we also see that either jboss threads are processing for a long time OR a particular thread is idle for a relatively long time. I would really appreciate if someone can explain why this particular error occurs and how to remediate the problem. Currently we are restarting both jboss and apache but we are not able to get to
Re: ajp connector issue - getting Unable to get the free in mod_jk.log file.
Rainer, We upgraded mod_jk to 1.2.19 and we are still getting the same error in mod_jk. [Tue Dec 19 11:35:36 2006] [31691:] [warn] ajp_get_endpoint::jk_ajp_common.c (2258): Unable to get the free endpoint for worker myWorker from 1 slots [Tue Dec 19 11:35:36 2006] [31691:] [info] ajp_get_endpoint::jk_ajp_common.c (2272): can't find free endpoint [Tue Dec 19 11:35:36 2006] myWorker gorgon 0.99 [Tue Dec 19 11:35:36 2006] [31691:] [info] jk_handler::mod_jk.c (1986): Service error=0 for worker=myWorker I would really apperciate if anyone could help me on this. Shekar On 12/17/06, Shekar Tippur [EMAIL PROTECTED] wrote: Hello, Thanks for replying back. I cannot see any specal requests but there maybe high load. I can see 193 active threads. We are in the process of upgrading mod_jk version to 1.2.19. Here is some of the information you wanted. Please let me know if you need more information. cat /proc/version Linux version 2.6.9-34.ELsmp ([EMAIL PROTECTED]) (gcc version 3.4.5 20051201 (Red Hat 3.4.5-2 )) worker.properties worker.list=jkstatus,consWorker,myWorker # Configure Load Balancer status manager. worker.jkstatus.type=status worker.consWorker.port=8009 worker.consWorker.host=localhost worker.consWorker.type=ajp13 worker.consWorker.socket_timeout=120 # Define first worker for failover worker.myWorker.port=8010 worker.myWorker.host=localhost worker.myWorker.type=ajp13 worker.myWorker.socket_timeout=120 apache_mod_jk.conf file # conf/include/apache_mod_jk.conf # global settings files for the mod jk connector LoadModule jk_module libexec/apache_mod_jk.so # Where to find workers.properties JkWorkersFile /home/apache/conf/apache/mod_include/worker.properties # Where to put jk logs JkLogFile logs/apache/mod_jk.log # Set the jk log level [debug/error/info] JkLogLevel info # Select the log format JkLogStampFormat [%a %b %d %H:%M:%S %Y] # JkRequestLogFormat set the request format JkRequestLogFormat %w %V %T # JkOptions indicate to send SSL KEY SIZE, JkOptions +ForwardURICompat -ForwardDirectories # Configure Load Balancer status manager. #JkWorkerProperties worker.jkstatus.type=status # status for later load balancing Location /jkmanager/ JkMount /jkstatus/* Order deny,allow Deny from all Allow from 127.0.0.1 /Location JkMount /jkmanager/* jkstatus On 12/16/06, Rainer Jung [EMAIL PROTECTED] wrote: Hi, this looks strange. Could you please post your config and give a couple of details about your environment (OS+Version). Is there any pattern related to the problem (special requests, high load, ...)? It would be really good, if you could update mod_jk to 1.2.19 or 1.2.20 which will most likely be available middle of next week. Regards, Rainer Shekar Tippur schrieb: Hello We are getting unable to get the free endpoint and eventually resulting in a 500 (internal server error). We are using apache 1.3.37 and mod_jk version is 1.2.15. Due to many reasons, we are not in a position to upgrade wither of these packages. [Fri Dec 08 01:34:09 2006] [18477:] [warn] ajp_get_endpoint::jk_ajp_common.c (2138): Unable to get the free endpoint for worker myWorker from 1 slots [Fri Dec 08 01:34:09 2006] [18477:] [info] ajp_get_endpoint::jk_ajp_common.c (2152): can't find free endpoint [Fri Dec 08 01:34:09 2006] [18477:] myWorker 0.88 Under these situations, we also see that either jboss threads are processing for a long time OR a particular thread is idle for a relatively long time. I would really appreciate if someone can explain why this particular error occurs and how to remediate the problem. Currently we are restarting both jboss and apache but we are not able to get to the root cause of the problem. People who have got the same error earlier have suggested that we need to increase the cachesize OR the connection_pool_size of the worker. but mod_jk documentation says that it is not recommended to use cachesize more than 1 for apache version 1.3.x. I would really appreciate if anyone can suggest a remediation for this issue. Shekar - cachesize This directive has been deprecated since 1.2.16. Cachesize defines the number of connections made to the AJP backend that are maintained as a connection pool. It will limit the number of those connection that each web server child process can make. Cachesize property is used only for multi threaded web servers such as Apache 2.0 (worker), IIS and Netscape. The cachesize property should reflect the number of threads per child process. JK will discover the number of threads per child process on Apache 2 web server with worker-mpm and set its default value to match the ThreadsPerChild Apache directive. For IIS the default value is 10. For other web servers this value has to be set manually. Do not use cachesize with values higher then 1 on Apache 2.x
Re: ajp connector issue - getting Unable to get the free in mod_jk.log file.
Hello, Thanks for replying back. I cannot see any specal requests but there maybe high load. I can see 193 active threads. We are in the process of upgrading mod_jk version to 1.2.19. Here is some of the information you wanted. Please let me know if you need more information. cat /proc/version Linux version 2.6.9-34.ELsmp ([EMAIL PROTECTED]) (gcc version 3.4.5 20051201 (Red Hat 3.4.5-2)) worker.properties worker.list=jkstatus,consWorker,myWorker # Configure Load Balancer status manager. worker.jkstatus.type=status worker.consWorker.port=8009 worker.consWorker.host=localhost worker.consWorker.type=ajp13 worker.consWorker.socket_timeout=120 # Define first worker for failover worker.myWorker.port=8010 worker.myWorker.host=localhost worker.myWorker.type=ajp13 worker.myWorker.socket_timeout=120 apache_mod_jk.conf file # conf/include/apache_mod_jk.conf # global settings files for the mod jk connector LoadModule jk_module libexec/apache_mod_jk.so # Where to find workers.properties JkWorkersFile /home/apache/conf/apache/mod_include/worker.properties # Where to put jk logs JkLogFile logs/apache/mod_jk.log # Set the jk log level [debug/error/info] JkLogLevel info # Select the log format JkLogStampFormat [%a %b %d %H:%M:%S %Y] # JkRequestLogFormat set the request format JkRequestLogFormat %w %V %T # JkOptions indicate to send SSL KEY SIZE, JkOptions +ForwardURICompat -ForwardDirectories # Configure Load Balancer status manager. #JkWorkerProperties worker.jkstatus.type=status # status for later load balancing Location /jkmanager/ JkMount /jkstatus/* Order deny,allow Deny from all Allow from 127.0.0.1 /Location JkMount /jkmanager/* jkstatus On 12/16/06, Rainer Jung [EMAIL PROTECTED] wrote: Hi, this looks strange. Could you please post your config and give a couple of details about your environment (OS+Version). Is there any pattern related to the problem (special requests, high load, ...)? It would be really good, if you could update mod_jk to 1.2.19 or 1.2.20 which will most likely be available middle of next week. Regards, Rainer Shekar Tippur schrieb: Hello We are getting unable to get the free endpoint and eventually resulting in a 500 (internal server error). We are using apache 1.3.37 and mod_jk version is 1.2.15. Due to many reasons, we are not in a position to upgrade wither of these packages. [Fri Dec 08 01:34:09 2006] [18477:] [warn] ajp_get_endpoint::jk_ajp_common.c (2138): Unable to get the free endpoint for worker myWorker from 1 slots [Fri Dec 08 01:34:09 2006] [18477:] [info] ajp_get_endpoint::jk_ajp_common.c (2152): can't find free endpoint [Fri Dec 08 01:34:09 2006] [18477:] myWorker 0.88 Under these situations, we also see that either jboss threads are processing for a long time OR a particular thread is idle for a relatively long time. I would really appreciate if someone can explain why this particular error occurs and how to remediate the problem. Currently we are restarting both jboss and apache but we are not able to get to the root cause of the problem. People who have got the same error earlier have suggested that we need to increase the cachesize OR the connection_pool_size of the worker. but mod_jk documentation says that it is not recommended to use cachesize more than 1 for apache version 1.3.x. I would really appreciate if anyone can suggest a remediation for this issue. Shekar - cachesize This directive has been deprecated since 1.2.16. Cachesize defines the number of connections made to the AJP backend that are maintained as a connection pool. It will limit the number of those connection that each web server child process can make. Cachesize property is used only for multi threaded web servers such as Apache 2.0 (worker), IIS and Netscape. The cachesize property should reflect the number of threads per child process. JK will discover the number of threads per child process on Apache 2 web server with worker-mpm and set its default value to match the ThreadsPerChild Apache directive. For IIS the default value is 10. For other web servers this value has to be set manually. Do not use cachesize with values higher then 1 on Apache 2.x prefork or Apache 1.3.x! --- Shekar - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ajp connector issue - getting Unable to get the free in mod_jk.log file.
Hi, this looks strange. Could you please post your config and give a couple of details about your environment (OS+Version). Is there any pattern related to the problem (special requests, high load, ...)? It would be really good, if you could update mod_jk to 1.2.19 or 1.2.20 which will most likely be available middle of next week. Regards, Rainer Shekar Tippur schrieb: Hello We are getting unable to get the free endpoint and eventually resulting in a 500 (internal server error). We are using apache 1.3.37 and mod_jk version is 1.2.15. Due to many reasons, we are not in a position to upgrade wither of these packages. [Fri Dec 08 01:34:09 2006] [18477:] [warn] ajp_get_endpoint::jk_ajp_common.c (2138): Unable to get the free endpoint for worker myWorker from 1 slots [Fri Dec 08 01:34:09 2006] [18477:] [info] ajp_get_endpoint::jk_ajp_common.c (2152): can't find free endpoint [Fri Dec 08 01:34:09 2006] [18477:] myWorker 0.88 Under these situations, we also see that either jboss threads are processing for a long time OR a particular thread is idle for a relatively long time. I would really appreciate if someone can explain why this particular error occurs and how to remediate the problem. Currently we are restarting both jboss and apache but we are not able to get to the root cause of the problem. People who have got the same error earlier have suggested that we need to increase the cachesize OR the connection_pool_size of the worker. but mod_jk documentation says that it is not recommended to use cachesize more than 1 for apache version 1.3.x. I would really appreciate if anyone can suggest a remediation for this issue. Shekar - cachesize This directive has been deprecated since 1.2.16. Cachesize defines the number of connections made to the AJP backend that are maintained as a connection pool. It will limit the number of those connection that each web server child process can make. Cachesize property is used only for multi threaded web servers such as Apache 2.0 (worker), IIS and Netscape. The cachesize property should reflect the number of threads per child process. JK will discover the number of threads per child process on Apache 2 web server with worker-mpm and set its default value to match the ThreadsPerChild Apache directive. For IIS the default value is 10. For other web servers this value has to be set manually. Do not use cachesize with values higher then 1 on Apache 2.x prefork or Apache 1.3.x! --- Shekar - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
