Re: mod_jk logging issue
> Hi Rainer/Simon - I've just had another look at this. With no > application running (IOW, all Java processes killed), I see this > behaviour: Sorry, I was confused because I thought we're talking about files from Tomcat and not from Apache/mod_jk. Regards, Simon > > # systemctl start apache2 > > This create a number of apache2 processes (generally 7). 2 new mod_jk > files are created, corresponding to the apache2 process with the lowest > PID > > # systemctl stop apache2 > > This does not remove any files (but see below) > > # systemctl restart apache2 > > This has the same effect as a 'start' followed by a 'stop'. A 'reload', > as expected, doesn't change the PIDs and has no effect on file creation > or deletion. > > During testing, I did see one occasion on which the current mod_jk files > were deleted. I though this might be a timeout issue, since the restart > was carried out after 7 minutes, which was longer that normal. So, I > carried out 5 more tests, with the restart after 1, 2, 4, 8, and 11 > minutes, and in all these cases the old files were retained and not > deleted. > > Maybe there's a race condition, or something distribution-specific, in > the code which registers the cleanup? I can't do much for a couple of > days, at least, but I'll have a look when I get a minute. > > > On 19/12/2023 19:03, Rainer Jung wrote: >> Hi there, >> >> Am 19.12.23 um 18:05 schrieb EML: >>> Hi - I'm running mod_jk with an Apache front-end, and I'm having an >>> issue with the JkShmFile files. >>> >>> Every time Apache restarts mod_jk creates two new files >>> (jk-runtime-status.PID and jk-runtime-status.PID.lock). These are >>> never cleaned up; the log directory simply fills up with these files. >>> This happens whether or not I explicitly set JkShmFile in the Apache >>> conf. >> >> That should no happen. There is a cleanup routine registered, which >> should delete the files during shutdown. And that's the behavior that >> I normally observe. >> >>> Is there some way I can persuade mod_jk to use a single file pair, >>> without the PID suffix, or to delete the previous file pair on a >>> restart? I'm not doing any load sharing. >> >> If you must remove the PID, you can patch the code and build it >> yourself. The ID is added in file common/jk_shm.c in the following line: >> >> sprintf(jk_shmem.filename, "%s.%" JK_PID_T_FMT, fname, >> getpid()); >> >> You could replace it by: >> >> sprintf(jk_shmem.filename, "%s", fname); >> >> If you compile the code yourself, please us the latest version 1.2.49. >> >> As I mentioned, a normal shutdown should already remove the files. A >> reload should not change the pid and thereby the files. A restart in >> the sense of stop-then-start should also remove the old files. >> >>> I'm on Ubuntu 22.04, Apache 2.4.52. The mod_jk version is possibly >>> 1.2.48-1. >>> >>> Thanks. >> >> Regards, >> >> Rainer >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: mod_jk logging issue
Hi Rainer/Simon - I've just had another look at this. With no application running (IOW, all Java processes killed), I see this behaviour: # systemctl start apache2 This create a number of apache2 processes (generally 7). 2 new mod_jk files are created, corresponding to the apache2 process with the lowest PID # systemctl stop apache2 This does not remove any files (but see below) # systemctl restart apache2 This has the same effect as a 'start' followed by a 'stop'. A 'reload', as expected, doesn't change the PIDs and has no effect on file creation or deletion. During testing, I did see one occasion on which the current mod_jk files were deleted. I though this might be a timeout issue, since the restart was carried out after 7 minutes, which was longer that normal. So, I carried out 5 more tests, with the restart after 1, 2, 4, 8, and 11 minutes, and in all these cases the old files were retained and not deleted. Maybe there's a race condition, or something distribution-specific, in the code which registers the cleanup? I can't do much for a couple of days, at least, but I'll have a look when I get a minute. On 19/12/2023 19:03, Rainer Jung wrote: Hi there, Am 19.12.23 um 18:05 schrieb EML: Hi - I'm running mod_jk with an Apache front-end, and I'm having an issue with the JkShmFile files. Every time Apache restarts mod_jk creates two new files (jk-runtime-status.PID and jk-runtime-status.PID.lock). These are never cleaned up; the log directory simply fills up with these files. This happens whether or not I explicitly set JkShmFile in the Apache conf. That should no happen. There is a cleanup routine registered, which should delete the files during shutdown. And that's the behavior that I normally observe. Is there some way I can persuade mod_jk to use a single file pair, without the PID suffix, or to delete the previous file pair on a restart? I'm not doing any load sharing. If you must remove the PID, you can patch the code and build it yourself. The ID is added in file common/jk_shm.c in the following line: sprintf(jk_shmem.filename, "%s.%" JK_PID_T_FMT, fname, getpid()); You could replace it by: sprintf(jk_shmem.filename, "%s", fname); If you compile the code yourself, please us the latest version 1.2.49. As I mentioned, a normal shutdown should already remove the files. A reload should not change the pid and thereby the files. A restart in the sense of stop-then-start should also remove the old files. I'm on Ubuntu 22.04, Apache 2.4.52. The mod_jk version is possibly 1.2.48-1. Thanks. Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: mod_jk logging issue
Hi, > Hi - I'm running mod_jk with an Apache front-end, and I'm having an > issue with the JkShmFile files. > > Every time Apache restarts mod_jk creates two new files > (jk-runtime-status.PID and jk-runtime-status.PID.lock). These are never > cleaned up; the log directory simply fills up with these files. This > happens whether or not I explicitly set JkShmFile in the Apache conf. > > Is there some way I can persuade mod_jk to use a single file pair, > without the PID suffix, or to delete the previous file pair on a > restart? I'm not doing any load sharing. > > I'm on Ubuntu 22.04, Apache 2.4.52. The mod_jk version is possibly > 1.2.48-1. Can it be that your application crashes on shutdown? This is usually why cleanup is not working properly. Regards, Simon - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: mod_jk logging issue
Hi there, Am 19.12.23 um 18:05 schrieb EML: Hi - I'm running mod_jk with an Apache front-end, and I'm having an issue with the JkShmFile files. Every time Apache restarts mod_jk creates two new files (jk-runtime-status.PID and jk-runtime-status.PID.lock). These are never cleaned up; the log directory simply fills up with these files. This happens whether or not I explicitly set JkShmFile in the Apache conf. That should no happen. There is a cleanup routine registered, which should delete the files during shutdown. And that's the behavior that I normally observe. Is there some way I can persuade mod_jk to use a single file pair, without the PID suffix, or to delete the previous file pair on a restart? I'm not doing any load sharing. If you must remove the PID, you can patch the code and build it yourself. The ID is added in file common/jk_shm.c in the following line: sprintf(jk_shmem.filename, "%s.%" JK_PID_T_FMT, fname, getpid()); You could replace it by: sprintf(jk_shmem.filename, "%s", fname); If you compile the code yourself, please us the latest version 1.2.49. As I mentioned, a normal shutdown should already remove the files. A reload should not change the pid and thereby the files. A restart in the sense of stop-then-start should also remove the old files. I'm on Ubuntu 22.04, Apache 2.4.52. The mod_jk version is possibly 1.2.48-1. Thanks. Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
mod_jk logging issue
Hi - I'm running mod_jk with an Apache front-end, and I'm having an issue with the JkShmFile files. Every time Apache restarts mod_jk creates two new files (jk-runtime-status.PID and jk-runtime-status.PID.lock). These are never cleaned up; the log directory simply fills up with these files. This happens whether or not I explicitly set JkShmFile in the Apache conf. Is there some way I can persuade mod_jk to use a single file pair, without the PID suffix, or to delete the previous file pair on a restart? I'm not doing any load sharing. I'm on Ubuntu 22.04, Apache 2.4.52. The mod_jk version is possibly 1.2.48-1. Thanks.
[SECURITY] [CORRECTION] CVE-2023-41081 Apache Tomcat Connectors (mod_jk) Authentication Bypass
CVE-2023-41081 Apache Tomcat Connectors (mod_jk) Authentication Bypass Severity: Important Vendor: The Apache Software Foundation Versions Affected: - Apache Tomcat Connectors mod_jk Connector 1.2.0 to 1.2.48 Description: In some circumstances, such as when a configuration included "JkOptions +ForwardDirectories" but the configuration did not provide explicit mounts for all possible proxied requests, mod_jk would use an implicit mapping and map the request to the first defined worker. Such an implicit mapping could result in the unintended exposure of the status worker and/or bypass security constraints configured in httpd. As of JK 1.2.49, the implicit mapping functionality has been removed and all mappings must now be via explicit configuration. Only mod_jk is affected by this issue. The ISAPI redirector is not affected. Mitigation: Users of affected versions should apply one of the following mitigations: - Upgrade to Apache Tomcat Connector (mod_jk) 1.2.49 or later. - Ensure explicit mounts are configured for all possible proxied requests Credit: This vulnerability was reported responsibly to the Tomcat security team by Karl von Randow. History 2023-09-13 Original advisory 2023-09-28 Updated summary References: [1] http://tomcat.apache.org/security-jk.html - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
[SECURITY] [CORRECTION] CVE-2023-41081 Apache Tomcat Connectors (mod_jk) Authentication Bypass
CVE-2023-41081 Apache Tomcat Connectors (mod_jk) Authentication Bypass Severity: Important Vendor: The Apache Software Foundation Versions Affected: - Apache Tomcat Connectors mod_jk Connector 1.2.0 to 1.2.48 Description: In some circumstances, such as when a configuration included "JkOptions +ForwardDirectories" but the configuration did not provide explicit mounts for all possible proxied requests, mod_jk would use an implicit mapping and map the request to the first defined worker. Such an implicit mapping could result in the unintended exposure of the status worker and/or bypass security constraints configured in httpd. As of JK 1.2.49, the implicit mapping functionality has been removed and all mappings must now be via explicit configuration. Only mod_jk is affected by this issue. The ISAPI redirector is not affected. Mitigation: Users of affected versions should apply one of the following mitigations: - Upgrade to Apache Tomcat Connector (mod_jk) 1.2.49 or later. - Ensure explicit mounts are configured for all possible proxied requests Credit: This vulnerability was reported responsibly to the Tomcat security team by Karl von Randow. History 2023-09-13 Original advisory 2023-09-28 Updated summary References: [1] http://tomcat.apache.org/security-jk.html - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
[SECURITY] CVE-2023-41081 Apache Tomcat Connectors (mod_jk) Information Disclosure
CVE-2023-41081 Apache Tomcat Connectors (mod_jk) Information Disclosure Severity: Important Vendor: The Apache Software Foundation Versions Affected: - Apache Tomcat Connectors mod_jk Connector 1.2.0 to 1.2.48 Description: In some circumstances, such as when a configuration included "JkOptions +ForwardDirectories" but the configuration did not provide explicit mounts for all possible proxied requests, mod_jk would use an implicit mapping and map the request to the first defined worker. Such an implicit mapping could result in the unintended exposure of the status worker and/or bypass security constraints configured in httpd. As of JK 1.2.49, the implicit mapping functionality has been removed and all mappings must now be via explicit configuration. Only mod_jk is affected by this issue. The ISAPI redirector is not affected. Mitigation: Users of affected versions should apply one of the following mitigations: - Upgrade to Apache Tomcat Connector (mod_jk) 1.2.49 or later. - Ensure explicit mounts are configured for all possible proxied requests Credit: This vulnerability was reported responsibly to the Tomcat security team by Karl von Randow. References: [1] http://tomcat.apache.org/security-jk.html - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [mod_jk] Is it possible to set the value of a specific attribute via HTTP?
Martin, On 7/3/23 04:47, Martin Knoblauch wrote: On 6/29/23 17:06, Rainer Jung wrote: Since I try to push people into mod_proxy, I am hesitant to implement more and more features which keep people from switching ;) Hi Rainer, so, what do you suggest for the mod_jk retirement? mod_proxy+mod_proxy_ajp, or just proxy to the HTTPS port? You should consider whether you actually need a "real" reverse-proxy or if you can get away with "simple" load-balancing from a network balancer )i.e. one that doesn't know anything about HTTP). If you still need one, I would recommend migrating from AJP -> HTTP(S). I have a whole talk about it: https://tomcat.apache.org/presentations.html#latest-migrate-ajp-http Is there an equivalent to jkmanager with mod_proxy? Yes. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [mod_jk] Is it possible to set the value of a specific attribute via HTTP?
Jon, On 6/30/23 17:21, jonmcalexan...@wellsfargo.com.INVALID wrote: Hi Chris and Rainer, Just want to add my .02 worth. Having the ability to "Drain" hosts in a Proxy configuration would be an awesome boon so you could gracefully take down a "node" for maintenance, or even just a restart. Then be able to put it back in action afterwards. :-) Of course, only in setups where you are using load-balancing and multiple back-end app servers. :-) I have a presentation which covers how to do this, including references to automated tools to drain the servers, how to configure Tomcat to participate in that draining, etc. It's this one from ApacheCon 2015: http://home.apache.org/~schultz/ApacheCon%20NA%202015/Load-balancing%20Tomcat%20with%20mod_jk.pdf -chris -Original Message- From: Christopher Schultz Sent: Friday, June 30, 2023 2:19 PM To: users@tomcat.apache.org Subject: Re: [mod_jk] Is it possible to set the value of a specific attribute via HTTP? Rainer, On 6/29/23 17:06, Rainer Jung wrote: Hi Chris, Am 29.06.23 um 15:00 schrieb Christopher Schultz: All, I've been using mod_jk forever and have some tools[1][2] to check on the status of a worker and change its state using the status worker. One of the samples I check is the "errors" count and if it's above 0 then I report an error to my monitoring system. The problem is that sometimes we just get a random error here or there, and my only recourse is to go into the status worker and "reset" the worker which clears out everything. That may not be a big deal because honestly I don't care what mod_jk thinks the estimated number of sessions on a particular node is, but what I'd prefer to do is bleed-off those errors over time. For example, we check the service every few minutes. If we have more than 0 errors, we start checking more frequently. If, every time we checked, we reduced the error-count by some small number, the count would eventually reach 0 if the event was temporary but it would continue to grow as long as there was some kind of persistent error (like Tomcat-node-is-down). Is there a way to decrement the "errors" count without resetting all counters back to zero? Thanks, -chris [1] Hmm... I haven't put my check_mod_jk.py upon GitHub. I should do that. [2] https://urldefense.com/v3/__https://github.com/ChristopherSchultz/apa che-tomcat- stuff/tree/master/bin/mod_jk__;!!F9svGWnIaVPGSwU!t6oVjPiPK IiI1py49MyQzz_Jewu0_iQqa6xWLqEokHwNpzvlcQ2qAXIfGvhJsWTS34rA8tgC _le50_ lUkwrMqUjevlf5d9KD$ no, there is no way to change insdividual runtime counters. As always it would be possible to code it as an addition to the jk manager. One would have to think about which counters for which workers (lb, member, ajp) and whether one should be able to reset to 0, to adjust by some delta or whatever. I have not immediate intention to implement it, at this point just wanted to mention it is not there but doable. Thank you. I figured you would know best :) Since I try to push people into mod_proxy, I am hesitant to implement more and more features which keep people from switching ;) I wouldn't suggest adding this to mod_jk for exactly the same reason. But if the feature DID exist, I would have used it :) The last feature I added was putting a request id on the log lines (yet unreleased). Does mod_proxy_balancer have this kind of thing? Does it sound like something worth implementing? mod_jk's support for monitoring and live- adjustments has always been better than mod_proxy_* IMHO but it is catching up. Something like this would be very helpful addition. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [mod_jk] Is it possible to set the value of a specific attribute via HTTP?
On 6/29/23 17:06, Rainer Jung wrote: > > > Since I try to push people into mod_proxy, I am hesitant to implement > > more and more features which keep people from switching ;) > > Hi Rainer, so, what do you suggest for the mod_jk retirement? mod_proxy+mod_proxy_ajp, or just proxy to the HTTPS port? Is there an equivalent to jkmanager with mod_proxy? Thanks Martin -- -- Martin Knoblauch email: k n o b i AT knobisoft DOT de www: http://www.knobisoft.de
RE: [mod_jk] Is it possible to set the value of a specific attribute via HTTP?
Hi Chris and Rainer, Just want to add my .02 worth. Having the ability to "Drain" hosts in a Proxy configuration would be an awesome boon so you could gracefully take down a "node" for maintenance, or even just a restart. Then be able to put it back in action afterwards. :-) Of course, only in setups where you are using load-balancing and multiple back-end app servers. :-) Thanks and have a great Weekend! Dream * Excel * Explore * Inspire Jon McAlexander Senior Infrastructure Engineer Asst. Vice President He/His Middleware Product Engineering Enterprise CIO | EAS | Middleware | Infrastructure Solutions 8080 Cobblestone Rd | Urbandale, IA 50322 MAC: F4469-010 Tel 515-988-2508 | Cell 515-988-2508 jonmcalexan...@wellsfargo.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > -Original Message- > From: Christopher Schultz > Sent: Friday, June 30, 2023 2:19 PM > To: users@tomcat.apache.org > Subject: Re: [mod_jk] Is it possible to set the value of a specific attribute > via > HTTP? > > Rainer, > > On 6/29/23 17:06, Rainer Jung wrote: > > Hi Chris, > > > > Am 29.06.23 um 15:00 schrieb Christopher Schultz: > >> All, > >> > >> I've been using mod_jk forever and have some tools[1][2] to check on > >> the status of a worker and change its state using the status worker. > >> > >> One of the samples I check is the "errors" count and if it's above 0 > >> then I report an error to my monitoring system. > >> > >> The problem is that sometimes we just get a random error here or > >> there, and my only recourse is to go into the status worker and > >> "reset" the worker which clears out everything. That may not be a big > >> deal because honestly I don't care what mod_jk thinks the estimated > >> number of sessions on a particular node is, but what I'd prefer to do > >> is bleed-off those errors over time. > >> > >> For example, we check the service every few minutes. If we have more > >> than 0 errors, we start checking more frequently. If, every time we > >> checked, we reduced the error-count by some small number, the count > >> would eventually reach 0 if the event was temporary but it would > >> continue to grow as long as there was some kind of persistent error > >> (like Tomcat-node-is-down). > >> > >> Is there a way to decrement the "errors" count without resetting all > >> counters back to zero? > >> > >> Thanks, > >> -chris > >> > >> [1] Hmm... I haven't put my check_mod_jk.py upon GitHub. I should do > >> that. > >> [2] > >> > https://urldefense.com/v3/__https://github.com/ChristopherSchultz/apa > >> che-tomcat- > stuff/tree/master/bin/mod_jk__;!!F9svGWnIaVPGSwU!t6oVjPiPK > >> > IiI1py49MyQzz_Jewu0_iQqa6xWLqEokHwNpzvlcQ2qAXIfGvhJsWTS34rA8tgC > _le50_ > >> lUkwrMqUjevlf5d9KD$ > > > > no, there is no way to change insdividual runtime counters. As always > > it would be possible to code it as an addition to the jk manager. One > > would have to think about which counters for which workers (lb, > > member, ajp) and whether one should be able to reset to 0, to adjust > > by some delta or whatever. > > > > I have not immediate intention to implement it, at this point just > > wanted to mention it is not there but doable. > > Thank you. I figured you would know best :) > > > Since I try to push people into mod_proxy, I am hesitant to implement > > more and more features which keep people from switching ;) > > I wouldn't suggest adding this to mod_jk for exactly the same reason. > But if the feature DID exist, I would have used it :) > > > The last feature I added was putting a request id on the log lines > > (yet unreleased). > > Does mod_proxy_balancer have this kind of thing? Does it sound like > something worth implementing? mod_jk's support for monitoring and live- > adjustments has always been better than mod_proxy_* IMHO but it is > catching up. Something like this would be very helpful addition. > > -chris > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [mod_jk] Is it possible to set the value of a specific attribute via HTTP?
Rainer, On 6/29/23 17:06, Rainer Jung wrote: Hi Chris, Am 29.06.23 um 15:00 schrieb Christopher Schultz: All, I've been using mod_jk forever and have some tools[1][2] to check on the status of a worker and change its state using the status worker. One of the samples I check is the "errors" count and if it's above 0 then I report an error to my monitoring system. The problem is that sometimes we just get a random error here or there, and my only recourse is to go into the status worker and "reset" the worker which clears out everything. That may not be a big deal because honestly I don't care what mod_jk thinks the estimated number of sessions on a particular node is, but what I'd prefer to do is bleed-off those errors over time. For example, we check the service every few minutes. If we have more than 0 errors, we start checking more frequently. If, every time we checked, we reduced the error-count by some small number, the count would eventually reach 0 if the event was temporary but it would continue to grow as long as there was some kind of persistent error (like Tomcat-node-is-down). Is there a way to decrement the "errors" count without resetting all counters back to zero? Thanks, -chris [1] Hmm... I haven't put my check_mod_jk.py upon GitHub. I should do that. [2] https://github.com/ChristopherSchultz/apache-tomcat-stuff/tree/master/bin/mod_jk no, there is no way to change insdividual runtime counters. As always it would be possible to code it as an addition to the jk manager. One would have to think about which counters for which workers (lb, member, ajp) and whether one should be able to reset to 0, to adjust by some delta or whatever. I have not immediate intention to implement it, at this point just wanted to mention it is not there but doable. Thank you. I figured you would know best :) Since I try to push people into mod_proxy, I am hesitant to implement more and more features which keep people from switching ;) I wouldn't suggest adding this to mod_jk for exactly the same reason. But if the feature DID exist, I would have used it :) The last feature I added was putting a request id on the log lines (yet unreleased). Does mod_proxy_balancer have this kind of thing? Does it sound like something worth implementing? mod_jk's support for monitoring and live-adjustments has always been better than mod_proxy_* IMHO but it is catching up. Something like this would be very helpful addition. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [mod_jk] Is it possible to set the value of a specific attribute via HTTP?
Hi Chris, Am 29.06.23 um 15:00 schrieb Christopher Schultz: All, I've been using mod_jk forever and have some tools[1][2] to check on the status of a worker and change its state using the status worker. One of the samples I check is the "errors" count and if it's above 0 then I report an error to my monitoring system. The problem is that sometimes we just get a random error here or there, and my only recourse is to go into the status worker and "reset" the worker which clears out everything. That may not be a big deal because honestly I don't care what mod_jk thinks the estimated number of sessions on a particular node is, but what I'd prefer to do is bleed-off those errors over time. For example, we check the service every few minutes. If we have more than 0 errors, we start checking more frequently. If, every time we checked, we reduced the error-count by some small number, the count would eventually reach 0 if the event was temporary but it would continue to grow as long as there was some kind of persistent error (like Tomcat-node-is-down). Is there a way to decrement the "errors" count without resetting all counters back to zero? Thanks, -chris [1] Hmm... I haven't put my check_mod_jk.py upon GitHub. I should do that. [2] https://github.com/ChristopherSchultz/apache-tomcat-stuff/tree/master/bin/mod_jk no, there is no way to change insdividual runtime counters. As always it would be possible to code it as an addition to the jk manager. One would have to think about which counters for which workers (lb, member, ajp) and whether one should be able to reset to 0, to adjust by some delta or whatever. I have not immediate intention to implement it, at this point just wanted to mention it is not there but doable. Since I try to push people into mod_proxy, I am hesitant to implement more and more features which keep people from switching ;) The last feature I added was putting a request id on the log lines (yet unreleased). Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
[mod_jk] Is it possible to set the value of a specific attribute via HTTP?
All, I've been using mod_jk forever and have some tools[1][2] to check on the status of a worker and change its state using the status worker. One of the samples I check is the "errors" count and if it's above 0 then I report an error to my monitoring system. The problem is that sometimes we just get a random error here or there, and my only recourse is to go into the status worker and "reset" the worker which clears out everything. That may not be a big deal because honestly I don't care what mod_jk thinks the estimated number of sessions on a particular node is, but what I'd prefer to do is bleed-off those errors over time. For example, we check the service every few minutes. If we have more than 0 errors, we start checking more frequently. If, every time we checked, we reduced the error-count by some small number, the count would eventually reach 0 if the event was temporary but it would continue to grow as long as there was some kind of persistent error (like Tomcat-node-is-down). Is there a way to decrement the "errors" count without resetting all counters back to zero? Thanks, -chris [1] Hmm... I haven't put my check_mod_jk.py upon GitHub. I should do that. [2] https://github.com/ChristopherSchultz/apache-tomcat-stuff/tree/master/bin/mod_jk - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Clustering, Mod_JK, Fail_on_Status, Stopped Application
Mark and Dan, On 6/21/23 04:57, Mark Thomas wrote: On 20/06/2023 17:12, Dan McLaughlin wrote: Mark, What are your thoughts on changing the Tomcat codebase to return a 503 instead of a 404 if a context is marked as distributable or if clustering is enabled and deployed but stopped? When I did searches years ago on this issue, most people at the time would recommend adding 404 to the fail_on_status, which is what we did...until I realized that we were causing our own internal DOS attack when we had a 404 mistakenly left in our apps; that got me thinking how easy it would be to make mod_jk thrash by just requesting pages that didn't exist. It's not a huge issue for us since most of our apps are authenticated using SAML, so all requests are intercepted before the request is ever sent to Tomcat, but for our apps that don't require authentication, it would be easy to exploit any app that had 404 in the fail_on_status. I think the problem is the "STOPPED" state is used by different users for different things. Some want it to be equivalent to "The application isn't deployed" while others want it to be equivalent to "The application is present but currently under maintenance". I don't think we can safely infer which of those behaviors the user wants from the clustering and/or distributable settings. I think the best solution is the "maintenance in progress" servlet deployed in the ROOT web application. Other options I considered: 1. New Lifecycle state "MAINTENANCE". This would be a significant change and I don't think the size of the problem justifies the scale of the changes required. 2. Extending/enhancing the "pause" feature. Not really the right place to start as pausing a context doesn't allow it to be updated (assuming updates are the main reason for the maintenance). 3. A per Host configuration option to set the status to be used for deployed but stopped web applications. Defaults to 404. Could be configured to be 503. Would require some changes to the mapper to add/remove contexts on deploy/undeploy rather than start/stop. Actually, this is a significant behavioural change since it changes the mapping. And the rewrite valve may complicate things further. The more I think about this, the more nervous I get about changes like this introducing regressions. I come back to the "maintenance in progress" servlet deployed in the ROOT web application. The one use case this doesn't cover is maintenance of the ROOT web application. Currently Tomcat is hard-coded to return a 404 if a request would be mapped to ROOT but that application isn't started. I think a request to make that status configurable would be implemented pretty quickly. If you want to remove the node from the load-balancer, why not ... just do it? You can't test an application without it being deployed, and taking a node down for maintenance can (and IMHO) should include notifying the load-balancer that that node is coming down for maintenance. Otherwise, you'll bounce users off the node unnecessarily. Since mod_jk is being used, why not simply change the state of the node-worker in mod_jk from ACTIVE to DISABLED (for testing, since requests with that node as a target will continue to go to it) or STOPPED (where mod_jk won't send any requests to it anymore? http://home.apache.org/~schultz/ApacheCon%20NA%202015/Load-balancing%20Tomcat%20with%20mod_jk.pdf Start on Slide 41 -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Clustering, Mod_JK, Fail_on_Status, Stopped Application
On 20/06/2023 17:12, Dan McLaughlin wrote:
Mark,
What are your thoughts on changing the Tomcat codebase to return a 503
instead of a 404 if a context is marked as distributable or if
clustering is enabled and deployed but stopped? When I did searches
years ago on this issue, most people at the time would recommend
adding 404 to the fail_on_status, which is what we did...until I
realized that we were causing our own internal DOS attack when we had
a 404 mistakenly left in our apps; that got me thinking how easy it
would be to make mod_jk thrash by just requesting pages that didn't
exist. It's not a huge issue for us since most of our apps are
authenticated using SAML, so all requests are intercepted before the
request is ever sent to Tomcat, but for our apps that don't require
authentication, it would be easy to exploit any app that had 404 in
the fail_on_status.
I think the problem is the "STOPPED" state is used by different users
for different things. Some want it to be equivalent to "The application
isn't deployed" while others want it to be equivalent to "The
application is present but currently under maintenance". I don't think
we can safely infer which of those behaviors the user wants from the
clustering and/or distributable settings.
I think the best solution is the "maintenance in progress" servlet
deployed in the ROOT web application. Other options I considered:
1. New Lifecycle state "MAINTENANCE". This would be a significant change
and I don't think the size of the problem justifies the scale of the
changes required.
2. Extending/enhancing the "pause" feature. Not really the right place
to start as pausing a context doesn't allow it to be updated (assuming
updates are the main reason for the maintenance).
3. A per Host configuration option to set the status to be used for
deployed but stopped web applications. Defaults to 404. Could be
configured to be 503. Would require some changes to the mapper to
add/remove contexts on deploy/undeploy rather than start/stop. Actually,
this is a significant behavioural change since it changes the mapping.
And the rewrite valve may complicate things further.
The more I think about this, the more nervous I get about changes like
this introducing regressions.
I come back to the "maintenance in progress" servlet deployed in the
ROOT web application. The one use case this doesn't cover is maintenance
of the ROOT web application. Currently Tomcat is hard-coded to return a
404 if a request would be mapped to ROOT but that application isn't
started. I think a request to make that status configurable would be
implemented pretty quickly.
Mark
--
Thanks,
Dan
On Tue, Jun 20, 2023 at 10:41 AM Dan McLaughlin
wrote:
We typically don't deploy a ROOT context in our production environments--for no
other reason than making it more difficult to poke around. I'll look at that
as an option. Thanks for the tips.
--
Thanks,
Dan
On Tue, Jun 20, 2023 at 10:28 AM Mark Thomas wrote:
On 20/06/2023 15:41, Dan McLaughlin wrote:
So I tried to create a Valve to check to see if the application is stopped
and convert the 404 response to a 503, but I haven't had any luck getting
it to work. Is there another internal API that I should be using?
context.getState().isAvailable
ways seems to report the app is available even though it's stopped.
The code is looking at the wrong Context. Since the web application has
been stopped the request won't be mapped to it. I'm guessing the request
has been mapped to the root context which is available.
You'll need to do something like:
Container[] containers = request.getHost().findChildren();
for (Container container : containers) {
if (container.getState().isAvailable()) {
continue;
}
Context context = (Context) container;
if (request.getDecodedRequestURI().equals(context.getPath()) ||
request.getDecodedRequestURI().startsWith(
context.getPath() + '/')) {
response.sendError(HttpServletResponse.SC_SERVICE_UNAVAILABLE);
}
}
I haven't optimised this at all. It isn't particularly efficient. It is
just to give you an idea.
Actually. I have just had a much better idea. It works by taking
advantage of the Servlet specification mapping rules which require the
longest context path match.
Lets assume you have /app1 /app2 and /app3
In your ROOT web application create a maintenance Servlet that just
returns a 503 and map it to "/app1/*" "/app2/*" and /app3/*".
If app1 is running, the longest context path match rule means it will be
mapped to /app1 and the application will handle it. If the web
application is stopped, the request will be mapped to ROOT where it will
match the maintenance Servlet and return a 503.
The only thing that this won't work for is if you want to take the RROT
web application out of servi
Re: Tomcat Clustering, Mod_JK, Fail_on_Status, Stopped Application
Dan, On 6/20/23 11:32, Dan McLaughlin wrote: When I attach with a debugger, I can see what's causing it not to work. When the Web Application is started, then request.getContext(); returns the correct Web Application context, but when the application is stopped, request.getContext(); returns the ROOT context, which is up, so the 404 is passed on. Why would request.getContext(); return ROOT if that wasn't the requested context? Is this a bug? I know you posted a lot of messages in a short amount of time, and maybe you've moved-on from this question, but.. How does Tomcat know the difference between a request for /foo/bar and /bar/foo if there is a ROOT application and a /foo application? What happens when /foo is stopped, undeployed, etc.? Why *wouldn't* ROOT handle all requests that don't go to another application? URL paths dictate which application handles a particular request, and the ROOT application, by definition, handles requests that don't map to another application. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Clustering, Mod_JK, Fail_on_Status, Stopped Application
FYI... Here is the valve I finally came up with that seems to work.
import org.apache.catalina.*;
import org.apache.catalina.connector.Request;
import org.apache.catalina.connector.Response;
import org.apache.catalina.valves.ValveBase;
import jakarta.servlet.ServletException;
import java.io.IOException;
import java.util.logging.Logger;
import java.util.logging.Level;
import jakarta.servlet.http.HttpServletResponse;
public class DownForMaintenanceValve extends ValveBase {
// Create a Logger instance to log activity
private static final Logger log =
Logger.getLogger(DownForMaintenanceValve.class.getName());
// Constructor logs that the valve has been instantiated
public DownForMaintenanceValve() {
log.info("DownForMaintenanceValve started");
}
// Main method of the Valve, where the logic is implemented
@Override
public void invoke(Request request, Response response) throws
IOException, ServletException {
// Get the Context of the request
Context context = request.getContext();
// If the context is null, log an info message and send a 503 error
if (context == null) {
log.info("Context is null, sending 503");
response.sendError(HttpServletResponse.SC_SERVICE_UNAVAILABLE);
return; // Stop further execution
}
// If the context is not available, log an info message and send a 503 error
if (!context.getState().isAvailable()) {
log.info("Application is not available, sending 503");
response.sendError(HttpServletResponse.SC_SERVICE_UNAVAILABLE);
} else {
// If the context is available, get all contexts (children of the host)
Container[] containers = request.getHost().findChildren();
// Iterate over all contexts
for (Container container : containers) {
// If the current context is available, skip the rest of the loop
if (container.getState().isAvailable()) {
continue;
}
// Cast the container to Context to be able to call Context methods
context = (Context) container;
// If the request URI matches the path of the context or is a subpath
of the context,
// log an info message and send a 503 error
if (request.getDecodedRequestURI().equals(context.getPath()) ||
request.getDecodedRequestURI().startsWith(context.getPath() + '/')) {
log.info("Application is not available, sending 503");
response.sendError(HttpServletResponse.SC_SERVICE_UNAVAILABLE);
return; // Stop further execution
}
}
// If no unavailable context matching the request URI was found, log a
fine message
// and pass the request to the next Valve
log.info("Application is available, passing to next valve");
getNext().invoke(request, response);
}
}
}
--
Thanks,
Dan
On Tue, Jun 20, 2023 at 12:15 PM Dan McLaughlin
wrote:
>
> One thing I just tested was to undeploy the ROOT context, which is how
> we run anyways, and this causes request.getContext() to return null,
> which with the code, as is, results in a null pointer and a 500 being
> thrown--which inadvertently would cause mod_jk to retry on another
> node. I don't like letting code knowingly throw null pointers, so I
> was thinking of just checking if the context is null and throwing a
> 503. The only problem is that the valve would only work when the ROOT
> context wasn't deployed, so your two other suggestions would be the
> only options.
>
> Mark,
>
> I've been considering opening an official enhancement request to the
> clustering implementation in Tomcat that would state the following...
>
> Currently, when an application within a clustered environment is
> unavailable or stopped, Tomcat returns an HTTP 404 (Not Found) status
> code. While this behavior is generally acceptable in a non-clustered
> environment, it can lead to less than optimal routing decisions by
> load balancers within a clustered setup.
>
> Most load balancers, including mod_jk, do not interpret a 404 status
> code as an indication of application unavailability warranting a
> failover. Moreover, reconfiguring load balancers to treat 404 codes as
> triggers for failover could potentially expose systems to DOS attacks,
> as malicious users could generate unnecessary failovers by requesting
> non-existent resources.
>
> While there are workarounds to this issue, such as creating a custom
> valve to check the application status and modifying the 404 to a 503,
> or using root context and servlet mappings to return a 503, these
> solutions require custom implementations by the end user. This adds
> complexity and is not an ideal solution.
>
> In light of this, I propose that Tomcat should return an HTTP 503
> (Service Unavailable) status code when an application is not available
> in a clustered environment. The 503 code, which signifies temporary
> unavailability of the application, would align more accurately with
> the circumstances and could enable load balancers to make more
> informed and effective routing decisions.
>
> Thoughts?
>
&
Re: Tomcat Clustering, Mod_JK, Fail_on_Status, Stopped Application
One thing I just tested was to undeploy the ROOT context, which is how
we run anyways, and this causes request.getContext() to return null,
which with the code, as is, results in a null pointer and a 500 being
thrown--which inadvertently would cause mod_jk to retry on another
node. I don't like letting code knowingly throw null pointers, so I
was thinking of just checking if the context is null and throwing a
503. The only problem is that the valve would only work when the ROOT
context wasn't deployed, so your two other suggestions would be the
only options.
Mark,
I've been considering opening an official enhancement request to the
clustering implementation in Tomcat that would state the following...
Currently, when an application within a clustered environment is
unavailable or stopped, Tomcat returns an HTTP 404 (Not Found) status
code. While this behavior is generally acceptable in a non-clustered
environment, it can lead to less than optimal routing decisions by
load balancers within a clustered setup.
Most load balancers, including mod_jk, do not interpret a 404 status
code as an indication of application unavailability warranting a
failover. Moreover, reconfiguring load balancers to treat 404 codes as
triggers for failover could potentially expose systems to DOS attacks,
as malicious users could generate unnecessary failovers by requesting
non-existent resources.
While there are workarounds to this issue, such as creating a custom
valve to check the application status and modifying the 404 to a 503,
or using root context and servlet mappings to return a 503, these
solutions require custom implementations by the end user. This adds
complexity and is not an ideal solution.
In light of this, I propose that Tomcat should return an HTTP 503
(Service Unavailable) status code when an application is not available
in a clustered environment. The 503 code, which signifies temporary
unavailability of the application, would align more accurately with
the circumstances and could enable load balancers to make more
informed and effective routing decisions.
Thoughts?
--
Thanks,
Dan
--
Thanks,
Dan McLaughlin
Robert Clay Vineyards
Proprietor/Vigneron
d...@robertclayvineyards.com
mobile: 512.633.8086
main: 325.261.0075
https://robertclayvineyards.com
Facebook | Instagram
On Tue, Jun 20, 2023 at 10:28 AM Mark Thomas wrote:
>
> On 20/06/2023 15:41, Dan McLaughlin wrote:
> > So I tried to create a Valve to check to see if the application is stopped
> > and convert the 404 response to a 503, but I haven't had any luck getting
> > it to work. Is there another internal API that I should be using?
> > context.getState().isAvailable
> > ways seems to report the app is available even though it's stopped.
>
> The code is looking at the wrong Context. Since the web application has
> been stopped the request won't be mapped to it. I'm guessing the request
> has been mapped to the root context which is available.
>
> You'll need to do something like:
>
> Container[] containers = request.getHost().findChildren();
> for (Container container : containers) {
> if (container.getState().isAvailable()) {
> continue;
> }
> Context context = (Context) container;
> if (request.getDecodedRequestURI().equals(context.getPath()) ||
> request.getDecodedRequestURI().startsWith(
> context.getPath() + '/')) {
> response.sendError(HttpServletResponse.SC_SERVICE_UNAVAILABLE);
> }
> }
>
> I haven't optimised this at all. It isn't particularly efficient. It is
> just to give you an idea.
>
> Actually. I have just had a much better idea. It works by taking
> advantage of the Servlet specification mapping rules which require the
> longest context path match.
>
> Lets assume you have /app1 /app2 and /app3
>
> In your ROOT web application create a maintenance Servlet that just
> returns a 503 and map it to "/app1/*" "/app2/*" and /app3/*".
>
> If app1 is running, the longest context path match rule means it will be
> mapped to /app1 and the application will handle it. If the web
> application is stopped, the request will be mapped to ROOT where it will
> match the maintenance Servlet and return a 503.
>
> The only thing that this won't work for is if you want to take the RROT
> web application out of service.
>
> Mark
>
>
> > import org.apache.catalina.*;
> > import org.apache.catalina.connector.Request;
> > import org.apache.catalina.connector.Response;
> > import org.apache.catalina.valves.ValveBase;
> >
> > import jakarta.servlet.ServletException;
> > import java.io.IOException;
> > import java.util.logging.Logger;
> > import java.util.logging.Level;
>
Re: Tomcat Clustering, Mod_JK, Fail_on_Status, Stopped Application
Mark,
What are your thoughts on changing the Tomcat codebase to return a 503
instead of a 404 if a context is marked as distributable or if
clustering is enabled and deployed but stopped? When I did searches
years ago on this issue, most people at the time would recommend
adding 404 to the fail_on_status, which is what we did...until I
realized that we were causing our own internal DOS attack when we had
a 404 mistakenly left in our apps; that got me thinking how easy it
would be to make mod_jk thrash by just requesting pages that didn't
exist. It's not a huge issue for us since most of our apps are
authenticated using SAML, so all requests are intercepted before the
request is ever sent to Tomcat, but for our apps that don't require
authentication, it would be easy to exploit any app that had 404 in
the fail_on_status.
--
Thanks,
Dan
On Tue, Jun 20, 2023 at 10:41 AM Dan McLaughlin
wrote:
>
> We typically don't deploy a ROOT context in our production environments--for
> no other reason than making it more difficult to poke around. I'll look at
> that as an option. Thanks for the tips.
>
> --
>
> Thanks,
> Dan
>
>
> On Tue, Jun 20, 2023 at 10:28 AM Mark Thomas wrote:
>>
>> On 20/06/2023 15:41, Dan McLaughlin wrote:
>> > So I tried to create a Valve to check to see if the application is stopped
>> > and convert the 404 response to a 503, but I haven't had any luck getting
>> > it to work. Is there another internal API that I should be using?
>> > context.getState().isAvailable
>> > ways seems to report the app is available even though it's stopped.
>>
>> The code is looking at the wrong Context. Since the web application has
>> been stopped the request won't be mapped to it. I'm guessing the request
>> has been mapped to the root context which is available.
>>
>> You'll need to do something like:
>>
>> Container[] containers = request.getHost().findChildren();
>> for (Container container : containers) {
>> if (container.getState().isAvailable()) {
>> continue;
>> }
>> Context context = (Context) container;
>> if (request.getDecodedRequestURI().equals(context.getPath()) ||
>> request.getDecodedRequestURI().startsWith(
>> context.getPath() + '/')) {
>> response.sendError(HttpServletResponse.SC_SERVICE_UNAVAILABLE);
>> }
>> }
>>
>> I haven't optimised this at all. It isn't particularly efficient. It is
>> just to give you an idea.
>>
>> Actually. I have just had a much better idea. It works by taking
>> advantage of the Servlet specification mapping rules which require the
>> longest context path match.
>>
>> Lets assume you have /app1 /app2 and /app3
>>
>> In your ROOT web application create a maintenance Servlet that just
>> returns a 503 and map it to "/app1/*" "/app2/*" and /app3/*".
>>
>> If app1 is running, the longest context path match rule means it will be
>> mapped to /app1 and the application will handle it. If the web
>> application is stopped, the request will be mapped to ROOT where it will
>> match the maintenance Servlet and return a 503.
>>
>> The only thing that this won't work for is if you want to take the RROT
>> web application out of service.
>>
>> Mark
>>
>>
>> > import org.apache.catalina.*;
>> > import org.apache.catalina.connector.Request;
>> > import org.apache.catalina.connector.Response;
>> > import org.apache.catalina.valves.ValveBase;
>> >
>> > import jakarta.servlet.ServletException;
>> > import java.io.IOException;
>> > import java.util.logging.Logger;
>> > import java.util.logging.Level;
>> >
>> > public class DownForMaintenanceValve extends ValveBase {
>> >
>> > // Create a Logger
>> > private static final Logger log = Logger.getLogger(DownForMaintenanceValve.
>> > class.getName());
>> >
>> > public DownForMaintenanceValve() {
>> > log.info("DownForMaintenanceValve started");
>> > }
>> >
>> > @Override
>> > public void invoke(Request request, Response response) throws
>> > IOException, ServletException
>> > {
>> > Context context = request.getContext();
>> > if (!context.getState().isAvailable()) {
>> > log.info("Application is not available, sending 503");
>> > response.sendError(503);
>> > } else {
>> > log.fine("Application is available, passing to next valve");
>> > getNext().invoke(request
Re: Tomcat Clustering, Mod_JK, Fail_on_Status, Stopped Application
We typically don't deploy a ROOT context in our production
environments--for no other reason than making it more difficult to poke
around. I'll look at that as an option. Thanks for the tips.
--
Thanks,
Dan
On Tue, Jun 20, 2023 at 10:28 AM Mark Thomas wrote:
> On 20/06/2023 15:41, Dan McLaughlin wrote:
> > So I tried to create a Valve to check to see if the application is
> stopped
> > and convert the 404 response to a 503, but I haven't had any luck getting
> > it to work. Is there another internal API that I should be using?
> > context.getState().isAvailable
> > ways seems to report the app is available even though it's stopped.
>
> The code is looking at the wrong Context. Since the web application has
> been stopped the request won't be mapped to it. I'm guessing the request
> has been mapped to the root context which is available.
>
> You'll need to do something like:
>
> Container[] containers = request.getHost().findChildren();
> for (Container container : containers) {
> if (container.getState().isAvailable()) {
> continue;
> }
> Context context = (Context) container;
> if (request.getDecodedRequestURI().equals(context.getPath()) ||
> request.getDecodedRequestURI().startsWith(
> context.getPath() + '/')) {
> response.sendError(HttpServletResponse.SC_SERVICE_UNAVAILABLE);
> }
> }
>
> I haven't optimised this at all. It isn't particularly efficient. It is
> just to give you an idea.
>
> Actually. I have just had a much better idea. It works by taking
> advantage of the Servlet specification mapping rules which require the
> longest context path match.
>
> Lets assume you have /app1 /app2 and /app3
>
> In your ROOT web application create a maintenance Servlet that just
> returns a 503 and map it to "/app1/*" "/app2/*" and /app3/*".
>
> If app1 is running, the longest context path match rule means it will be
> mapped to /app1 and the application will handle it. If the web
> application is stopped, the request will be mapped to ROOT where it will
> match the maintenance Servlet and return a 503.
>
> The only thing that this won't work for is if you want to take the RROT
> web application out of service.
>
> Mark
>
>
> > import org.apache.catalina.*;
> > import org.apache.catalina.connector.Request;
> > import org.apache.catalina.connector.Response;
> > import org.apache.catalina.valves.ValveBase;
> >
> > import jakarta.servlet.ServletException;
> > import java.io.IOException;
> > import java.util.logging.Logger;
> > import java.util.logging.Level;
> >
> > public class DownForMaintenanceValve extends ValveBase {
> >
> > // Create a Logger
> > private static final Logger log =
> Logger.getLogger(DownForMaintenanceValve.
> > class.getName());
> >
> > public DownForMaintenanceValve() {
> > log.info("DownForMaintenanceValve started");
> > }
> >
> > @Override
> > public void invoke(Request request, Response response) throws
> > IOException, ServletException
> > {
> > Context context = request.getContext();
> > if (!context.getState().isAvailable()) {
> > log.info("Application is not available, sending 503");
> > response.sendError(503);
> > } else {
> > log.fine("Application is available, passing to next valve");
> > getNext().invoke(request, response);
> > }
> > }
> > }
> >
> >
> > --
> >
> > Thanks,
> > Dan
> >
> > On Wed, Jun 14, 2023 at 2:32 PM Mark Thomas wrote:
> >
> >> On 14/06/2023 19:49, Dan McLaughlin wrote:
> >>> Hello,
> >>>
> >>> This is probably a question that would be better suited for the dev
> list,
> >>> but I thought I'd start here first.
> >>
> >> That depends. It is generally better to start on the users list.
> >>
> >>> Does anyone understand the reasoning behind why Tomcat, when clustered,
> >>> throws an HTTP status 404 and not a 503 when you have an application
> >>> deployed but stopped or paused?
> >>
> >> The issue you describe only affects stopped applications. If an
> >> application is paused then any requests to that application should be
> >> held until the application is unpaused (or the client timeouts out).
> >>
> >> The current Tomcat Mapper dates back to at least Tomcat 4. It might be
> >> earlier but I don't know the Tomcat 3 code well enough to find the
> >> Tomcat 3 mapping code in the web interface and I'm not curious enough to
> >> check the code out so I can use grep.
> >>
> >> The clustering implementation dates back to Tomcat 5.
> >>
> >> You'll need to dig through the archives to see if this topic was ever
> >> raised and, if it was, the result of that discussion. Probably around
> >> the time clustering was added.
> >>
> >>> I think I understand that my only option is to
> >>> failover for 404s considering the current implementation.
> >>
> >> That might cause problems. If the node returning 404 is marked as down
> >> you'll have a DoS vulnerability that is trivial to exploit.
> >>
> >>> I've looked to
> >>> see if there was a configuration setting related to clustering that
>
Re: Tomcat Clustering, Mod_JK, Fail_on_Status, Stopped Application
When I attach with a debugger, I can see what's causing it not to
work. When the Web Application is started, then
request.getContext(); returns the correct Web Application context, but
when the application is stopped, request.getContext(); returns the
ROOT context, which is up, so the 404 is passed on. Why would
request.getContext(); return ROOT if that wasn't the requested
context? Is this a bug?
--
Thanks,
Dan
--
Thanks,
Dan McLaughlin
DJAB Enterprises, LLC
d...@djabenterprises.com
mobile: 512.633.8086
NOTICE: This e-mail message and all attachments transmitted with it
are for the sole use of the intended recipient(s) and may contain
confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is strictly prohibited. The contents of
this e-mail are confidential and may be subject to work product
privileges. If you are not the intended recipient, please contact the
sender by reply e-mail and destroy all copies of the original message.
On Tue, Jun 20, 2023 at 9:41 AM Dan McLaughlin wrote:
>
> So I tried to create a Valve to check to see if the application is stopped
> and convert the 404 response to a 503, but I haven't had any luck getting it
> to work. Is there another internal API that I should be using?
> context.getState().isAvailable ways seems to report the app is available even
> though it's stopped.
> import org.apache.catalina.*;
> import org.apache.catalina.connector.Request;
> import org.apache.catalina.connector.Response;
> import org.apache.catalina.valves.ValveBase;
>
> import jakarta.servlet.ServletException;
> import java.io.IOException;
> import java.util.logging.Logger;
> import java.util.logging.Level;
>
> public class DownForMaintenanceValve extends ValveBase {
>
> // Create a Logger
> private static final Logger log =
> Logger.getLogger(DownForMaintenanceValve.class.getName());
>
> public DownForMaintenanceValve() {
> log.info("DownForMaintenanceValve started");
> }
>
> @Override
> public void invoke(Request request, Response response) throws IOException,
> ServletException {
> Context context = request.getContext();
> if (!context.getState().isAvailable()) {
> log.info("Application is not available, sending 503");
> response.sendError(503);
> } else {
> log.fine("Application is available, passing to next valve");
> getNext().invoke(request, response);
> }
> }
> }
>
>
> --
>
> Thanks,
> Dan
>
> On Wed, Jun 14, 2023 at 2:32 PM Mark Thomas wrote:
>>
>> On 14/06/2023 19:49, Dan McLaughlin wrote:
>> > Hello,
>> >
>> > This is probably a question that would be better suited for the dev list,
>> > but I thought I'd start here first.
>>
>> That depends. It is generally better to start on the users list.
>>
>> > Does anyone understand the reasoning behind why Tomcat, when clustered,
>> > throws an HTTP status 404 and not a 503 when you have an application
>> > deployed but stopped or paused?
>>
>> The issue you describe only affects stopped applications. If an
>> application is paused then any requests to that application should be
>> held until the application is unpaused (or the client timeouts out).
>>
>> The current Tomcat Mapper dates back to at least Tomcat 4. It might be
>> earlier but I don't know the Tomcat 3 code well enough to find the
>> Tomcat 3 mapping code in the web interface and I'm not curious enough to
>> check the code out so I can use grep.
>>
>> The clustering implementation dates back to Tomcat 5.
>>
>> You'll need to dig through the archives to see if this topic was ever
>> raised and, if it was, the result of that discussion. Probably around
>> the time clustering was added.
>>
>> > I think I understand that my only option is to
>> > failover for 404s considering the current implementation.
>>
>> That might cause problems. If the node returning 404 is marked as down
>> you'll have a DoS vulnerability that is trivial to exploit.
>>
>> > I've looked to
>> > see if there was a configuration setting related to clustering that would
>> > allow me to change the behavior, and I couldn't find one; the only solution
>> > seems to be to write a custom listener that detects that an application is
>> > deployed but stopped or paused, and then throw a 503 instead.
>>
>> That would be a better short-term solution and fairly simple to write.
>> I'd probably do it as a Valve as you'll get access to Tomcat's internals
>> that way.
>>
>> The clustering implementation generally assumes that all applications
>> are available on all nodes. If that isn't the case I wouldn't be
>> surprised to see log messages indicating issues with replication.
>>
>> What is the use case for stopping one (or more) web applications on a node?
>>
>> Mark
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
--
*NOTICE:* This e-mail message and all attachments transmitted with
it are for the
Re: Tomcat Clustering, Mod_JK, Fail_on_Status, Stopped Application
On 20/06/2023 15:41, Dan McLaughlin wrote:
So I tried to create a Valve to check to see if the application is stopped
and convert the 404 response to a 503, but I haven't had any luck getting
it to work. Is there another internal API that I should be using?
context.getState().isAvailable
ways seems to report the app is available even though it's stopped.
The code is looking at the wrong Context. Since the web application has
been stopped the request won't be mapped to it. I'm guessing the request
has been mapped to the root context which is available.
You'll need to do something like:
Container[] containers = request.getHost().findChildren();
for (Container container : containers) {
if (container.getState().isAvailable()) {
continue;
}
Context context = (Context) container;
if (request.getDecodedRequestURI().equals(context.getPath()) ||
request.getDecodedRequestURI().startsWith(
context.getPath() + '/')) {
response.sendError(HttpServletResponse.SC_SERVICE_UNAVAILABLE);
}
}
I haven't optimised this at all. It isn't particularly efficient. It is
just to give you an idea.
Actually. I have just had a much better idea. It works by taking
advantage of the Servlet specification mapping rules which require the
longest context path match.
Lets assume you have /app1 /app2 and /app3
In your ROOT web application create a maintenance Servlet that just
returns a 503 and map it to "/app1/*" "/app2/*" and /app3/*".
If app1 is running, the longest context path match rule means it will be
mapped to /app1 and the application will handle it. If the web
application is stopped, the request will be mapped to ROOT where it will
match the maintenance Servlet and return a 503.
The only thing that this won't work for is if you want to take the RROT
web application out of service.
Mark
import org.apache.catalina.*;
import org.apache.catalina.connector.Request;
import org.apache.catalina.connector.Response;
import org.apache.catalina.valves.ValveBase;
import jakarta.servlet.ServletException;
import java.io.IOException;
import java.util.logging.Logger;
import java.util.logging.Level;
public class DownForMaintenanceValve extends ValveBase {
// Create a Logger
private static final Logger log = Logger.getLogger(DownForMaintenanceValve.
class.getName());
public DownForMaintenanceValve() {
log.info("DownForMaintenanceValve started");
}
@Override
public void invoke(Request request, Response response) throws
IOException, ServletException
{
Context context = request.getContext();
if (!context.getState().isAvailable()) {
log.info("Application is not available, sending 503");
response.sendError(503);
} else {
log.fine("Application is available, passing to next valve");
getNext().invoke(request, response);
}
}
}
--
Thanks,
Dan
On Wed, Jun 14, 2023 at 2:32 PM Mark Thomas wrote:
On 14/06/2023 19:49, Dan McLaughlin wrote:
Hello,
This is probably a question that would be better suited for the dev list,
but I thought I'd start here first.
That depends. It is generally better to start on the users list.
Does anyone understand the reasoning behind why Tomcat, when clustered,
throws an HTTP status 404 and not a 503 when you have an application
deployed but stopped or paused?
The issue you describe only affects stopped applications. If an
application is paused then any requests to that application should be
held until the application is unpaused (or the client timeouts out).
The current Tomcat Mapper dates back to at least Tomcat 4. It might be
earlier but I don't know the Tomcat 3 code well enough to find the
Tomcat 3 mapping code in the web interface and I'm not curious enough to
check the code out so I can use grep.
The clustering implementation dates back to Tomcat 5.
You'll need to dig through the archives to see if this topic was ever
raised and, if it was, the result of that discussion. Probably around
the time clustering was added.
I think I understand that my only option is to
failover for 404s considering the current implementation.
That might cause problems. If the node returning 404 is marked as down
you'll have a DoS vulnerability that is trivial to exploit.
I've looked to
see if there was a configuration setting related to clustering that would
allow me to change the behavior, and I couldn't find one; the only
solution
seems to be to write a custom listener that detects that an application
is
deployed but stopped or paused, and then throw a 503 instead.
That would be a better short-term solution and fairly simple to write.
I'd probably do it as a Valve as you'll get access to Tomcat's internals
that way.
The clustering implementation generally assumes that all applications
are available on all nodes. If that isn't the case I wouldn't be
surprised to see log messages indicating issues with replication.
What is the use case for stopping one (or more) web applications on a node?
Mark
Re: Tomcat Clustering, Mod_JK, Fail_on_Status, Stopped Application
So I tried to create a Valve to check to see if the application is stopped
and convert the 404 response to a 503, but I haven't had any luck getting
it to work. Is there another internal API that I should be using?
context.getState().isAvailable
ways seems to report the app is available even though it's stopped.
import org.apache.catalina.*;
import org.apache.catalina.connector.Request;
import org.apache.catalina.connector.Response;
import org.apache.catalina.valves.ValveBase;
import jakarta.servlet.ServletException;
import java.io.IOException;
import java.util.logging.Logger;
import java.util.logging.Level;
public class DownForMaintenanceValve extends ValveBase {
// Create a Logger
private static final Logger log = Logger.getLogger(DownForMaintenanceValve.
class.getName());
public DownForMaintenanceValve() {
log.info("DownForMaintenanceValve started");
}
@Override
public void invoke(Request request, Response response) throws
IOException, ServletException
{
Context context = request.getContext();
if (!context.getState().isAvailable()) {
log.info("Application is not available, sending 503");
response.sendError(503);
} else {
log.fine("Application is available, passing to next valve");
getNext().invoke(request, response);
}
}
}
--
Thanks,
Dan
On Wed, Jun 14, 2023 at 2:32 PM Mark Thomas wrote:
> On 14/06/2023 19:49, Dan McLaughlin wrote:
> > Hello,
> >
> > This is probably a question that would be better suited for the dev list,
> > but I thought I'd start here first.
>
> That depends. It is generally better to start on the users list.
>
> > Does anyone understand the reasoning behind why Tomcat, when clustered,
> > throws an HTTP status 404 and not a 503 when you have an application
> > deployed but stopped or paused?
>
> The issue you describe only affects stopped applications. If an
> application is paused then any requests to that application should be
> held until the application is unpaused (or the client timeouts out).
>
> The current Tomcat Mapper dates back to at least Tomcat 4. It might be
> earlier but I don't know the Tomcat 3 code well enough to find the
> Tomcat 3 mapping code in the web interface and I'm not curious enough to
> check the code out so I can use grep.
>
> The clustering implementation dates back to Tomcat 5.
>
> You'll need to dig through the archives to see if this topic was ever
> raised and, if it was, the result of that discussion. Probably around
> the time clustering was added.
>
> > I think I understand that my only option is to
> > failover for 404s considering the current implementation.
>
> That might cause problems. If the node returning 404 is marked as down
> you'll have a DoS vulnerability that is trivial to exploit.
>
> > I've looked to
> > see if there was a configuration setting related to clustering that would
> > allow me to change the behavior, and I couldn't find one; the only
> solution
> > seems to be to write a custom listener that detects that an application
> is
> > deployed but stopped or paused, and then throw a 503 instead.
>
> That would be a better short-term solution and fairly simple to write.
> I'd probably do it as a Valve as you'll get access to Tomcat's internals
> that way.
>
> The clustering implementation generally assumes that all applications
> are available on all nodes. If that isn't the case I wouldn't be
> surprised to see log messages indicating issues with replication.
>
> What is the use case for stopping one (or more) web applications on a node?
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
--
*NOTICE:* This e-mail message and all attachments transmitted with
it are for the sole use of the intended recipient(s) and may contain
confidential and privileged information. Any unauthorized review, use,
disclosure, or distribution is strictly prohibited. The contents of this
e-mail are confidential and may be subject to work product privileges. If
you are not the intended recipient, please contact the sender by reply
e-mail and destroy all copies of the original message.
Re: Tomcat Clustering, Mod_JK, Fail_on_Status, Stopped Application
Hey Mark, Thanks for the information and quick response! The typical use case is either during a hot redeployment of an application; we don't use the application context versions only because we had issues with it in the past, but the last time I tried it was years ago. If I remember correctly, the problems might have been classloader issues or related to JMX conflicts. For that reason, we redeploy using the same context and version. When the redeployment happens using the same context version, there is a small window where the app is stopped during the redeployment. The other case is on rare occasions, we will need to stop just one application deployed on a Tomcat node to troubleshoot something where clustering is making it more difficult to debug. We don't want to take down all the apps or the entire Tomcat node because we need it to handle the load. We don't hot deploy often, so it's not a huge issue, and even more rarely do we run into issues in production where we need to stop just one app, but it has happened. It would just be nice not to have to go tell mod_jk that a node was down for an application or have to stop Tomcat to get it to not send requests to a stopped app, if it was stopped and threw a 503 it would just happen. The only reason I even looked at this is that I've been tasked with implementing a comprehensive solution for handling all the different error conditions properly and displaying the proper error pages. We are also implementing a way to put all our applications in a "Down for Maintenance Mode" without having to stop them and that can be scheduled at the individual application level. I'll look at using a valve if we decide it's a big enough issue. Thanks again for the explanation! Dan On Wed, Jun 14, 2023 at 2:32 PM Mark Thomas wrote: > On 14/06/2023 19:49, Dan McLaughlin wrote: > > Hello, > > > > This is probably a question that would be better suited for the dev list, > > but I thought I'd start here first. > > That depends. It is generally better to start on the users list. > > > Does anyone understand the reasoning behind why Tomcat, when clustered, > > throws an HTTP status 404 and not a 503 when you have an application > > deployed but stopped or paused? > > The issue you describe only affects stopped applications. If an > application is paused then any requests to that application should be > held until the application is unpaused (or the client timeouts out). > > The current Tomcat Mapper dates back to at least Tomcat 4. It might be > earlier but I don't know the Tomcat 3 code well enough to find the > Tomcat 3 mapping code in the web interface and I'm not curious enough to > check the code out so I can use grep. > > The clustering implementation dates back to Tomcat 5. > > You'll need to dig through the archives to see if this topic was ever > raised and, if it was, the result of that discussion. Probably around > the time clustering was added. > > > I think I understand that my only option is to > > failover for 404s considering the current implementation. > > That might cause problems. If the node returning 404 is marked as down > you'll have a DoS vulnerability that is trivial to exploit. > > > I've looked to > > see if there was a configuration setting related to clustering that would > > allow me to change the behavior, and I couldn't find one; the only > solution > > seems to be to write a custom listener that detects that an application > is > > deployed but stopped or paused, and then throw a 503 instead. > > That would be a better short-term solution and fairly simple to write. > I'd probably do it as a Valve as you'll get access to Tomcat's internals > that way. > > The clustering implementation generally assumes that all applications > are available on all nodes. If that isn't the case I wouldn't be > surprised to see log messages indicating issues with replication. > > What is the use case for stopping one (or more) web applications on a node? > > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > -- *NOTICE:* This e-mail message and all attachments transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure, or distribution is strictly prohibited. The contents of this e-mail are confidential and may be subject to work product privileges. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
Re: Tomcat Clustering, Mod_JK, Fail_on_Status, Stopped Application
On 14/06/2023 19:49, Dan McLaughlin wrote: Hello, This is probably a question that would be better suited for the dev list, but I thought I'd start here first. That depends. It is generally better to start on the users list. Does anyone understand the reasoning behind why Tomcat, when clustered, throws an HTTP status 404 and not a 503 when you have an application deployed but stopped or paused? The issue you describe only affects stopped applications. If an application is paused then any requests to that application should be held until the application is unpaused (or the client timeouts out). The current Tomcat Mapper dates back to at least Tomcat 4. It might be earlier but I don't know the Tomcat 3 code well enough to find the Tomcat 3 mapping code in the web interface and I'm not curious enough to check the code out so I can use grep. The clustering implementation dates back to Tomcat 5. You'll need to dig through the archives to see if this topic was ever raised and, if it was, the result of that discussion. Probably around the time clustering was added. I think I understand that my only option is to failover for 404s considering the current implementation. That might cause problems. If the node returning 404 is marked as down you'll have a DoS vulnerability that is trivial to exploit. I've looked to see if there was a configuration setting related to clustering that would allow me to change the behavior, and I couldn't find one; the only solution seems to be to write a custom listener that detects that an application is deployed but stopped or paused, and then throw a 503 instead. That would be a better short-term solution and fairly simple to write. I'd probably do it as a Valve as you'll get access to Tomcat's internals that way. The clustering implementation generally assumes that all applications are available on all nodes. If that isn't the case I wouldn't be surprised to see log messages indicating issues with replication. What is the use case for stopping one (or more) web applications on a node? Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat Clustering, Mod_JK, Fail_on_Status, Stopped Application
Hello, This is probably a question that would be better suited for the dev list, but I thought I'd start here first. Does anyone understand the reasoning behind why Tomcat, when clustered, throws an HTTP status 404 and not a 503 when you have an application deployed but stopped or paused? What's confusing to me is why the Tomcat developers felt a 404 was an appropriate response even when Tomcat is clustered. It seems to me that a 503 would be more appropriate when Tomcat is clustered for several reasons. 1) When Tomcat is clustered, and you only have an application stopped or paused on one of the clustered nodes, it doesn't mean the request is truly unavailable; it just needs to be retried on a node where the application is running. 2) Since it's throwing a 404, that means if you don't want a stopped or paused app to cause the clustered application to become unavailable, you have to configure mod_jk fail_on_status to failover for 404s. 3) Lastly, configuring mod_jk to failover for 404s means you will never throw a 404 even when all apps are started, but a page really doesn't exist. 4) It seems to fail over for every 404 would make it very easy to create a DOS attack causing mod_jk to thrash by simply making lots of requests for pages you know don't exist. Anyways, just wondering if anyone out there understands why the decision was made that a 404 was still the appropriate status code to throw even when Tomcat is clustered. I think I understand that my only option is to failover for 404s considering the current implementation. I've looked to see if there was a configuration setting related to clustering that would allow me to change the behavior, and I couldn't find one; the only solution seems to be to write a custom listener that detects that an application is deployed but stopped or paused, and then throw a 503 instead. I asked ChatPGT what it thought about all this, and here is what it had to say... *"Your points are absolutely valid and they highlight some of the challenges with using a 404 status for situations where a web application is stopped or paused in a clustered environment. A 503 status would indeed be more semantically appropriate in these situations as it more accurately indicates that the service is temporarily unavailable rather than the resource being not found.* *1) As you correctly pointed out, in a clustered environment, a stopped or paused application on one node does not necessarily mean that the requested resource is not available. It could simply be that the resource needs to be requested from a different node where the application is running.2) Configuring `mod_jk` to failover on 404 errors can help in these situations, but it comes with the drawback of treating all 404 errors as potential failover triggers, which may not always be appropriate or efficient.3) If `mod_jk` is configured to failover on 404 errors, then, as you mentioned, a true 404 error (where a page really does not exist across all nodes) would not be surfaced to the client. Instead, `mod_jk` would keep trying to find a node that can handle the request, potentially wasting resources.4) Lastly, you're right that this setup could potentially be exploited for a denial of service (DoS) attack. An attacker could generate a large number of requests for non-existent pages, causing `mod_jk` to constantly attempt failovers and use up system resources.In an ideal world, Tomcat would provide a more nuanced way to differentiate between these scenarios and return a 503 status when an application is stopped or paused, especially in a clustered environment. However, as of my knowledge cutoff in September 2021, this is not the case. I'm not aware of the specific reasons why the Tomcat developers chose to use a 404 status for these situations, but it's possible that it was a simpler option to implement and it met the needs of most users at the time.The custom Valve solution discussed earlier could potentially help address these challenges by allowing you to control the error status that Tomcat returns based on the specific state of the application and server. But this does require additional custom development and testing.This is certainly an interesting topic, and I appreciate your insights. Let me know if you have any further questions or thoughts!"* -- Thanks, Dan -- *NOTICE:* This e-mail message and all attachments transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure, or distribution is strictly prohibited. The contents of this e-mail are confidential and may be subject to work product privileges. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
Re: Mod_JK vs Mod_Proxy
Jon, On 12/7/22 19:36, jonmcalexan...@wellsfargo.com.INVALID wrote: I get it and agree, but it does just add unnecessary complexity also. In my case, I find it necessary to encrypt ;) There are some reasons I can't move to mod_proxy_* yet, so it's a /necessary/ complexity for me. -chris -Original Message- From: Christopher Schultz Sent: Wednesday, December 7, 2022 4:54 PM To: Tomcat Users List ; jonmcalexan...@wellsfargo.com.INVALID Subject: Re: Mod_JK vs Mod_Proxy Jon, On 12/6/22 16:22, jonmcalexan...@wellsfargo.com.INVALID wrote: What, pray tell, is an encrypted AJP connection? Are you talking AJP over an SSH Tunnel (Stunnel)? Exactly. It's absolutely cheating, but it achieves the goal :) -chris -Original Message- From: Christopher Schultz Sent: Tuesday, December 6, 2022 3:01 PM To: users@tomcat.apache.org Subject: Re: Mod_JK vs Mod_Proxy Jon, On 12/6/22 12:36, jonmcalexan...@wellsfargo.com.INVALID wrote: IMHO, switching to mod_proxy, and using it over SSL, is by far better than using mod_jk or mod_ajp, primarily as mod_proxy allows for secure proxy connection, whereas mod_jk and mod_ajp aren't "secure" as they are not encrypted channels. While this is true (and supports my assertion that everyone should migrate), it doesn't preclude the use of encrypted AJP connections. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Mod_JK vs Mod_Proxy
I get it and agree, but it does just add unnecessary complexity also. Have a Happy!!! Dream * Excel * Explore * Inspire Jon McAlexander Senior Infrastructure Engineer Asst. Vice President He/His Middleware Product Engineering Enterprise CIO | EAS | Middleware | Infrastructure Solutions 8080 Cobblestone Rd | Urbandale, IA 50322 MAC: F4469-010 Tel 515-988-2508 | Cell 515-988-2508 jonmcalexan...@wellsfargo.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > -Original Message- > From: Christopher Schultz > Sent: Wednesday, December 7, 2022 4:54 PM > To: Tomcat Users List ; > jonmcalexan...@wellsfargo.com.INVALID > Subject: Re: Mod_JK vs Mod_Proxy > > Jon, > > On 12/6/22 16:22, jonmcalexan...@wellsfargo.com.INVALID wrote: > > What, pray tell, is an encrypted AJP connection? Are you talking AJP > > over an SSH Tunnel (Stunnel)? > Exactly. It's absolutely cheating, but it achieves the goal :) > > -chris > > >> -Original Message- > >> From: Christopher Schultz > >> Sent: Tuesday, December 6, 2022 3:01 PM > >> To: users@tomcat.apache.org > >> Subject: Re: Mod_JK vs Mod_Proxy > >> > >> Jon, > >> > >> On 12/6/22 12:36, jonmcalexan...@wellsfargo.com.INVALID wrote: > >>> IMHO, switching to mod_proxy, and using it over SSL, is by far > >>> better than > >> using mod_jk or mod_ajp, primarily as mod_proxy allows for secure > >> proxy connection, whereas mod_jk and mod_ajp aren't "secure" as they > >> are not encrypted channels. > >> > >> While this is true (and supports my assertion that everyone should > >> migrate), it doesn't preclude the use of encrypted AJP connections. > >> > >> -chris > >> > >> - > >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > >> For additional commands, e-mail: users-h...@tomcat.apache.org > > > > > > - > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Mod_JK vs Mod_Proxy
Jon, On 12/6/22 16:22, jonmcalexan...@wellsfargo.com.INVALID wrote: What, pray tell, is an encrypted AJP connection? Are you talking AJP over an SSH Tunnel (Stunnel)? Exactly. It's absolutely cheating, but it achieves the goal :) -chris -Original Message- From: Christopher Schultz Sent: Tuesday, December 6, 2022 3:01 PM To: users@tomcat.apache.org Subject: Re: Mod_JK vs Mod_Proxy Jon, On 12/6/22 12:36, jonmcalexan...@wellsfargo.com.INVALID wrote: IMHO, switching to mod_proxy, and using it over SSL, is by far better than using mod_jk or mod_ajp, primarily as mod_proxy allows for secure proxy connection, whereas mod_jk and mod_ajp aren't "secure" as they are not encrypted channels. While this is true (and supports my assertion that everyone should migrate), it doesn't preclude the use of encrypted AJP connections. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Mod_JK vs Mod_Proxy
What, pray tell, is an encrypted AJP connection? Are you talking AJP over an SSH Tunnel (Stunnel)? Dream * Excel * Explore * Inspire Jon McAlexander Senior Infrastructure Engineer Asst. Vice President He/His Middleware Product Engineering Enterprise CIO | EAS | Middleware | Infrastructure Solutions 8080 Cobblestone Rd | Urbandale, IA 50322 MAC: F4469-010 Tel 515-988-2508 | Cell 515-988-2508 jonmcalexan...@wellsfargo.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > -Original Message- > From: Christopher Schultz > Sent: Tuesday, December 6, 2022 3:01 PM > To: users@tomcat.apache.org > Subject: Re: Mod_JK vs Mod_Proxy > > Jon, > > On 12/6/22 12:36, jonmcalexan...@wellsfargo.com.INVALID wrote: > > IMHO, switching to mod_proxy, and using it over SSL, is by far better than > using mod_jk or mod_ajp, primarily as mod_proxy allows for secure proxy > connection, whereas mod_jk and mod_ajp aren't "secure" as they are not > encrypted channels. > > While this is true (and supports my assertion that everyone should migrate), > it doesn't preclude the use of encrypted AJP connections. > > -chris > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Mod_JK vs Mod_Proxy
Jon, On 12/6/22 12:36, jonmcalexan...@wellsfargo.com.INVALID wrote: IMHO, switching to mod_proxy, and using it over SSL, is by far better than using mod_jk or mod_ajp, primarily as mod_proxy allows for secure proxy connection, whereas mod_jk and mod_ajp aren't "secure" as they are not encrypted channels. While this is true (and supports my assertion that everyone should migrate), it doesn't preclude the use of encrypted AJP connections. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Mod_JK vs Mod_Proxy
IMHO, switching to mod_proxy, and using it over SSL, is by far better than using mod_jk or mod_ajp, primarily as mod_proxy allows for secure proxy connection, whereas mod_jk and mod_ajp aren't "secure" as they are not encrypted channels. Again, just my .02 worth. Dream * Excel * Explore * Inspire Jon McAlexander Senior Infrastructure Engineer Asst. Vice President He/His Middleware Product Engineering Enterprise CIO | EAS | Middleware | Infrastructure Solutions 8080 Cobblestone Rd | Urbandale, IA 50322 MAC: F4469-010 Tel 515-988-2508 | Cell 515-988-2508 jonmcalexan...@wellsfargo.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > -Original Message- > From: Christopher Schultz > Sent: Tuesday, December 6, 2022 11:21 AM > To: Tomcat Users List ; Mark H. Wood > > Subject: Re: Mod_JK vs Mod_Proxy > > Mark, > > On 12/6/22 08:48, Mark H. Wood wrote: > > On Mon, Dec 05, 2022 at 03:37:59PM -0500, Christopher Schultz wrote: > >> On 12/5/22 15:03, Cathy Spears wrote: > >>> Using Tomcat 8.5 and 9.0 with 32-bit Apache 2.4 and mod_jk. Are > >>> there benefits to using mod_proxy instead of mod_jk? Also, is there > >>> a planned end of life for mod_jk or will it continue to be supported > >>> for now? > >> Hopefully this will be helpful: > >> > >> > https://urldefense.com/v3/__https://tomcat.apache.org/presentations.h > >> tml*latest-migrate-ajp-http__;Iw!!F9svGWnIaVPGSwU!pPfhr06Y5US- > 4xynUlu > >> > 8MkDyH2IZQTGO7ONWfErKJXwgn3RbLTJLgtoDj19eKsXfa65gU91ozXFiavI > nikky > >> ekiHowkw$ > > > > I read this as a question about mod_proxy_ajp vs. mod_jk. > > I think I make the case that mod_proxy_ajp is a (slightly) better choice than > mod_jk in that presentation. > > > Happily using mod_proxy_ajp here for some years. Both work well but I > > very much prefer the way mod_proxy_ajp integrates with the proxy > > configuration in HTTPD. > > +1 > > And it doesn't require a custom-built add-on. > > -chris > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Mod_JK vs Mod_Proxy
Mark, On 12/6/22 08:48, Mark H. Wood wrote: On Mon, Dec 05, 2022 at 03:37:59PM -0500, Christopher Schultz wrote: On 12/5/22 15:03, Cathy Spears wrote: Using Tomcat 8.5 and 9.0 with 32-bit Apache 2.4 and mod_jk. Are there benefits to using mod_proxy instead of mod_jk? Also, is there a planned end of life for mod_jk or will it continue to be supported for now? Hopefully this will be helpful: https://tomcat.apache.org/presentations.html#latest-migrate-ajp-http I read this as a question about mod_proxy_ajp vs. mod_jk. I think I make the case that mod_proxy_ajp is a (slightly) better choice than mod_jk in that presentation. Happily using mod_proxy_ajp here for some years. Both work well but I very much prefer the way mod_proxy_ajp integrates with the proxy configuration in HTTPD. +1 And it doesn't require a custom-built add-on. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Mod_JK vs Mod_Proxy
On Mon, Dec 05, 2022 at 03:37:59PM -0500, Christopher Schultz wrote: > On 12/5/22 15:03, Cathy Spears wrote: > > Using Tomcat 8.5 and 9.0 with 32-bit Apache 2.4 and mod_jk. Are there > > benefits to using mod_proxy instead of mod_jk? Also, is there a > > planned end of life for mod_jk or will it continue to be supported > > for now? > Hopefully this will be helpful: > > https://tomcat.apache.org/presentations.html#latest-migrate-ajp-http I read this as a question about mod_proxy_ajp vs. mod_jk. Happily using mod_proxy_ajp here for some years. Both work well but I very much prefer the way mod_proxy_ajp integrates with the proxy configuration in HTTPD. -- Mark H. Wood Lead Technology Analyst University Library Indiana University - Purdue University Indianapolis 755 W. Michigan Street Indianapolis, IN 46202 317-274-0749 www.ulib.iupui.edu signature.asc Description: PGP signature
Re: Mod_JK vs Mod_Proxy
Cathy, On 12/5/22 15:03, Cathy Spears wrote: Using Tomcat 8.5 and 9.0 with 32-bit Apache 2.4 and mod_jk. Are there benefits to using mod_proxy instead of mod_jk? Also, is there a planned end of life for mod_jk or will it continue to be supported for now? Hopefully this will be helpful: https://tomcat.apache.org/presentations.html#latest-migrate-ajp-http -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Mod_JK vs Mod_Proxy
Using Tomcat 8.5 and 9.0 with 32-bit Apache 2.4 and mod_jk. Are there benefits to using mod_proxy instead of mod_jk? Also, is there a planned end of life for mod_jk or will it continue to be supported for now? Thanks, Cathy DISCLAIMER: The information transmitted in this e-mail message and attachments, if any, may be attorney-client information, including privileged and confidential matter, and is intended only for the use of the individual or entity named above. Distribution to, or review by, unauthorized persons is strictly prohibited. All personal messages express views solely of the sender, which are not to be attributed to any organization. If you have received this transmission in error, immediately notify the sender and permanently delete this transmission including attachments.
RE: [External] Re: Looking for Mod_JK compiled for Windows
Thanks Mark! Was looking on VS17 tab. All good. From: Mark Thomas Sent: Monday, December 5, 2022 6:10 AM To: users@tomcat.apache.org Subject: [External] Re: Looking for Mod_JK compiled for Windows CAUTION: This email originated from an external system. Do not click links, open attachments or forward unless you recognize the sender and know the content is safe. On 05/12/2022 13:46, Cathy Spears wrote: > Hello all - I am looking for the latest version of mod_jk for Windows. At one > time I was able to find it on Apache Lounge but no longer. Please advise. They are still there: https://www.apachelounge.com/download/VS16/<https://www.apachelounge.com/download/VS16> Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org<mailto:users-unsubscr...@tomcat.apache.org> For additional commands, e-mail: users-h...@tomcat.apache.org<mailto:users-h...@tomcat.apache.org> DISCLAIMER: The information transmitted in this e-mail message and attachments, if any, may be attorney-client information, including privileged and confidential matter, and is intended only for the use of the individual or entity named above. Distribution to, or review by, unauthorized persons is strictly prohibited. All personal messages express views solely of the sender, which are not to be attributed to any organization. If you have received this transmission in error, immediately notify the sender and permanently delete this transmission including attachments.
Re: Looking for Mod_JK compiled for Windows
On 05/12/2022 13:46, Cathy Spears wrote: Hello all - I am looking for the latest version of mod_jk for Windows. At one time I was able to find it on Apache Lounge but no longer. Please advise. They are still there: https://www.apachelounge.com/download/VS16/ Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Looking for Mod_JK compiled for Windows
Hello all - I am looking for the latest version of mod_jk for Windows. At one time I was able to find it on Apache Lounge but no longer. Please advise. Thanks, Cathy DISCLAIMER: The information transmitted in this e-mail message and attachments, if any, may be attorney-client information, including privileged and confidential matter, and is intended only for the use of the individual or entity named above. Distribution to, or review by, unauthorized persons is strictly prohibited. All personal messages express views solely of the sender, which are not to be attributed to any organization. If you have received this transmission in error, immediately notify the sender and permanently delete this transmission including attachments.
Re: What causes "client errors" with mod_jk
Hi Chris, Am 27.05.2022 um 01:49 schrieb Christopher Schultz: On 5/26/22 17:25, Rainer Jung wrote: Am 26.05.2022 um 21:49 schrieb Christopher Schultz: Would you prefer to use mod_unique_id + unique-id-logging in mod_jk over just adding more request-level information to the mod_jk.log? I'm kind of okay either way, but for my current purposes it seems more convenient to have all relevant information in a single place (the mod_jk.log file). I understand, but more useful info might pile up (URI, client IP), so I prefer having a working correlation ID to the other major sources of info, Apache access log and Apache error log. Also: the current idea of mod_jk when a request starts is not exactly when it started in Apache, but when the JK service method started. So we would also need to add the web server start time. For now I used the request id and switched a lot (!) of log calls to using the new jk_request_log instead of jk_log. So you get the id in the next release for many of the lines mod_jk is able to log in a request context. Some very low level log lines will not have access to the request id, but on ase of error they should always be accompanied by a higher level logging of the error including the request id. We'll see how it goes. Feel free to try it, I committed everything to the git repos. I'm okay adding either or both of these "features" to the JK portion of the code. If we are considering "enhancing" this kind of logging in the JK portion, I would recommend that we add request_start_time to the jk_ws_service; I don't see a good way to determine the nature of the host web server from within the JK code and it's better-done from the outside-in rather than the inside-out. Unrelated: I believe the segfaults I'm seeing have to do with me simply updating the .so file on the disk before restarting the httpd process. As soon as I copy the .so file over the existing module binary, I start getting a string of segfaults in the log file. When I don't try to "hot-update" the module binary, I don't see any of that happening. (I also don't see any possible segfaults in my code at this point, eitaher.) I have httpd set up to dump cores but I think my file permissions are wrong so I'm not actually getting anything in there (yet). Best regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: What causes "client errors" with mod_jk
Rainer,
On 5/26/22 17:25, Rainer Jung wrote:
Hi Chris,
Am 26.05.2022 um 21:49 schrieb Christopher Schultz:
On 5/16/22 13:48, Christopher Schultz wrote:
I see the place in the code where the error is generated, but I'm not
familiar enough with the code to know how to add that kind of thing.
The function in question (ajp_process_callback) has a pointer to a
jk_ws_service_t structure. Is it as simple as also logging like this?
/* convert start-time to a string */
char[32] timestamp;
apr_strftime(timestamp, NULL, 32, "%Y-%m-%d %H:%M:%S",
r->r->request_time);
/* emit a detailed log message */
jk_log(l, JK_LOG_INFO,
"(%s) Request to (%s %s) started at %s,%ld",
ae->worker->name, r->method, r->req_uri, timestamp,
r->r->request_time.tm_usec);
Does anyone think this might be generally useful?
It looks like I needed a few more things in order to get this to work:
{
char *timestamp = malloc(32);
apr_time_exp_t *timerec = malloc(sizeof(apr_time_exp_t));
apache_private_data_t *ap = (apache_private_data_t*)r->ws_private;
apr_time_exp_gmt(timerec, ap->r->request_time);
apr_strftime(timestamp, NULL, 32, "%Y-%m-%d %H:%M:%S", timerec);
/* emit a detailed log message */
jk_log(l, JK_LOG_INFO,
"(%s) Request to (%s %s) started at %s",
ae->worker->name, r->method, r->req_uri, timestamp);
free(timerec);
free(timestamp);
}
The compiler wouldn't let me use an automatically-allocated char[32]
so I had to malloc it. I also had to convert from long to
apr_time_exp_t which required another structure/malloc as well.
Finally, I had to cast the r->ws_private to apache_private_data_t*
which required me to copy/paste the definition of
apache_private_data_t from mod_jk.h into jk_ajp_common.c -- just as a
test for now.
Obviously, this works only for Apache httpd.
I have it running on one of my web servers for now -- hoping to catch
an error and see this additional logging to see if it's helpful to me.
(LOL just segfaulted; time to go back and look.)
What would be the best way to get the "start time" of the request in a
platform-independent way? Maybe just expand the jk_ws_service
structure to include it?
Apart from the info chuck send via PM, I think it would be better to try
to add a unique request ID as a correlation ID. Apache can already
generate them using mod_unique_id and you can add them there to the
access log.
Would you prefer to use mod_unique_id + unique-id-logging in mod_jk over
just adding more request-level information to the mod_jk.log? I'm kind
of okay either way, but for my current purposes it seems more convenient
to have all relevant information in a single place (the mod_jk.log file).
Now how could we make that ID accessible from mod_jk?
We could either add it as a new item to jk_ws_service and I think it
would be a good fit. Any server not yet providing it, eg. if we find no
way adding it in IIS, would have a null value there (or some constant we
init it to). We are free to add things, because we do not really provide
a public API used elsewhere which we need to keep stable.
When we do logging in mod_jk, we use jk_log(jk_logger_t *l, ...) where
the remaining arguments are just standard log arguments. We could add a
new jk_request_log(jk_logger_t *l, jk_ws_service_t *s, ...) and that
function retrieves the request ID from s and adds it to the log line.
It seems, typically where we want to log something that would benefit
from a request ID, we have the jk_ws_service_t at hand, so could add it
to the log call.
WDYT?
I'm okay adding either or both of these "features" to the JK portion of
the code. If we are considering "enhancing" this kind of logging in the
JK portion, I would recommend that we add request_start_time to the
jk_ws_service; I don't see a good way to determine the nature of the
host web server from within the JK code and it's better-done from the
outside-in rather than the inside-out.
Unrelated: I believe the segfaults I'm seeing have to do with me simply
updating the .so file on the disk before restarting the httpd process.
As soon as I copy the .so file over the existing module binary, I start
getting a string of segfaults in the log file. When I don't try to
"hot-update" the module binary, I don't see any of that happening. (I
also don't see any possible segfaults in my code at this point, either.)
I have httpd set up to dump cores but I think my file permissions are
wrong so I'm not actually getting anything in there (yet).
-chris
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: What causes "client errors" with mod_jk
Hi Chris,
Am 26.05.2022 um 21:49 schrieb Christopher Schultz:
On 5/16/22 13:48, Christopher Schultz wrote:
I see the place in the code where the error is generated, but I'm not
familiar enough with the code to know how to add that kind of thing.
The function in question (ajp_process_callback) has a pointer to a
jk_ws_service_t structure. Is it as simple as also logging like this?
/* convert start-time to a string */
char[32] timestamp;
apr_strftime(timestamp, NULL, 32, "%Y-%m-%d %H:%M:%S",
r->r->request_time);
/* emit a detailed log message */
jk_log(l, JK_LOG_INFO,
"(%s) Request to (%s %s) started at %s,%ld",
ae->worker->name, r->method, r->req_uri, timestamp,
r->r->request_time.tm_usec);
Does anyone think this might be generally useful?
It looks like I needed a few more things in order to get this to work:
{
char *timestamp = malloc(32);
apr_time_exp_t *timerec = malloc(sizeof(apr_time_exp_t));
apache_private_data_t *ap = (apache_private_data_t*)r->ws_private;
apr_time_exp_gmt(timerec, ap->r->request_time);
apr_strftime(timestamp, NULL, 32, "%Y-%m-%d %H:%M:%S", timerec);
/* emit a detailed log message */
jk_log(l, JK_LOG_INFO,
"(%s) Request to (%s %s) started at %s",
ae->worker->name, r->method, r->req_uri, timestamp);
free(timerec);
free(timestamp);
}
The compiler wouldn't let me use an automatically-allocated char[32] so
I had to malloc it. I also had to convert from long to apr_time_exp_t
which required another structure/malloc as well.
Finally, I had to cast the r->ws_private to apache_private_data_t* which
required me to copy/paste the definition of apache_private_data_t from
mod_jk.h into jk_ajp_common.c -- just as a test for now.
Obviously, this works only for Apache httpd.
I have it running on one of my web servers for now -- hoping to catch an
error and see this additional logging to see if it's helpful to me. (LOL
just segfaulted; time to go back and look.)
What would be the best way to get the "start time" of the request in a
platform-independent way? Maybe just expand the jk_ws_service structure
to include it?
Apart from the info chuck send via PM, I think it would be better to try
to add a unique request ID as a correlation ID. Apache can already
generate them using mod_unique_id and you can add them there to the
access log.
Now how could we make that ID accessible from mod_jk?
We could either add it as a new item to jk_ws_service and I think it
would be a good fit. Any server not yet providing it, eg. if we find no
way adding it in IIS, would have a null value there (or some constant we
init it to). We are free to add things, because we do not really provide
a public API used elsewhere which we need to keep stable.
When we do logging in mod_jk, we use jk_log(jk_logger_t *l, ...) where
the remaining arguments are just standard log arguments. We could add a
new jk_request_log(jk_logger_t *l, jk_ws_service_t *s, ...) and that
function retrieves the request ID from s and adds it to the log line.
It seems, typically where we want to log something that would benefit
from a request ID, we have the jk_ws_service_t at hand, so could add it
to the log call.
WDYT?
Best regards,
Rainer
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: What causes "client errors" with mod_jk
Rainer,
On 5/26/22 16:46, Rainer Jung wrote:
Hi Chris,
Am 16.05.2022 um 19:48 schrieb Christopher Schultz:
I've been looking into this a little more in my production environment.
These errors are not super common, but there seems to be a steady
trickle of errors from my two services that have human users. I see 0
errors for my API-based services, which makes me think that I don't
have any performance issues... I probably have human users
disappearing for random reasons.
Could be unstable (mobile) client connections. Or people already
clicking on the next frontend action before they received the complete
response. But that is speculating. So it is right, you try to identify
some individual reasons to understand more.
The errors in mod_jk.log look like this:
[Sun May 15 04:19:15.643 2022] [5859:139625025315392] [info]
ajp_process_callback::jk_ajp_common.c (2077): (myworker) Writing to
client aborted or client network problems
[Sun May 15 04:19:15.644 2022] [5859:139625025315392] [info]
ajp_service::jk_ajp_common.c (2773): (myworker) sending request to
tomcat failed (unrecoverable), because of client write error (attempt=1)
[Sun May 15 04:19:15.646 2022] [5859:139625025315392] [info]
service::jk_lb_worker.c (1595): service failed, worker myworker is in
local error state
[Sun May 15 04:19:15.646 2022] [5859:139625025315392] [info]
service::jk_lb_worker.c (1614): unrecoverable error 200, request
failed. Client failed in the middle of request, we can't recover to
another instance.
[Sun May 15 04:19:15.646 2022] [5859:139625025315392] [info]
jk_handler::mod_jk.c (2984): Aborting connection for worker=myworker
(Note that the last message "Aborting connection for worker=myworker"
may have a bug; my actual worker name has a name containing a hyphen
(-) and only the text before the hyphen is being emitted in that error
message.)
Strange, never observed that, but maybe never used a hyphen. Docs say,
hypens are allowed. Would be interesting to do a server startup with
trace-Logging and see where things corresponding to the name start to go
wrong. But of course not related to sporadic client failures.
Right. I may investigate that separately, as I have a setup already with
everything in place.
Anyway, when researching these errors, it would be helpful to me to
know which requests are failing. By looking at the access_log, I only
see a single request logged for 04:19:15 on that server so it's
probably the right one, but httpd says that the response code is 302
instead of e.g. 50x for an error.
What I typically do:
- log "%P:%{tid}P" in your Apache httpd custom LogFormat used for the
access log.
- make sure, I log in in the Apache httpd access log the request
timestamp including milli or microseconds (not default but
configurable). Can be done by using the %{format}t syntax in the
LogFormat and adding "usec_frac" to the format.
- adding %D to the access log format (duration in microseconds)
- remember that Apache logs start of request as default time stamp, but
mod_jk logs at the moment of error, so later than start of request.
Finding the right access log line for a mod_jk error log line now means:
- filter the access log according to the PID:TID logged in the mod_jk
error log. In your case 5859:139625025315392. We know, that the requests
handled by one thread in one process are run strictly sequentially.
- look for the last request in this filtered list, that by access log
line timestamp started before (or unlikely exactly at) the point in time
given by the mod_jk access log. If you find one exactly add, it might be
also the one directly before.
- look at the request durations of these one or two requests to double
check, whether the times fit.
If you can spare the additional log line bytes, you can additionally log
the end of request timestamp in the apache access log (prefix "format"
by "begin:").
Especially by adding this "enhanced logging", it was very easy to find
the failing requests.
Fortunately for me, the JK log is "now" and the request_time is the
start-of-request, so I can see the delay between the two. In the cases
I've seen since I started watching the log, it's typically a very short
tie like 1-2 sec which shouldn't be something a user gets tired waiting for.
I was more worried like "mod_jk waited 35 seconds for a response from
upstream and the user went away" and that's not the case.
So I'm happy to find that the reason for these errors is pathological
user behavior and not some performance problem on my end.
Thanks,
-chris
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: What causes "client errors" with mod_jk
All,
On 5/26/22 15:49, Christopher Schultz wrote:
Rainer,
On 5/16/22 13:48, Christopher Schultz wrote:
Rainer,
I've been looking into this a little more in my production environment.
These errors are not super common, but there seems to be a steady
trickle of errors from my two services that have human users. I see 0
errors for my API-based services, which makes me think that I don't
have any performance issues... I probably have human users
disappearing for random reasons.
The errors in mod_jk.log look like this:
[Sun May 15 04:19:15.643 2022] [5859:139625025315392] [info]
ajp_process_callback::jk_ajp_common.c (2077): (myworker) Writing to
client aborted or client network problems
[Sun May 15 04:19:15.644 2022] [5859:139625025315392] [info]
ajp_service::jk_ajp_common.c (2773): (myworker) sending request to
tomcat failed (unrecoverable), because of client write error (attempt=1)
[Sun May 15 04:19:15.646 2022] [5859:139625025315392] [info]
service::jk_lb_worker.c (1595): service failed, worker myworker is in
local error state
[Sun May 15 04:19:15.646 2022] [5859:139625025315392] [info]
service::jk_lb_worker.c (1614): unrecoverable error 200, request
failed. Client failed in the middle of request, we can't recover to
another instance.
[Sun May 15 04:19:15.646 2022] [5859:139625025315392] [info]
jk_handler::mod_jk.c (2984): Aborting connection for worker=myworker
(Note that the last message "Aborting connection for worker=myworker"
may have a bug; my actual worker name has a name containing a hyphen
(-) and only the text before the hyphen is being emitted in that error
message.)
Anyway, when researching these errors, it would be helpful to me to
know which requests are failing. By looking at the access_log, I only
see a single request logged for 04:19:15 on that server so it's
probably the right one, but httpd says that the response code is 302
instead of e.g. 50x for an error.
When we log these kinds of errors, it would be great to know a few
things IMO:
1. What was the URL of the request
2. How long did the client wait for the response before we found we
couldn't write to the stream (or, conversely, the start-timestamp of
the request as well as the timestamp of the error, which I think is
already in the log itself)
I see the place in the code where the error is generated, but I'm not
familiar enough with the code to know how to add that kind of thing.
The function in question (ajp_process_callback) has a pointer to a
jk_ws_service_t structure. Is it as simple as also logging like this?
/* convert start-time to a string */
char[32] timestamp;
apr_strftime(timestamp, NULL, 32, "%Y-%m-%d %H:%M:%S",
r->r->request_time);
/* emit a detailed log message */
jk_log(l, JK_LOG_INFO,
"(%s) Request to (%s %s) started at %s,%ld",
ae->worker->name, r->method, r->req_uri, timestamp,
r->r->request_time.tm_usec);
Does anyone think this might be generally useful?
It looks like I needed a few more things in order to get this to work:
{
char *timestamp = malloc(32);
apr_time_exp_t *timerec = malloc(sizeof(apr_time_exp_t));
apache_private_data_t *ap = (apache_private_data_t*)r->ws_private;
apr_time_exp_gmt(timerec, ap->r->request_time);
apr_strftime(timestamp, NULL, 32, "%Y-%m-%d %H:%M:%S", timerec);
/* emit a detailed log message */
jk_log(l, JK_LOG_INFO,
"(%s) Request to (%s %s) started at %s",
ae->worker->name, r->method, r->req_uri, timestamp);
free(timerec);
free(timestamp);
}
The compiler wouldn't let me use an automatically-allocated char[32] so
I had to malloc it. I also had to convert from long to apr_time_exp_t
which required another structure/malloc as well.
Finally, I had to cast the r->ws_private to apache_private_data_t* which
required me to copy/paste the definition of apache_private_data_t from
mod_jk.h into jk_ajp_common.c -- just as a test for now.
Obviously, this works only for Apache httpd.
I have it running on one of my web servers for now -- hoping to catch an
error and see this additional logging to see if it's helpful to me. (LOL
just segfaulted; time to go back and look.)
What would be the best way to get the "start time" of the request in a
platform-independent way? Maybe just expand the jk_ws_service structure
to include it?
Here is my latest code which hasn't segfaulted in a while:
{
/* emit a detailed log message */
char timestamp[32]; // For formatted timestamp string
apr_time_exp_t timerec; // Required for apr_strftime
apr_size_t retsize; // Required for apr_strftime
apache_private_data_t *ap = (apache_private_data_t*)r->ws_private;
apr_time_exp_gmt(, ap->r->request_time); // Convert
request_time to apr_time_exp_t
apr_strftime(timestamp, , 32, "%Y-%m-%d %H:%M:%S", );
// Format the timestamp
if(0 == retsize) {
strcpy(timestamp, "(overflow)");
}
jk_log(l, JK_LOG_INFO,
Re: What causes "client errors" with mod_jk
Hi Chris,
Am 16.05.2022 um 19:48 schrieb Christopher Schultz:
I've been looking into this a little more in my production environment.
These errors are not super common, but there seems to be a steady
trickle of errors from my two services that have human users. I see 0
errors for my API-based services, which makes me think that I don't have
any performance issues... I probably have human users disappearing for
random reasons.
Could be unstable (mobile) client connections. Or people already
clicking on the next frontend action before they received the complete
response. But that is speculating. So it is right, you try to identify
some individual reasons to understand more.
The errors in mod_jk.log look like this:
[Sun May 15 04:19:15.643 2022] [5859:139625025315392] [info]
ajp_process_callback::jk_ajp_common.c (2077): (myworker) Writing to
client aborted or client network problems
[Sun May 15 04:19:15.644 2022] [5859:139625025315392] [info]
ajp_service::jk_ajp_common.c (2773): (myworker) sending request to
tomcat failed (unrecoverable), because of client write error (attempt=1)
[Sun May 15 04:19:15.646 2022] [5859:139625025315392] [info]
service::jk_lb_worker.c (1595): service failed, worker myworker is in
local error state
[Sun May 15 04:19:15.646 2022] [5859:139625025315392] [info]
service::jk_lb_worker.c (1614): unrecoverable error 200, request failed.
Client failed in the middle of request, we can't recover to another
instance.
[Sun May 15 04:19:15.646 2022] [5859:139625025315392] [info]
jk_handler::mod_jk.c (2984): Aborting connection for worker=myworker
(Note that the last message "Aborting connection for worker=myworker"
may have a bug; my actual worker name has a name containing a hyphen (-)
and only the text before the hyphen is being emitted in that error
message.)
Strange, never observed that, but maybe never used a hyphen. Docs say,
hypens are allowed. Would be interesting to do a server startup with
trace-Logging and see where things corresponding to the name start to go
wrong. But of course not related to sporadic client failures.
Anyway, when researching these errors, it would be helpful to me to know
which requests are failing. By looking at the access_log, I only see a
single request logged for 04:19:15 on that server so it's probably the
right one, but httpd says that the response code is 302 instead of e.g.
50x for an error.
What I typically do:
- log "%P:%{tid}P" in your Apache httpd custom LogFormat used for the
access log.
- make sure, I log in in the Apache httpd access log the request
timestamp including milli or microseconds (not default but
configurable). Can be done by using the %{format}t syntax in the
LogFormat and adding "usec_frac" to the format.
- adding %D to the access log format (duration in microseconds)
- remember that Apache logs start of request as default time stamp, but
mod_jk logs at the moment of error, so later than start of request.
Finding the right access log line for a mod_jk error log line now means:
- filter the access log according to the PID:TID logged in the mod_jk
error log. In your case 5859:139625025315392. We know, that the requests
handled by one thread in one process are run strictly sequentially.
- look for the last request in this filtered list, that by access log
line timestamp started before (or unlikely exactly at) the point in time
given by the mod_jk access log. If you find one exactly add, it might be
also the one directly before.
- look at the request durations of these one or two requests to double
check, whether the times fit.
If you can spare the additional log line bytes, you can additionally log
the end of request timestamp in the apache access log (prefix "format"
by "begin:").
When we log these kinds of errors, it would be great to know a few
things IMO:
1. What was the URL of the request
2. How long did the client wait for the response before we found we
couldn't write to the stream (or, conversely, the start-timestamp of the
request as well as the timestamp of the error, which I think is already
in the log itself)
I see the place in the code where the error is generated, but I'm not
familiar enough with the code to know how to add that kind of thing. The
function in question (ajp_process_callback) has a pointer to a
jk_ws_service_t structure. Is it as simple as also logging like this?
/* convert start-time to a string */
char[32] timestamp;
apr_strftime(timestamp, NULL, 32, "%Y-%m-%d %H:%M:%S",
r->r->request_time);
/* emit a detailed log message */
jk_log(l, JK_LOG_INFO,
"(%s) Request to (%s %s) started at %s,%ld",
ae->worker->name, r->method, r->req_uri, timestamp,
r->r->request_time.tm_usec);
Does anyone think this might be generally useful?
I'll have a look at your other mail on this next.
Best regards,
Ra
Re: What causes "client errors" with mod_jk
Rainer,
On 5/16/22 13:48, Christopher Schultz wrote:
Rainer,
I've been looking into this a little more in my production environment.
These errors are not super common, but there seems to be a steady
trickle of errors from my two services that have human users. I see 0
errors for my API-based services, which makes me think that I don't have
any performance issues... I probably have human users disappearing for
random reasons.
The errors in mod_jk.log look like this:
[Sun May 15 04:19:15.643 2022] [5859:139625025315392] [info]
ajp_process_callback::jk_ajp_common.c (2077): (myworker) Writing to
client aborted or client network problems
[Sun May 15 04:19:15.644 2022] [5859:139625025315392] [info]
ajp_service::jk_ajp_common.c (2773): (myworker) sending request to
tomcat failed (unrecoverable), because of client write error (attempt=1)
[Sun May 15 04:19:15.646 2022] [5859:139625025315392] [info]
service::jk_lb_worker.c (1595): service failed, worker myworker is in
local error state
[Sun May 15 04:19:15.646 2022] [5859:139625025315392] [info]
service::jk_lb_worker.c (1614): unrecoverable error 200, request failed.
Client failed in the middle of request, we can't recover to another
instance.
[Sun May 15 04:19:15.646 2022] [5859:139625025315392] [info]
jk_handler::mod_jk.c (2984): Aborting connection for worker=myworker
(Note that the last message "Aborting connection for worker=myworker"
may have a bug; my actual worker name has a name containing a hyphen (-)
and only the text before the hyphen is being emitted in that error
message.)
Anyway, when researching these errors, it would be helpful to me to know
which requests are failing. By looking at the access_log, I only see a
single request logged for 04:19:15 on that server so it's probably the
right one, but httpd says that the response code is 302 instead of e.g.
50x for an error.
When we log these kinds of errors, it would be great to know a few
things IMO:
1. What was the URL of the request
2. How long did the client wait for the response before we found we
couldn't write to the stream (or, conversely, the start-timestamp of the
request as well as the timestamp of the error, which I think is already
in the log itself)
I see the place in the code where the error is generated, but I'm not
familiar enough with the code to know how to add that kind of thing. The
function in question (ajp_process_callback) has a pointer to a
jk_ws_service_t structure. Is it as simple as also logging like this?
/* convert start-time to a string */
char[32] timestamp;
apr_strftime(timestamp, NULL, 32, "%Y-%m-%d %H:%M:%S",
r->r->request_time);
/* emit a detailed log message */
jk_log(l, JK_LOG_INFO,
"(%s) Request to (%s %s) started at %s,%ld",
ae->worker->name, r->method, r->req_uri, timestamp,
r->r->request_time.tm_usec);
Does anyone think this might be generally useful?
It looks like I needed a few more things in order to get this to work:
{
char *timestamp = malloc(32);
apr_time_exp_t *timerec = malloc(sizeof(apr_time_exp_t));
apache_private_data_t *ap = (apache_private_data_t*)r->ws_private;
apr_time_exp_gmt(timerec, ap->r->request_time);
apr_strftime(timestamp, NULL, 32, "%Y-%m-%d %H:%M:%S", timerec);
/* emit a detailed log message */
jk_log(l, JK_LOG_INFO,
"(%s) Request to (%s %s) started at %s",
ae->worker->name, r->method, r->req_uri, timestamp);
free(timerec);
free(timestamp);
}
The compiler wouldn't let me use an automatically-allocated char[32] so
I had to malloc it. I also had to convert from long to apr_time_exp_t
which required another structure/malloc as well.
Finally, I had to cast the r->ws_private to apache_private_data_t* which
required me to copy/paste the definition of apache_private_data_t from
mod_jk.h into jk_ajp_common.c -- just as a test for now.
Obviously, this works only for Apache httpd.
I have it running on one of my web servers for now -- hoping to catch an
error and see this additional logging to see if it's helpful to me. (LOL
just segfaulted; time to go back and look.)
What would be the best way to get the "start time" of the request in a
platform-independent way? Maybe just expand the jk_ws_service structure
to include it?
-chris
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: What causes "client errors" with mod_jk
Rainer, I've been looking into this a little more in my production environment. These errors are not super common, but there seems to be a steady trickle of errors from my two services that have human users. I see 0 errors for my API-based services, which makes me think that I don't have any performance issues... I probably have human users disappearing for random reasons. The errors in mod_jk.log look like this: [Sun May 15 04:19:15.643 2022] [5859:139625025315392] [info] ajp_process_callback::jk_ajp_common.c (2077): (myworker) Writing to client aborted or client network problems [Sun May 15 04:19:15.644 2022] [5859:139625025315392] [info] ajp_service::jk_ajp_common.c (2773): (myworker) sending request to tomcat failed (unrecoverable), because of client write error (attempt=1) [Sun May 15 04:19:15.646 2022] [5859:139625025315392] [info] service::jk_lb_worker.c (1595): service failed, worker myworker is in local error state [Sun May 15 04:19:15.646 2022] [5859:139625025315392] [info] service::jk_lb_worker.c (1614): unrecoverable error 200, request failed. Client failed in the middle of request, we can't recover to another instance. [Sun May 15 04:19:15.646 2022] [5859:139625025315392] [info] jk_handler::mod_jk.c (2984): Aborting connection for worker=myworker (Note that the last message "Aborting connection for worker=myworker" may have a bug; my actual worker name has a name containing a hyphen (-) and only the text before the hyphen is being emitted in that error message.) Anyway, when researching these errors, it would be helpful to me to know which requests are failing. By looking at the access_log, I only see a single request logged for 04:19:15 on that server so it's probably the right one, but httpd says that the response code is 302 instead of e.g. 50x for an error. When we log these kinds of errors, it would be great to know a few things IMO: 1. What was the URL of the request 2. How long did the client wait for the response before we found we couldn't write to the stream (or, conversely, the start-timestamp of the request as well as the timestamp of the error, which I think is already in the log itself) I see the place in the code where the error is generated, but I'm not familiar enough with the code to know how to add that kind of thing. The function in question (ajp_process_callback) has a pointer to a jk_ws_service_t structure. Is it as simple as also logging like this? /* convert start-time to a string */ char[32] timestamp; apr_strftime(timestamp, NULL, 32, "%Y-%m-%d %H:%M:%S", r->r->request_time); /* emit a detailed log message */ jk_log(l, JK_LOG_INFO, "(%s) Request to (%s %s) started at %s,%ld", ae->worker->name, r->method, r->req_uri, timestamp, r->r->request_time.tm_usec); Does anyone think this might be generally useful? Thanks, -chris On 3/25/22 08:37, Christopher Schultz wrote: Rainer, On 3/24/22 05:50, Rainer Jung wrote: Hi Chris, client errors in jk log are always errors occurring when mod_jk tries to write back what it got from the backend using web server APIs to the client of the web server (user, browser etc.). So they point to a problem between and including the web server and something in front of it. Especially during performance problems, client errors are expected as a consequence, because whenever people try to reload, the browser closes the original connection and sending back response data via this connection later fails. I was pretty sure this was the case. Is that specifically documented anywhere? If not, I'd like to clarify that in the documentation for mod_jk. Thanks, -chris Am 23.03.2022 um 13:08 schrieb Christopher Schultz: All, What kinds of things will cause a "client error" in mod_jk's accounting? Does that mean things like unexpected disconnects on the part of the remote client (i.e. web browser), or does it mean failure of the jk module itself to connect (as a client) to the back-end Tomcat? I'm starting to see situations where we have small numbers of client errors occurring "all the time", meaning that we accumulate maybe 10-20 per day. If that's web browser disconnects then I don't care at all. If it's a problem I have with my internal networking and resource-allocation, then it's something I have to adjust. Thanks, -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: What causes "client errors" with mod_jk
Rainer, On 3/24/22 05:50, Rainer Jung wrote: Hi Chris, client errors in jk log are always errors occurring when mod_jk tries to write back what it got from the backend using web server APIs to the client of the web server (user, browser etc.). So they point to a problem between and including the web server and something in front of it. Especially during performance problems, client errors are expected as a consequence, because whenever people try to reload, the browser closes the original connection and sending back response data via this connection later fails. I was pretty sure this was the case. Is that specifically documented anywhere? If not, I'd like to clarify that in the documentation for mod_jk. Thanks, -chris Am 23.03.2022 um 13:08 schrieb Christopher Schultz: All, What kinds of things will cause a "client error" in mod_jk's accounting? Does that mean things like unexpected disconnects on the part of the remote client (i.e. web browser), or does it mean failure of the jk module itself to connect (as a client) to the back-end Tomcat? I'm starting to see situations where we have small numbers of client errors occurring "all the time", meaning that we accumulate maybe 10-20 per day. If that's web browser disconnects then I don't care at all. If it's a problem I have with my internal networking and resource-allocation, then it's something I have to adjust. Thanks, -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: What causes "client errors" with mod_jk
Hi Chris, client errors in jk log are always errors occurring when mod_jk tries to write back what it got from the backend using web server APIs to the client of the web server (user, browser etc.). So they point to a problem between and including the web server and something in front of it. Especially during performance problems, client errors are expected as a consequence, because whenever people try to reload, the browser closes the original connection and sending back response data via this connection later fails. Best regards, Rainer Am 23.03.2022 um 13:08 schrieb Christopher Schultz: All, What kinds of things will cause a "client error" in mod_jk's accounting? Does that mean things like unexpected disconnects on the part of the remote client (i.e. web browser), or does it mean failure of the jk module itself to connect (as a client) to the back-end Tomcat? I'm starting to see situations where we have small numbers of client errors occurring "all the time", meaning that we accumulate maybe 10-20 per day. If that's web browser disconnects then I don't care at all. If it's a problem I have with my internal networking and resource-allocation, then it's something I have to adjust. Thanks, -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: What causes "client errors" with mod_jk
All, On 3/23/22 08:08, Christopher Schultz wrote: What kinds of things will cause a "client error" in mod_jk's accounting? Does that mean things like unexpected disconnects on the part of the remote client (i.e. web browser), or does it mean failure of the jk module itself to connect (as a client) to the back-end Tomcat? I'm starting to see situations where we have small numbers of client errors occurring "all the time", meaning that we accumulate maybe 10-20 per day. If that's web browser disconnects then I don't care at all. If it's a problem I have with my internal networking and resource-allocation, then it's something I have to adjust. I have items such as these in the mod_jk.log file: [Wed Mar 23 12:07:36.192 2022] [22062:140330401956416] [info] ajp_process_callback::jk_ajp_common.c (2077): (myworker) Writing to client aborted or client network problems [Wed Mar 23 12:07:36.192 2022] [22062:140330401956416] [info] ajp_service::jk_ajp_common.c (2773): (myworker) sending request to tomcat failed (unrecoverable), because of client write error (attempt=1) [Wed Mar 23 12:07:36.194 2022] [22062:140330401956416] [info] service::jk_lb_worker.c (1595): service failed, worker myworker is in local error state [Wed Mar 23 12:07:36.194 2022] [22062:140330401956416] [info] service::jk_lb_worker.c (1614): unrecoverable error 200, request failed. Client failed in the middle of request, we can't recover to another instance. [Wed Mar 23 12:07:36.194 2022] [22062:140330401956416] [info] jk_handler::mod_jk.c (2984): Aborting connection for worker=myworker Those messages are somewhat confusing because some of them seem to indicate that the remote client (i.e. web browser) is gone, but then I see "worker myworker is in local error state" which looks like mod_jk is considering this *worker* to be in an error-state, meaning that it would direct traffic to another worker. I'm not seeing the worker being put into an ERR state. Is that log message just misleading? Thanks, -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
What causes "client errors" with mod_jk
All, What kinds of things will cause a "client error" in mod_jk's accounting? Does that mean things like unexpected disconnects on the part of the remote client (i.e. web browser), or does it mean failure of the jk module itself to connect (as a client) to the back-end Tomcat? I'm starting to see situations where we have small numbers of client errors occurring "all the time", meaning that we accumulate maybe 10-20 per day. If that's web browser disconnects then I don't care at all. If it's a problem I have with my internal networking and resource-allocation, then it's something I have to adjust. Thanks, -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: mod_jk interference with ErrorDocument/Alias on HEAD request
Hi, i created a bugzilla entry (https://bz.apache.org/bugzilla/show_bug.cgi?id=65901) and included a first attempt to patch this issue. Am 12.02.2022 um 14:24 schrieb Stefan Mayr: Hello Tomcat users, this week we were debugging a strange connection issue which I tracked down to an interference between Apache httpd and mod_jk. For the full picture, the infrastructure setup contains 1. a Loadbalancer providing HTTPS, HTTP/1.1 and HTTP/2 for Clients. 2. an Apache httpd 2.4 webserver (HTTP only) with mod_jk 3. a Tomcat mit AJP-Connector We have an application doing many different HEAD requests against an application running in the Tomcat server. The requests contain an Authorization header for Basic authentication. Expected response is a HTTP 200 OK or HTTP 401 if this particular user is not allowed to access that ressource. Because this is a HEAD request there must not be a response body according to RFC 2616. If there is a response body in the response to the HEAD request our loadbalancer does strange things: aborts the connection if the clients uses HTTP/2, SSL errors if using HTTP/1.1. But this is an issue on its own which we might have to solve with the vendor. Now comes the point where I need your help. We have a httpd configuration with mod_jk which generates these invalid response bodies on HEAD requests. I have a gut feeling this could be a bug with mod_jk. For demonstration purpose i created a minimal demo app which only is a WEB-INF/web.xml https://jakarta.ee/xml/ns/jakartaee; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation="https://jakarta.ee/xml/ns/jakartaee https://jakarta.ee/xml/ns/jakartaee/web-app_5_0.xsd; version="5.0"> Login /* manager manager BASIC Then I place a JkMount in my Apache httpd configuration (+ minimal worker.properties): JkMount /demo/* ajp13_worker Testing this with curl works like expected: root@1ae8973f1b6b:~# curl -I -v localhost/demo/ * Trying 127.0.0.1:80... * TCP_NODELAY set * Connected to localhost (127.0.0.1) port 80 (#0) > HEAD /demo/ HTTP/1.1 > Host: localhost > User-Agent: curl/7.68.0 > Accept: */* > * Mark bundle as not supporting multiuse < HTTP/1.1 401 401 HTTP/1.1 401 401 < Date: Sat, 12 Feb 2022 12:57:33 GMT Date: Sat, 12 Feb 2022 12:57:33 GMT < Server: Apache/2.4.41 (Ubuntu) Server: Apache/2.4.41 (Ubuntu) < Cache-Control: private Cache-Control: private < WWW-Authenticate: Basic realm="Authentication required" WWW-Authenticate: Basic realm="Authentication required" < Content-Language: en Content-Language: en < Content-Type: text/html;charset=utf-8 Content-Type: text/html;charset=utf-8 < * Connection #0 to host localhost left intact But our default setup always includes custom error pages: Alias /error/ "/usr/share/apache2/error/" ErrorDocument 401 /error/HTTP_UNAUTHORIZED.html.var If both of those lines are added this results in a response body for the HEAD request. root@1ae8973f1b6b:~# curl -I -v localhost/demo/ * Trying 127.0.0.1:80... * TCP_NODELAY set * Connected to localhost (127.0.0.1) port 80 (#0) > HEAD /demo/ HTTP/1.1 > Host: localhost > User-Agent: curl/7.68.0 > Accept: */* > * Mark bundle as not supporting multiuse < HTTP/1.1 401 401 HTTP/1.1 401 401 < Date: Sat, 12 Feb 2022 12:56:27 GMT Date: Sat, 12 Feb 2022 12:56:27 GMT < Server: Apache/2.4.41 (Ubuntu) Server: Apache/2.4.41 (Ubuntu) < Cache-Control: private Cache-Control: private < WWW-Authenticate: Basic realm="Authentication required" WWW-Authenticate: Basic realm="Authentication required" < Content-Language: en Content-Language: en < Content-Type: text/html;charset=utf-8 Content-Type: text/html;charset=utf-8 < * Excess found: excess = 589 url = /demo/ (zero-length body) * Connection #0 to host localhost left intact Checking with tcpdump on port 8009 we see the expected response without a body from the Tomcat AJP connector. The tcpdump von port 80 reveals httpd is adding the configured ErrorDocument as response body. If we comment out either the Alias or ErrorDocument directive the response is correct again. Doing similar tests with CGI/PHP applications always show the correct response without a response body. This only affects requests which use mod_jk. So far I could reproduce this on SLES12 SP5 and SLES15 SP3 running Apache httpd 2.4.51 and a self compile mod_jk 1.2.46 (same with the included mod_jk 1.2.43) at work. At home the same happens on a stock openSUSE Leap 15.3 with Apache httpd 2.4.51 and mod_jk 1.2.43 as well as on Ubuntu 20.04 with httpd 2.4.41 and mod_jk 1.2.
AW: mod_jk interference with ErrorDocument/Alias on HEAD request
Hello Stefan,
the debug output of mod_jk shows at least which route the request is going:
[info] jk_handler::mod_jk.c (2968): No body with status=401 for
worker=ajp13_worker
So it looks like that the code
https://github.com/apache/tomcat-connectors/blob/main/native/apache-2.0/mod_jk.c#L2954#L2973
Returns 401 to the caller.
Apache sets the flag header_only when receiving a HEAD-Request. This flag can
also be seen in the mod_jk sources.
The "Excess" error is produces by curl:
https://fossies.org/linux/curl/lib/transfer.c
Dunno if this info helps much.
Greetings, Thomas
-Ursprüngliche Nachricht-
Von: Stefan Mayr
Gesendet: Dienstag, 15. Februar 2022 14:26
An: users@tomcat.apache.org
Betreff: Re: mod_jk interference with ErrorDocument/Alias on HEAD request
Hello Thomas,
Am 15.02.2022 um 11:38 schrieb Thomas Hoffmann (Speed4Trade GmbH):
> Hello Stefan,
>
> by spec / RFC, a HEAD request is not allowed to return any body.
>
> Greetings,
> Thomas
This is true and that is why i'm writing to this list. In the described case
mod_jk returns a response body although it should not (at least i think mod_jk
is somehow responsible for that)
> -Ursprüngliche Nachricht-
> Von: Stefan Mayr
> Gesendet: Montag, 14. Februar 2022 23:07
> An: users@tomcat.apache.org
> Betreff: Re: mod_jk interference with ErrorDocument/Alias on HEAD
> request
>
> Hello again,
>
> a self-compiled mod_jk 1.2.48 shows the same issue.
>
> Am 13.02.2022 um 18:37 schrieb Stefan Mayr:
>> Hi,
>>
>> looking at the source code
>> https://github.com/apache/tomcat-connectors/blob/main/native/apache-2.
>> 0/mod_jk.c#L2954#L2973
>> I did some more testing:
>>
>> Variant 1: JkMount /demo/* ajp13_worker;use_server_errors=401
>> Variant 2: JkMount /demo/* ajp13_worker
>>
>> ignoring what variant 2 changes for regular request: reading the
>> source comment my understanding is, that for both variants a HEAD
>> request (by definition must have an empty response body) should let
>> Apache httpd handle the error code.
>>
>> But the return code for jk_handler looks different:
>>
>> Variant 1: s.http_response_status
>> Variant 2: r->status
>
> Although this looks different on the first glance it seems to be the same.
>
>> The response only seems correct for variant 1 - which is configured
>> to let Apache httpd handle all responses for status codes >= 401. For
>> variant 2 mod_jk seems to handle the response itself - contrary to
>> what the comment explains.
>
> This leads to the next assumption, that whenever there is a special handling
> for use_server_errors there should be something similar for the case with an
> empty/non-existing response body.
>
> There is
> https://github.com/apache/tomcat-connectors/blob/main/native/common/jk
> _ajp_common.c#L1991#L1993 with no corresponding (pseudo) code like
>
> if (!r->something_like_bodyct && r->http_response_status >=
> JK_HTTP_BAD_REQUEST){
> r->response_blocked = JK_TRUE;
> }
>
> Adding code like this (sorry, i could not find out how to determine if there
> is a response body) fixes the issue with the wrong response body for a HEAD
> request. But we miss the WWW-Authenticate header now.
>
> Digging further we find
> https://github.com/apache/tomcat-connectors/blob/main/native/apache-2.
> 0/mod_jk.c#L331#L353 which has a special treatment for 401 HTTP
> Unauthorized. But again, only for use_server_errors.
>
> This should be fixable by extending the condition like this
>
> if ((s->extension.use_server_error_pages &&
> status >= s->extension.use_server_error_pages) ||
> (!r->sent_bodyct && r->status >= HTTP_BAD_REQUEST)) {
>
>
> But the WWW-Authenticate header is still missing. So i'm wrong, again.
> Although it feels like i'm close.
>
>> Am 12.02.2022 um 14:24 schrieb Stefan Mayr:
>>> Hello Tomcat users,
>>>
>>> this week we were debugging a strange connection issue which I
>>> tracked down to an interference between Apache httpd and mod_jk.
>>>
>>> For the full picture, the infrastructure setup contains
>>>
>>> 1. a Loadbalancer providing HTTPS, HTTP/1.1 and HTTP/2 for Clients.
>>> 2. an Apache httpd 2.4 webserver (HTTP only) with mod_jk 3. a Tomcat
>>> mit AJP-Connector
>>>
>>> We have an application doing many different HEAD requests against an
>>> application running in the Tomcat server. The requests contain an
>>> Authorization header for Basic authentication. Expected resp
AW: mod_jk interference with ErrorDocument/Alias on HEAD request
Hello Stefan,
Now I got it. Thanks for the clarification :)
-Ursprüngliche Nachricht-
Von: Stefan Mayr
Gesendet: Dienstag, 15. Februar 2022 14:26
An: users@tomcat.apache.org
Betreff: Re: mod_jk interference with ErrorDocument/Alias on HEAD request
Hello Thomas,
Am 15.02.2022 um 11:38 schrieb Thomas Hoffmann (Speed4Trade GmbH):
> Hello Stefan,
>
> by spec / RFC, a HEAD request is not allowed to return any body.
>
> Greetings,
> Thomas
This is true and that is why i'm writing to this list. In the described case
mod_jk returns a response body although it should not (at least i think mod_jk
is somehow responsible for that)
> -Ursprüngliche Nachricht-
> Von: Stefan Mayr
> Gesendet: Montag, 14. Februar 2022 23:07
> An: users@tomcat.apache.org
> Betreff: Re: mod_jk interference with ErrorDocument/Alias on HEAD
> request
>
> Hello again,
>
> a self-compiled mod_jk 1.2.48 shows the same issue.
>
> Am 13.02.2022 um 18:37 schrieb Stefan Mayr:
>> Hi,
>>
>> looking at the source code
>> https://github.com/apache/tomcat-connectors/blob/main/native/apache-2.
>> 0/mod_jk.c#L2954#L2973
>> I did some more testing:
>>
>> Variant 1: JkMount /demo/* ajp13_worker;use_server_errors=401
>> Variant 2: JkMount /demo/* ajp13_worker
>>
>> ignoring what variant 2 changes for regular request: reading the
>> source comment my understanding is, that for both variants a HEAD
>> request (by definition must have an empty response body) should let
>> Apache httpd handle the error code.
>>
>> But the return code for jk_handler looks different:
>>
>> Variant 1: s.http_response_status
>> Variant 2: r->status
>
> Although this looks different on the first glance it seems to be the same.
>
>> The response only seems correct for variant 1 - which is configured
>> to let Apache httpd handle all responses for status codes >= 401. For
>> variant 2 mod_jk seems to handle the response itself - contrary to
>> what the comment explains.
>
> This leads to the next assumption, that whenever there is a special handling
> for use_server_errors there should be something similar for the case with an
> empty/non-existing response body.
>
> There is
> https://github.com/apache/tomcat-connectors/blob/main/native/common/jk
> _ajp_common.c#L1991#L1993 with no corresponding (pseudo) code like
>
> if (!r->something_like_bodyct && r->http_response_status >=
> JK_HTTP_BAD_REQUEST){
> r->response_blocked = JK_TRUE;
> }
>
> Adding code like this (sorry, i could not find out how to determine if there
> is a response body) fixes the issue with the wrong response body for a HEAD
> request. But we miss the WWW-Authenticate header now.
>
> Digging further we find
> https://github.com/apache/tomcat-connectors/blob/main/native/apache-2.
> 0/mod_jk.c#L331#L353 which has a special treatment for 401 HTTP
> Unauthorized. But again, only for use_server_errors.
>
> This should be fixable by extending the condition like this
>
> if ((s->extension.use_server_error_pages &&
> status >= s->extension.use_server_error_pages) ||
> (!r->sent_bodyct && r->status >= HTTP_BAD_REQUEST)) {
>
>
> But the WWW-Authenticate header is still missing. So i'm wrong, again.
> Although it feels like i'm close.
>
>> Am 12.02.2022 um 14:24 schrieb Stefan Mayr:
>>> Hello Tomcat users,
>>>
>>> this week we were debugging a strange connection issue which I
>>> tracked down to an interference between Apache httpd and mod_jk.
>>>
>>> For the full picture, the infrastructure setup contains
>>>
>>> 1. a Loadbalancer providing HTTPS, HTTP/1.1 and HTTP/2 for Clients.
>>> 2. an Apache httpd 2.4 webserver (HTTP only) with mod_jk 3. a Tomcat
>>> mit AJP-Connector
>>>
>>> We have an application doing many different HEAD requests against an
>>> application running in the Tomcat server. The requests contain an
>>> Authorization header for Basic authentication. Expected response is
>>> a HTTP 200 OK or HTTP 401 if this particular user is not allowed to
>>> access that ressource. Because this is a HEAD request there must not
>>> be a response body according to RFC 2616.
>>>
>>> If there is a response body in the response to the HEAD request our
>>> loadbalancer does strange things: aborts the connection if the
>>> clients uses HTTP/2, SSL errors if using HTTP/1.1. But this is an
>>> issue on its own which we might have t
Re: mod_jk interference with ErrorDocument/Alias on HEAD request
Hello Thomas,
Am 15.02.2022 um 11:38 schrieb Thomas Hoffmann (Speed4Trade GmbH):
Hello Stefan,
by spec / RFC, a HEAD request is not allowed to return any body.
Greetings,
Thomas
This is true and that is why i'm writing to this list. In the described
case mod_jk returns a response body although it should not (at least i
think mod_jk is somehow responsible for that)
-Ursprüngliche Nachricht-
Von: Stefan Mayr
Gesendet: Montag, 14. Februar 2022 23:07
An: users@tomcat.apache.org
Betreff: Re: mod_jk interference with ErrorDocument/Alias on HEAD request
Hello again,
a self-compiled mod_jk 1.2.48 shows the same issue.
Am 13.02.2022 um 18:37 schrieb Stefan Mayr:
Hi,
looking at the source code
https://github.com/apache/tomcat-connectors/blob/main/native/apache-2.
0/mod_jk.c#L2954#L2973
I did some more testing:
Variant 1: JkMount /demo/* ajp13_worker;use_server_errors=401
Variant 2: JkMount /demo/* ajp13_worker
ignoring what variant 2 changes for regular request: reading the
source comment my understanding is, that for both variants a HEAD
request (by definition must have an empty response body) should let
Apache httpd handle the error code.
But the return code for jk_handler looks different:
Variant 1: s.http_response_status
Variant 2: r->status
Although this looks different on the first glance it seems to be the same.
The response only seems correct for variant 1 - which is configured to
let Apache httpd handle all responses for status codes >= 401. For
variant 2 mod_jk seems to handle the response itself - contrary to
what the comment explains.
This leads to the next assumption, that whenever there is a special handling
for use_server_errors there should be something similar for the case with an
empty/non-existing response body.
There is
https://github.com/apache/tomcat-connectors/blob/main/native/common/jk_ajp_common.c#L1991#L1993
with no corresponding (pseudo) code like
if (!r->something_like_bodyct && r->http_response_status >=
JK_HTTP_BAD_REQUEST){
r->response_blocked = JK_TRUE;
}
Adding code like this (sorry, i could not find out how to determine if there is
a response body) fixes the issue with the wrong response body for a HEAD
request. But we miss the WWW-Authenticate header now.
Digging further we find
https://github.com/apache/tomcat-connectors/blob/main/native/apache-2.0/mod_jk.c#L331#L353
which has a special treatment for 401 HTTP Unauthorized. But again, only for
use_server_errors.
This should be fixable by extending the condition like this
if ((s->extension.use_server_error_pages &&
status >= s->extension.use_server_error_pages) ||
(!r->sent_bodyct && r->status >= HTTP_BAD_REQUEST)) {
But the WWW-Authenticate header is still missing. So i'm wrong, again.
Although it feels like i'm close.
Am 12.02.2022 um 14:24 schrieb Stefan Mayr:
Hello Tomcat users,
this week we were debugging a strange connection issue which I
tracked down to an interference between Apache httpd and mod_jk.
For the full picture, the infrastructure setup contains
1. a Loadbalancer providing HTTPS, HTTP/1.1 and HTTP/2 for Clients.
2. an Apache httpd 2.4 webserver (HTTP only) with mod_jk 3. a Tomcat
mit AJP-Connector
We have an application doing many different HEAD requests against an
application running in the Tomcat server. The requests contain an
Authorization header for Basic authentication. Expected response is a
HTTP 200 OK or HTTP 401 if this particular user is not allowed to
access that ressource. Because this is a HEAD request there must not
be a response body according to RFC 2616.
If there is a response body in the response to the HEAD request our
loadbalancer does strange things: aborts the connection if the
clients uses HTTP/2, SSL errors if using HTTP/1.1. But this is an
issue on its own which we might have to solve with the vendor.
Now comes the point where I need your help. We have a httpd
configuration with mod_jk which generates these invalid response
bodies on HEAD requests. I have a gut feeling this could be a bug
with mod_jk.
For demonstration purpose i created a minimal demo app which only is
a WEB-INF/web.xml https://jakarta.ee/xml/ns/jakartaee;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="https://jakarta.ee/xml/ns/jakartaee
https://jakarta.ee/xml/ns/jakartaee/web-app_5_0.xsd;
version="5.0">
Login
/*
manager
manager
BASIC
Then I place a JkMount in my Apache httpd configuration (+ minimal
worker.properties):
JkMount /demo/* ajp13_worker
Testing this with curl works like
AW: mod_jk interference with ErrorDocument/Alias on HEAD request
Hello Stefan,
by spec / RFC, a HEAD request is not allowed to return any body.
Greetings,
Thomas
-Ursprüngliche Nachricht-
Von: Stefan Mayr
Gesendet: Montag, 14. Februar 2022 23:07
An: users@tomcat.apache.org
Betreff: Re: mod_jk interference with ErrorDocument/Alias on HEAD request
Hello again,
a self-compiled mod_jk 1.2.48 shows the same issue.
Am 13.02.2022 um 18:37 schrieb Stefan Mayr:
> Hi,
>
> looking at the source code
> https://github.com/apache/tomcat-connectors/blob/main/native/apache-2.
> 0/mod_jk.c#L2954#L2973
> I did some more testing:
>
> Variant 1: JkMount /demo/* ajp13_worker;use_server_errors=401
> Variant 2: JkMount /demo/* ajp13_worker
>
> ignoring what variant 2 changes for regular request: reading the
> source comment my understanding is, that for both variants a HEAD
> request (by definition must have an empty response body) should let
> Apache httpd handle the error code.
>
> But the return code for jk_handler looks different:
>
> Variant 1: s.http_response_status
> Variant 2: r->status
Although this looks different on the first glance it seems to be the same.
> The response only seems correct for variant 1 - which is configured to
> let Apache httpd handle all responses for status codes >= 401. For
> variant 2 mod_jk seems to handle the response itself - contrary to
> what the comment explains.
This leads to the next assumption, that whenever there is a special handling
for use_server_errors there should be something similar for the case with an
empty/non-existing response body.
There is
https://github.com/apache/tomcat-connectors/blob/main/native/common/jk_ajp_common.c#L1991#L1993
with no corresponding (pseudo) code like
if (!r->something_like_bodyct && r->http_response_status >=
JK_HTTP_BAD_REQUEST){
r->response_blocked = JK_TRUE;
}
Adding code like this (sorry, i could not find out how to determine if there is
a response body) fixes the issue with the wrong response body for a HEAD
request. But we miss the WWW-Authenticate header now.
Digging further we find
https://github.com/apache/tomcat-connectors/blob/main/native/apache-2.0/mod_jk.c#L331#L353
which has a special treatment for 401 HTTP Unauthorized. But again, only for
use_server_errors.
This should be fixable by extending the condition like this
if ((s->extension.use_server_error_pages &&
status >= s->extension.use_server_error_pages) ||
(!r->sent_bodyct && r->status >= HTTP_BAD_REQUEST)) {
But the WWW-Authenticate header is still missing. So i'm wrong, again.
Although it feels like i'm close.
> Am 12.02.2022 um 14:24 schrieb Stefan Mayr:
>> Hello Tomcat users,
>>
>> this week we were debugging a strange connection issue which I
>> tracked down to an interference between Apache httpd and mod_jk.
>>
>> For the full picture, the infrastructure setup contains
>>
>> 1. a Loadbalancer providing HTTPS, HTTP/1.1 and HTTP/2 for Clients.
>> 2. an Apache httpd 2.4 webserver (HTTP only) with mod_jk 3. a Tomcat
>> mit AJP-Connector
>>
>> We have an application doing many different HEAD requests against an
>> application running in the Tomcat server. The requests contain an
>> Authorization header for Basic authentication. Expected response is a
>> HTTP 200 OK or HTTP 401 if this particular user is not allowed to
>> access that ressource. Because this is a HEAD request there must not
>> be a response body according to RFC 2616.
>>
>> If there is a response body in the response to the HEAD request our
>> loadbalancer does strange things: aborts the connection if the
>> clients uses HTTP/2, SSL errors if using HTTP/1.1. But this is an
>> issue on its own which we might have to solve with the vendor.
>>
>> Now comes the point where I need your help. We have a httpd
>> configuration with mod_jk which generates these invalid response
>> bodies on HEAD requests. I have a gut feeling this could be a bug
>> with mod_jk.
>>
>> For demonstration purpose i created a minimal demo app which only is
>> a WEB-INF/web.xml > xmlns="https://jakarta.ee/xml/ns/jakartaee;
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>> xsi:schemaLocation="https://jakarta.ee/xml/ns/jakartaee
>>
>> https://jakarta.ee/xml/ns/jakartaee/web-app_5_0.xsd;
>> version="5.0">
>>
>>
>> Login
>> /*
>>
>>
>> manager
>>
>>
>>
Re: mod_jk interference with ErrorDocument/Alias on HEAD request
Hello again,
a self-compiled mod_jk 1.2.48 shows the same issue.
Am 13.02.2022 um 18:37 schrieb Stefan Mayr:
Hi,
looking at the source code
https://github.com/apache/tomcat-connectors/blob/main/native/apache-2.0/mod_jk.c#L2954#L2973
I did some more testing:
Variant 1: JkMount /demo/* ajp13_worker;use_server_errors=401
Variant 2: JkMount /demo/* ajp13_worker
ignoring what variant 2 changes for regular request: reading the source
comment my understanding is, that for both variants a HEAD request (by
definition must have an empty response body) should let Apache httpd
handle the error code.
But the return code for jk_handler looks different:
Variant 1: s.http_response_status
Variant 2: r->status
Although this looks different on the first glance it seems to be the same.
The response only seems correct for variant 1 - which is configured to
let Apache httpd handle all responses for status codes >= 401. For
variant 2 mod_jk seems to handle the response itself - contrary to what
the comment explains.
This leads to the next assumption, that whenever there is a special
handling for use_server_errors there should be something similar for the
case with an empty/non-existing response body.
There is
https://github.com/apache/tomcat-connectors/blob/main/native/common/jk_ajp_common.c#L1991#L1993
with no corresponding (pseudo) code like
if (!r->something_like_bodyct && r->http_response_status >=
JK_HTTP_BAD_REQUEST){
r->response_blocked = JK_TRUE;
}
Adding code like this (sorry, i could not find out how to determine if
there is a response body) fixes the issue with the wrong response body
for a HEAD request. But we miss the WWW-Authenticate header now.
Digging further we find
https://github.com/apache/tomcat-connectors/blob/main/native/apache-2.0/mod_jk.c#L331#L353
which has a special treatment for 401 HTTP Unauthorized. But again, only
for use_server_errors.
This should be fixable by extending the condition like this
if ((s->extension.use_server_error_pages &&
status >= s->extension.use_server_error_pages) ||
(!r->sent_bodyct && r->status >= HTTP_BAD_REQUEST)) {
But the WWW-Authenticate header is still missing. So i'm wrong, again.
Although it feels like i'm close.
Am 12.02.2022 um 14:24 schrieb Stefan Mayr:
Hello Tomcat users,
this week we were debugging a strange connection issue which I tracked
down to an interference between Apache httpd and mod_jk.
For the full picture, the infrastructure setup contains
1. a Loadbalancer providing HTTPS, HTTP/1.1 and HTTP/2 for Clients.
2. an Apache httpd 2.4 webserver (HTTP only) with mod_jk
3. a Tomcat mit AJP-Connector
We have an application doing many different HEAD requests against an
application running in the Tomcat server. The requests contain an
Authorization header for Basic authentication. Expected response is a
HTTP 200 OK or HTTP 401 if this particular user is not allowed to
access that ressource. Because this is a HEAD request there must not
be a response body according to RFC 2616.
If there is a response body in the response to the HEAD request our
loadbalancer does strange things: aborts the connection if the clients
uses HTTP/2, SSL errors if using HTTP/1.1. But this is an issue on its
own which we might have to solve with the vendor.
Now comes the point where I need your help. We have a httpd
configuration with mod_jk which generates these invalid response
bodies on HEAD requests. I have a gut feeling this could be a bug with
mod_jk.
For demonstration purpose i created a minimal demo app which only is a
WEB-INF/web.xml
https://jakarta.ee/xml/ns/jakartaee;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="https://jakarta.ee/xml/ns/jakartaee
https://jakarta.ee/xml/ns/jakartaee/web-app_5_0.xsd;
version="5.0">
Login
/*
manager
manager
BASIC
Then I place a JkMount in my Apache httpd configuration (+ minimal
worker.properties):
JkMount /demo/* ajp13_worker
Testing this with curl works like expected:
root@1ae8973f1b6b:~# curl -I -v localhost/demo/
* Trying 127.0.0.1:80...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 80 (#0)
> HEAD /demo/ HTTP/1.1
> Host: localhost
> User-Agent: curl/7.68.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 401 401
HTTP/1.1 401 401
< Date: Sat, 12 Feb 2022 12:57:33 GMT
Date: Sat, 12 Feb 2022 12:57:33 GMT
< Server: Apache/2.4.41 (Ubuntu)
Server: Apache/2.4.41 (Ubuntu)
< Cache-Control: private
Cache-Control: private
< WWW-Authenticate: Basic realm
AW: mod_jk interference with ErrorDocument/Alias on HEAD request
Hello, the spec https://datatracker.ietf.org/doc/html/rfc7231#page-25 says in chapter 4.3.2: " The HEAD method is identical to GET except that the server MUST NOT send a message body in the response (i.e., the response terminates at the end of the header section)." Greetings, Thomas -Ursprüngliche Nachricht- Von: Stefan Mayr Gesendet: Sonntag, 13. Februar 2022 18:37 An: users@tomcat.apache.org Betreff: Re: mod_jk interference with ErrorDocument/Alias on HEAD request Hi, looking at the source code https://github.com/apache/tomcat-connectors/blob/main/native/apache-2.0/mod_jk.c#L2954#L2973 I did some more testing: Variant 1: JkMount /demo/* ajp13_worker;use_server_errors=401 Variant 2: JkMount /demo/* ajp13_worker ignoring what variant 2 changes for regular request: reading the source comment my understanding is, that for both variants a HEAD request (by definition must have an empty response body) should let Apache httpd handle the error code. But the return code for jk_handler looks different: Variant 1: s.http_response_status Variant 2: r->status The response only seems correct for variant 1 - which is configured to let Apache httpd handle all responses for status codes >= 401. For variant 2 mod_jk seems to handle the response itself - contrary to what the comment explains. Am 12.02.2022 um 14:24 schrieb Stefan Mayr: > Hello Tomcat users, > > this week we were debugging a strange connection issue which I tracked > down to an interference between Apache httpd and mod_jk. > > For the full picture, the infrastructure setup contains > > 1. a Loadbalancer providing HTTPS, HTTP/1.1 and HTTP/2 for Clients. > 2. an Apache httpd 2.4 webserver (HTTP only) with mod_jk 3. a Tomcat > mit AJP-Connector > > We have an application doing many different HEAD requests against an > application running in the Tomcat server. The requests contain an > Authorization header for Basic authentication. Expected response is a > HTTP 200 OK or HTTP 401 if this particular user is not allowed to > access that ressource. Because this is a HEAD request there must not > be a response body according to RFC 2616. > > If there is a response body in the response to the HEAD request our > loadbalancer does strange things: aborts the connection if the clients > uses HTTP/2, SSL errors if using HTTP/1.1. But this is an issue on its > own which we might have to solve with the vendor. > > Now comes the point where I need your help. We have a httpd > configuration with mod_jk which generates these invalid response > bodies on HEAD requests. I have a gut feeling this could be a bug with mod_jk. > > For demonstration purpose i created a minimal demo app which only is a > WEB-INF/web.xml xmlns="https://jakarta.ee/xml/ns/jakartaee; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; > xsi:schemaLocation="https://jakarta.ee/xml/ns/jakartaee > https://jakarta.ee/xml/ns/jakartaee/web-app_5_0.xsd; > version="5.0"> > > > Login > /* > > > manager > > > > manager > > > BASIC > > > > Then I place a JkMount in my Apache httpd configuration (+ minimal > worker.properties): > > JkMount /demo/* ajp13_worker > > Testing this with curl works like expected: > > root@1ae8973f1b6b:~# curl -I -v localhost/demo/ > * Trying 127.0.0.1:80... > * TCP_NODELAY set > * Connected to localhost (127.0.0.1) port 80 (#0) > HEAD /demo/ > HTTP/1.1 > Host: localhost > User-Agent: curl/7.68.0 > Accept: */* > > > * Mark bundle as not supporting multiuse < HTTP/1.1 401 401 > HTTP/1.1 401 401 > < Date: Sat, 12 Feb 2022 12:57:33 GMT > Date: Sat, 12 Feb 2022 12:57:33 GMT > < Server: Apache/2.4.41 (Ubuntu) > Server: Apache/2.4.41 (Ubuntu) > < Cache-Control: private > Cache-Control: private > < WWW-Authenticate: Basic realm="Authentication required" > WWW-Authenticate: Basic realm="Authentication required" > < Content-Language: en > Content-Language: en > < Content-Type: text/html;charset=utf-8 > Content-Type: text/html;charset=utf-8 > > < > * Connection #0 to host localhost left intact > > But our default setup always includes custom error pages: > > Alias /error/ "/usr/share/apache2/error/" > ErrorDocument 401 /error/HTTP_UNAUTHORIZED.html.var > > If both of those lines are added this results in a response body for > the HEAD request. > > root@1ae8973f1b6b:~# curl -I
Re: mod_jk interference with ErrorDocument/Alias on HEAD request
Hi, looking at the source code https://github.com/apache/tomcat-connectors/blob/main/native/apache-2.0/mod_jk.c#L2954#L2973 I did some more testing: Variant 1: JkMount /demo/* ajp13_worker;use_server_errors=401 Variant 2: JkMount /demo/* ajp13_worker ignoring what variant 2 changes for regular request: reading the source comment my understanding is, that for both variants a HEAD request (by definition must have an empty response body) should let Apache httpd handle the error code. But the return code for jk_handler looks different: Variant 1: s.http_response_status Variant 2: r->status The response only seems correct for variant 1 - which is configured to let Apache httpd handle all responses for status codes >= 401. For variant 2 mod_jk seems to handle the response itself - contrary to what the comment explains. Am 12.02.2022 um 14:24 schrieb Stefan Mayr: Hello Tomcat users, this week we were debugging a strange connection issue which I tracked down to an interference between Apache httpd and mod_jk. For the full picture, the infrastructure setup contains 1. a Loadbalancer providing HTTPS, HTTP/1.1 and HTTP/2 for Clients. 2. an Apache httpd 2.4 webserver (HTTP only) with mod_jk 3. a Tomcat mit AJP-Connector We have an application doing many different HEAD requests against an application running in the Tomcat server. The requests contain an Authorization header for Basic authentication. Expected response is a HTTP 200 OK or HTTP 401 if this particular user is not allowed to access that ressource. Because this is a HEAD request there must not be a response body according to RFC 2616. If there is a response body in the response to the HEAD request our loadbalancer does strange things: aborts the connection if the clients uses HTTP/2, SSL errors if using HTTP/1.1. But this is an issue on its own which we might have to solve with the vendor. Now comes the point where I need your help. We have a httpd configuration with mod_jk which generates these invalid response bodies on HEAD requests. I have a gut feeling this could be a bug with mod_jk. For demonstration purpose i created a minimal demo app which only is a WEB-INF/web.xml https://jakarta.ee/xml/ns/jakartaee; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation="https://jakarta.ee/xml/ns/jakartaee https://jakarta.ee/xml/ns/jakartaee/web-app_5_0.xsd; version="5.0"> Login /* manager manager BASIC Then I place a JkMount in my Apache httpd configuration (+ minimal worker.properties): JkMount /demo/* ajp13_worker Testing this with curl works like expected: root@1ae8973f1b6b:~# curl -I -v localhost/demo/ * Trying 127.0.0.1:80... * TCP_NODELAY set * Connected to localhost (127.0.0.1) port 80 (#0) > HEAD /demo/ HTTP/1.1 > Host: localhost > User-Agent: curl/7.68.0 > Accept: */* > * Mark bundle as not supporting multiuse < HTTP/1.1 401 401 HTTP/1.1 401 401 < Date: Sat, 12 Feb 2022 12:57:33 GMT Date: Sat, 12 Feb 2022 12:57:33 GMT < Server: Apache/2.4.41 (Ubuntu) Server: Apache/2.4.41 (Ubuntu) < Cache-Control: private Cache-Control: private < WWW-Authenticate: Basic realm="Authentication required" WWW-Authenticate: Basic realm="Authentication required" < Content-Language: en Content-Language: en < Content-Type: text/html;charset=utf-8 Content-Type: text/html;charset=utf-8 < * Connection #0 to host localhost left intact But our default setup always includes custom error pages: Alias /error/ "/usr/share/apache2/error/" ErrorDocument 401 /error/HTTP_UNAUTHORIZED.html.var If both of those lines are added this results in a response body for the HEAD request. root@1ae8973f1b6b:~# curl -I -v localhost/demo/ * Trying 127.0.0.1:80... * TCP_NODELAY set * Connected to localhost (127.0.0.1) port 80 (#0) > HEAD /demo/ HTTP/1.1 > Host: localhost > User-Agent: curl/7.68.0 > Accept: */* > * Mark bundle as not supporting multiuse < HTTP/1.1 401 401 HTTP/1.1 401 401 < Date: Sat, 12 Feb 2022 12:56:27 GMT Date: Sat, 12 Feb 2022 12:56:27 GMT < Server: Apache/2.4.41 (Ubuntu) Server: Apache/2.4.41 (Ubuntu) < Cache-Control: private Cache-Control: private < WWW-Authenticate: Basic realm="Authentication required" WWW-Authenticate: Basic realm="Authentication required" < Content-Language: en Content-Language: en < Content-Type: text/html;charset=utf-8 Content-Type: text/html;charset=utf-8 < * Excess found: excess = 589 url = /demo/ (zero-length body) * Connection #0 to host localhost left intact Checking with tcpdump on port 8009 we see the expected response without a b
Re: mod_jk interference with ErrorDocument/Alias on HEAD request
Hi Thomas, Am 13.02.2022 um 17:27 schrieb Thomas Hoffmann (Speed4Trade GmbH): Hello, maybe you can try to set an environment variable which skips interpreting the content-length: https://tomcat.apache.org/connectors-doc/reference/apache.html#Advanced%20Environment%20Variables --> JK_IGNORE_CL To get more information, you can also set the logfile and log-level to debug: JkLogLevel (same reference page as above). Greetings, Thomas I added both options: Alias /error/ "/usr/share/apache2/error/" ErrorDocument 401 /error/HTTP_UNAUTHORIZED.html.var SetEnv JK_IGNORE_CL JkLogLevel Debug JkMount /demo/* ajp13_worker This produces the following debug output: [Sun Feb 13 16:37:02.591 2022] [212:140388647335680] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (1459): 005001 00 17 74 65 78 74 2F 68 74 6D 6C 3B 63 68 61 - ...text/html;cha [Sun Feb 13 16:37:02.591 2022] [212:140388647335680] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (1459): 006072 73 65 74 3D 75 74 66 2D 38 00 A0 02 00 02 65 - rset=utf-8.e [Sun Feb 13 16:37:02.591 2022] [212:140388647335680] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (1459): 00706E 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - n... [Sun Feb 13 16:37:02.591 2022] [212:140388647335680] [debug] ajp_unmarshal_response::jk_ajp_common.c (736): (ajp13_worker) status = 401 [Sun Feb 13 16:37:02.591 2022] [212:140388647335680] [debug] ajp_unmarshal_response::jk_ajp_common.c (743): Number of headers is = 4 [Sun Feb 13 16:37:02.591 2022] [212:140388647335680] [debug] ajp_unmarshal_response::jk_ajp_common.c (799): (ajp13_worker) Header[0] [Cache-Control] = [private] [Sun Feb 13 16:37:02.591 2022] [212:140388647335680] [debug] ajp_unmarshal_response::jk_ajp_common.c (799): (ajp13_worker) Header[1] [WWW-Authenticate] = [Basic realm="Authentication required"] [Sun Feb 13 16:37:02.591 2022] [212:140388647335680] [debug] ajp_unmarshal_response::jk_ajp_common.c (799): (ajp13_worker) Header[2] [Content-Type] = [text/html;charset=utf-8] [Sun Feb 13 16:37:02.591 2022] [212:140388647335680] [debug] ajp_unmarshal_response::jk_ajp_common.c (799): (ajp13_worker) Header[3] [Content-Language] = [en] [Sun Feb 13 16:37:02.591 2022] [212:140388647335680] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (1459): received from ajp13 pos=0 len=2 max=8192 [Sun Feb 13 16:37:02.591 2022] [212:140388647335680] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (1459): 05 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - [Sun Feb 13 16:37:02.591 2022] [212:140388647335680] [debug] ajp_process_callback::jk_ajp_common.c (2132): (ajp13_worker) AJP13 protocol: Reuse is OK [Sun Feb 13 16:37:02.591 2022] [212:140388647335680] [debug] ajp_reset_endpoint::jk_ajp_common.c (848): (ajp13_worker) resetting endpoint with socket 15 [Sun Feb 13 16:37:02.591 2022] [212:140388647335680] [debug] ajp_done::jk_ajp_common.c (3288): recycling connection pool for worker ajp13_worker and socket 15 [Sun Feb 13 16:37:02.591 2022] [212:140388647335680] [info] jk_handler::mod_jk.c (2968): No body with status=401 for worker=ajp13_worker [Sun Feb 13 16:37:02.592 2022] [212:140388647335680] [debug] jk_servlet_normalize::jk_util.c (2185): URI on entering jk_servlet_normalize: [/error/HTTP_UNAUTHORIZED.html.var] [Sun Feb 13 16:37:02.592 2022] [212:140388647335680] [debug] jk_servlet_normalize::jk_util.c (2279): URI on exiting jk_servlet_normalize: [/error/HTTP_UNAUTHORIZED.html.var] [Sun Feb 13 16:37:02.592 2022] [212:140388647335680] [debug] map_uri_to_worker_ext::jk_uri_worker_map.c (1168): Attempting to map URI '/error/HTTP_UNAUTHORIZED.html.var' from 1 maps [Sun Feb 13 16:37:02.592 2022] [212:140388647335680] [debug] find_match::jk_uri_worker_map.c (978): Attempting to map context URI '/demo/*=ajp13_worker' source 'JkMount' [Sun Feb 13 16:37:02.592 2022] [212:140388647335680] [debug] jk_map_to_storage::mod_jk.c (4058): no match for /error/HTTP_UNAUTHORIZED.html.var found The last lines are irritating. They don't change when I try to add a JkUnMount: JkMount /demo/* ajp13_worker JkUnMount /error/* ajp13_worker -Ursprüngliche Nachricht- Von: Stefan Mayr Gesendet: Samstag, 12. Februar 2022 14:24 An: Tomcat Users List Betreff: mod_jk interference with ErrorDocument/Alias on HEAD request Hello Tomcat users, this week we were debugging a strange connection issue which I tracked down to an interference between Apache httpd and mod_jk. For the full picture, the infrastructure setup contains 1. a Loadbalancer providing HTTPS, HTTP/1.1 and HTTP/2 for Clients. 2. an Apache httpd 2.4 webserver (HTTP only) with mod_jk 3. a Tomcat mit AJP-Connector We have an application doing many different HEAD requests against an application running in the Tomcat server. The requests contain an Authorization header for Basic authentication. Expected response is a HTTP 200 OK or HTTP
AW: mod_jk interference with ErrorDocument/Alias on HEAD request
Hello, maybe you can try to set an environment variable which skips interpreting the content-length: https://tomcat.apache.org/connectors-doc/reference/apache.html#Advanced%20Environment%20Variables --> JK_IGNORE_CL To get more information, you can also set the logfile and log-level to debug: JkLogLevel (same reference page as above). Greetings, Thomas -Ursprüngliche Nachricht- Von: Stefan Mayr Gesendet: Samstag, 12. Februar 2022 14:24 An: Tomcat Users List Betreff: mod_jk interference with ErrorDocument/Alias on HEAD request Hello Tomcat users, this week we were debugging a strange connection issue which I tracked down to an interference between Apache httpd and mod_jk. For the full picture, the infrastructure setup contains 1. a Loadbalancer providing HTTPS, HTTP/1.1 and HTTP/2 for Clients. 2. an Apache httpd 2.4 webserver (HTTP only) with mod_jk 3. a Tomcat mit AJP-Connector We have an application doing many different HEAD requests against an application running in the Tomcat server. The requests contain an Authorization header for Basic authentication. Expected response is a HTTP 200 OK or HTTP 401 if this particular user is not allowed to access that ressource. Because this is a HEAD request there must not be a response body according to RFC 2616. If there is a response body in the response to the HEAD request our loadbalancer does strange things: aborts the connection if the clients uses HTTP/2, SSL errors if using HTTP/1.1. But this is an issue on its own which we might have to solve with the vendor. Now comes the point where I need your help. We have a httpd configuration with mod_jk which generates these invalid response bodies on HEAD requests. I have a gut feeling this could be a bug with mod_jk. For demonstration purpose i created a minimal demo app which only is a WEB-INF/web.xml https://jakarta.ee/xml/ns/jakartaee; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation="https://jakarta.ee/xml/ns/jakartaee https://jakarta.ee/xml/ns/jakartaee/web-app_5_0.xsd; version="5.0"> Login /* manager manager BASIC Then I place a JkMount in my Apache httpd configuration (+ minimal worker.properties): JkMount /demo/* ajp13_worker Testing this with curl works like expected: root@1ae8973f1b6b:~# curl -I -v localhost/demo/ * Trying 127.0.0.1:80... * TCP_NODELAY set * Connected to localhost (127.0.0.1) port 80 (#0) > HEAD /demo/ HTTP/1.1 > Host: localhost > User-Agent: curl/7.68.0 > Accept: */* > * Mark bundle as not supporting multiuse < HTTP/1.1 401 401 HTTP/1.1 401 401 < Date: Sat, 12 Feb 2022 12:57:33 GMT Date: Sat, 12 Feb 2022 12:57:33 GMT < Server: Apache/2.4.41 (Ubuntu) Server: Apache/2.4.41 (Ubuntu) < Cache-Control: private Cache-Control: private < WWW-Authenticate: Basic realm="Authentication required" WWW-Authenticate: Basic realm="Authentication required" < Content-Language: en Content-Language: en < Content-Type: text/html;charset=utf-8 Content-Type: text/html;charset=utf-8 < * Connection #0 to host localhost left intact But our default setup always includes custom error pages: Alias /error/ "/usr/share/apache2/error/" ErrorDocument 401 /error/HTTP_UNAUTHORIZED.html.var If both of those lines are added this results in a response body for the HEAD request. root@1ae8973f1b6b:~# curl -I -v localhost/demo/ * Trying 127.0.0.1:80... * TCP_NODELAY set * Connected to localhost (127.0.0.1) port 80 (#0) > HEAD /demo/ HTTP/1.1 > Host: localhost > User-Agent: curl/7.68.0 > Accept: */* > * Mark bundle as not supporting multiuse < HTTP/1.1 401 401 HTTP/1.1 401 401 < Date: Sat, 12 Feb 2022 12:56:27 GMT Date: Sat, 12 Feb 2022 12:56:27 GMT < Server: Apache/2.4.41 (Ubuntu) Server: Apache/2.4.41 (Ubuntu) < Cache-Control: private Cache-Control: private < WWW-Authenticate: Basic realm="Authentication required" WWW-Authenticate: Basic realm="Authentication required" < Content-Language: en Content-Language: en < Content-Type: text/html;charset=utf-8 Content-Type: text/html;charset=utf-8 < * Excess found: excess = 589 url = /demo/ (zero-length body) * Connection #0 to host localhost left intact Checking with tcpdump on port 8009 we see the expected response without a body from the Tomcat AJP connector. The tcpdump von port 80 reveals httpd is adding the configured ErrorDocument as response body. If we comment out either the Alias or ErrorDocument directive the response is correct again. Doing similar tests with CGI/PHP applications always show the correct response without a response body. This only affects
mod_jk interference with ErrorDocument/Alias on HEAD request
Hello Tomcat users, this week we were debugging a strange connection issue which I tracked down to an interference between Apache httpd and mod_jk. For the full picture, the infrastructure setup contains 1. a Loadbalancer providing HTTPS, HTTP/1.1 and HTTP/2 for Clients. 2. an Apache httpd 2.4 webserver (HTTP only) with mod_jk 3. a Tomcat mit AJP-Connector We have an application doing many different HEAD requests against an application running in the Tomcat server. The requests contain an Authorization header for Basic authentication. Expected response is a HTTP 200 OK or HTTP 401 if this particular user is not allowed to access that ressource. Because this is a HEAD request there must not be a response body according to RFC 2616. If there is a response body in the response to the HEAD request our loadbalancer does strange things: aborts the connection if the clients uses HTTP/2, SSL errors if using HTTP/1.1. But this is an issue on its own which we might have to solve with the vendor. Now comes the point where I need your help. We have a httpd configuration with mod_jk which generates these invalid response bodies on HEAD requests. I have a gut feeling this could be a bug with mod_jk. For demonstration purpose i created a minimal demo app which only is a WEB-INF/web.xml https://jakarta.ee/xml/ns/jakartaee; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation="https://jakarta.ee/xml/ns/jakartaee https://jakarta.ee/xml/ns/jakartaee/web-app_5_0.xsd; version="5.0"> Login /* manager manager BASIC Then I place a JkMount in my Apache httpd configuration (+ minimal worker.properties): JkMount /demo/* ajp13_worker Testing this with curl works like expected: root@1ae8973f1b6b:~# curl -I -v localhost/demo/ * Trying 127.0.0.1:80... * TCP_NODELAY set * Connected to localhost (127.0.0.1) port 80 (#0) > HEAD /demo/ HTTP/1.1 > Host: localhost > User-Agent: curl/7.68.0 > Accept: */* > * Mark bundle as not supporting multiuse < HTTP/1.1 401 401 HTTP/1.1 401 401 < Date: Sat, 12 Feb 2022 12:57:33 GMT Date: Sat, 12 Feb 2022 12:57:33 GMT < Server: Apache/2.4.41 (Ubuntu) Server: Apache/2.4.41 (Ubuntu) < Cache-Control: private Cache-Control: private < WWW-Authenticate: Basic realm="Authentication required" WWW-Authenticate: Basic realm="Authentication required" < Content-Language: en Content-Language: en < Content-Type: text/html;charset=utf-8 Content-Type: text/html;charset=utf-8 < * Connection #0 to host localhost left intact But our default setup always includes custom error pages: Alias /error/ "/usr/share/apache2/error/" ErrorDocument 401 /error/HTTP_UNAUTHORIZED.html.var If both of those lines are added this results in a response body for the HEAD request. root@1ae8973f1b6b:~# curl -I -v localhost/demo/ * Trying 127.0.0.1:80... * TCP_NODELAY set * Connected to localhost (127.0.0.1) port 80 (#0) > HEAD /demo/ HTTP/1.1 > Host: localhost > User-Agent: curl/7.68.0 > Accept: */* > * Mark bundle as not supporting multiuse < HTTP/1.1 401 401 HTTP/1.1 401 401 < Date: Sat, 12 Feb 2022 12:56:27 GMT Date: Sat, 12 Feb 2022 12:56:27 GMT < Server: Apache/2.4.41 (Ubuntu) Server: Apache/2.4.41 (Ubuntu) < Cache-Control: private Cache-Control: private < WWW-Authenticate: Basic realm="Authentication required" WWW-Authenticate: Basic realm="Authentication required" < Content-Language: en Content-Language: en < Content-Type: text/html;charset=utf-8 Content-Type: text/html;charset=utf-8 < * Excess found: excess = 589 url = /demo/ (zero-length body) * Connection #0 to host localhost left intact Checking with tcpdump on port 8009 we see the expected response without a body from the Tomcat AJP connector. The tcpdump von port 80 reveals httpd is adding the configured ErrorDocument as response body. If we comment out either the Alias or ErrorDocument directive the response is correct again. Doing similar tests with CGI/PHP applications always show the correct response without a response body. This only affects requests which use mod_jk. So far I could reproduce this on SLES12 SP5 and SLES15 SP3 running Apache httpd 2.4.51 and a self compile mod_jk 1.2.46 (same with the included mod_jk 1.2.43) at work. At home the same happens on a stock openSUSE Leap 15.3 with Apache httpd 2.4.51 and mod_jk 1.2.43 as well as on Ubuntu 20.04 with httpd 2.4.41 and mod_jk 1.2.46. I didn't try to compile the latest mod_jk version yet because I didn't spot a relevant point in the changelog. Can anyone confirm this behaviour or point me to a configuration directive i missed? Thank you,
Re: mod_jk "Can not determine the proper size for pid_t" on macOS 10.15.7
Brian, On 10/28/20 21:24, Paquin, Brian wrote: Chris, On Oct 27, 2020, at 12:31 PM, Christopher Schultz wrote: Brian On 10/26/20 15:33, Paquin, Brian wrote: I’m trying to build httpd and mod_jk for the first time on a macOS 10.15.7 box. XCode 12.1 is installed and I was able to compile OpenSSL 1.1.1g. I got an error “Can not determine the proper size for pid_t” when compiling httpd (v2.4.46) with included apr (v1.7.0). This issue https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbz.apache.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D64753data=04%7C01%7Cbrian.paquin%40yale.edu%7C4a009b9f4c19439afc4708d87a95d92e%7Cdd8cbebb21394df8b4114e3e87abeb5c%7C0%7C0%7C637394131299938700%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=WdzfXIIBvFQzON0aA2Q3EHqNyHK2bFqXpGYm2aEyi1A%3Dreserved=0 provided a diff patch that adds “#include ” in a number of locations. Applying this patch allowed me to compile httpd! Weird. pid_it is defined in and yet the patch adds to fix it. I don't have access to my Catalina machine right now, but my clang-based Mojave machine still says to use when you "man getpid": " GETPID(2) BSD System Calls Manual NAME getpid, getppid -- get parent or calling process identification SYNOPSIS #include pid_t getpid(void); " $ cc --version Apple LLVM version 10.0.1 (clang-1001.0.46.4) Target: x86_64-apple-darwin18.7.0 Thread model: posix InstalledDir: /Library/Developer/CommandLineTools/usr/bin Now I am trying to compile mod_jk (v1.2.48), and I get the same error. Does someone have a patch file I can use to get around this issue? $ ./configure CFLAGS='-arch x86_64' APXSLDFLAGS='-arch x86_64' --with-apxs=/usr/local/apache2/bin/apxs $ make Making all in common /usr/local/apache-2.4.46/build/libtool --silent --mode=compile gcc -I. -I/usr/local/apache-2.4.46/include -arch x86_64 -DHAVE_CONFIG_H -arch x86_64 -DHAVE_APR -I/usr/local/apache-2.4.46/include -I/usr/local/apache-2.4.46/include -arch x86_64 -DHAVE_CONFIG_H -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -DDARWIN_10 -c jk_ajp12_worker.c -o jk_ajp12_worker.lo In file included from jk_ajp12_worker.c:25: In file included from ./jk_ajp12_worker.h:26: In file included from ./jk_logger.h:26: In file included from ./jk_global.h:340: ./jk_types.h:56:2: error: Can not determine the proper size for pid_t #error Can not determine the proper size for pid_t ^ ./jk_types.h:62:2: error: Can not determine the proper size for pthread_t #error Can not determine the proper size for pthread_t ^ 2 errors generated. make[1]: *** [jk_ajp12_worker.lo] Error 1 make: *** [all-recursive] Error 1 $ I'm sorry, I have no idea how configure does its magic. The auto-generated jk_types.h looks like a hand-wavy template to me. You can probably hack it briefly by running "configure" (which you already did) and then hand-editing include/jk_types.h (ignoring the warning NOT to hand-edit it!) and manually adding: #include to the top. I added the line above to ./tomcat-connectors-1.2.48-src/native/common/jk_types.h and tried running make again but got the same error. I do not have an include directory in ./tomcat-connectors-1.2.48-src/native/. Any other suggestions? Sorry, native/common/jk_types.h was the file I meant. Can you just post the whole content of that file? I'm guessing that you have something like: typedef jk_pid_t @pid_t@ ; leftover from 'configure' not finding the right definition. We may have to adjust that line, too. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: mod_jk "Can not determine the proper size for pid_t" on macOS 10.15.7
Chris, > On Oct 27, 2020, at 12:31 PM, Christopher Schultz > wrote: > > Brian > > On 10/26/20 15:33, Paquin, Brian wrote: >> I’m trying to build httpd and mod_jk for the first time on a macOS 10.15.7 >> box. XCode 12.1 is installed and I was able to compile OpenSSL 1.1.1g. >> I got an error “Can not determine the proper size for pid_t” when compiling >> httpd (v2.4.46) with included apr (v1.7.0). >> This issue >> https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbz.apache.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D64753data=04%7C01%7Cbrian.paquin%40yale.edu%7C4a009b9f4c19439afc4708d87a95d92e%7Cdd8cbebb21394df8b4114e3e87abeb5c%7C0%7C0%7C637394131299938700%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=WdzfXIIBvFQzON0aA2Q3EHqNyHK2bFqXpGYm2aEyi1A%3Dreserved=0 >> provided a diff patch that adds “#include ” in a number of >> locations. >> Applying this patch allowed me to compile httpd! > > Weird. pid_it is defined in and yet the patch adds > to fix it. > > I don't have access to my Catalina machine right now, but my clang-based > Mojave machine still says to use when you "man getpid": > > " > GETPID(2) BSD System Calls Manual > > NAME > getpid, getppid -- get parent or calling process identification > > SYNOPSIS > #include > > pid_t > getpid(void); > " > > $ cc --version > Apple LLVM version 10.0.1 (clang-1001.0.46.4) > Target: x86_64-apple-darwin18.7.0 > Thread model: posix > InstalledDir: /Library/Developer/CommandLineTools/usr/bin > >> Now I am trying to compile mod_jk (v1.2.48), and I get the same error. >> Does someone have a patch file I can use to get around this issue? >> $ ./configure CFLAGS='-arch x86_64' APXSLDFLAGS='-arch x86_64' >> --with-apxs=/usr/local/apache2/bin/apxs >> >> $ make >> >> Making all in common >> /usr/local/apache-2.4.46/build/libtool --silent --mode=compile gcc -I. >> -I/usr/local/apache-2.4.46/include -arch x86_64 -DHAVE_CONFIG_H -arch x86_64 >> -DHAVE_APR -I/usr/local/apache-2.4.46/include >> -I/usr/local/apache-2.4.46/include -arch x86_64 -DHAVE_CONFIG_H -DDARWIN >> -DSIGPROCMASK_SETS_THREAD_MASK -DDARWIN_10 -c jk_ajp12_worker.c -o >> jk_ajp12_worker.lo >> In file included from jk_ajp12_worker.c:25: >> In file included from ./jk_ajp12_worker.h:26: >> In file included from ./jk_logger.h:26: >> In file included from ./jk_global.h:340: >> ./jk_types.h:56:2: error: Can not determine the proper size for pid_t >> #error Can not determine the proper size for pid_t >> ^ >> ./jk_types.h:62:2: error: Can not determine the proper size for pthread_t >> #error Can not determine the proper size for pthread_t >> ^ >> 2 errors generated. >> make[1]: *** [jk_ajp12_worker.lo] Error 1 >> make: *** [all-recursive] Error 1 >> $ > > I'm sorry, I have no idea how configure does its magic. The auto-generated > jk_types.h looks like a hand-wavy template to me. > > You can probably hack it briefly by running "configure" (which you already > did) and then hand-editing include/jk_types.h (ignoring the warning NOT to > hand-edit it!) and manually adding: > > #include > > to the top. I added the line above to ./tomcat-connectors-1.2.48-src/native/common/jk_types.h and tried running make again but got the same error. I do not have an include directory in ./tomcat-connectors-1.2.48-src/native/. Any other suggestions? I really appreciate your help! Brian > Give that a try and see if it works. > > -chris > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: mod_jk "Can not determine the proper size for pid_t" on macOS 10.15.7
Brian On 10/26/20 15:33, Paquin, Brian wrote: I’m trying to build httpd and mod_jk for the first time on a macOS 10.15.7 box. XCode 12.1 is installed and I was able to compile OpenSSL 1.1.1g. I got an error “Can not determine the proper size for pid_t” when compiling httpd (v2.4.46) with included apr (v1.7.0). This issue https://bz.apache.org/bugzilla/show_bug.cgi?id=64753 provided a diff patch that adds “#include ” in a number of locations. Applying this patch allowed me to compile httpd! Weird. pid_it is defined in and yet the patch adds to fix it. I don't have access to my Catalina machine right now, but my clang-based Mojave machine still says to use when you "man getpid": " GETPID(2) BSD System Calls Manual NAME getpid, getppid -- get parent or calling process identification SYNOPSIS #include pid_t getpid(void); " $ cc --version Apple LLVM version 10.0.1 (clang-1001.0.46.4) Target: x86_64-apple-darwin18.7.0 Thread model: posix InstalledDir: /Library/Developer/CommandLineTools/usr/bin Now I am trying to compile mod_jk (v1.2.48), and I get the same error. Does someone have a patch file I can use to get around this issue? $ ./configure CFLAGS='-arch x86_64' APXSLDFLAGS='-arch x86_64' --with-apxs=/usr/local/apache2/bin/apxs $ make Making all in common /usr/local/apache-2.4.46/build/libtool --silent --mode=compile gcc -I. -I/usr/local/apache-2.4.46/include -arch x86_64 -DHAVE_CONFIG_H -arch x86_64 -DHAVE_APR -I/usr/local/apache-2.4.46/include -I/usr/local/apache-2.4.46/include -arch x86_64 -DHAVE_CONFIG_H -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -DDARWIN_10 -c jk_ajp12_worker.c -o jk_ajp12_worker.lo In file included from jk_ajp12_worker.c:25: In file included from ./jk_ajp12_worker.h:26: In file included from ./jk_logger.h:26: In file included from ./jk_global.h:340: ./jk_types.h:56:2: error: Can not determine the proper size for pid_t #error Can not determine the proper size for pid_t ^ ./jk_types.h:62:2: error: Can not determine the proper size for pthread_t #error Can not determine the proper size for pthread_t ^ 2 errors generated. make[1]: *** [jk_ajp12_worker.lo] Error 1 make: *** [all-recursive] Error 1 $ I'm sorry, I have no idea how configure does its magic. The auto-generated jk_types.h looks like a hand-wavy template to me. You can probably hack it briefly by running "configure" (which you already did) and then hand-editing include/jk_types.h (ignoring the warning NOT to hand-edit it!) and manually adding: #include to the top. Give that a try and see if it works. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
mod_jk "Can not determine the proper size for pid_t" on macOS 10.15.7
I’m trying to build httpd and mod_jk for the first time on a macOS 10.15.7 box. XCode 12.1 is installed and I was able to compile OpenSSL 1.1.1g. I got an error “Can not determine the proper size for pid_t” when compiling httpd (v2.4.46) with included apr (v1.7.0). This issue https://bz.apache.org/bugzilla/show_bug.cgi?id=64753 provided a diff patch that adds “#include ” in a number of locations. Applying this patch allowed me to compile httpd! Now I am trying to compile mod_jk (v1.2.48), and I get the same error. Does someone have a patch file I can use to get around this issue? $ ./configure CFLAGS='-arch x86_64' APXSLDFLAGS='-arch x86_64' --with-apxs=/usr/local/apache2/bin/apxs $ make Making all in common /usr/local/apache-2.4.46/build/libtool --silent --mode=compile gcc -I. -I/usr/local/apache-2.4.46/include -arch x86_64 -DHAVE_CONFIG_H -arch x86_64 -DHAVE_APR -I/usr/local/apache-2.4.46/include -I/usr/local/apache-2.4.46/include -arch x86_64 -DHAVE_CONFIG_H -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -DDARWIN_10 -c jk_ajp12_worker.c -o jk_ajp12_worker.lo In file included from jk_ajp12_worker.c:25: In file included from ./jk_ajp12_worker.h:26: In file included from ./jk_logger.h:26: In file included from ./jk_global.h:340: ./jk_types.h:56:2: error: Can not determine the proper size for pid_t #error Can not determine the proper size for pid_t ^ ./jk_types.h:62:2: error: Can not determine the proper size for pthread_t #error Can not determine the proper size for pthread_t ^ 2 errors generated. make[1]: *** [jk_ajp12_worker.lo] Error 1 make: *** [all-recursive] Error 1 $ Brian
Tomcat mod_jk rpm-build for CentOS-8 - exit with error.
@Klaus Trachtler: Managed to build mod_jk RPM for CentOS8. See https://gist.github.com/robertoschwald/3317b4d777f44260fef86c5059955ffc
Re: request.getLocatHost() Different with port 80 vs mod_jk
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jerry, On 7/18/20 18:29, Jerry Malcolm wrote: > I'm taking Christopher's advice to remove httpd and mod_jk out of > my process and go straight to Tomcat on port 80. At this point the > only thing I've done is stop the httpd service and change the > Connector port to 80. I'm running on my local machine. I have a > hosts entry set to "local.a.com 127.0.0.1", and I use the url > http://local.a.com to access the site. When I use the old > setup with httpd/mod_jk, a call to request.getLocalHost() returns > "local.a.com" as expected. getLocalAddr or getLocalName? getLocalHost isn't in the API. > After doing nothing but changing to go straight to TC on port 80, > getLocalHost() returns 127.0.0.1.request.getRequestURL() still > gives me the http://local.a.com. Theoretically, I could > change my code to parse getRequestURL() instead of getLocalHost() > to get the real host name. But I don't really want to do that > without understanding why I'm seeing the change. Is there > something else I need to add to the config file when moving to > direct port 80 off of mod_jk? Ideas? BTW... I'm on TC 9.0.16. Wild guess: Tomcat doesn't bother to resolve the "127.0.0.1" into a hostname when you call getLocalName, but the AJP connector will accept this hostname from the reverse proxy... and httpd DOES resolve it for you. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8UP6oACgkQHPApP6U8 pFgzKg/9Hj67KnafXpQymCy8wSicDf8u1QvXNxdIN8poiLWSrwml3HwlBLdibYRH MPqZOrmV+WFTEzTxjhREb3qUxQkcN2rEWFp4fYZmMS5VB8gyOBVMcCp381SNbHUa pX7Nftr0ofCznhSQZmuCnBrR8+HGNNoucYLrfTPCMhuMrja+JtYNhrC+pQnTO6ZI ZBVKxoTuUhxQltVleqotC1bISNq70W6gG0CImi/k435b+ujK6qSEGVUBdLs1Q6RZ db/a2TaWjXlBi3yRQqRT852tpeo/kSAapzJX41wzKuQeDiysM0+scJmq8lrERMdO mDugoePcxpNpOgCUsa8YznPro4Snt0MZM9fApO/PTNfzHlftS2FMQEidmFNl+03i zkbQ/TNcRa2pKM5ivvqnqIJF1aJWPwD5Qfw7E+h+ovaVMxftOyB86z2/SxGqG5un TbMZZlJqp2PqchuTUpCuEtnOWYdzGmNnUSxPJhNpxguQ80BQj2EeGr2dX626+2VA 56tBqK97HXgmRzJoa5JAJJx+AYKBEenSDW3HlWVoHm2Lshni7P9rqPVGzUROEV6/ McYDww9ukuw6jyz2owepFwVmym3q2s/apBdnTEbJUL4GR48bwI3O6iwogE7FLgGD aLqbYYnlOf5KsdvzHFtnqKQcERHCZDDhKE+a05ijLNho3JHqZG0= =pKGS -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
request.getLocatHost() Different with port 80 vs mod_jk
I'm taking Christopher's advice to remove httpd and mod_jk out of my process and go straight to Tomcat on port 80. At this point the only thing I've done is stop the httpd service and change the Connector port to 80. I'm running on my local machine. I have a hosts entry set to "local.a.com 127.0.0.1", and I use the url http://local.a.com to access the site. When I use the old setup with httpd/mod_jk, a call to request.getLocalHost() returns "local.a.com" as expected. After doing nothing but changing to go straight to TC on port 80, getLocalHost() returns 127.0.0.1. request.getRequestURL() still gives me the http://local.a.com. Theoretically, I could change my code to parse getRequestURL() instead of getLocalHost() to get the real host name. But I don't really want to do that without understanding why I'm seeing the change. Is there something else I need to add to the config file when moving to direct port 80 off of mod_jk? Ideas? BTW... I'm on TC 9.0.16. Thanks. Jerry - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat mod_jk rpm-build for CentOS-8 - exit with error.
Hi Klaus,
Am 06.07.2020 um 15:13 schrieb Klaus Tachtler:
> Hi,
>
> I'm trying to build a rpm package for CentOS-8 for mod_jk with the
> latest version 1.2.48. While building the rpm package, following error
> occurs:
>
>
> - %< -
>
> ...
> make[1]: Entering directory
> '/root/rpmbuild/BUILD/tomcat-connectors-1.2.48-src/native/apache-2.0'
> /usr/lib64/apr-1/build/libtool --silent --mode=link gcc
> -I/usr/include/httpd -O2 -g -pipe -Wall -Werror=format-security
> -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions
> -fstack-protector-strong -grecord-gcc-switches
> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
> -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
> -DHAVE_CONFIG_H -DUSE_APACHE_MD5 -I../common -I ../common -DLINUX
> -D_REENTRANT -D_GNU_SOURCE -O2 -g -pipe -Wall -Werror=format-security
> -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions
> -fstack-protector-strong -grecord-gcc-switches
> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
> -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
> -pthread -DHAVE_APR -I/usr/include/apr-1 -I/usr/include/apr-1 -O2 -g
> -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
> -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong
> -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
> -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
> -DHAVE_CONFIG_H -O2 -g -pipe -Wall -Werror=format-security
> -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions
> -fstack-protector-strong -grecord-gcc-switches
> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
> -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
> -I/usr/include/apr-1 -Wl,-z,relro,-z,now -Wl,-z,relro -Wl,-z,now
> -Wl,-specs=/usr/lib/rpm/redhat/redhat-hardened-ld -o mod_jk.la -module
> -rpath /usr/lib64/httpd/modules -avoid-version mod_jk.lo
> ../common/jk_ajp12_worker.lo ../common/jk_connect.lo
> ../common/jk_msg_buff.lo ../common/jk_util.lo ../common/jk_ajp13.lo
> ../common/jk_pool.lo ../common/jk_worker.lo ../common/jk_ajp13_worker.lo
> ../common/jk_lb_worker.lo ../common/jk_sockbuf.lo ../common/jk_map.lo
> ../common/jk_uri_worker_map.lo ../common/jk_ajp14.lo
> ../common/jk_ajp14_worker.lo ../common/jk_md5.lo ../common/jk_shm.lo
> ../common/jk_ajp_common.lo ../common/jk_context.lo ../common/jk_url.lo
> ../common/jk_status.lo
> /usr/bin/ld: unrecognized option
> '-specs=/usr/lib/rpm/redhat/redhat-hardened-ld'
> /usr/bin/ld: use the --help option for usage information
> collect2: error: ld returned 1 exit status
> make[1]: *** [Makefile:83: mod_jk.la] Error 1
> make[1]: Leaving directory
> '/root/rpmbuild/BUILD/tomcat-connectors-1.2.48-src/native/apache-2.0'
> make: *** [Makefile:470: all-recursive] Error 1
> error: Bad exit status from /var/tmp/rpm-tmp.O4kRZI (%build)
>
> ----- >% -
Does it build without the specfile? I tried to reproduce it in a simple
Dockerfile. This works so far - can you show us your .spec-file?
Sample Dockerfile to build mod_jk on CentOS 8
FROM centos:8
ARG JK_VERSION=1.2.48
ARG
REMOTE_URL=https://downloads.apache.org/tomcat/tomcat-connectors/jk/tomcat-connectors-${JK_VERSION}-src.tar.gz
RUN yum --assumeyes --quiet update && \
yum --assumeyes --quiet install \
diffutils \
file \
gcc \
httpd-devel \
libtool \
make \
redhat-rpm-config && \
yum clean all
RUN cd /usr/src && \
curl --silent --remote-name ${REMOTE_URL} && \
tar -xzf tomcat-connectors-${JK_VERSION}-src.tar.gz && \
cd tomcat-connectors-${JK_VERSION}-src/native && \
./configure --with-apxs=/usr/bin/apxs && \
make && \
libtool --finish /usr/lib64/httpd/modules && \
make install
Regards,
Stefan
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Monitoring Connections and Limits Thru HTTPD/mod_jk/Tomcat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jerry, On 7/7/20 18:32, Jerry Malcolm wrote: > I going to assume that the reason I have apache httpd in there is > 'because I always have had it there' is not going to go over well > as a good reason, huh? I mean... if you want to do more work and worry abot more resources, free free to leave it in there. IMO the only reason to use httpd is if you need something more complicated than what e.g. ELB can provide for you. For example, classic ELB can't separate between two (or more) applications running on each node under the same (external) hostname and port. (Maybe Application Load Balancers can, but I haven't used them .) So if you have /foo and /bar applications then you need a reverse proxy in addition to the ELB. Another reason might be some kind of authentication system which is plugged-into httpd but is not possible (or inconvenient) to configure in Tomcat. > I used to use it to serve static files. But that is pretty much > taken over by S3 now. I still use it for the SSL stuff. ELB can handle TLS termination. If you want to use TLS between ELB and your Tomcat instances, there's no particular reason to use httpd for that: just use NIO+OpenSSL and you'll have comparable performance. > But that's primarily because it worked, and I hadn't yet learned > how to set up SSL in TC. It's "easy" in the sense that is't not much more complicated than doing it anywhere else. If you are familiar with all the pieces and parts, you just need to know how to configure them in Tomcat. The complexity of the process is in the whole x509/CA relationship, etc. and not configuring the server itself. > It would definitely simplify things to get httpd out of the picture > and go straight to Tomcat. I'll start looking into trying that in > a sandbox and see if we can't simplify things. I still have to > worry about maxing out connections. > > But an 'only-Tomcat' solution might ease a bit of the worries. If you remove httpd, you should be cutting your connection count in half, which I assume is a win for you. > At least we can focus on one thing only. Thanks for the info and > the link. I'll probably be back with more questions... :-) Maybe start with configuring Tomcat for TLS. Modern Tomcats basically just take this from httpd: SSLProtocol [protocols] SSLCertificateFile /path/to/key/and/cert/chain SSLHonorCipherOrder On SSLCipherSuite [cipher-suite-spec] And turn it into this in Tomcat: ... I'm not sure why both httpd and Tomcat's documentation say that having a single file containing both the server's key and certificate is "(NOT RECOMMENDED)". I see no security issues with that setup. You are free to have separate files if you'd like. You can also use a keystore to store your stuff but I find keystores to be cumbersome and like PEM-encoded DER files better. Leave httpd installed and configured, but just turn off the service and maybe change the port number ELB is using to contact your server (point it at :8080 instead of :80) and get Tomcat working. Once it's working, you can start looking at monitoring. Do you want to know how to monitor the instance so you can tell the ELB when to auto-scale (up or down), or do you just want to "keep an eye" on things so you can check to see if auto-scaling is "doing its job "? Thanks, - -chris > On 7/7/2020 5:23 PM, Christopher Schultz wrote: Jerry, > > On 7/7/20 16:50, Jerry Malcolm wrote: >>>> I'm setting up an environment that has the potential for a >>>> large number of simultaneous requests coming in. I have a >>>> basic Apache HTTPD with mod_jk talking to Tomcat, all on the >>>> same Amazon EC2 instance. From my understanding, I have the >>>> potential of maxing out connections at httpd, at mod_jk, and >>>> also at Tomcat. > Yes, and you'll also need enough file handles and ports available > for all that. If one client-connection requires a connection to the > web server (1 file handle, 1 port) and a connection from > httpd->Tomcat (2 file handles, 2 ports), it may add up quickly. > > Are you sure you need httpd at all? I assume since you are AWS > that you are using a load-balancer. What purpose does httpd serve > in your setup? > >>>> We are looking at setting up monitors to track all of this. >>>> But I don't want to reinvent the wheel if there are others >>>> who have created solutions for this. Is there documentation >>>> on guidelines for configuring connections on all three so >>>> that they work together smoothly? > The golden rule applies, here, but that mostly affects you when > you have a multi-node cross-linked network like this: > > httpd 1 -\ /- Tomcat 1 httpd 2 -- Tomcat 2 httpd 3 -/ \- > Tom
Re: Monitoring Connections and Limits Thru HTTPD/mod_jk/Tomcat
I going to assume that the reason I have apache httpd in there is 'because I always have had it there' is not going to go over well as a good reason, huh? I used to use it to serve static files. But that is pretty much taken over by S3 now. I still use it for the SSL stuff. But that's primarily because it worked, and I hadn't yet learned how to set up SSL in TC. It would definitely simplify things to get httpd out of the picture and go straight to Tomcat. I'll start looking into trying that in a sandbox and see if we can't simplify things. I still have to worry about maxing out connections. But an 'only-Tomcat' solution might ease a bit of the worries. At least we can focus on one thing only. Thanks for the info and the link. I'll probably be back with more questions... :-) Jerry On 7/7/2020 5:23 PM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jerry, On 7/7/20 16:50, Jerry Malcolm wrote: I'm setting up an environment that has the potential for a large number of simultaneous requests coming in. I have a basic Apache HTTPD with mod_jk talking to Tomcat, all on the same Amazon EC2 instance. From my understanding, I have the potential of maxing out connections at httpd, at mod_jk, and also at Tomcat. Yes, and you'll also need enough file handles and ports available for all that. If one client-connection requires a connection to the web server (1 file handle, 1 port) and a connection from httpd->Tomcat (2 file handles, 2 ports), it may add up quickly. Are you sure you need httpd at all? I assume since you are AWS that you are using a load-balancer. What purpose does httpd serve in your setup? We are looking at setting up monitors to track all of this. But I don't want to reinvent the wheel if there are others who have created solutions for this. Is there documentation on guidelines for configuring connections on all three so that they work together smoothly? The golden rule applies, here, but that mostly affects you when you have a multi-node cross-linked network like this: httpd 1 -\ /- Tomcat 1 httpd 2 -- Tomcat 2 httpd 3 -/ \- Tomcat 3 You have to make sure that if for some reason ALL conecctions from ALL THREE web servers come-down on a SINGLE Tomcat node that it can handle that number of connections. Those numbers are sometimes surprising to people. If you have max-connections on each web server set to 200 then each Tomcat needs to have a max-connections limit of 600, not 200. We are setting up load-balancing on Amazon that will launch another EC2 instance if one EC2 get overwhelmed. But that is obviously dependent upon accurately tracking and recognizing that the EC2 is indeed becoming overwhelmed. Any advice on where to start with this? First, I would find ways to get httpd out of the picture. That will significantly reduce the complexity of the situation. If httpd is providing significant value, then it's fine to leave it there: I'm not in a crusade to remove httpd from the world; I'm just trying to remove unnecessary components if they aren't providing value. It used to be that Tomcat had to be fronted by a reverse-proxy for a number of reasons (like mod_proxy not existing, for instance. Or that TLS performance was awful. Or that httpd could significantly improve response-times for static-content. None of that has been true for a long time, now. In terms of monitoring, feel free to have a look at my Monitoring presentation[1] which may help get you started. It talks about monitoring Tomcat connections only, but you could use similar techniques to monitor httpd and also EC2. The only knowledge I have about Amazon's auto-scaling is that it exists. I'm really hoping someone will step-up and do an ApacheCon presentation about cloud-native deployments of Tomcat in EC2 to take advantage of things like auto-scaling, etc. Maybe you could be the one to do it (seriously)! - -chris [1] http://tomcat.apache.org/presentations.html#latest-monitoring-with-j mx -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8E9cgACgkQHPApP6U8 pFj8dhAAyShiMv2XtdlKQyaMzqpYhl0MCnrGGwtO9244P/eMPVgDJoHKw837H4iD cPPr9BL7nYT4O5v0F6honS33ykzhddXhefIw8nAFQcZEkRkoJl/XlP4mGLQyf78E JUvnSW+/7xuL+oJ3FGdpo5nQMnkTj4odnXwN3aHRPSz2yxpGZhlRKXxV3e6z4ama Js5L9Ztc3T896oaDzzrA459M8/xm5eyUv5OaJIrPkGRE5kXB7i6IqpKDWRWZ56bU FZlbAeKB3aoZx9Orj2tLp8YuOEcNVkSEPNLcpVnL+l/SMlkQUbxlHspejOBHE1sk f2lyFTZ593Gqm3yzAk1HBT4A3QfPVPz5JKAEYm0RLpmq0zzkTKvSWZARYnGGQQZd hZKGYaj1aafPIvSpsUlb4VJt22GxtkQk0PZ2d025KcZsX8TfFoV0mmbm3a/BDITT /cP4h23OyReUgESrXQlHA2j8QDF4bmQnRxilPTXZXqkOIFXw/EdtAjLBoJ/U0wdT S4jStnqqu3HkofshSNcGGLJ0K2LvopCnPk3449qcYSWcZN8xZ9OXfC8RYr17zqc3 FNlfPEreoEMqxxca39QDGcN2uSWeswZ9gZXsaz5tbYGs4wJLwRU4uSAfrvMB9eGd 9RFVIendlLa1hf3Rb3nevSxuXlSp6KyhuweU6R5pLQyubMM7ahM= =FjkO -END PGP SIGNATURE- - To unsubscribe
Re: Monitoring Connections and Limits Thru HTTPD/mod_jk/Tomcat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jerry, On 7/7/20 16:50, Jerry Malcolm wrote: > I'm setting up an environment that has the potential for a large > number of simultaneous requests coming in. I have a basic Apache > HTTPD with mod_jk talking to Tomcat, all on the same Amazon EC2 > instance. From my understanding, I have the potential of maxing > out connections at httpd, at mod_jk, and also at Tomcat. Yes, and you'll also need enough file handles and ports available for all that. If one client-connection requires a connection to the web server (1 file handle, 1 port) and a connection from httpd->Tomcat (2 file handles, 2 ports), it may add up quickly. Are you sure you need httpd at all? I assume since you are AWS that you are using a load-balancer. What purpose does httpd serve in your setup? > We are looking at setting up monitors to track all of this. But I > don't want to reinvent the wheel if there are others who have > created solutions for this. Is there documentation on guidelines > for configuring connections on all three so that they work together > smoothly? The golden rule applies, here, but that mostly affects you when you have a multi-node cross-linked network like this: httpd 1 -\ /- Tomcat 1 httpd 2 -- Tomcat 2 httpd 3 -/ \- Tomcat 3 You have to make sure that if for some reason ALL conecctions from ALL THREE web servers come-down on a SINGLE Tomcat node that it can handle that number of connections. Those numbers are sometimes surprising to people. If you have max-connections on each web server set to 200 then each Tomcat needs to have a max-connections limit of 600, not 200. > We are setting up load-balancing on Amazon that will launch another > EC2 instance if one EC2 get overwhelmed. But that is obviously > dependent upon accurately tracking and recognizing that the EC2 is > indeed becoming overwhelmed. Any advice on where to start with > this? First, I would find ways to get httpd out of the picture. That will significantly reduce the complexity of the situation. If httpd is providing significant value, then it's fine to leave it there: I'm not in a crusade to remove httpd from the world; I'm just trying to remove unnecessary components if they aren't providing value. It used to be that Tomcat had to be fronted by a reverse-proxy for a number of reasons (like mod_proxy not existing, for instance. Or that TLS performance was awful. Or that httpd could significantly improve response-times for static-content. None of that has been true for a long time, now. In terms of monitoring, feel free to have a look at my Monitoring presentation[1] which may help get you started. It talks about monitoring Tomcat connections only, but you could use similar techniques to monitor httpd and also EC2. The only knowledge I have about Amazon's auto-scaling is that it exists. I'm really hoping someone will step-up and do an ApacheCon presentation about cloud-native deployments of Tomcat in EC2 to take advantage of things like auto-scaling, etc. Maybe you could be the one to do it (seriously)! - -chris [1] http://tomcat.apache.org/presentations.html#latest-monitoring-with-j mx -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8E9cgACgkQHPApP6U8 pFj8dhAAyShiMv2XtdlKQyaMzqpYhl0MCnrGGwtO9244P/eMPVgDJoHKw837H4iD cPPr9BL7nYT4O5v0F6honS33ykzhddXhefIw8nAFQcZEkRkoJl/XlP4mGLQyf78E JUvnSW+/7xuL+oJ3FGdpo5nQMnkTj4odnXwN3aHRPSz2yxpGZhlRKXxV3e6z4ama Js5L9Ztc3T896oaDzzrA459M8/xm5eyUv5OaJIrPkGRE5kXB7i6IqpKDWRWZ56bU FZlbAeKB3aoZx9Orj2tLp8YuOEcNVkSEPNLcpVnL+l/SMlkQUbxlHspejOBHE1sk f2lyFTZ593Gqm3yzAk1HBT4A3QfPVPz5JKAEYm0RLpmq0zzkTKvSWZARYnGGQQZd hZKGYaj1aafPIvSpsUlb4VJt22GxtkQk0PZ2d025KcZsX8TfFoV0mmbm3a/BDITT /cP4h23OyReUgESrXQlHA2j8QDF4bmQnRxilPTXZXqkOIFXw/EdtAjLBoJ/U0wdT S4jStnqqu3HkofshSNcGGLJ0K2LvopCnPk3449qcYSWcZN8xZ9OXfC8RYr17zqc3 FNlfPEreoEMqxxca39QDGcN2uSWeswZ9gZXsaz5tbYGs4wJLwRU4uSAfrvMB9eGd 9RFVIendlLa1hf3Rb3nevSxuXlSp6KyhuweU6R5pLQyubMM7ahM= =FjkO -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Monitoring Connections and Limits Thru HTTPD/mod_jk/Tomcat
I'm setting up an environment that has the potential for a large number of simultaneous requests coming in. I have a basic Apache HTTPD with mod_jk talking to Tomcat, all on the same Amazon EC2 instance. From my understanding, I have the potential of maxing out connections at httpd, at mod_jk, and also at Tomcat. We are looking at setting up monitors to track all of this. But I don't want to reinvent the wheel if there are others who have created solutions for this. Is there documentation on guidelines for configuring connections on all three so that they work together smoothly? We are setting up load-balancing on Amazon that will launch another EC2 instance if one EC2 get overwhelmed. But that is obviously dependent upon accurately tracking and recognizing that the EC2 is indeed becoming overwhelmed. Any advice on where to start with this? Thanks. Jerry - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat mod_jk rpm-build for CentOS-8 - exit with error.
Hi, I'm trying to build a rpm package for CentOS-8 for mod_jk with the latest version 1.2.48. While building the rpm package, following error occurs: - %< - ... make[1]: Entering directory '/root/rpmbuild/BUILD/tomcat-connectors-1.2.48-src/native/apache-2.0' /usr/lib64/apr-1/build/libtool --silent --mode=link gcc -I/usr/include/httpd -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -DHAVE_CONFIG_H -DUSE_APACHE_MD5 -I../common -I ../common -DLINUX -D_REENTRANT -D_GNU_SOURCE -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -pthread -DHAVE_APR -I/usr/include/apr-1 -I/usr/include/apr-1 -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -DHAVE_CONFIG_H -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -I/usr/include/apr-1 -Wl,-z,relro,-z,now -Wl,-z,relro -Wl,-z,now -Wl,-specs=/usr/lib/rpm/redhat/redhat-hardened-ld -o mod_jk.la -module -rpath /usr/lib64/httpd/modules -avoid-version mod_jk.lo ../common/jk_ajp12_worker.lo ../common/jk_connect.lo ../common/jk_msg_buff.lo ../common/jk_util.lo ../common/jk_ajp13.lo ../common/jk_pool.lo ../common/jk_worker.lo ../common/jk_ajp13_worker.lo ../common/jk_lb_worker.lo ../common/jk_sockbuf.lo ../common/jk_map.lo ../common/jk_uri_worker_map.lo ../common/jk_ajp14.lo ../common/jk_ajp14_worker.lo ../common/jk_md5.lo ../common/jk_shm.lo ../common/jk_ajp_common.lo ../common/jk_context.lo ../common/jk_url.lo ../common/jk_status.lo /usr/bin/ld: unrecognized option '-specs=/usr/lib/rpm/redhat/redhat-hardened-ld' /usr/bin/ld: use the --help option for usage information collect2: error: ld returned 1 exit status make[1]: *** [Makefile:83: mod_jk.la] Error 1 make[1]: Leaving directory '/root/rpmbuild/BUILD/tomcat-connectors-1.2.48-src/native/apache-2.0' make: *** [Makefile:470: all-recursive] Error 1 error: Bad exit status from /var/tmp/rpm-tmp.O4kRZI (%build) - >% - Any ideas how can I solve that problem? Thank you in advance! Klaus. -- --- e-Mail : kl...@tachtler.net Homepage: https://www.tachtler.net DokuWiki: https://dokuwiki.tachtler.net --- binQ1HNUvMZAY.bin Description: Öffentlicher PGP-Schlüssel - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: mod_jk and application deployed check
Il giorno ven, 29/05/2020 alle 14.09 -0400, Christopher Schultz ha scritto: > Giuseppe, > > On 5/29/20 11:57, Giuseppe Sacco wrote: > > [...] > > misconfigured machines and failed with 404 errors. From what I > > understood, the mod_jk protocol only allows to check it tomcat is > > alive. Is it possibile to also check if an application is deployed > > (giving a dedicated URL in the application context)? Thank > > you,Giuseppe > > One way to do this would be to create a ROOT context which returns > something other than 404 for all requests. Maybe return 500 status > for > example. > > If /myapp/ isn't deployed, the ROOT web application will respond with > 500 and mod_jk will mark the node as degraded. Thank you Cris, I am going to try this solution. Bye, Giuseppe signature.asc Description: This is a digitally signed message part
Re: mod_jk and application deployed check
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Giuseppe, On 5/29/20 11:57, Giuseppe Sacco wrote: > Hello,I have an apache httpd with mod_jk that load balance > requests among two different tomcat servers.Today, one of the > tomcat servers has been rebooted and tomcat could not deploy the > application since it failed to find a configuration file. Please > note that tomcat was running correctly, only the application deploy > failed. The balancer could not understand that one of the servers > was not to be used: half of the requests were going to the > misconfigured machines and failed with 404 errors. From what I > understood, the mod_jk protocol only allows to check it tomcat is > alive. Is it possibile to also check if an application is deployed > (giving a dedicated URL in the application context)? Thank > you,Giuseppe One way to do this would be to create a ROOT context which returns something other than 404 for all requests. Maybe return 500 status for example. If /myapp/ isn't deployed, the ROOT web application will respond with 500 and mod_jk will mark the node as degraded. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl7RT/EACgkQHPApP6U8 pFj54RAAqkYbZTloR0qMqcgB9THgj8OvE9+6CIq3Ls7LngeFbgkdjxQzO/vtJOgF HkGYxjsSidA+N/58VN3ZFuRro+IwkrxWHzmXr8wMQKnOaDnr1oAYFWiOIZ8v5inh 5FHM3Wk0Nqb7YUP5D/PVrR4IQcC7DGRU8X21kRB1+3YZJpaf/HHzr0P1j8up7DTj 3qPhf5gvkNDa5/vnGqgoj6RjYGtVtUsE2VqIPAIMQU4Fh1ZZJcU68KjqCsxo5IhM QmGsX/qWLm5HAMYWuChSMy+LKGjQNfTWYkqW+h0O4rsM3bbfT7upQiqQE4d9UPQQ k5nAJ71cBJu3m9oh8ClpQn2HtKDefJW2NfrzdbMlpgQ2CVio9IhCLQMVtmAagNz9 XXahmnAveiTfdKBbfk2JN/MtnU1Tp/0HiXTRravURqp3ffReJWWKF3yz3mzyn+kG DmaTYLqIIFZAd3l1UiPazmSEB2Sw23abI6+yqMkXZEjiWNM9WhS/zooAe+UwF9K6 VP1uznctMvaOXegCaUgAo/f7liFGqTsk95KEdGrN4NAoBYbJrzB4Wbli3zdZbI0E EfEASAr0Rb2o5fnd/6RNRFJoC9etbi3dPOvUUI+bOw4oNQUIBpFp43rli3ycUxtB qJLFaaxrlb7Jlwt13dMtJiyLw3P9zRZQkO7WNIS+DVGvmShDq88= =yngg -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
mod_jk and application deployed check
Hello,I have an apache httpd with mod_jk that load balance requests among two different tomcat servers.Today, one of the tomcat servers has been rebooted and tomcat could not deploy the application since it failed to find a configuration file. Please note that tomcat was running correctly, only the application deploy failed. The balancer could not understand that one of the servers was not to be used: half of the requests were going to the misconfigured machines and failed with 404 errors. >From what I understood, the mod_jk protocol only allows to check it tomcat is alive. Is it possibile to also check if an application is deployed (giving a dedicated URL in the application context)? Thank you,Giuseppe
Re: [semi-OT] tomcat 7.0.100 AJP connector with mod_jk on another host
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Thomas, On 3/4/20 19:37, Thomas Glanzmann wrote: > allowedRequestAttributesPattern=JK_LB_ACTIVATION Note that JK_LB_ACTIVATION is already in the list of white-listed attribute names. You should probably not have to set this configuration attribute. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5iaHIACgkQHPApP6U8 pFhBjg//Un1JwuTVjpcLHOi+Tat3alJg4X4wGUuLs0N99OX7SHhum7O6WAOw0h0H 0onbgHAk8AKuCOJgJnndh5pcV5iFIF45fSMd5exhq1SBOAdKf01LHqqeuL7FuIpk 37nTduULel8KOqb7i05eGBrelcZAJTu1MoeL6+4DGAFGWHb9IgD1R7CxhYCSVvIf Ud1QtwRpr2SBpQVTmu54FFJhhGJfe48UPGge4Pu/i/r7ahAL/0Y26OMJ53xMN7Q3 sYPjF1/HUJSG4ogyxWatVw1w02bY0mwtbzcaeHnv5ItOJzzxzdweRgpKJUgPUC+y ungG3cYcUeNCsT9aJcPt6m3OEivK3emuOWPhgnEtRUH09WG5XmuRkvOGa7+krxEj xCEa4XDq2OK32NWJFDyGJHfvVv42mgKCcPNupVUZ8ap35T4RqccMzGLfkvi14Hmn mLxYgHz9f5nb0T95fPSu+R7jzSEYy3jiwzjAcVte27fvCyJhTTGQep95FXOacp34 Efxrt+w9p1P5yzzExK99WQ9IYp/gA94GiXz+jv5lJIt4Zc0PSyTnUcH8ZAslSF8Z ZKp73664o04RnKHNYF6TiyQEtZtsq4i2W0HhcAgOoGL3S0KU35G8h4B2oQnRKwrS sUGG7cVhNGbuDdpShqgak3iw3U0Hdui9FNfS0YYI3ZFHSdIGvnE= =V+Hw -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat 7.0.100 AJP connector with mod_jk on another host
On 06/03/2020 06:46, Thomas Glanzmann wrote: > the issue seems to be that mod_jk no longer works without a password > with tomcat7. So you need to set a password on both sites, and than > everything works again. This is not the case. Tomcat can be configured so a secret is not required. > server.xml: > > secret="verysecure" secretRequired="true"/> > > workers.properties of mod_jk > > worker.tomcat-06.secret=verysecure That won't work when httpd/mod_jk is on a separate host to Tomcat (as per the subject of this thread). > If I do _not_ set a password I'm getting a 403 no matter what I do. That is a configuration issue. The equivalent Tomcat configuration to that quoted above that will not require a password is: Note: With 7.0.100 if you specify a secret, even an empty string, the client must provide a matching secret irrespective of the setting of secretRequired. secretRequired determines if the secret attribute must be set in the configuration, not whether the client has to provide a secret. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat 7.0.100 AJP connector with mod_jk on another host
Hello, > If you don't set secretRequired="false" properly then at start time Tomcat > will complain if there is no specified "secret" attribute. > If it doesn't complain then most probably you are testing again with the > wrong server.xml or old version of Tomcat. the issue seems to be that mod_jk no longer works without a password with tomcat7. So you need to set a password on both sites, and than everything works again. server.xml: workers.properties of mod_jk worker.tomcat-06.secret=verysecure If I do _not_ set a password I'm getting a 403 no matter what I do. Cheers, Thomas - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat 7.0.100 AJP connector with mod_jk on another host
On Thu, Mar 5, 2020 at 10:05 AM Thomas Glanzmann wrote: > Hello Martin, > > > > This should be: secretRequired="false". > > > This attribute has been renamed recently. > > I just looked at my notes, and I tried that already yesterday night. > Still facing the same problem with 403. Might it be possible that I need > to use a secret in order to access ajp from mod_jk? > If you don't set secretRequired="false" properly then at start time Tomcat will complain if there is no specified "secret" attribute. If it doesn't complain then most probably you are testing again with the wrong server.xml or old version of Tomcat. > > Cheers, > Thomas > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: tomcat 7.0.100 AJP connector with mod_jk on another host
Hello Martin, > > This should be: secretRequired="false". > > This attribute has been renamed recently. I just looked at my notes, and I tried that already yesterday night. Still facing the same problem with 403. Might it be possible that I need to use a secret in order to access ajp from mod_jk? Cheers, Thomas - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat 7.0.100 AJP connector with mod_jk on another host
Hello Martin, > This should be: secretRequired="false". > This attribute has been renamed recently. thanks. I'll test later and let you know how it went. Cheers, Thomas - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat 7.0.100 AJP connector with mod_jk on another host
Hi Thomas, On Thu, Mar 5, 2020 at 3:53 AM Thomas Glanzmann wrote: > Hello, > the problem was that I edited the wrong server.xml. The one that was not > used. So now that I figured that out, settings these two settings help. > > > > > className="org.apache.catalina.core.JreMemoryLeakPreventionListener" /> > className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" /> > className="org.apache.catalina.core.ThreadLocalLeakPreventionListener" /> > > type="org.apache.catalina.UserDatabase" > description="User database that can be updated and > saved" > > factory="org.apache.catalina.users.MemoryUserDatabaseFactory" > pathname="conf/tomcat-users.xml" /> > > > connectionTimeout="3000" > URIEncoding="UTF-8" > redirectPort="8443" > maxHttpHeaderSize="8192" > maxThreads="400" > processorCache="400" > minSpareThreads="40" > enableLookups="false" > acceptCount="100" > disableUploadTimeout="true" > /> > address="0.0.0.0" > requiredSecret="false" > This should be: secretRequired="false". This attribute has been renamed recently. Martin > redirectPort="8443" > URIEncoding="UTF-8" > connectionTimeout="3000" > maxThreads="400" > processorCache="400" > minSpareThreads="40" > maxConnections="400" > enableLookups="false" > acceptCount="100" > /> > jvmRoute="tomcat-06" > > className="org.apache.catalina.realm.LockOutRealm"> > className="org.apache.catalina.realm.UserDatabaseRealm" > resourceName="UserDatabase"/> > > unpackWARs="true" autoDeploy="true"> > className="org.apache.catalina.valves.AccessLogValve" > directory="logs" > prefix="localhost_access_log." > suffix=".txt" > pattern="%h %l %u %t %r %s %b" > /> > > > > > > However when I try to access this using mod_jk, I get a 403. I used a > sniffer > and it is coming from the AJP connector. So I tried to set > allowedRequestAttributesPattern=".*" but that did not solve my problems, > any > ideas? > > Setup is: > > apache with mod_jk 1.2.46 load balances over 4 tomcats on seperate hosts. > > Cheers, > Thomas > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: tomcat 7.0.100 AJP connector with mod_jk on another host
Hello, the problem was that I edited the wrong server.xml. The one that was not used. So now that I figured that out, settings these two settings help. However when I try to access this using mod_jk, I get a 403. I used a sniffer and it is coming from the AJP connector. So I tried to set allowedRequestAttributesPattern=".*" but that did not solve my problems, any ideas? Setup is: apache with mod_jk 1.2.46 load balances over 4 tomcats on seperate hosts. Cheers, Thomas - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
tomcat 7.0.100 AJP connector with mod_jk on another host
Hello, I've just upgraded to tomcat7 (7.0.100) afterwards I'm unable to reconfigure it to the pre 7.0.100 behaviour where AJP connector listens on the public ip address in order to use it with mod_jk. Can someone help me out to make it works again? My server.xml is: The issue seems to be, that even when I add the address property to the above AJP connector, it does not listen on its internal ip address so it can not be reached from mod_jk which is running on another host: (tomcat-06) [/etc/tomcat7] lsof -P -i -n | grep -i tomcat java 29094 tomcat7 16u IPv6 4315605 0t0 TCP *:46937 (LISTEN) java 29094 tomcat7 17u IPv6 4315606 0t0 TCP *:3000 (LISTEN) java 29094 tomcat7 19u IPv6 4316198 0t0 TCP *:42795 (LISTEN) java 29094 tomcat7 56u IPv6 4278035 0t0 TCP *:8080 (LISTEN) java 29094 tomcat7 57u IPv6 4278036 0t0 TCP 127.0.0.1:8009 (LISTEN) java 29094 tomcat7 238u IPv6 4316200 0t0 TCP 127.0.0.1:8005 (LISTEN) Cheers, Thomas - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Is there a limit to mod_jk?
Am 25.04.2019 um 06:22 schrieb John Larsen: Hello, Is there a limit to the number of workers instances mod_jk can handle? There will be limits due to general file descriptor limits, each TCP connection counts as a file descriptor. But I am not aware of a limit on the number of workers per se. I currently have 38 tomcat instances running on a machine. I have had up to 75 in the past, but this machine I keep getting bind exception errors but lsof -i :port comes up empty when that particular tomcat is offline. These numbers do not look that high. A nasty limit on some linuxes is the number of processes (maxproc or ulimit -u). It is counted per user and despite its name it actually counts tasks, and each thread in each process of a user is such a task. So it actually counts the number of threads in all processes fo some user id. The first process that hits the limit will only observe, that it can not start a new thread. Typically this will result in very unexpected behavior. Im at loss as to what is causing it. Usually bind exceptions is when another java process is running on the same port - but not the case here. Even if i shutdown apache where mod_jk isnt being used tells me this is really unrelated to mod_jk How exactly does the exception look like (full stack)? mod_jk.log: [Thu Apr 25 04:14:07.458 2019] [30178:139932601325312] [error] ajp_service::jk_ajp_common.c (2796): (w314) connecting to tomcat failed (rc=-3, errors=2, client_errors=0). [Thu Apr 25 04:14:07.458 2019] [30178:139932601325312] [info] jk_handler::mod_jk.c (2991): Service error=-3 for worker=w314 I tried updating mod_jk to 1.2.46 There should be additional log lines directly above the snippet you showed here. Could you provide a more complete snippet? Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Is there a limit to mod_jk?
Hello, Is there a limit to the number of workers instances mod_jk can handle? I currently have 38 tomcat instances running on a machine. I have had up to 75 in the past, but this machine I keep getting bind exception errors but lsof -i :port comes up empty when that particular tomcat is offline. Im at loss as to what is causing it. Usually bind exceptions is when another java process is running on the same port - but not the case here. Even if i shutdown apache where mod_jk isnt being used tells me this is really unrelated to mod_jk mod_jk.log: [Thu Apr 25 04:14:07.458 2019] [30178:139932601325312] [error] ajp_service::jk_ajp_common.c (2796): (w314) connecting to tomcat failed (rc=-3, errors=2, client_errors=0). [Thu Apr 25 04:14:07.458 2019] [30178:139932601325312] [info] jk_handler::mod_jk.c (2991): Service error=-3 for worker=w314 I tried updating mod_jk to 1.2.46 John Larsen
RE: loss of connection with mod_jk(tomcat connector)
Hi Rainer, I am not much aware about JkShmFile but it was working fine with tomcat connector 1.2.43, is anything I need to setup for more loggers because even I am also not getting the actual problem. Thanks and Regards, Rajendra Rathore 9922701491 -Original Message- From: Rainer Jung Sent: 06 February 2019 06:41 PM To: Tomcat Users List ; Rathore, Rajendra Subject: Re: loss of connection with mod_jk(tomcat connector) External email from: rainer.j...@kippdata.de Hi Rajendra, Am 06.02.2019 um 12:36 schrieb Rathore, Rajendra: > Hi Mark, > > I am stuck and due to below issue unable to update to latest tomcat > connector, can you please share your finding, let me know if you need > anything from my side, I also raise issue > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbz.apache.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D63075data=02%7C01%7Crarathore%40ptc.com%7C1a09aaa2eae847b573eb08d68c349039%7Cb9921086ff774d0d828acb3381f678e2%7C0%7C0%7C636850554720305577sdata=6u4FOXO5xbYRAJ2GFXE8zwNOIZ2MyNuVtuphdD6xur0%3Dreserved=0 > but there is no progress on it. as Mark already wrote, your mod_jk log file shows, that many of your tomcat instances are down. You have configured a load balancer with 9 members, listening on localhost ports 8010-8018, but of these 9 tomcat instances only the one listening on port 8010 was up. So some requests work, because they were forwarded coincidentally to the working port, others fail, because they were forwarded to one of the 8 ports were nothing is listening and even their failover failed, because when only one out of 9 ports work, chances are very high, that the failover also hits a port where nothing listens. mod_jk remembers the failing workers (ports) for some time and will not retry to use them, but as I wrote in the ticket, you have a broken JkShmFile, so mod_jk balancers can not correctly work. Fix that problem first and make sure your ports are actually listening. Regards, Rainer > -Original Message- > From: Rathore, Rajendra > Sent: 17 January 2019 10:33 AM > To: Tomcat Users List > Subject: RE: loss of connection with mod_jk(tomcat connector) > > External email from: > users-return-266670-rarathore=ptc@tomcat.apache.org > > Hi Mark, > > We configure multiple tomcat and based on the configuration start > other tomcat, since one tomcat running fine but after some time it > will stop communicating, this problem we face from Tomcat Connector > 1.2.46 version onwards, for 1.2.43 it works fine, please let me know > if I need to enable extra loggers that will help out to understand the > problem better, > > Thanks and Regards, > Rajendra Rathore > 9922701491 > > -Original Message- > From: Mark Thomas > Sent: 17 January 2019 05:05 AM > To: Tomcat Users List > Subject: Re: loss of connection with mod_jk(tomcat connector) > > External email from: > users-return-29-rarathore=ptc@tomcat.apache.org > > On 16/01/2019 12:26, Rathore, Rajendra wrote: >> Hi Team, >> >> >> >> we are using Apache Http server with basic authentication, when we >> try to send some request to apache for authentication it will fail >> with >> 401 error and when we check the JK Status, >> >> we found that status was not proper means instead of 'OK' state it >> was 'Awaiting..'. We are facing this issue with tomcat connector >> 1.2.46, it worked with 1.2.43. I attached our log files for your >> reference, please let me know if you need anything else. > > Logs show the Tomcat instances aren't listening on the configured host/ports. > > Mark
Re: loss of connection with mod_jk(tomcat connector)
Hi Rajendra, Am 06.02.2019 um 12:36 schrieb Rathore, Rajendra: Hi Mark, I am stuck and due to below issue unable to update to latest tomcat connector, can you please share your finding, let me know if you need anything from my side, I also raise issue https://bz.apache.org/bugzilla/show_bug.cgi?id=63075 but there is no progress on it. as Mark already wrote, your mod_jk log file shows, that many of your tomcat instances are down. You have configured a load balancer with 9 members, listening on localhost ports 8010-8018, but of these 9 tomcat instances only the one listening on port 8010 was up. So some requests work, because they were forwarded coincidentally to the working port, others fail, because they were forwarded to one of the 8 ports were nothing is listening and even their failover failed, because when only one out of 9 ports work, chances are very high, that the failover also hits a port where nothing listens. mod_jk remembers the failing workers (ports) for some time and will not retry to use them, but as I wrote in the ticket, you have a broken JkShmFile, so mod_jk balancers can not correctly work. Fix that problem first and make sure your ports are actually listening. Regards, Rainer -Original Message- From: Rathore, Rajendra Sent: 17 January 2019 10:33 AM To: Tomcat Users List Subject: RE: loss of connection with mod_jk(tomcat connector) External email from: users-return-266670-rarathore=ptc@tomcat.apache.org Hi Mark, We configure multiple tomcat and based on the configuration start other tomcat, since one tomcat running fine but after some time it will stop communicating, this problem we face from Tomcat Connector 1.2.46 version onwards, for 1.2.43 it works fine, please let me know if I need to enable extra loggers that will help out to understand the problem better, Thanks and Regards, Rajendra Rathore 9922701491 -Original Message- From: Mark Thomas Sent: 17 January 2019 05:05 AM To: Tomcat Users List Subject: Re: loss of connection with mod_jk(tomcat connector) External email from: users-return-29-rarathore=ptc@tomcat.apache.org On 16/01/2019 12:26, Rathore, Rajendra wrote: Hi Team, we are using Apache Http server with basic authentication, when we try to send some request to apache for authentication it will fail with 401 error and when we check the JK Status, we found that status was not proper means instead of 'OK' state it was 'Awaiting..'. We are facing this issue with tomcat connector 1.2.46, it worked with 1.2.43. I attached our log files for your reference, please let me know if you need anything else. Logs show the Tomcat instances aren't listening on the configured host/ports. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: loss of connection with mod_jk(tomcat connector)
Hi Mark, I am stuck and due to below issue unable to update to latest tomcat connector, can you please share your finding, let me know if you need anything from my side, I also raise issue https://bz.apache.org/bugzilla/show_bug.cgi?id=63075 but there is no progress on it. Thanks and Regards, Rajendra Rathore 9922701491 -Original Message- From: Rathore, Rajendra Sent: 17 January 2019 10:33 AM To: Tomcat Users List Subject: RE: loss of connection with mod_jk(tomcat connector) External email from: users-return-266670-rarathore=ptc@tomcat.apache.org Hi Mark, We configure multiple tomcat and based on the configuration start other tomcat, since one tomcat running fine but after some time it will stop communicating, this problem we face from Tomcat Connector 1.2.46 version onwards, for 1.2.43 it works fine, please let me know if I need to enable extra loggers that will help out to understand the problem better, Thanks and Regards, Rajendra Rathore 9922701491 -Original Message- From: Mark Thomas Sent: 17 January 2019 05:05 AM To: Tomcat Users List Subject: Re: loss of connection with mod_jk(tomcat connector) External email from: users-return-29-rarathore=ptc@tomcat.apache.org On 16/01/2019 12:26, Rathore, Rajendra wrote: > Hi Team, > > > > we are using Apache Http server with basic authentication, when we try > to send some request to apache for authentication it will fail with > 401 error and when we check the JK Status, > > we found that status was not proper means instead of 'OK' state it was > 'Awaiting..'. We are facing this issue with tomcat connector 1.2.46, > it worked with 1.2.43. I attached our log files for your reference, > please let me know if you need anything else. Logs show the Tomcat instances aren't listening on the configured host/ports. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: loss of connection with mod_jk(tomcat connector)
Hi Mark, We configure multiple tomcat and based on the configuration start other tomcat, since one tomcat running fine but after some time it will stop communicating, this problem we face from Tomcat Connector 1.2.46 version onwards, for 1.2.43 it works fine, please let me know if I need to enable extra loggers that will help out to understand the problem better, Thanks and Regards, Rajendra Rathore 9922701491 -Original Message- From: Mark Thomas Sent: 17 January 2019 05:05 AM To: Tomcat Users List Subject: Re: loss of connection with mod_jk(tomcat connector) External email from: users-return-29-rarathore=ptc@tomcat.apache.org On 16/01/2019 12:26, Rathore, Rajendra wrote: > Hi Team, > > > > we are using Apache Http server with basic authentication, when we try > to send some request to apache for authentication it will fail with > 401 error and when we check the JK Status, > > we found that status was not proper means instead of 'OK' state it was > 'Awaiting..'. We are facing this issue with tomcat connector 1.2.46, > it worked with 1.2.43. I attached our log files for your reference, > please let me know if you need anything else. Logs show the Tomcat instances aren't listening on the configured host/ports. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: loss of connection with mod_jk(tomcat connector)
On 16/01/2019 12:26, Rathore, Rajendra wrote: > Hi Team, > > > > we are using Apache Http server with basic authentication, when we try > to send some request to apache for authentication it will fail with 401 > error and when we check the JK Status, > > we found that status was not proper means instead of 'OK' state it was > 'Awaiting..'. We are facing this issue with tomcat connector 1.2.46, it > worked with 1.2.43. I attached our log files for your reference, please > let me know if you need anything else. Logs show the Tomcat instances aren't listening on the configured host/ports. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Using mod_jk on Alpine
Greetings all. I'm trying to use mod_jk within a Docker container using the Alpine Linux base. I was successful on building the Module, but when I activate it, Apache gives me an instant Segmentation Fault. Don't know if something is missing. Right now, this is my Dockerfile: https://gist.github.com/L30Bola/62f75c089fac5e0ff09b55f32ea2215c I've attached, on the same gist link, a GDB backtrace, maybe it helps.
Re: help installing mod_jk on Centos 7 on a Google Cloud server
hi.
1) I have removed the previous correspondence from this email, because by now it has
become pretty much unreadable anyway.
Also, there are 2 links at the bottom of your last email (to "avg"-something). I don't
know if these are supposed to provide some additional information, but they both lead to a
page asking me to install something on my laptop, which of course I am not going to do.
2) according to the paths which you show below, it does not look like there is an overlap
between the httpd DocumentRoot and the tomcat webapps directory.
(Of course that does not show if there are any symlinks anywhere which may provide such a
connection on the sly. But let's suppose there aren't, and let's for now forget about that
red warning in the documentation.)
3) I do not really remember what the stage of your problem is right now. Can you summarise
it again ?
(And remind us of the versions of Java and tomcat please, it will save us a search through
the archive.)
What I suppose is that you now have this configuration, on one host for httpd
and tomcat :
browser <- HTTP/S -> httpd + mod_jk <- AJP -> tomcat AJP Connector
|
webapps
|
your webapp
|- files (HTML, JSP)
|- WEB-INF
|- private files
(Note in the above, that the protocol between mod_jk and tomcat is AJP, not HTTP/S. In
summary, it is a binary and somewhat optimised version of HTTP, which only mod_jk and the
AJP Connector in tomcat understand. But that should be transparent as far as tomcat
webapps are concerned).
You have a "workers.properties" file somewhere which tells the mod_jk module "where" the
tomcat instance is ("name", host/IP, port), and the AJP Connector in tomcat matches that
IP and port.
You also have a mod_jk setup (in the Apache config) that tells httpd which URLs should be
forwarded to which tomcat instance. These are the "JkMount" directives.
There are also logfiles, for both httpd and tomcat, which are generally helpful to find
out what happens.
I also seem to remember that initially, you had a problem getting httpd to load the mod_jk
module, but that now this is resolved, and the command "apache2ctl -M" shows the list of
loaded modules, including mod_jk.
So wat is the remaining issue ?
Note also :
In the information below, there is mention of a
> TOMCATS_BASE="/var/lib/tomcats/"
variable and directory. This is not something that I know. It may be new in recent
versions of tomcat, or it may be something which the CentOS package managers do.
(I also do not find it in the "RUNNING.txt" file of the tomcat 9 distribution, so I guess
that it is CentOS-specific.)
There may be more things like that, which may complicate a bit our efforts to help you,
because we do not necessarily have a CentOS system like yours at hand.
On 27.11.2018 20:18, Lou Wallace wrote:
Hi André,
Here is some info on the setup, let me know what it tells you.
tomcat
etc/tomcat
drwxrwxr-x. 3 root tomcat 23 Nov 18 17:48 Catalina
-rw-r--r--. 1 root tomcat 13443 Oct 16 09:16 catalina.policy
-rw-r--r--. 1 root tomcat 6496 Oct 16 09:16 catalina.properties
drwxr-xr-x. 2 root tomcat 20 Nov 18 17:48 conf.d
-rw-r--r--. 1 root tomcat 1394 Oct 16 09:16 context.xml
-rw-r--r--. 1 root tomcat547 Oct 16 09:16 log4j.properties
-rw-r--r--. 1 root tomcat 3288 Oct 16 09:16 logging.properties
-rw-r--r--. 1 root tomcat 6613 Oct 16 09:16 server.xml
-rw-r--r--. 1 root tomcat 1651 Oct 16 09:16 tomcat.conf
-rw-r-. 1 root tomcat 2418 Oct 16 09:16 tomcat-users.xml
-rw-r--r--. 1 root tomcat 167655 Oct 16 09:16 web.xml
DocumentRoot (from httpd.conf)
var/www/html
ServerRoot (from httpd.conf)
/etc/httpd
webapps directory is at
/var/lib/tomcat
tomcat.conf
# System-wide configuration file for tomcat services
# This will be loaded by systemd as an environment file,
# so please keep the syntax. For shell expansion support
# place your custom files as /etc/tomcat/conf.d/*.conf
#
# There are 2 "classes" of startup behavior in this package.
# The old one, the default service named tomcat.service.
# The new named instances are called tomcat@instance.service.
#
# Use this file to change default values for all services.
# Change the service specific ones to affect only one service.
# For tomcat.service it's /etc/sysconfig/tomcat, for
# tomcat@instance it's /etc/sysconfig/tomcat@instance.
# This variable is used to figure out if config is loaded or not.
TOMCAT_CFG_LOADED="1"
# In new-style instances, if CATALINA_BASE isn't specified, it will
Re: help installing mod_jk on Centos 7 on a Google Cloud server
Hi André, Here is some info on the setup, let me know what it tells you. tomcat etc/tomcat drwxrwxr-x. 3 root tomcat 23 Nov 18 17:48 Catalina -rw-r--r--. 1 root tomcat 13443 Oct 16 09:16 catalina.policy -rw-r--r--. 1 root tomcat 6496 Oct 16 09:16 catalina.properties drwxr-xr-x. 2 root tomcat 20 Nov 18 17:48 conf.d -rw-r--r--. 1 root tomcat 1394 Oct 16 09:16 context.xml -rw-r--r--. 1 root tomcat547 Oct 16 09:16 log4j.properties -rw-r--r--. 1 root tomcat 3288 Oct 16 09:16 logging.properties -rw-r--r--. 1 root tomcat 6613 Oct 16 09:16 server.xml -rw-r--r--. 1 root tomcat 1651 Oct 16 09:16 tomcat.conf -rw-r-. 1 root tomcat 2418 Oct 16 09:16 tomcat-users.xml -rw-r--r--. 1 root tomcat 167655 Oct 16 09:16 web.xml DocumentRoot (from httpd.conf) var/www/html ServerRoot (from httpd.conf) /etc/httpd webapps directory is at /var/lib/tomcat tomcat.conf # System-wide configuration file for tomcat services # This will be loaded by systemd as an environment file, # so please keep the syntax. For shell expansion support # place your custom files as /etc/tomcat/conf.d/*.conf # # There are 2 "classes" of startup behavior in this package. # The old one, the default service named tomcat.service. # The new named instances are called tomcat@instance.service. # # Use this file to change default values for all services. # Change the service specific ones to affect only one service. # For tomcat.service it's /etc/sysconfig/tomcat, for # tomcat@instance it's /etc/sysconfig/tomcat@instance. # This variable is used to figure out if config is loaded or not. TOMCAT_CFG_LOADED="1" # In new-style instances, if CATALINA_BASE isn't specified, it will # be constructed by joining TOMCATS_BASE and NAME. TOMCATS_BASE="/var/lib/tomcats/" # Where your java installation lives JAVA_HOME="/usr/lib/jvm/jre" # Where your tomcat installation lives CATALINA_HOME="/usr/share/tomcat" # System-wide tmp CATALINA_TMPDIR="/var/cache/tomcat/temp" # You can pass some parameters to java here if you wish to #JAVA_OPTS="-Xminf0.1 -Xmaxf0.3" # Use JAVA_OPTS to set java.library.path for libtcnative.so #JAVA_OPTS="-Djava.library.path=/usr/lib" # You can change your tomcat locale here #LANG="en_US" # Run tomcat under the Java Security Manager SECURITY_MANAGER="false" # Time to wait in seconds, before killing process # TODO(stingray): does nothing, fix. # SHUTDOWN_WAIT="30" # If you wish to further customize your tomcat environment, # put your own definitions here # (i.e. LD_LIBRARY_PATH for some jdbc drivers) <http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=webmail> Virus-free. www.avg.com <http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=webmail> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> On Sun, Nov 25, 2018 at 4:19 PM André Warnier (tomcat) wrote: > On 25.11.2018 21:43, Lou Wallace wrote: > > Whew. Just read that link > > > > Warning: If Apache and Tomcat are configured to serve content from the > same > > file system location then care must be taken to ensure that Apache is not > > able to serve inappropriate content such as the contents of the WEB-INF > > directory or JSP source code. > > > > This could occur if the Apache DocumentRoot overlaps with a Tomcat Host's > > appBase or the docBase of any Context. It could also occur when using the > > Apache Alias directive with a Tomcat Host's appBase or the docBase of any > > Context. > > > > And I just checked and sure enough I can access from the browser the > > contents of the site directory. Now I haven't yet configured httpd-vhosts > > to define site yet - could that be why I can access the directory itself > > from a browser? > > > > And where do I look to see if Apache DocumentRoot overlaps with a Tomcat > > Host's appBase or the docBase? > > > > Make a picture. I'm not kidding. > Presumably, you know what a filesystem directory structure looks like. > So make a little schema of the Apache httpd document directories, starting > at what is > indicated in the DocumentRoot of the httpd.conf (or apache2.conf or > whatever it is on your > system); and make a similar schema of the directories of Tomcat, starting > at the positions > mentioned in the appBase/docBase attributes. > If any of these overlap, you have a problem. It is not a fatal problem, > and one can avoid > the problem with a careful httpd configuration. But if there is an > overlap, you are always > at risk of forgetting to configure this properly, so better to avoid it > altogether. > (Of course, all of this can happen only if Apache httpd and Tomcat are > running on the same > host; if not, there is no
Re: [OT] help installing mod_jk on Centos 7 on a Google Cloud server
Hi Chris, For the most party those were there when the Google Cloud instance created the Apache web server. But you are right once working I need to eval all of them. Lou On Mon, Nov 26, 2018 at 9:38 AM Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Lou, > > On 11/24/18 17:01, Lou Wallace wrote: > > Here is what I see > > > > Loaded Modules: core_module (static) so_module (static) http_module > > (static) access_compat_module (shared) actions_module (shared) > > alias_module (shared) allowmethods_module (shared) > > auth_basic_module (shared) auth_digest_module (shared) > > authn_anon_module (shared) authn_core_module (shared) > > authn_dbd_module (shared) authn_dbm_module (shared) > > authn_file_module (shared) authn_socache_module (shared) > > authz_core_module (shared) authz_dbd_module (shared) > > authz_dbm_module (shared) authz_groupfile_module (shared) > > authz_host_module (shared) authz_owner_module (shared) > > authz_user_module (shared) autoindex_module (shared) cache_module > > (shared) cache_disk_module (shared) data_module (shared) dbd_module > > (shared) deflate_module (shared) dir_module (shared) dumpio_module > > (shared) echo_module (shared) env_module (shared) expires_module > > (shared) ext_filter_module (shared) filter_module (shared) > > headers_module (shared) include_module (shared) info_module > > (shared) log_config_module (shared) logio_module (shared) > > mime_magic_module (shared) mime_module (shared) negotiation_module > > (shared) remoteip_module (shared) reqtimeout_module (shared) > > rewrite_module (shared) setenvif_module (shared) > > slotmem_plain_module (shared) slotmem_shm_module (shared) > > socache_dbm_module (shared) socache_memcache_module (shared) > > socache_shmcb_module (shared) status_module (shared) > > substitute_module (shared) suexec_module (shared) unique_id_module > > (shared) unixd_module (shared) userdir_module (shared) > > version_module (shared) vhost_alias_module (shared) dav_module > > (shared) dav_fs_module (shared) dav_lock_module (shared) lua_module > > (shared) mpm_prefork_module (shared) proxy_module (shared) > > lbmethod_bybusyness_module (shared) lbmethod_byrequests_module > > (shared) lbmethod_bytraffic_module (shared) > > lbmethod_heartbeat_module (shared) proxy_ajp_module (shared) > > proxy_balancer_module (shared) proxy_connect_module (shared) > > proxy_express_module (shared) proxy_fcgi_module (shared) > > proxy_fdpass_module (shared) proxy_ftp_module (shared) > > proxy_http_module (shared) proxy_scgi_module (shared) > > proxy_wstunnel_module (shared) ssl_module (shared) systemd_module > > (shared) cgi_module (shared) > > That's like ... every single module available. Are you sure you want > all those modules? After you get mod_jk working, you might want to > review your configuration. Lots of stuff in there you almost certainly > don't need. > > - -chris > -BEGIN PGP SIGNATURE- > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlv8BX0ACgkQHPApP6U8 > pFgv9g//S4yxRRcCIo7bRxz4vZZim+Oun7Dg0Qpao5w/MhMHDwry2P512ozds2z4 > ZPpnWKKFuWzu4S45oCaDAYnAzkhEJlcn7mbXzR7TbLGWwSrkM/TWGMiMNbAAwOm4 > uvmkKJf6XOHZH4NexhAlDb3b+u/1g/kusLrsmZ58lt2GhOqVBJEaoWsBQ+xTW+Q6 > XVY/tEJIIBJsv5PD9qXf6MZi6vafYkOd1tv7n8VE+nCbG1wRKzF+sDcsGnxNUlZl > 2F3qSplfYEVCZZRJCSNCgk8ZxWv2j2iB754jHDUzYR0iqxyzzgx4SCuH117LIo+U > cGa116omE945IuLrhzcjM5fe1N0KdKvR4zrmTQTCRumaAzvEoFTRzB2TddStf/50 > FX/TQ7ULSmgNXRNnq3e/DjqmyrTRHoOrJnNn6AaL/Vftk6bN9p83oPCqtyvR9L0h > kxGa6pvOAJ9qbQaixscRypSSHUmWkAz8MS6vIQyBqNyl9VtAKEcJ+nqUzhu8Y9aL > UdQS+iMVwUjYEh1RlIuT6SETlOUoa0VXrRt/DG7P5HY+S0DQmgnBduZG/PZO3LLM > E88mDXYFCMTCLfsawAU3slODt0DchcpVHt3dc8xuspsHbGLG0yxCZCCEFzgDZWij > 6NfMHpGtAI4U7FJc3pMjB7IKVOS8aTyltPOevAtUGOF8Mv6pAQE= > =8n4C > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
