Bug #67884 [Com]: Doing a request to itself causes a lock

From: Date: Fri, 22 Aug 2014 18:59:14 +0000
Subject: Bug #67884 [Com]: Doing a request to itself causes a lock
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-187245@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=67884&edit=1 ID: 67884 Comment by: jgmdev@php.net Reported by: jgmdev@php.net Summary: Doing a request to itself causes a lock Status: Open Type: Bug Package: Built-in web server Operating System: Linux (Archlinux) PHP Version: 5.5.15 Block user comment: N Private report: N New Comment: I see :(, looking at the code polling was used, well I'm not going to be able to test my system using the built-in server. Something like http://en.wikipedia.org/wiki/Multiple_asynchronous_periodic_polling would solve the issue, wonder how much work it would be to implement that. Previous Comments: ------------------------------------------------------------------------ [2014-08-22 18:45:12] requinix@php.net With a sleep(1) in the router script I get Concurrency Level: 100 Time taken for tests: 1000.604 seconds Complete requests: 1000 Failed requests: 0 Total transferred: 121000 bytes HTML transferred: 0 bytes Requests per second: 1.00 [#/sec] (mean) Time per request: 100060.414 [ms] (mean) Time per request: 1000.604 [ms] (mean, across all concurrent requests) Transfer rate: 0.12 [Kbytes/sec] received Given X=number of concurrent requests served by PHP, and a sleep(1) to account for the various "per second"-s, the report will say: - Time taken: 1000 [total time] / X - Requests per second: X - Mean time per request: 100 [concurrent requests by AB] * 1000 [msec. each] / X So it's not concurrent. Besides, I don't see any threading or forking going on in the source code. ------------------------------------------------------------------------ [2014-08-22 13:10:34] jgmdev@php.net I tested with ab -c 100 -n 1000 http://localhost:8001/ and a router file that doesn't request it self: <?php print "something"; And here are the results, which shows that the built-in server does supports concurrency/threading (unless it is happening so fast that feels like threading): Concurrency Level: 100 Time taken for tests: 0.075 seconds Complete requests: 1000 Failed requests: 0 Total transferred: 118000 bytes HTML transferred: 7000 bytes Requests per second: 13335.82 [#/sec] (mean) Time per request: 7.499 [ms] (mean) Time per request: 0.075 [ms] (mean, across all concurrent requests) Transfer rate: 1536.75 [Kbytes/sec] received Also the meaning of "PHP applications will stall if a request is blocked" isn't clear. ------------------------------------------------------------------------ [2014-08-22 04:17:37] requinix@php.net Isn't the server single-threaded? The docs say right there at the top "PHP applications will stall if a request is blocked". ------------------------------------------------------------------------ [2014-08-22 03:28:22] jgmdev@php.net Description: ------------ The built-in testing webserver locks down if current executing script makes a request using file_get_contents, get_headers, as any function which supports the http:// streams that makes a request to itself. With the router test script provided try: php -S localhost:8001 router-test.php wget http://localhost:8001/something (works fine) wget http://localhost:8001/ (lock when requesting /something) Test script: --------------- <?php $path = ""; if(isset($_SERVER["PHP_SELF"])) { $path .= ltrim($_SERVER["PHP_SELF"], "/"); } if($path == "something") { print "something"; } else { print "nothing"; // Locks here print file_get_contents("http://localhost:8001/something"); } Expected result: ---------------- Request to http://localhost:8001/ should print nothingsomething Actual result: -------------- The php built-in webserver locks when trying to request http://localhost:8001/something. ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=67884&edit=1

« previous php.bugs (#187245) next »