Req #41243 [Com]: How to use ZIPARCHIVE::CM_STORE
Edit report at https://bugs.php.net/bug.php?id=41243edit=1 ID: 41243 Comment by: gilles dot bouthenot at univ-fcomte dot fr Reported by:joel dot alexandre at gmail dot com Summary:How to use ZIPARCHIVE::CM_STORE Status: Assigned Type: Feature/Change Request Package:Zip Related PHP Version:5.x Assigned To:pajoye Block user comment: N Private report: N New Comment: Almost SIX years, and no sign that the php developper will improve ZipArchive. The lack of no-compression support is a show stopper, for me and others. This should not be that hard to implement, do it ? Previous Comments: [2013-02-22 14:13:29] chaumond at gmail dot com I need this capability as well. Can anyone help me fix the code and submit a Pull Request on Github? [2012-12-21 19:20:22] dac dot chartrand at gmail dot com I need to create a zip file with a compression level of 0 on some files. Specifically, the EPUB 2.0.1 specification *requires* a file called mimetype to uncompressed, unencrypted, and the first file in the ZIP archive. Without this feature available in ZipArchive, it's useless for EPUB creation. Thank you for your consideration. [2012-10-26 12:34:23] kalibrov1 at gmail dot com Faced with the same problem, I can not create the correct ODS file! [2012-10-17 12:01:39] spamme at filbilisim dot com For back up features and performance issues uncompressed zipping is essential. Please provide this feature [2012-07-18 16:54:16] frozenf...@php.net Any progress on this, pajoye? Given the number of votes on this bug, and its age, I think this needs to be addressed as soon as possible. I encountered this bug today, and it's quite frustrating to not be able to set the compression level. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=41243 -- Edit this bug report at https://bugs.php.net/bug.php?id=41243edit=1
Bug #52948 [Fbk-Opn]: Improper connection closing logic leads to TIME_WAIT sockets on server
Edit report at http://bugs.php.net/bug.php?id=52948edit=1 ID: 52948 User updated by:gilles dot rayrat at continuent dot com Reported by:gilles dot rayrat at continuent dot com Summary:Improper connection closing logic leads to TIME_WAIT sockets on server -Status: Feedback +Status: Open Type: Bug Package:MySQLi related Operating System: Any PHP Version:5.2.14 Block user comment: N New Comment: I'm not sure what I'm using, I am not a php user. I run ubuntu 9.10 and got the package php5-mysql. If you need further info, please advise on how to collect it. I also encountered the case of double time_wait, I guess that the behavior is not fully predictable, and depends on whom between server and client starts the connection closing first. Using, on client, shutdown(sock, SHUT_RD) before sending the quit command, then running shutdown(sock, SHUT_WR) will give more predictable (and, at least to me, appropriate) results Previous Comments: [2010-10-01 03:10:15] cataphr...@php.net I can't reproduce this. Are you using mysqlnd? With the mysql client (package for Ubuntu 10.4), I sometimes get a simultaneous shutdown (which means TIME_WAIT on both sides): (look only at the source, 192.168.1.102 is the client and 192.168.1.2 is the server; the varying destination is because of DNAT) 02:20:31.109223 IP (tos 0x8, ttl 64, id 30843, offset 0, flags [DF], proto TCP (6), length 57) 192.168.1.102.50375 79.168.249.157.3306: P 451:456(5) ack 5105 win 23584 nop,nop,timestamp 549252121 211008142 02:20:31.109535 IP (tos 0x8, ttl 64, id 30844, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.102.50375 79.168.249.157.3306: F, cksum 0xe3b8 (correct), 456:456(0) ack 5105 win 23584 nop,nop,timestamp 549252121 211008142 02:20:31.109766 IP (tos 0x0, ttl 128, id 7011, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.2.3306 192.168.1.1.50375: F, cksum 0xc83d (correct), 5105:5105(0) ack 456 win 64705 nop,nop,timestamp 211008872 549252121 02:20:31.110026 IP (tos 0x0, ttl 128, id 7012, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.2.3306 192.168.1.1.50375: ., cksum 0xc83c (correct), ack 457 win 64705 nop,nop,timestamp 211008872 549252121 02:20:31.112839 IP (tos 0x8, ttl 64, id 30845, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.102.50375 79.168.249.157.3306: ., cksum 0xe0dd (correct), ack 5106 win 23584 nop,nop,timestamp 549252121 211008872 Other times I get the same I get with your example script, a client initiated shutdown, with TIME_WAIT only on the client): 02:24:51.798486 IP (tos 0x0, ttl 64, id 18397, offset 0, flags [DF], proto TCP (6), length 57) 192.168.1.102.55529 79.168.249.157.3306: P 70:75(5) ack 79 win 5840 nop,nop,timestamp 549278188 211034639 02:24:51.798790 IP (tos 0x0, ttl 64, id 18398, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.102.55529 79.168.249.157.3306: F, cksum 0x3dd4 (correct), 75:75(0) ack 79 win 5840 nop,nop,timestamp 549278188 211034639 02:24:51.800286 IP (tos 0x0, ttl 128, id 8297, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.2.3306 192.168.1.1.55529: ., cksum 0xdd38 (correct), ack 76 win 65086 nop,nop,timestamp 211034940 549278188 02:24:51.800583 IP (tos 0x0, ttl 128, id 8298, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.2.3306 192.168.1.1.55529: F, cksum 0xdd37 (correct), 79:79(0) ack 76 win 65086 nop,nop,timestamp 211034940 549278188 02:24:51.802275 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.102.55529 79.168.249.157.3306: ., cksum 0x3ca6 (correct), ack 80 win 5840 nop,nop,timestamp 549278188 211034940 Looking at the source code for mysqlnd, it just calls the PHP stream closing function, which, on Linux, is just a call to close(). I'm by no means a socket expert, but from what I read, unless someone messed with the linger options, close() will send the FIN as soon as it's emptied the send buffer. I don't see how calling shutdown explicitly could possibly help. [2010-09-30 09:03:39] gilles dot rayrat at continuent dot com php: No. TimeSourceDestination Protocol Info 1 0.00192.168.50.129192.168.50.128TCP 57338 mysql [SYN] Seq=0 Win=5840 Len=0 MSS=1460 TSV=88257291 TSER=0 WS=5 2 0.000550192.168.50.128192.168.50.129TCP mysql 57338 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1460 TSV=170478509 TSER=88257291 WS=5 3 0.000574192.168.50.129192.168.50.128TCP 57338 mysql [ACK] Seq=1 Ack=1 Win=5856 Len=0 TSV=88257291 TSER=170478509 4 0.001434192.168.50.128192.168.50.129MySQL Server Greeting
Bug #52948 [Opn]: Improper connection closing logic leads to TIME_WAIT sockets on server
Edit report at http://bugs.php.net/bug.php?id=52948edit=1 ID: 52948 User updated by:gilles dot rayrat at continuent dot com Reported by:gilles dot rayrat at continuent dot com Summary:Improper connection closing logic leads to TIME_WAIT sockets on server Status: Open Type: Bug Package:MySQLi related Operating System: Any PHP Version:5.2.14 Block user comment: N New Comment: Re-reading my previous comment, I realized that the 1st paragraph can be misunderstood. No offense, I just need you to tell me how to provide more accurate info Cheers, Gilles. Previous Comments: [2010-10-01 17:18:55] gilles dot rayrat at continuent dot com I'm not sure what I'm using, I am not a php user. I run ubuntu 9.10 and got the package php5-mysql. If you need further info, please advise on how to collect it. I also encountered the case of double time_wait, I guess that the behavior is not fully predictable, and depends on whom between server and client starts the connection closing first. Using, on client, shutdown(sock, SHUT_RD) before sending the quit command, then running shutdown(sock, SHUT_WR) will give more predictable (and, at least to me, appropriate) results [2010-10-01 03:10:15] cataphr...@php.net I can't reproduce this. Are you using mysqlnd? With the mysql client (package for Ubuntu 10.4), I sometimes get a simultaneous shutdown (which means TIME_WAIT on both sides): (look only at the source, 192.168.1.102 is the client and 192.168.1.2 is the server; the varying destination is because of DNAT) 02:20:31.109223 IP (tos 0x8, ttl 64, id 30843, offset 0, flags [DF], proto TCP (6), length 57) 192.168.1.102.50375 79.168.249.157.3306: P 451:456(5) ack 5105 win 23584 nop,nop,timestamp 549252121 211008142 02:20:31.109535 IP (tos 0x8, ttl 64, id 30844, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.102.50375 79.168.249.157.3306: F, cksum 0xe3b8 (correct), 456:456(0) ack 5105 win 23584 nop,nop,timestamp 549252121 211008142 02:20:31.109766 IP (tos 0x0, ttl 128, id 7011, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.2.3306 192.168.1.1.50375: F, cksum 0xc83d (correct), 5105:5105(0) ack 456 win 64705 nop,nop,timestamp 211008872 549252121 02:20:31.110026 IP (tos 0x0, ttl 128, id 7012, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.2.3306 192.168.1.1.50375: ., cksum 0xc83c (correct), ack 457 win 64705 nop,nop,timestamp 211008872 549252121 02:20:31.112839 IP (tos 0x8, ttl 64, id 30845, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.102.50375 79.168.249.157.3306: ., cksum 0xe0dd (correct), ack 5106 win 23584 nop,nop,timestamp 549252121 211008872 Other times I get the same I get with your example script, a client initiated shutdown, with TIME_WAIT only on the client): 02:24:51.798486 IP (tos 0x0, ttl 64, id 18397, offset 0, flags [DF], proto TCP (6), length 57) 192.168.1.102.55529 79.168.249.157.3306: P 70:75(5) ack 79 win 5840 nop,nop,timestamp 549278188 211034639 02:24:51.798790 IP (tos 0x0, ttl 64, id 18398, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.102.55529 79.168.249.157.3306: F, cksum 0x3dd4 (correct), 75:75(0) ack 79 win 5840 nop,nop,timestamp 549278188 211034639 02:24:51.800286 IP (tos 0x0, ttl 128, id 8297, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.2.3306 192.168.1.1.55529: ., cksum 0xdd38 (correct), ack 76 win 65086 nop,nop,timestamp 211034940 549278188 02:24:51.800583 IP (tos 0x0, ttl 128, id 8298, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.2.3306 192.168.1.1.55529: F, cksum 0xdd37 (correct), 79:79(0) ack 76 win 65086 nop,nop,timestamp 211034940 549278188 02:24:51.802275 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.102.55529 79.168.249.157.3306: ., cksum 0x3ca6 (correct), ack 80 win 5840 nop,nop,timestamp 549278188 211034940 Looking at the source code for mysqlnd, it just calls the PHP stream closing function, which, on Linux, is just a call to close(). I'm by no means a socket expert, but from what I read, unless someone messed with the linger options, close() will send the FIN as soon as it's emptied the send buffer. I don't see how calling shutdown explicitly could possibly help. [2010-09-30 09:03:39] gilles dot rayrat at continuent dot com php: No. TimeSourceDestination Protocol Info 1 0.00192.168.50.129192.168.50.128TCP 57338 mysql [SYN] Seq=0 Win=5840 Len=0 MSS=1460 TSV=88257291 TSER=0 WS=5 2 0.000550192.168.50.128192.168.50.129TCP mysql 57338 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len
Bug #52948 [Fbk-Opn]: Improper connection closing logic leads to TIME_WAIT sockets on server
Edit report at http://bugs.php.net/bug.php?id=52948edit=1 ID: 52948 User updated by:gilles dot rayrat at continuent dot com Reported by:gilles dot rayrat at continuent dot com Summary:Improper connection closing logic leads to TIME_WAIT sockets on server -Status: Feedback +Status: Open Type: Bug Package:MySQLi related Operating System: Any PHP Version:5.2.14 Block user comment: N New Comment: So I'm not using mysqlnd at all. This behavior is not predictable and probably depends on the link and on the velocity of both ends. The shutdown calls allow better control over time_wait tcp connection state, so why not introducing an option so that the user can choose the behavior he wants. Note that there are some threads where sys admins complain about these numerous time_wait sockets and they might appreciate the trick. For the record, here is the mysql (non i) code: ?php # Simple script to demonstrate the TIME_WAIT issue # Connects to the database, nothing more $host = u2; # Host where the Tungsten Connector is running $port = 3306;# Using the Tungsten Connector port $username = tungsten; $password = secret; $dbname = test; echo Connecting to $host $username $password $dbname $port\n; # Make the connection $connection = mysql_connect($host, $username, $password); mysql_close($connection); ? Previous Comments: [2010-10-01 18:12:22] cataphr...@php.net You can check if you're using mysqlnd with phpinfo() or php -i, if in the CLI. Example: php -i | grep mysqlnd Client API library version = mysqlnd 5.0.7-dev - 091210 - $Revision: 300533 $ mysqlnd mysqlnd = enabled Version = mysqlnd 5.0.7-dev - 091210 - $Revision: 300533 $ If you're not using mysqlnd, then it's not our problem to fix. See: http://www.php.net/manual/en/mysqlnd.overview.php As to the shutdown implementation in Linux, it doesn't seem to do a whole lot with SHUT_RD (in terms of packets sent): http://lxr.free-electrons.com/source/net/ipv4/af_inet.c#L768 (note the how++ on line #776) http://lxr.free-electrons.com/source/net/ipv4/tcp.c#L1852 SHUT_RW would force a FIN, but my tests show a FIN is always being sent by the client. The only variable is if the FIN reaches the server before it sends its own FIN. If it does reach it before, then we have a TIME_WAIT on the client; otherwise we have a simultaneous termination and TIME_WAIT on both. There's no way we would be able to prevent this. Web servers typically wait a few seconds to allow the client to disconnect and avoid the TIME_WAIT, maybe the mysql server could do the same. In any case, it's out of our hands. [2010-10-01 17:26:22] gilles dot rayrat at continuent dot com Re-reading my previous comment, I realized that the 1st paragraph can be misunderstood. No offense, I just need you to tell me how to provide more accurate info Cheers, Gilles. [2010-10-01 17:18:55] gilles dot rayrat at continuent dot com I'm not sure what I'm using, I am not a php user. I run ubuntu 9.10 and got the package php5-mysql. If you need further info, please advise on how to collect it. I also encountered the case of double time_wait, I guess that the behavior is not fully predictable, and depends on whom between server and client starts the connection closing first. Using, on client, shutdown(sock, SHUT_RD) before sending the quit command, then running shutdown(sock, SHUT_WR) will give more predictable (and, at least to me, appropriate) results [2010-10-01 03:10:15] cataphr...@php.net I can't reproduce this. Are you using mysqlnd? With the mysql client (package for Ubuntu 10.4), I sometimes get a simultaneous shutdown (which means TIME_WAIT on both sides): (look only at the source, 192.168.1.102 is the client and 192.168.1.2 is the server; the varying destination is because of DNAT) 02:20:31.109223 IP (tos 0x8, ttl 64, id 30843, offset 0, flags [DF], proto TCP (6), length 57) 192.168.1.102.50375 79.168.249.157.3306: P 451:456(5) ack 5105 win 23584 nop,nop,timestamp 549252121 211008142 02:20:31.109535 IP (tos 0x8, ttl 64, id 30844, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.102.50375 79.168.249.157.3306: F, cksum 0xe3b8 (correct), 456:456(0) ack 5105 win 23584 nop,nop,timestamp 549252121 211008142 02:20:31.109766 IP (tos 0x0, ttl 128, id 7011, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.2.3306 192.168.1.1.50375: F, cksum 0xc83d (correct), 5105:5105(0) ack 456 win 64705 nop,nop,timestamp 211008872 549252121 02:20:31.110026 IP (tos 0x0, ttl 128, id
Bug #52948 [Fbk-Opn]: Improper connection closing logic leads to TIME_WAIT sockets on server
Edit report at http://bugs.php.net/bug.php?id=52948edit=1 ID: 52948 User updated by:gilles dot rayrat at continuent dot com Reported by:gilles dot rayrat at continuent dot com Summary:Improper connection closing logic leads to TIME_WAIT sockets on server -Status: Feedback +Status: Open Type: Bug Package:MySQLi related Operating System: Any PHP Version:5.2.14 Block user comment: N New Comment: Thanks for your answer. Yes, the webserver should get the time_wait connections, since you can have several web servers but generally only one database server Furthermore, other mysql client (perl, CLI) will properly let the time_wait connection on the client side After some more testing, it actually appears that the behavior is somehow unpredictable (or I didn't get the logic). I sometimes got time_wait on the client, sometimes on the server - the following shows the case where it appears on the server. These tests are comparing regular mysql CLI client with a simple php script. Host u1 is the client (or webapp) Host u2 is the mysql server Mysql command line is: mysql -hu2 -utungsten -psecret -P3306 test Php script is: ?php # Simple script to demonstrate the TIME_WAIT issue # Connects to the database, nothing more $host = u2; # Host where the Tungsten Connector is running $port = 3306;# Using the Tungsten Connector port $username = tungsten; $password = secret; $dbname = test; echo Connecting to $host $username $password $dbname $port\n; # Make the connection $connection = mysqli_connect($host, $username, $password, $dbname, $port); $connection-close(); ? Command to check for time_wait: netstat -nat| grep 3306| grep TIME_WAIT Will attach both dumps taken with wireshark Previous Comments: [2010-09-30 05:14:41] cataphr...@php.net I'm sorry, I didn't get this. If I understand correctly, you would prefer the web server to be in a TIME_WAIT, rather than the database server, and for that it would have to send the first FIN packet. But why would you prefer the web server to be in a TIME_WAIT state? The front-end side typically needs to handle many more connections. Additionally, it would be nice if you provided an example script and its ouput (in this case, a tcpdump). [2010-09-29 08:36:08] gilles dot rayrat at continuent dot com Description: Similarly to connector/j bug reported here: http://bugs.mysql.com/bug.php? id=56979, there is a problem with mysql disconnection logic where the TCP connection TIME_WAIT state is found on the server rather than on the client. With multiple clients and multiple connection, the MySQL server can run out of file descriptors quickly. The disconnect method should first set EOF to its input, then send the QUIT command, then set its output to EOF, then close the socket Note: I guess the same bug appears in MySQL-non-i as well -- Edit this bug report at http://bugs.php.net/bug.php?id=52948edit=1
Bug #52948 [Opn]: Improper connection closing logic leads to TIME_WAIT sockets on server
Edit report at http://bugs.php.net/bug.php?id=52948edit=1 ID: 52948 User updated by:gilles dot rayrat at continuent dot com Reported by:gilles dot rayrat at continuent dot com Summary:Improper connection closing logic leads to TIME_WAIT sockets on server Status: Open Type: Bug Package:MySQLi related Operating System: Any PHP Version:5.2.14 Block user comment: N New Comment: php: No. TimeSourceDestination Protocol Info 1 0.00192.168.50.129192.168.50.128TCP 57338 mysql [SYN] Seq=0 Win=5840 Len=0 MSS=1460 TSV=88257291 TSER=0 WS=5 2 0.000550192.168.50.128192.168.50.129TCP mysql 57338 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1460 TSV=170478509 TSER=88257291 WS=5 3 0.000574192.168.50.129192.168.50.128TCP 57338 mysql [ACK] Seq=1 Ack=1 Win=5856 Len=0 TSV=88257291 TSER=170478509 4 0.001434192.168.50.128192.168.50.129MySQL Server Greeting proto=10 version=5.1.26-rc-log 5 0.001960192.168.50.129192.168.50.128TCP 57338 mysql [ACK] Seq=1 Ack=64 Win=5856 Len=0 TSV=88257292 TSER=170478510 6 0.005680192.168.50.129192.168.50.128MySQL Login Request user=tungsten db=test 7 0.006010192.168.50.128192.168.50.129TCP mysql 57338 [ACK] Seq=64 Ack=72 Win=5792 Len=0 TSV=170478511 TSER=88257293 8 0.006073192.168.50.128192.168.50.129MySQL Response OK 9 0.006383192.168.50.129192.168.50.128MySQL Request Quit 10 0.006618192.168.50.128192.168.50.129TCP mysql 57338 [FIN, ACK] Seq=75 Ack=77 Win=5792 Len=0 TSV=170478511 TSER=88257293 11 0.006672192.168.50.129192.168.50.128TCP 57338 mysql [FIN, ACK] Seq=77 Ack=76 Win=5856 Len=0 TSV=88257293 TSER=170478511 12 0.007198192.168.50.128192.168.50.129TCP mysql 57338 [ACK] Seq=76 Ack=78 Win=5792 Len=0 TSV=170478511 TSER=88257293 mysql CLI: No. TimeSourceDestination Protocol Info 1 0.00192.168.50.129192.168.50.128TCP 57339 mysql [SYN] Seq=0 Win=5840 Len=0 MSS=1460 TSV=88268477 TSER=0 WS=5 2 0.000453192.168.50.128192.168.50.129TCP mysql 57339 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1460 TSV=170489695 TSER=88268477 WS=5 3 0.000671192.168.50.129192.168.50.128TCP 57339 mysql [ACK] Seq=1 Ack=1 Win=5856 Len=0 TSV=88268477 TSER=170489695 4 0.001337192.168.50.128192.168.50.129MySQL Server Greeting proto=10 version=5.1.26-rc-log 5 0.001504192.168.50.129192.168.50.128TCP 57339 mysql [ACK] Seq=1 Ack=64 Win=5856 Len=0 TSV=88268477 TSER=170489695 6 0.001685192.168.50.129192.168.50.128MySQL Login Request user=tungsten db=test 7 0.001872192.168.50.128192.168.50.129TCP mysql 57339 [ACK] Seq=64 Ack=72 Win=5792 Len=0 TSV=170489695 TSER=88268477 8 0.001984192.168.50.128192.168.50.129MySQL Response OK 9 0.003621192.168.50.129192.168.50.128MySQL Request Query 10 0.004348192.168.50.128192.168.50.129MySQL Response 11 0.004764192.168.50.129192.168.50.128MySQL Request Query 12 0.005434192.168.50.128192.168.50.129MySQL Response 13 0.005698192.168.50.129192.168.50.128MySQL Request Show Fields 14 0.005941192.168.50.128192.168.50.129MySQL Response 15 0.006104192.168.50.129192.168.50.128MySQL Request Show Fields 16 0.006336192.168.50.128192.168.50.129MySQL Response 17 0.006438192.168.50.129192.168.50.128MySQL Request Show Fields 18 0.006650192.168.50.128192.168.50.129MySQL Response 19 0.006760192.168.50.129192.168.50.128MySQL Request Show Fields 20 0.006975192.168.50.128192.168.50.129MySQL Response 21 0.007077192.168.50.129192.168.50.128MySQL Request Show Fields 22 0.007325192.168.50.128192.168.50.129MySQL Response 23 0.007884192.168.50.129192.168.50.128MySQL Request Show Fields 24 0.008327192.168.50.128192.168.50.129MySQL Response 25 0.008498192.168.50.129192.168.50.128MySQL Request Show Fields 26 0.008752
[PHP-BUG] Bug #52948 [NEW]: Improper connection closing logic leads to TIME_WAIT sockets on server
From: Operating system: Any PHP version: 5.2.14 Package: MySQLi related Bug Type: Bug Bug description:Improper connection closing logic leads to TIME_WAIT sockets on server Description: Similarly to connector/j bug reported here: http://bugs.mysql.com/bug.php? id=56979, there is a problem with mysql disconnection logic where the TCP connection TIME_WAIT state is found on the server rather than on the client. With multiple clients and multiple connection, the MySQL server can run out of file descriptors quickly. The disconnect method should first set EOF to its input, then send the QUIT command, then set its output to EOF, then close the socket Note: I guess the same bug appears in MySQL-non-i as well -- Edit bug report at http://bugs.php.net/bug.php?id=52948edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52948r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52948r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52948r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52948r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52948r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52948r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52948r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52948r=needscript Try newer version: http://bugs.php.net/fix.php?id=52948r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52948r=support Expected behavior: http://bugs.php.net/fix.php?id=52948r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52948r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52948r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52948r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52948r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52948r=dst IIS Stability: http://bugs.php.net/fix.php?id=52948r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52948r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52948r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52948r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52948r=mysqlcfg
#13142 [Com]: strtotime() returns -1 for M d H:i:s Y format
ID: 13142 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Verified Bug Type: Date/time related Operating System: Linux PHP Version: 4.3.0-dev New Comment: I am using PHP 4.2.3 under Windows 2000 where date(D M d H:i:s T Y) produces... Fri Oct 11 09:52:47 Eastern Standard Time 2002 instead of... Fri Oct 11 09:52:47 EDT 2002 and, strtotime() of either format produced above returns -1 Previous Comments: [2002-07-04 13:22:32] [EMAIL PROTECTED] Verified during the Bughunt [2001-09-04 20:15:24] [EMAIL PROTECTED] Uh..reproduced I meant. :) [2001-09-04 20:15:10] [EMAIL PROTECTED] Confirmed with latest CVS. [2001-09-04 16:47:44] [EMAIL PROTECTED] strtotime(Sep 04 16:39:45 2001) returns -1 with PHP 4.0.6 this was working with PHP 4.0.3 -- Edit this bug report at http://bugs.php.net/?id=13142edit=1
Bug #16680 Updated: socket_read() does not have the described behaviour ...
ID: 16680
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: Sockets related
Operating System: Windows 9x
PHP Version: 4.2.0
New Comment:
i ran your script and connected with teraterm pro from my win2000 box
(local):
i typed 'hello world' ans then disconnected.
this is the output i got:
D:\Apache\htdocsd:\php\php-cli -q -f d:\apache\htdocs\testje.php
string(1) h
string(1) e
string(1) l
string(1) l
string(1) o
string(1)
string(1) w
string(1) o
string(1) r
string(1) l
string(1) d
ring(2)
i guess this should have been a single line, right?
i couldn't test it at this moment with a connection from my linux box
since i'm in a NAT'ed network.
i will try later though.
Previous Comments:
[2002-05-04 19:37:46] [EMAIL PROTECTED]
How did you test sending data to your php script which received the
data? I've noticed that the telnet version shipped with windows does by
default transmit every character immidiately over the line (hence
resulting only in single characters sent). If I telnet from a linux
host to the script running under win32 I recevied the whole data only
after I pressed return.
I've tested it with this simple script:
?
error_reporting(E_ALL);
if (false === ($s = socket_create(AF_INET, SOCK_STREAM, SOL_TCP)))
exit;
if (false === socket_bind($s, '0.0.0.0', 8765))
exit;
if (false === socket_listen($s, 10))
exit;
if (false === ($t = socket_accept($s)))
exit;
while ($data = socket_read($t, 1024)) {
var_dump($data);
}
?
[2002-05-04 19:07:35] [EMAIL PROTECTED]
Please try with CVS HEAD and report back.
[2002-05-04 13:19:44] [EMAIL PROTECTED]
i have exactly the same problem with win2000.
it closes the connection immidiatly after the first received char.
that little scriptlet upthere seems to be be a way around this.
is this a bug or is it suppost to work like this?
[2002-04-18 09:57:00] [EMAIL PROTECTED]
In the documentation, it's written that socket_read() reads data from
the socket until a \n, \t, \0 or until the end of the buffer.
But under win32 it reads only 1 char.
This would be fixed.
Just use instead :
$buf=;
while (substr($buf,-1)!=\n) {
$buf.=socket_read($socket,1);
}
I've put 1 here, but you can write 16777216 it'll continue to give back
only 1 char.
--
Edit this bug report at http://bugs.php.net/?id=16680edit=1
Bug #16680 Updated: socket_read() does not have the described behaviour ...
ID: 16680
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Sockets related
Operating System: Windows 9x
PHP Version: 4.2.0
New Comment:
i have exactly the same problem with win2000.
it closes the connection immidiatly after the first received char.
that little scriptlet upthere seems to be be a way around this.
is this a bug or is it suppost to work like this?
Previous Comments:
[2002-04-18 09:57:00] [EMAIL PROTECTED]
In the documentation, it's written that socket_read() reads data from
the socket until a \n, \t, \0 or until the end of the buffer.
But under win32 it reads only 1 char.
This would be fixed.
Just use instead :
$buf=;
while (substr($buf,-1)!=\n) {
$buf.=socket_read($socket,1);
}
I've put 1 here, but you can write 16777216 it'll continue to give back
only 1 char.
--
Edit this bug report at http://bugs.php.net/?id=16680edit=1
