[Bug 65589] Serious Performance Degradation as of 2.4.47
https://bz.apache.org/bugzilla/show_bug.cgi?id=65589 --- Comment #1 from Rainer Jung --- You attachment is a Safari WebArchive and not usable for non-Safari users. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 65589] Serious Performance Degradation as of 2.4.47
https://bz.apache.org/bugzilla/show_bug.cgi?id=65589
--- Comment #2 from Ruediger Pluem ---
In order to investigate further we would also need:
1. The httpd configuration used for the load test.
2. Information about your load test, e.g. URL's, frequency, number of parallel
requests, protocols used (TLS (which version), HTTP/2, etc).
3. Any changes in 3rd party libraries e.g. OpenSSL between 2.4.46 and
2.4.4[789],
4. Logfiles preferably at a debug or trace level.
5. Access logs which log the request times in ms (%{ms}T)
6. More details of the noticed performance degradation, e.g. lower amount of
request throughput, slower answer times, etc.
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 65589] Serious Performance Degradation as of 2.4.47
https://bz.apache.org/bugzilla/show_bug.cgi?id=65589 Ruediger Pluem changed: What|Removed |Added Status|NEW |NEEDINFO -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 65589] Serious Performance Degradation as of 2.4.47
https://bz.apache.org/bugzilla/show_bug.cgi?id=65589 --- Comment #3 from Stefan Eissing --- There are long HTML lists of some performance figures on their test suites. Does not tell me anything really. I mean you see that things are slower, but one as no idea what they do. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 65590] New: fix_uds_filename function seems broken since apache 2.4.49
https://bz.apache.org/bugzilla/show_bug.cgi?id=65590
Bug ID: 65590
Summary: fix_uds_filename function seems broken since apache
2.4.49
Product: Apache httpd-2
Version: 2.4.49
Hardware: PC
Status: NEW
Severity: normal
Priority: P2
Component: mod_proxy
Assignee: bugs@httpd.apache.org
Reporter: scre...@gmail.com
Target Milestone: ---
Since we have upgraded from httpd-2.4.48 to httpd-2.4.49 our websocket
application fail to load in web browser.
Apache seems to hang.
Our configuration is :
Options FollowSymLinks
RewriteEngine On
RewriteCond %{HTTP:Upgrade} !=websocket [NC]
RewriteRule /activex/([^\/]+)/(.*)
unix:/dev/shm/HXL_${NOM_UTILISATEUR}/backoffice_$1.socket|http://localhost/$2
[NE,P,L]
RewriteCond %{HTTP:Upgrade} =websocket [NC]
RewriteCond %{HTTP_COOKIE} hxlsession=([^;]+)
RewriteRule /activex/([^\/]+)/(.*)
unix:/dev/shm/HXL_${NOM_UTILISATEUR}/backoffice_$1.socket|ws://localhost/$2?arg=%1
[NE,P,L]
To try to fix I have replace fix_uds_filename function in
httpd-2.4.49/modules/proxy/proxy_util.c with version presents in
httpd-2.4.48/modules/proxy/proxy_util.c and the problem has go away,
so il looks like a httpd-2.4.49 regression.
If it can help I have add some trace in this function and it's look like the
probleme is with "unix:" part who does no more match with ap_cstr_casecmpn
function.
I notice too that r->filaneme length seem to anormaly grow.
Tracing r->filename display:
proxy:http://dev76.lis-dev.net:2000/activex/unix:/dev/shm/HXL_scresto/backoffice_session.8f304bcaaf818c4d5bd799b8c75dbf20.14400.MHXL.socket|http://localhost/
proxy:http://dev76.lis-dev.net:2000/activex/unix:/dev/shm/HXL_scresto/backoffice_session.8f304bcaaf818c4d5bd799b8c75dbf20.14400.MHXL.socket|http://localhost/
proxy:http://dev76.lis-dev.net:2000/activex/unix:/dev/shm/HXL_scresto/backoffice_unix:.socket|http://localhost/dev/shm/HXL_scresto/backoffice_session.8f304bcaaf818c4d5bd799b8c75dbf20.14400.MHXL.socket|http:/localhost/
proxy:http://dev76.lis-dev.net:2000/activex/unix:/dev/shm/HXL_scresto/backoffice_unix:.socket|http://localhost/dev/shm/HXL_scresto/backoffice_session.8f304bcaaf818c4d5bd799b8c75dbf20.14400.MHXL.socket|http:/localhost/
proxy:http://dev76.lis-dev.net:2000/activex/unix:/dev/shm/HXL_scresto/backoffice_unix:.socket|http://localhost/dev/shm/HXL_scresto/backoffice_unix:.socket|http:/localhost/dev/shm/HXL_scresto/backoffice_session.8f304bcaaf818c4d5bd799b8c75dbf20.14400.MHXL.socket|http:/localhost/
proxy:http://dev76.lis-dev.net:2000/activex/unix:/dev/shm/HXL_scresto/backoffice_unix:.socket|http://localhost/dev/shm/HXL_scresto/backoffice_unix:.socket|http:/localhost/dev/shm/HXL_scresto/backoffice_session.8f304bcaaf818c4d5bd799b8c75dbf20.14400.MHXL.socket|http:/localhost/
proxy:http://dev76.lis-dev.net:2000/activex/unix:/dev/shm/HXL_scresto/backoffice_unix:.socket|http://localhost/dev/shm/HXL_scresto/backoffice_unix:.socket|http:/localhost/dev/shm/HXL_scresto/backoffice_unix:.socket|http:/localhost/dev/shm/HXL_scresto/backoffice_session.8f304bcaaf818c4d5bd799b8c75dbf20.14400.MHXL.socket|http:/localhost/
proxy:http://dev76.lis-dev.net:2000/activex/unix:/dev/shm/HXL_scresto/backoffice_unix:.socket|http://localhost/dev/shm/HXL_scresto/backoffice_unix:.socket|http:/localhost/dev/shm/HXL_scresto/backoffice_unix:.socket|http:/localhost/dev/shm/HXL_scresto/backoffice_session.8f304bcaaf818c4d5bd799b8c75dbf20.14400.MHXL.socket|http:/localhost/]
proxy:http://dev76.lis-dev.net:2000/activex/unix:/dev/shm/HXL_scresto/backoffice_unix:.socket|http://localhost/dev/shm/HXL_scresto/backoffice_unix:.socket|http:/localhost/dev/shm/HXL_scresto/backoffice_unix:.socket|http:/localhost/dev/shm/HXL_scresto/backoffice_unix:.socket|http:/localhost/dev/shm/HXL_scresto/backoffice_session.8f304bcaaf818c4d5bd799b8c75dbf20.14400.MHXL.socket|http:/localhost/
proxy:http://dev76.lis-dev.net:2000/activex/unix:/dev/shm/HXL_scresto/backoffice_unix:.socket|http://localhost/dev/shm/HXL_scresto/backoffice_unix:.socket|http:/localhost/dev/shm/HXL_scresto/backoffice_unix:.socket|http:/localhost/dev/shm/HXL_scresto/backoffice_unix:.socket|http:/localhost/dev/shm/HXL_scresto/backoffice_session.8f304bcaaf818c4d5bd799b8c75dbf20.14400.MHXL.socket|http:/localhost/
If you need more information, please let me know.
Thanks
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 65590] fix_uds_filename function seems broken since apache 2.4.49
https://bz.apache.org/bugzilla/show_bug.cgi?id=65590 Ruediger Pluem changed: What|Removed |Added OS||All Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #1 from Ruediger Pluem --- Your RewriteRules are broken. Move them out of the Location block and it should work. The r->filenames you show below are correctly classified as invalid. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 65590] fix_uds_filename function seems broken since apache 2.4.49
https://bz.apache.org/bugzilla/show_bug.cgi?id=65590
--- Comment #2 from Yann Ylavic ---
Created attachment 38043
--> https://bz.apache.org/bugzilla/attachment.cgi?id=38043&action=edit
Handle UDS ("unix:") scheme is mod_rewrite
Maybe the issue is that mod_rewrite does not consider that a "unix:" scheme
forms an absolute URI?
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 65590] fix_uds_filename function seems broken since apache 2.4.49
https://bz.apache.org/bugzilla/show_bug.cgi?id=65590 --- Comment #3 from Yann Ylavic --- Related to bug 57691 ? -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 65590] fix_uds_filename function seems broken since apache 2.4.49
https://bz.apache.org/bugzilla/show_bug.cgi?id=65590
--- Comment #4 from Yann Ylavic ---
Created attachment 38044
--> https://bz.apache.org/bugzilla/attachment.cgi?id=38044&action=edit
Handle UDS ("unix:") scheme in mod_rewrite [P]
Or maybe this one instead since the "unix:" scheme is a [P] thing only.
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 65590] fix_uds_filename function seems broken since apache 2.4.49
https://bz.apache.org/bugzilla/show_bug.cgi?id=65590
Yann Ylavic changed:
What|Removed |Added
Attachment #38044|0 |1
is obsolete||
--- Comment #5 from Yann Ylavic ---
Created attachment 38045
--> https://bz.apache.org/bugzilla/attachment.cgi?id=38045&action=edit
Handle UDS ("unix:") scheme in mod_rewrite [P]
This one should compile..
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 57691] mod_proxy/proxy_util confuses UDS scheme with HTTP scheme when using RewriteRule
https://bz.apache.org/bugzilla/show_bug.cgi?id=57691 --- Comment #6 from Yann Ylavic --- Attachment 38045 from bug 65590 is possibly more targeted since the "unix:" scheme is a mod_proxy thing only. Would that work for you? -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 65590] fix_uds_filename function seems broken since apache 2.4.49
https://bz.apache.org/bugzilla/show_bug.cgi?id=65590 --- Comment #6 from Sylvain Cresto --- Thanks for your quick reply. OK I have move RewriteRules in correct Directy section. I have applied patch 38045 but it does not make different, it does not works. With fix_uds_filename function from httpd-2.4.48 it still works. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 65590] fix_uds_filename function seems broken since apache 2.4.49
https://bz.apache.org/bugzilla/show_bug.cgi?id=65590 Sylvain Cresto changed: What|Removed |Added Resolution|INVALID |--- Status|RESOLVED|REOPENED -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 65590] fix_uds_filename function seems broken since apache 2.4.49
https://bz.apache.org/bugzilla/show_bug.cgi?id=65590 --- Comment #7 from Ruediger Pluem --- Do you have traces for r->filename with the patch applied? Does the 38043 attached patch help? -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 65590] fix_uds_filename function seems broken since apache 2.4.49
https://bz.apache.org/bugzilla/show_bug.cgi?id=65590 --- Comment #8 from Yann Ylavic --- (In reply to Sylvain Cresto from comment #6) > I have applied patch 38045 but it does not make different, it does not works. Please verify that you are running the patched version, I can't reproduce the issue with the patch applied. Also the RewriteRule should go outside any Location or Directory section (directly at the VirtualHost level), otherwise the rewritten URL will always be prefixed by the directory or location specified, which breaks the "unix:" scheme. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 65591] New: Standard + non-standard SSL port + name-based vhosts + SNI: Port number disregarded when selecting certificate?
https://bz.apache.org/bugzilla/show_bug.cgi?id=65591 Bug ID: 65591 Summary: Standard + non-standard SSL port + name-based vhosts + SNI: Port number disregarded when selecting certificate? Product: Apache httpd-2 Version: 2.4.6 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P2 Component: mod_ssl Assignee: bugs@httpd.apache.org Reporter: bjorn.wib...@uu.se Target Milestone: --- It appears that when using both a standard (443) and a non-standard (8443) SSL port together with name-based virtual hosts and SNI, Apache does not consider the port number when selecting which certificate to serve to the client if multiple vhosts have equal ServerNames (but different ports). Instead, Apache appears to serve the certificate from the first listed vhost with a matching ServerName, regardless of the port number. Furthermore, ServerAliases appear not to be considered when determining which vhost will serve the actual web content. Consider the following configuration. Two default vhosts to catch "unexpected" requests, followed by two "real" vhosts serving the actual web content: Listen 443 https Listen 8443 https ServerName default_vhost_ssl SSLEngine on SSLCertificateFile /etc/pki/tls/certs/idp-frontend.crt SSLCertificateKeyFile /etc/pki/tls/private/idp-frontend.key SSLCertificateChainFile /etc/pki/tls/certs/idp-frontend.chain Options None Require all denied ServerName default_vhost_ssl_8443 SSLEngine on SSLCertificateFile /opt/shibboleth-idp/credentials/idp-backchannel.crt SSLCertificateKeyFile /opt/shibboleth-idp/credentials/idp-backchannel.key # no SSLCertificateChainFile as the certificate is self-signed Options None Require all denied ServerName myservice.com SSLEngine on SSLCertificateFile /etc/pki/tls/certs/idp-frontend.crt SSLCertificateKeyFile /etc/pki/tls/private/idp-frontend.key SSLCertificateChainFile /etc/pki/tls/certs/idp-frontend.chain ServerName myservice.com SSLEngine on SSLCertificateFile /opt/shibboleth-idp/credentials/idp-backchannel.crt SSLCertificateKeyFile /opt/shibboleth-idp/credentials/idp-backchannel.key # no SSLCertificateChainFile as the certificate is self-signed Testing with: openssl s_client -connect myservice.com:8443 -no_ssl2 -no_ssl3 -debug -servername 'myservice.com' < /dev/null ...appears to yield the idp-frontend.crt certificate (incorrect), but no certificate chain (correct). I would have expected Apache to serve the idp-backchannel.crt certificate and no certificate chain. I would definitely not have expected to get the wrong certificate but the correct (no) certificate chain. Is this expected behavior, or could there perhaps be some kind of bug in the vhost/certificate selection process when using SNI? Adjusting the ServerName in the "real" (last) 8443 vhost to: ServerName myservice.com:8443 ...as per https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.23 will instead cause the SNI name (which is "myservice.com") not to match the ServerName, causing Apache to select the default 8443 vhost, so not serving any "real" content any longer (yielding 404s to the client). Trying to add a ServerAlias in the "real" (last) 8443 vhost to overcome this: ServerName myservice.com ServerAlias myservice.com:8443 ...appears not to work. Apache appears to only consider ServerNames when determining which vhost will serve the web content when using SNI. The only easy work-around for this that I can think of would be to skip having a default 8443 vhost. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 65590] fix_uds_filename function seems broken since apache 2.4.49
https://bz.apache.org/bugzilla/show_bug.cgi?id=65590 --- Comment #9 from Sylvain Cresto --- Hi OK my bad, i haven't applied patch 38043. With patchs 38043 and 38045 it's now correctly working, thank you ! -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 61818] OCSP "SSLUseStapling on" completely blocking the server when something is off with the responder
https://bz.apache.org/bugzilla/show_bug.cgi?id=61818 --- Comment #7 from Archie Cobbs --- We had a similar problem where nobody could login just now. The root cause was that DNS lookups for the OCSP responder were failing. Our configuration: SSLUseStapling on SSLStaplingResponderTimeout 5 SSLStaplingReturnResponderErrorsoff The errors that were logged: [ssl:error] [pid 103363] (EAI 2)Name or service not known: [client X.X.X.X:X] AH01972: could not resolve address of OCSP responder r3.o.lencr.org [ssl:error] [pid 103363] AH01941: stapling_renew_response: responder error Here's my main issue with this behavior: We have explicitly configured "SSLStaplingResponderTimeout 5", but the connections were hanging for much longer than that. Presumably this is because "SSLStaplingResponderTimeout" only applies to the TCP connection, not the DNS lookup that precedes it. But this means "SSLStaplingResponderTimeout" is not really useful because it only gives a partial guarantee that the time spent futzing with OCSP will be limited. Instead, "SSLStaplingResponderTimeout" should limit the time spent on the ENTIRE OCSP operation including DNS lookup, TCP connection, etc. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 65590] fix_uds_filename function seems broken since apache 2.4.49
https://bz.apache.org/bugzilla/show_bug.cgi?id=65590 --- Comment #10 from Ruediger Pluem --- Only one of the patches should be applied. Can you please do tests with only one of them applied? -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 65589] Serious Performance Degradation as of 2.4.47
https://bz.apache.org/bugzilla/show_bug.cgi?id=65589 --- Comment #4 from Judea --- (In reply to Rainer Jung from comment #1) > You attachment is a Safari WebArchive and not usable for non-Safari users. Then download safari -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 65589] Serious Performance Degradation as of 2.4.47
https://bz.apache.org/bugzilla/show_bug.cgi?id=65589 --- Comment #5 from Yann Ylavic --- (In reply to Judea from comment #4) > Then download safari Then fix it for you.. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 65590] fix_uds_filename function seems broken since apache 2.4.49
https://bz.apache.org/bugzilla/show_bug.cgi?id=65590 --- Comment #11 from Sylvain Cresto --- OK I've just test those patchs. Patch 38043 is the mandatory patch. Thanks -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 65590] fix_uds_filename function seems broken since apache 2.4.49
https://bz.apache.org/bugzilla/show_bug.cgi?id=65590 --- Comment #12 from Yann Ylavic --- Do you mean that 38045 alone is not working? -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 65589] Serious Performance Degradation as of 2.4.47
https://bz.apache.org/bugzilla/show_bug.cgi?id=65589 --- Comment #6 from Judea --- (In reply to Yann Ylavic from comment #5) > (In reply to Judea from comment #4) > > Then download safari > > Then fix it for you.. sAfArI cAnNoT dO -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 65589] Serious Performance Degradation as of 2.4.47
https://bz.apache.org/bugzilla/show_bug.cgi?id=65589 --- Comment #7 from Yann Ylavic --- So it seems that you need help somehow, please provide the requested informations. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 65589] Serious Performance Degradation as of 2.4.47
https://bz.apache.org/bugzilla/show_bug.cgi?id=65589 --- Comment #8 from Judea --- (In reply to Ruediger Pluem from comment #2) > In order to investigate further we would also need: > > 1. Coming soon, needs redaction > 2. Coming soon, needs redaction > 3. There are no changes other than changing the https image from 46 to 47+ > 4. Coming soon, needs redaction > 5. Thats in the JMeter reports > 6. Thats also in the JMeter reports -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 65589] Serious Performance Degradation as of 2.4.47
https://bz.apache.org/bugzilla/show_bug.cgi?id=65589 --- Comment #9 from Judea --- (In reply to Stefan Eissing from comment #3) > There are long HTML lists of some performance figures on their test suites. > Does not tell me anything really. I mean you see that things are slower, but > one as no idea what they do. "We need performance figures" "The performance figures don't tell us anything" How bout that as of 47 there is a severe performance regression? Thats something. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 65589] Serious Performance Degradation as of 2.4.47
https://bz.apache.org/bugzilla/show_bug.cgi?id=65589 --- Comment #10 from Judea --- (In reply to Yann Ylavic from comment #7) > So it seems that you need help somehow, please provide the requested > informations. Hence this ticket, and yes, will do -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 65592] New: mpm_event does not create new child after MaxConnectionsPerChild is hit
https://bz.apache.org/bugzilla/show_bug.cgi?id=65592 Bug ID: 65592 Summary: mpm_event does not create new child after MaxConnectionsPerChild is hit Product: Apache httpd-2 Version: 2.4.49 Hardware: PC OS: Linux Status: NEW Severity: regression Priority: P2 Component: mpm_event Assignee: bugs@httpd.apache.org Reporter: matt.z...@goodwillaz.org Target Milestone: --- I've encountered issues on multiple servers running Apache 2.4.49 where we have MaxConnectionsPerChild set for the event mpm. When child processes die after this limit his hit, the mpm is not creating new processes which stop Apache from serving any requests. This issue did not exist in 2.4.48. The easiest way for me to reproduce with the most simplistic example is with the httpd docker images. When modifying the mpm_event conf and setting all values to 1 (for ease of testing), 2.4.49 will cease to serve any requests, whereas 2.4.48 will continue to serve request after request. = StartServers 1 MinSpareThreads 1 MaxSpareThreads1 ThreadsPerChild 1 MaxRequestWorkers 1 MaxConnectionsPerChild 1 = I can produce some repos with Dockerfiles in them if necessary. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 65589] Serious Performance Degradation as of 2.4.47
https://bz.apache.org/bugzilla/show_bug.cgi?id=65589 --- Comment #11 from Ruediger Pluem --- (In reply to Judea from comment #8) > (In reply to Ruediger Pluem from comment #2) > > In order to investigate further we would also need: > > > > 1. Coming soon, needs redaction > > 2. Coming soon, needs redaction > > 3. There are no changes other than changing the https image from 46 to 47+ What do you mean by image? A container image? > > 4. Coming soon, needs redaction > > 5. Thats in the JMeter reports Unfortunately it is not. I need the access logs with this information to correlate things. > > 6. Thats also in the JMeter reports I don't have Safari and I will not install it. Please provide it in a format readable for everyone (e.g. zip archive / tar.gz archive containing the reports). -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 65592] mpm_event does not create new child after MaxConnectionsPerChild is hit
https://bz.apache.org/bugzilla/show_bug.cgi?id=65592 --- Comment #1 from Ruediger Pluem --- Created attachment 38046 --> https://bz.apache.org/bugzilla/attachment.cgi?id=38046&action=edit Correctly account processes Can you please try if the attached patch fixes your issue? -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 65589] Serious Performance Degradation as of 2.4.47
https://bz.apache.org/bugzilla/show_bug.cgi?id=65589 --- Comment #12 from Judea --- (In reply to Ruediger Pluem from comment #11) > (In reply to Judea from comment #8) > > (In reply to Ruediger Pluem from comment #2) > > > In order to investigate further we would also need: > > > > > > 1. Coming soon, needs redaction > > > 2. Coming soon, needs redaction > > > 3. There are no changes other than changing the https image from 46 to 47+ > > What do you mean by image? A container image? > > > > 4. Coming soon, needs redaction > > > 5. Thats in the JMeter reports > > Unfortunately it is not. I need the access logs with this information to > correlate things. > > > > 6. Thats also in the JMeter reports > > I don't have Safari and I will not install it. Please provide it in a format > readable for everyone (e.g. zip archive / tar.gz archive containing the > reports). Forget it, we're going to switch to nginx -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 65589] Serious Performance Degradation as of 2.4.47
https://bz.apache.org/bugzilla/show_bug.cgi?id=65589 Judea changed: What|Removed |Added Attachment #38042|0 |1 is obsolete|| -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 65590] fix_uds_filename function seems broken since apache 2.4.49
https://bz.apache.org/bugzilla/show_bug.cgi?id=65590 --- Comment #13 from Sylvain Cresto --- Yes, in my case : Patch 38043 alone : good Patch 38045 alone : bad Patch 38043 + 38045 : good -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 65593] New: MDMessageCmd: event 'ocsp-renewed' is undocumented
https://bz.apache.org/bugzilla/show_bug.cgi?id=65593 Bug ID: 65593 Summary: MDMessageCmd: event 'ocsp-renewed' is undocumented Product: Apache httpd-2 Version: 2.4-HEAD Hardware: All URL: https://httpd.apache.org/docs/2.4/en/mod/mod_md.html#m dmessagecmd OS: All Status: NEW Severity: normal Priority: P2 Component: mod_md Assignee: bugs@httpd.apache.org Reporter: apa...@ohreally.nl Target Milestone: --- Hi, As the subject says, the 'ocsp-renewed' event for the MDMessageCmd directive, which is triggered quite regularly, is not documented. I think I can safely ignore it, but I'd prefer to be sure. Thanks, Rob -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 65592] mpm_event does not create new child after MaxConnectionsPerChild is hit
https://bz.apache.org/bugzilla/show_bug.cgi?id=65592 alex2g...@gmail.com changed: What|Removed |Added CC||alex2g...@gmail.com -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 65592] mpm_event does not create new child after MaxConnectionsPerChild is hit
https://bz.apache.org/bugzilla/show_bug.cgi?id=65592 --- Comment #2 from Matt Zuba --- Thank you for the quick patch. I've applied it on top of the Apache source for Ubuntu from Ondřej Surý found at https://launchpad.net/~ondrej/+archive/ubuntu/apache2 and it has solved the problem in 2.4.49. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 65590] fix_uds_filename function seems broken since apache 2.4.49
https://bz.apache.org/bugzilla/show_bug.cgi?id=65590 Yann Ylavic changed: What|Removed |Added Resolution|--- |DUPLICATE Keywords||FixedInTrunk Status|REOPENED|RESOLVED --- Comment #14 from Yann Ylavic --- Thanks for testing Sylvain. This is now fixed in trunk (r1893516) with the patch attachment 37289 from bug 57691, so I'm marking this PR as duplicate to track the backport at a single place. *** This bug has been marked as a duplicate of bug 57691 *** -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 57691] mod_proxy/proxy_util confuses UDS scheme with HTTP scheme when using RewriteRule
https://bz.apache.org/bugzilla/show_bug.cgi?id=57691 Yann Ylavic changed: What|Removed |Added CC||scre...@gmail.com --- Comment #7 from Yann Ylavic --- *** Bug 65590 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 57691] mod_proxy/proxy_util confuses UDS scheme with HTTP scheme when using RewriteRule
https://bz.apache.org/bugzilla/show_bug.cgi?id=57691 Yann Ylavic changed: What|Removed |Added Keywords|PatchAvailable |FixedInTrunk --- Comment #8 from Yann Ylavic --- Fixed in trunk (r1893516) with Janne's patch which works better than mine when the RewriteRule is in a directory/location context. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 65589] Serious Performance Degradation as of 2.4.47
https://bz.apache.org/bugzilla/show_bug.cgi?id=65589 Ruediger Pluem changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution|--- |CLOSED -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 65592] mpm_event does not create new child after MaxConnectionsPerChild is hit
https://bz.apache.org/bugzilla/show_bug.cgi?id=65592 --- Comment #3 from Ruediger Pluem --- Committed to trunk a r1893520. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 65592] mpm_event does not create new child after MaxConnectionsPerChild is hit
https://bz.apache.org/bugzilla/show_bug.cgi?id=65592 Ruediger Pluem changed: What|Removed |Added Keywords||FixedInTrunk, ||PatchAvailable -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
