|Summary:||RewriteMap program: mod_rewrite sends request but does not read response?!?!|
|Product:||Apache httpd-2||Reporter:||Marco Walther <marco.walther>|
|Component:||mod_rewrite||Assignee:||Apache HTTPD Bugs Mailing List <bugs>|
|Attachments:||mod_rewrite additional debug logs|
Description Marco Walther 2011-03-11 12:13:36 UTC
Created attachment 26764 [details] mod_rewrite additional debug logs It looks like a thread acquires the lock, sends a request line to the map program and `disappears'?? The next thread acquires the lock (?) sends it's request line and reads the response from the previous request:-( After that, the synchronisation is broken:-( I added a couple of debug prints to mod_rewrite (diff attached) and they generated the following log (after about two days of running fine:-() ------------------------------------------------------------- ii.247 - - [10/Mar/2011:10:02:27 +0000] usersguide.bd/sid#81f8778rid#9381588/initial (1) mw before lookup_map_program(http://ih/api;usersguide) thread= 0x00000014 ii.247 - - [10/Mar/2011:10:02:27 +0000] usersguide.bd/sid#81f8778rid#9381588/initial (1) mw lookup_map_program thread= 0x00000014 aquire_lock ii.247 - - [10/Mar/2011:10:02:28 +0000] versioncontrol.bd/sid#81f8778rid#98d7060/initial (1) mw before lookup_map_program(http://ih/api;versioncontrol) thread= 0x00000009 ii.247 - - [10/Mar/2011:10:02:28 +0000] versioncontrol.bd/sid#81f8778rid#98d7060/initial (1) mw lookup_map_program thread= 0x00000009 aquire_lock ii.247 - - [10/Mar/2011:10:02:28 +0000] versioncontrol.bd/sid#81f8778rid#98d7060/initial (1) mw lookup_map_program thread= 0x00000009 release_lock ii.247 - - [10/Mar/2011:10:02:28 +0000] versioncontrol.bd/sid#81f8778rid#98d7060/initial (1) mw after lookup_map_program(http://ih/api;versioncontrol)= /projects/usersguide/content thread= 0x00000009 ii.247 - - [10/Mar/2011:10:02:28 +0000] versioncontrol.bd/sid#81f8778rid#98d7060/initial (1) go-ahead with proxy request proxy:balancer://ch/projects/usersguide/content/subversion/teepee/svnclientadapter.html [OK] Thread 0x14 acquires the lock but somehow 0x09 can acquire the lock as well and gets the line actually intended for 0x14. It looks like 0x14 never finishes that request. It's later showing up with other requests. But after this, the results are off by one line.
Comment 1 Stefan Fritsch 2011-04-08 15:45:15 UTC
Look into the error log, too. Maybe the process with thread 0x00000014 died at that time?
Comment 2 Marco Walther 2011-04-08 16:50:07 UTC
I looked in the error log and everywhere. No sign of sudden thread-death:-( so I'm somewhat at a loss there:-( My solution :-( to the problem is to send a timestamp along to the mapping helpers and they send it back with their response. So I can read again when I find a response from a previous request. I would still like to know where those threads go:-(
Comment 3 CaioToOn! 2011-05-31 19:40:32 UTC
Hi, there. I'm facing the sync problem. I'm also using mod_rewrite with external map program, written in Java. My problem rarely happens on my production server, and some days the server is messed up, out of the blue. I'm trying to force the problem to happen again, with no success. I've created a program that starts 65 threads that continuously ask for a random URL on the server in a random ammount of milliseconds, then checks to see if the page matches the expected result. I've create another 25 threads that in a random time kill one of the 65 threads and recreate it, willing to stop the connection abruptly in the middle. The program is running for several minutes without issuing the sync error. Do you guys have any tips on forcing this error to happen consistently, so we could start to understand it? Cheers, CaioToOn!
Comment 4 William A. Rowe Jr. 2018-11-07 21:09:29 UTC
Please help us to refine our list of open and current defects; this is a mass update of old and inactive Bugzilla reports which reflect user error, already resolved defects, and still-existing defects in httpd. As repeatedly announced, the Apache HTTP Server Project has discontinued all development and patch review of the 2.2.x series of releases. The final release 2.2.34 was published in July 2017, and no further evaluation of bug reports or security risks will be considered or published for 2.2.x releases. All reports older than 2.4.x have been updated to status RESOLVED/LATER; no further action is expected unless the report still applies to a current version of httpd. If your report represented a question or confusion about how to use an httpd feature, an unexpected server behavior, problems building or installing httpd, or working with an external component (a third party module, browser etc.) we ask you to start by bringing your question to the User Support and Discussion mailing list, see [https://httpd.apache.org/lists.html#http-users] for details. Include a link to this Bugzilla report for completeness with your question. If your report was clearly a defect in httpd or a feature request, we ask that you retest using a modern httpd release (2.4.33 or later) released in the past year. If it can be reproduced, please reopen this bug and change the Version field above to the httpd version you have reconfirmed with. Your help in identifying defects or enhancements still applicable to the current httpd server software release is greatly appreciated.