ID: 29074 User updated by: david dot blair at nsi1 dot com Reported By: david dot blair at nsi1 dot com Status: Open Bug Type: MSSQL related Operating System: MS 2003 PHP Version: 4.3.7 New Comment:
I've never had Apache hang before but I'm also not running through TDS. I just tried upgrading the production server to 5.0.1 last night. I've been running 5.0.0 on the development server and 5.0.1 on my laptop for two weeks/one week with no problems. The database connection failed 6 times last night after we brought everything back up. After 2 more failures this morning I rolled everything back. Oh hell, I just remembered I left php_mssql.dll from the 5.0.1 build in the windows directory...I think I'm going to leave it in there and see what happens...two of us have tested the system with no crashes so far... More info as it comes in... Previous Comments: ------------------------------------------------------------------------ [2004-08-27 01:43:36] jochen dot daum at cabletalk dot co dot nz Hi, I have the same experience with mssql_select_db. I use PHP 4.3.2 as a module with FreeTDS. The mssql extension is patched though with a datetime extension that reads the milliseconds as well (as mentioned in some early bugs) The problem does not seem to occur with heavy load, but after a certain amount of mssql_select_db. According to the documentation: "In case a second call is made to mssql_connect() with the same arguments, no new link will be established, but instead, the link identifier of the already opened link will be returned." (mssql_connect) and "Every subsequent call to mssql_query() will be made on the active database." (mssql_select_db) I have modified my database access layer to call mssql_select_db() before each mssql_query(). After a number of mssql_select_db, I get an instant failure. Retrying helps for some more queries, but then the process hangs with Apache running at 100%. HTH, Jochen ------------------------------------------------------------------------ [2004-07-26 16:14:25] david dot blair at nsi1 dot com I should probably note that fmk and I have exchanged 2 emails outside of this bug report (just so it's part of this paper trail). He brought me up to speed on the thread safety issues of the dblib library. This next part can be taken with a grain of salt. I'm not sure if it's a seperate issue or something that will help fmk in debugging...I upgraded our development server to PHP 5. It's still showing the intermittent problems of the failed connection, but it's not happening at mssql_connect. It happens at mssql_select_db. The error that's returned is: Warning: mssql_select_db() [function.mssql-select-db]: Unable to select database: blah blah blah... I dunno fmk if you made a fix in the 5 version that's not present in the 4.3.7 version? Wondering if you created some magic code that fixes the mssql_connect issue that needs to be applied to the other mssql functions... DB ------------------------------------------------------------------------ [2004-07-12 23:58:22] david dot blair at nsi1 dot com Today at 4:22 the production server just informed me that it took 15 attempts to get a connection. Normally it's alot lower than this when mssql_connect fails...but on the 15th connect it caught. How am I doing this? for-loop until mssql_connect returns a connection. Since it instantaneously fails the user doesn't even know it occurs. Is this a good solution. No. Hence this bug report. What failover would there be in mssql to cause it to fail right away without even looking for the server? Should I have my error email send me any information? I'm not sure what function is out there that would report on the state of mssql. In fact I don't see any reporting functions...I really need someone that knows the workings of this module to work with me on this... ------------------------------------------------------------------------ [2004-07-09 19:51:39] david dot blair at nsi1 dot com We have mssql.max_procs set to 250. So what does that mean; processes? Is a process a single SQL connection? Or is it all events running through mssql? Would: mssql_connect(yada yada); mssql_close(yada); be considered two processes or one? Or is a process a single user requesting thru Apache? We only have 30 employees in our company and there's never an instance where all 30 would be creating a SQL connection at the same time. All connections to the database are made per page, so if they wanted to list all open technician projects, an mssql_connect would be called at the beginning, several different fetches would be made, and then an mssql_close command would be sent before the HTML is generated and shot out to the client computer. If each individual command is a "process" I can see where mssql.max_procs is the problem...but shouldn't each individual command end before the next one begins thus there could only really be 1 or 0 processes at any given time per client connection?? If I used mssql_connect but didn't use mssql_close how long would a process keep alive? Until the script finishes or a specific time frame? And then when we changed mssql_connect to mssql_pconnect last night why did we still have intermittent problems when only one client computer was requesting...that one user should've retained that one persistent connnection as per documentation...it shouldn't have broken instantly with a "Unable to connect..." warning. What's the max number I can set mssql.max_procs to? I don't believe that is the issue, but if it is, then there's another serious bug where once you meet the max procs, then it always assumes max procs and it will never let you connect until the SQL server and the Apache server are reset. ------------------------------------------------------------------------ [2004-07-09 18:46:16] [EMAIL PROTECTED] You can set the number of allowed connections to the server in php.ini. The default value is 25. mssql.max_procs = 25 ------------------------------------------------------------------------ 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 http://bugs.php.net/29074 -- Edit this bug report at http://bugs.php.net/?id=29074&edit=1