Even if it did, it would be by convention only, there is no guarantee. Not only that, but it would likewise be dependent on the browser closing normally, which is likewise no guarantee. The fact of the matter here however is that there is NO set of behavior that would suit everyone. I can think of several examples (modifying table structure, inserting data, etc) where I would want query execution to continue even after the client has gone away. Lastly, and I'll test this later, is this strictly php behavior? I seem to remember queries started with MySQL query browser running to completion even after losing my connection (although I think these were all writes, not reads).
-----Original Message----- From: Johnny Withers [mailto:joh...@pixelated.net] Sent: Sunday, July 26, 2009 6:34 PM To: Eric Bergen Cc: Daevid Vincent; mysql@lists.mysql.com Subject: Re: Why doesn't mySQL stop a query when the browser tab is closedL I'm not sure closing the browser window sends the RST packet back to the server, if it does, that's great! However, if php is waiting on mysql to return a result, it wouldn't notice this anyway until mysql finished processing and returned control back to the script. I could be completly off-base here, I have no way to test this. On Saturday, July 25, 2009, Eric Bergen <eric.ber...@gmail.com> wrote: > PHP will notice if the browser has disconnected when it tries to write > data. If it detects the browser has disconnected it will stop script > execution. You can control what php should do in the event of a > disconnect with the ignore_user_abort() function. See the connection > handling page for more details: > > http://us3.php.net/manual/en/features.connection-handling.php > > On Wed, Jun 3, 2009 at 2:54 PM, Johnny Withers<joh...@pixelated.net> wrote: >> It just seems odd to me that PHP does a mysql_connect and gets a resource >> ID. Then it uses that socket (or whatever it is) to do subsequent queries. >> Mysql has to know about it too in order for it to send back results to the >> same resource/handle/socket/whatever. So either PHP should do some >> cleanup, which >> I assume it does when the page goes away, otherwise PHP would leak memory >> like a sieve all over the place as pages are closed/aborted. >> PHP has no idea the browser left/aborted/died/etc. When you begin a request >> that PHP handles, it begins processing the script, which in turn begins >> processing whatever instructions the script has. At no point in time is it >> aware if a "browser window" is waiting on its response, it simply spits it >> response back to the HTTP server which may or may not have a client reading >> the response to display to a user. >> >> PHP's clean up is when the script ends processing. You can see this by >> creating a PHP script that takes ages to complete (no mysql involved, maybe >> just a loop and sleep statements that sends output to a text file) and >> kicking it off by browsing to the page, then closing your browser and >> tail'ing the output file, you will see it continuing to write to this file >> until the loop is complete. >> >> You can assume what you like about PHP, but that doesn't make it true. >> >> -johnny >> >> >> On Wed, Jun 3, 2009 at 2:03 PM, Daevid Vincent <dae...@daevid.com> wrote: >> >>> We have a "NOC" that displays this sort of thing and shows myTop in six >>> windows for DEV/TEST/PROD and Master/Slave for >>> each.(http://www.daevid.com/content/examples/snippets.php scroll down to >>> "Automatic Monitoring of remote servers" for a handy script) >>> >>> So we do monitor this and will kill long running queries by hand. I was >>> hoping for something a little more automated however. It just seems odd to >>> me that PHP does a mysql_connect and gets a resource ID. Then it uses that >>> socket (or whatever it is) to do subsequent queries. Mysql has to know >>> about >>> it too in order for it to send back results to the same >>> resource/handle/socket/whatever. So either PHP should do some cleanup, >>> which >>> I assume it does when the page goes away, otherwise PHP would leak memory >>> like a sieve all over the place as pages are closed/aborted, OR mySQL >>> should >>> get a signal that, "hey, your handle to return your data on just STB, so >>> stop what you're doing please". >>> >>> On a related note then, is there a way to set a my.cnf setting so that >>> queries that are going for longer than X seconds are re-niced or something >>> to not bog down the system? Ideally I'd assume you'd want each query to >>> "peg >>> the CPU" so that they're in and out quickly and the user can get on with >>> their life. But these long running ones at some point X are then taking >>> over >>> the entire server with 135% CPU usage and killing the experience for any >>> other user on the web site -- and for a duration too! >>> >>> >>> > -----Original Message----- >>> > From: Darryle Steplight [mailto:dstepli...@gmail.com] >>> > Sent: Wednesday, June 03, 2009 8:41 AM >>> > To: Jerry Schwartz >>> > Cc: Jay Blanchard; Daevid Vincent; mysql@lists.mysql.com >>> > Subject: Re: Why doesn't mySQL stop a query when the browser >>> > tab is closedL >>> > >>> > Hi Daevid, >>> > >>> > You can always stop the query by running >>> > >>> > SHOW PROCESSLIST; >>> > >>> > from the command line or your MySql Admin tool. The above command will >>> > show you all of the queries that are currently running along with >>> > their PID# and state. Find the query your want to stop, and run the >>> > following command >>> > KILL #; (where # is -- > Eric Bergen > eric.ber...@gmail.com > http://www.ebergen.net > -- ----------------------------- Johnny Withers 601.209.4985 joh...@pixelated.net -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/mysql?unsub=wal...@vyper.hopto.org -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/mysql?unsub=arch...@jab.org
