DO NOT REPLY [Bug 40029] mod_proxy should interoperate with RPC over HTTP
https://issues.apache.org/bugzilla/show_bug.cgi?id=40029 Graham Mainwaring changed: What|Removed |Added CC||gra...@mhn.org -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 39079] thread eats 100% CPU, presumably spinning in futex
https://issues.apache.org/bugzilla/show_bug.cgi?id=39079 --- Comment #30 from Rainer Jung 2009-10-06 17:16:07 PDT --- (In reply to comment #29) In case it happens again: you can use ps with the "L" flag to see the list of threads (lightweigt processes) of a process and also CPU time by thread. That way you can identify which thread (or threads) are consuming CPU thus allowing to map it more reliably to the stacks generated with gstack. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 39079] thread eats 100% CPU, presumably spinning in futex
https://issues.apache.org/bugzilla/show_bug.cgi?id=39079 Patrick Higgins changed: What|Removed |Added CC||patrick1...@yahoo.com -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 39079] thread eats 100% CPU, presumably spinning in futex
https://issues.apache.org/bugzilla/show_bug.cgi?id=39079 Patrick Higgins changed: What|Removed |Added Status|NEEDINFO|NEW --- Comment #29 from Patrick Higgins 2009-10-06 16:38:42 PDT --- I'm also seeing a problem that I believe is the same as this one. I think this may be related to bug 44402, but I am not sure and have not been able to apply the patch yet because of fear of losing support from our enterprise distribution vendor. The later comments by Henrik K and Huo Mingyu about the problem persisting in 2.2.11 make me think it may be separate from 44402, but since they did not post additional information, I am not sure that they are really seeing this problem or perhaps a different one. I am running the Red Hat httpd-2.2.3-22.el5 version on two servers that jointly serve around 8 million hits per day. I see around 15 segfaults per day, and so far I've seen two processes enter and endless loop in the two weeks I have been using the worker MPM. I am using the following modules: LoadModule alias_module modules/mod_alias.so LoadModule authz_host_module modules/mod_authz_host.so LoadModule deflate_module modules/mod_deflate.so LoadModule expires_module modules/mod_expires.so LoadModule headers_module modules/mod_headers.so LoadModule jk_module modules/mod_jk.so LoadModule log_config_module modules/mod_log_config.so LoadModule mime_module modules/mod_mime.so LoadModule proxy_http_module modules/mod_proxy_http.so LoadModule proxy_module modules/mod_proxy.so LoadModule rewrite_module modules/mod_rewrite.so LoadModule security2_module modules/mod_security2.so LoadModule setenvif_module modules/mod_setenvif.so LoadModule ssl_module modules/mod_ssl.so LoadModule status_module modules/mod_status.so LoadModule unique_id_module modules/mod_unique_id.so I have not used the log_forensic_module to get better reporting on the segfaults, but the two hung processes (three looping threads total) have all been serving requests in a space that is reverse proxied through mod_proxy_http with rewrite rules. The unusual modules of note that I am loading are mod_security2 and mod_jk. Both of those were compiled in-house, and are versions 2.5.9 and 1.2.28, respectively. I have not captured any core files yet, but have taken stack traces from the two processes in the endless loop. I used "gstack " to get the traces. I took three with a pause of a few seconds between each. The complete stack traces follow (there really were only 3 and 4 threads total), along with a unified diff showing what changed between the three traces I took: Week 2 trace: Thread 3 (Thread 0x428fc940 (LWP 6559)): #0 0x2ae823ee85f2 in select () from /lib64/libc.so.6 #1 0x2ae8237f46d5 in apr_sleep () from /usr/lib64/libapr-1.so.0 #2 0x2ae8278dcd6f in jk_watchdog_func () #3 0x2ae823a02367 in start_thread () from /lib64/libpthread.so.0 #4 0x2ae823eef0ad in clone () from /lib64/libc.so.6 Thread 2 (Thread 0x4fb11940 (LWP 6581)): #0 0x2ae821f1da9f in ap_core_input_filter () from /proc/6558/exe #1 0x2ae821f2d90a in ap_http_filter () from /proc/6558/exe #2 0x2ae827f4300a in ?? () #3 0x2ae827f44f16 in ?? () #4 0x2ae827d31cb1 in proxy_run_scheme_handler () #5 0x2ae827d357f3 in ?? () #6 0x2ae821f1e38a in ap_run_handler () from /proc/6558/exe #7 0x2ae821f21802 in ap_invoke_handler () from /proc/6558/exe #8 0x2ae821f2bfc8 in ap_process_request () from /proc/6558/exe #9 0x2ae821f29200 in ?? () from /proc/6558/exe #10 0x2ae821f255f2 in ap_run_process_connection () from /proc/6558/exe #11 0x2ae821f30a37 in ?? () from /proc/6558/exe #12 0x2ae823a02367 in start_thread () from /lib64/libpthread.so.0 #13 0x2ae823eef0ad in clone () from /lib64/libc.so.6 Thread 1 (Thread 0x2ae826528560 (LWP 6558)): #0 0x2ae823a03655 in pthread_join () from /lib64/libpthread.so.0 #1 0x2ae8237f3d85 in apr_thread_join () from /usr/lib64/libapr-1.so.0 #2 0x2ae821f301b0 in ?? () from /proc/6558/exe #3 0x2ae821f30d79 in ?? () from /proc/6558/exe #4 0x2ae821f30ef5 in ?? () from /proc/6558/exe #5 0x2ae821f3173b in ap_mpm_run () from /proc/6558/exe #6 0x2ae821f0b7e0 in main () from /proc/6558/exe Week 2 diff: --- 6558.12009-10-06 14:37:51.0 -0600 +++ 6558.22009-10-06 14:37:51.0 -0600 @@ -5,7 +5,7 @@ #3 0x2ae823a02367 in start_thread () from /lib64/libpthread.so.0 #4 0x2ae823eef0ad in clone () from /lib64/libc.so.6 Thread 2 (Thread 0x4fb11940 (LWP 6581)): -#0 0x2ae821f1da9f in ap_core_input_filter () from /proc/6558/exe +#0 0x2ae821f1daab in ap_core_input_filter () from /proc/6558/exe #1 0x2ae821f2d90a in ap_http_filter () from /proc/6558/exe #2 0x2ae827f4300a in ?? () #3 0x2ae827f44f16 in ?? () The third trace was identical to the second. Week 1 trace: Thread 4
DO NOT REPLY [Bug 46749] Ldap cache cleaning is broken when LDAPSharedCacheSize is too small
https://issues.apache.org/bugzilla/show_bug.cgi?id=46749 Stefan Fritsch changed: What|Removed |Added Keywords||FixedInTrunk --- Comment #5 from Stefan Fritsch 2009-10-06 12:41:34 PDT --- Fixed in trunk in r822458 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 47925] apache redirection not working
https://issues.apache.org/bugzilla/show_bug.cgi?id=47925 Will Rowe changed: What|Removed |Added Status|REOPENED|NEEDINFO --- Comment #3 from Will Rowe 2009-10-06 09:20:09 PDT --- Prove your assertion with at RewriteLogLevel 9 and provide the log of a single request on this incident. Thanks. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 47945] SSLSessionCache directive mis-parses parens() in pathname
https://issues.apache.org/bugzilla/show_bug.cgi?id=47945 Will Rowe changed: What|Removed |Added Platform|PC |All Summary|SSLSessionCache problem |SSLSessionCache directive |only win x64|mis-parses parens() in ||pathname OS/Version|Windows XP |All --- Comment #1 from Will Rowe 2009-10-06 09:18:09 PDT --- Your analysis is correct (and description was wrong - it is an issue on any platform if the path includes parens). The fix is to split the directive into a TAKE12, where if there is a second argument, the paren parsing is disabled entirely. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 47925] apache redirection not working
https://issues.apache.org/bugzilla/show_bug.cgi?id=47925
sharjeel changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALID |
--- Comment #2 from sharjeel 2009-10-06 07:38:56
PDT ---
I had raised the question in http://httpd.apache.org/userslist.html but that
did not produce any result. I think it is a bug in apache. The redirection rule
was taken from apache manual, so it should handle all types of urls.
RewriteCond %{HTTP_HOST} ^example.com$
RewriteRule ^/(.*)$ http://www.example.com/$1 [L,R]
The above rule does not handles urls like
http://example.com/news/headlines/more.jsp?content=20090624_075115_6540
The rule should redirect
http://example.com/news/headlines/more.jsp?content=20090624_075115_6540
to
http://www.example.com/news/headlines/more.jsp?content=20090624_075115_6540
But it is actually redirecting the url to home page of site with
"?content=20090624_075115_6540" at the end of url.
http://www.example.com/index.jsp?content=20090624_075115_6540
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- 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
DO NOT REPLY [Bug 47945] New: SSLSessionCache problem only win x64
https://issues.apache.org/bugzilla/show_bug.cgi?id=47945 Summary: SSLSessionCache problem only win x64 Product: Apache httpd-2 Version: 2.2.14 Platform: PC OS/Version: Windows XP Status: NEW Severity: critical Priority: P2 Component: mod_ssl AssignedTo: bugs@httpd.apache.org ReportedBy: bugzill...@gmail.com [httpd-ssl.conf] SSLSessionCache "shmcb:C:/Program Files (x86)/Apache Software Foundation/Apache2.2/logs/ssl_scache(512000)" The error is: SSLSessionCache: Invalid Argument: size has to be >- 8192 bytes I THINK what is happening is that the parser is seeing the (x86) part of the file path and getting confused... -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 39418] CacheMaxExpire directive not enforced
https://issues.apache.org/bugzilla/show_bug.cgi?id=39418 Graham Leggett changed: What|Removed |Added See Also||https://issues.apache.org/b ||ugzilla/show_bug.cgi?id=212 ||60 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 21260] CacheMaxExpire directive not enforced !
https://issues.apache.org/bugzilla/show_bug.cgi?id=21260 Graham Leggett changed: What|Removed |Added See Also||https://issues.apache.org/b ||ugzilla/show_bug.cgi?id=394 ||18 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
