Bug 50916 - RewriteMap program: mod_rewrite sends request but does not read response?!?!
RewriteMap program: mod_rewrite sends request but does not read response?!?!
Status: NEW
Product: Apache httpd-2
Classification: Unclassified
Component: mod_rewrite
2.2.17
PC Solaris
: P2 normal (vote)
: ---
Assigned To: Apache HTTPD Bugs Mailing List
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2011-03-11 12:13 UTC by Marco Walther
Modified: 2011-05-31 19:46 UTC (History)
1 user (show)



Attachments
mod_rewrite additional debug logs (1.40 KB, application/octet-stream)
2011-03-11 12:13 UTC, Marco Walther
Details

Note You need to log in before you can comment on or make changes to this bug.
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!