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 the process id) >> > >> > As far as the relationship between killing queries and the browser, I >> > think the previous comments pretty much summed it up. >> > >> > >> > On Wed, Jun 3, 2009 at 10:22 AM, Jerry Schwartz >> > <jschwa...@the-infoshop.com> wrote: >> > > >> > > >> > >>-----Original Message----- >> > >>From: Jay Blanchard [mailto:jblanch...@pocket.com] >> > >>Sent: Wednesday, June 03, 2009 8:46 AM >> > >>To: Daevid Vincent; mysql@lists.mysql.com >> > >>Subject: RE: Why doesn't mySQL stop a query when the browser tab is >> > >>closedL >> > >> >> > >>[snip] >> > >>I just noticed a horrible thing. >> > >>[/snip] >> > >> >> > >>Keep in mind that the query event is server side and is not >> > tied to the >> > >>browser (client side) once it has begun because of the >> > statelessness of >> > >>the connection. You would have to have some sort of >> > onClose() event from >> > >>the browser that would trigger a query cancellation. >> > >> >> > > [JS] Going beyond that, the browser is at several removes >> > from the MySQL >> > > server. Typically the browser talks to the web server, then >> > the web server >> > > runs some application code (PHP or whatever), and then the >> > application code >> > > talks to the MySQL server. The only part of this chain that >> > "knows" what the >> > > MySQL server is doing is the last bit, the application >> > code, which is >> > > typically waiting for a response. >> > > >> > > Getting back to the user, HTTP itself is a stateless >> > protocol. That means >> > > the web server has no way of knowing if the user, the >> > browser, or even the >> > > user's computer is still there; it also doesn't really know >> > what the user >> > > last did (it's up to the application code to remember that somehow). >> > > >> > > In order for an end user to cancel a query, there would >> > have to be some way >> > > for the user to tell the browser to tell the web server to tell the >> > > application code to tell the MySQL server to stop. I'm >> > pretty sure you could >> > > create a "tired of waiting" button for the user, but I >> > haven't done it >> > > myself. >> > > >> > > Regards, >> > > >> > > Jerry Schwartz >> > > The Infoshop by Global Information Incorporated >> > > 195 Farmington Ave. >> > > Farmington, CT 06032 >> > > >> > > 860.674.8796 / FAX: 860.674.8341 >> > > >> > > www.the-infoshop.com >> > > >> > > >> > > >> > > >> > > >> > >>-- >> > >>MySQL General Mailing List >> > >>For list archives: http://lists.mysql.com/mysql >> > >>To unsubscribe: http://lists.mysql.com/mysql?unsub=jschwa...@the- >> > >>infoshop.com >> > > >> > > >> > > >> > > >> > > >> > > -- >> > > MySQL General Mailing List >> > > For list archives: http://lists.mysql.com/mysql >> > > To unsubscribe: >> > http://lists.mysql.com/mysql?unsub=dstepli...@gmail.com >> > > >> > > >> > >> > >> > >> > -- >> > A: It reverses the normal flow of conversation. >> > Q: What's wrong with top-posting? >> > A: Top-posting. >> > Q: What's the biggest scourge on plain text email discussions? >> > >> >> >> -- >> MySQL General Mailing List >> For list archives: http://lists.mysql.com/mysql >> To unsubscribe: http://lists.mysql.com/mysql?unsub=joh...@pixelated.net >> >> > > > -- > ----------------------------- > Johnny Withers > 601.209.4985 > joh...@pixelated.net > -- Eric Bergen eric.ber...@gmail.com http://www.ebergen.net -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/mysql?unsub=arch...@jab.org
