MySQL Bugs: #16918: Aborted_clients

Bug #16918	Aborted_clients > Connections
Submitted:	30 Jan 2006 23:48	Modified:	23 Oct 2007 2:22
Reporter:	Olaf van der Spek (Basic Quality Contributor)
Status:	Closed
Category:	Server: General	Severity:	S3 (Non-critical)
Version:	5.0.19-BK, 5.0.16	OS:	Linux (Linux, Windows)
Assigned to:	Alexander Nozdrin	Target Version:
Tags:	qc, bfsm_2007_08_02

Description:
show status
917450: Aborted_clients
476260: Connections  

How can Aborted_clients be greater than Connections?

http://dev.mysql.com/doc/refman/5.0/en/server-status-variables.html

> Aborted_clients 
> The number of connections that were aborted because the client died without 
> closing the connection properly. See Section A.2.10, “Communication Errors and 
> Aborted Connections”. 

> Connections 
> The number of connection attempts (successful or not) to the MySQL server. 

How to repeat:
-

Could you please verify if the server increments the aborted_client
status variables when affected for the situations mentioned at:

http://dev.mysql.com/doc/refman/5.0/en/communication-errors.html

 If Aborted connections messages appear in the error log, the cause can be any of the
following:

    *

      The client program did not call mysql_close() before exiting.
    *

      The client had been sleeping more than wait_timeout or interactive_timeout seconds
without issuing any requests to the server. See Section 5.2.2, “Server System
Variables”.
    *

      The client program ended abruptly in the middle of a data transfer.

When any of these things happen, the server increments the Aborted_clients status
variable. 

Thank you in advance.

> Could you please verify if the server increments the aborted_client
> status variables when affected for the situations mentioned at:

I could, but what would that 'proof'?
Aborted_clients is too high, not too low.
So either Aborted_clients is incremented multiple times per connection or Connections is
not (always) incremented.

That proof that the clients aren't using mysql_close, they are exceeding
the timeout and so on.

But I'm not asking why Aborted_clients is so high.
I'm asking why it's higher than Connections itself.

Connections is the number of created connections. How can you abort more connections than
you create?

And what is the value of Threads_created status variable and thread_cache_size server
variable? Had you flushed status since startup?

484112: Threads_created 
0: thread cache size

I may have used flush status, but I'm not sure.

Could you please please provide the output of show status and show
variables.

Thanks in advance.

See attached file.

It looks like a bug for me. But we need a repeatable test case. So, please, try to repeat
the problem after server restart (I was not able to do it yet). The uname -a results for
your system may be also useful.

Linux xwis.net 2.6.12-1-686-smp #1 SMP Tue Sep 27 13:10:31 JST 2005 i686 GNU/Linux

I'll try to produce a repeatable test case.

Got it. I you don't call mysql_close, aborted is increased twice.
OS -> * as Windows is affected too.

You a right! Verified with 5.0.19-BK (ChangeSet@1.2015.1.1, 2006-01-30 22:52:15+03:00) on
Linux, and with some older version on Windows.

To repeat, just open mysql session, execute SHOW STATUS to get Aborted_clients and
Connections values, store them, then kill -9 the mysql process (or just close the cmd.exe
window where it runs, in case of Windows). In the new mysql session execute SHOW STATUS to
get the same values. You will see:

mysql> show status like 'Aborted%';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| Aborted_clients  | 2     |
| Aborted_connects | 0     |
+------------------+-------+
2 rows in set (0.01 sec)

mysql> show status like 'Conn%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Connections   | 5     |
+---------------+-------+
1 row in set (0.00 sec)

Connections incremented by 1, and Aborted_clients incremented by 2. It is either a bug or
a documentation request.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/34176

ChangeSet@1.2524, 2007-09-13 17:30:44+04:00, anozdrin@station. +2 -0
  Bug#16918: Aborted_clients > Connections.
  
  The problem was that aborted_threads variable was updated
  twice when a client connection had been aborted.
  
  The fix is to refactor a code to have aborted_threads updated
  only in one place.

Pushed into 5.0-runtime.

Pushed into 5.1.23-beta

Pushed into 5.0.52

Noted in 5.0.52, 5.1.23 changelogs.

The Aborted_clients status variable was incremented twice if a client
exited without calling mysql_close().