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

Reply via email to