MySQL Bugs: #28204: Net Connector 5.0.6/5.1.0 compression problem

Bug #28204	Net Connector 5.0.6/5.1.0 compression problem
Submitted:	2 May 2007 14:56	Modified:	19 Jun 2007 7:33
Reporter:	adam chapman	Email Updates:
Status:	Closed	Impact on me:	None
Category:	Connector / NET	Severity:	S3 (Non-critical)
Version:	5.1.0 & 5.0.6	OS:	Windows (visual basic NET 2.0)
Assigned to:		CPU Architecture:	Any
Tags:	mysql net connector

Description:
Using compression with the net connector results in failure when retrieving a large query result set.

How to repeat:
If I run a query with a small result set there is no problem (up to 5,000 records returned)

If i run it where i expect 20,000 records returned the program crashes in error returning 5989 records and the following error message "cannot determine compression algorithm" or something similar.

Hi Adam and thanks for your report. I have seen this while testing Bug#27865. I'll need better test case to see what's happening.

CurrentDbConn.Connection.Open()

Dim Command As New MySqlCommand(SQL)
Command.Connection = currentDbConn.Connection

Dim o_da As New MySqlDataAdapter(Command)
Dim o_DataTable As New DataTable

o_da.Fill(o_DataTable)

CurrentDBConn is just an object containing the standard mysql connection.

The error occus when filling a dataTable component from the dataadapter. The error seems to happen when decrypting large amounts of data to the dataadapter. When no compression is used there is no problem. When compression is used and the results are small there is no problem. But with many records it crashes. However, the records that were put into the datatable are accessible. I get around 5000 viewable records instead of 20,000.

I can possibly make a program with access to a server and debug info if it helps.

Hi Adam. Verified as described:
 - MySQL server 5.0.38BK on WinXP Pro SP2 localhost, NET fw 2.0
 - Test case is trivial, includes only necessary options + "use compression=true", repeated with C#.

mysql> show table status from mydb like "xxx";
+---------+--------+---------+------------+--------+----------------+-----------
--+-------------------+--------------+-----------+----------------+-------------
--------+---------------------+---------------------+-------------------+-------
---+----------------+---------+
| Name    | Engine | Version | Row_format | Rows   | Avg_row_length | Data_lengt
h | Max_data_length   | Index_length | Data_free | Auto_increment | Create_time
        | Update_time         | Check_time          | Collation         | Checks
um | Create_options | Comment |
+---------+--------+---------+------------+--------+----------------+-----------
--+-------------------+--------------+-----------+----------------+-------------
--------+---------------------+---------------------+-------------------+-------
---+----------------+---------+
| xxx | MyISAM |      10 | Fixed      | 189796 |            351 |    6661839
6 | 98797716825440255 |     20577280 |         0 |         194315 | 2006-10-23 2
3:31:54 | 2007-02-05 14:17:06 | 2006-10-23 23:32:14 | latin1_swedish_ci |     NU
LL |                |         |
+---------+--------+---------+------------+--------+----------------+-----------
--+-------------------+--------------+-----------+----------------+-------------
--------+---------------------+---------------------+-------------------+-------
---+----------------+---------+
1 row in set (0.00 sec)

mysql> select @@max_allowed_packet;
+----------------------+
| @@max_allowed_packet |
+----------------------+
|            125828096 |
+----------------------+
1 row in set (0.00 sec)

mysql> describe xxx;
+--------+------------------+------+-----+---------+----------------+
| Field  | Type             | Null | Key | Default | Extra          |
+--------+------------------+------+-----+---------+----------------+
| Rbr    | int(10) unsigned | NO   | PRI | NULL    | auto_increment |
| Godina | year(4)          | NO   | MUL | 2002    |                |
| Tip1   | char(3)          | YES  | MUL | NULL    |                |
| Tip2   | char(3)          | YES  | MUL | NULL    |                |
| Datum1 | date             | YES  | MUL | NULL    |                |
| Datum2 | date             | YES  | MUL | NULL    |                |
| Datum3 | date             | YES  | MUL | NULL    |                |
| Konto  | char(10)         | NO   | MUL |         |                |
| KOpis  | char(100)        | YES  |     | NULL    |                |
| PB     | char(13)         | YES  | MUL | NULL    |                |
| Ime    | char(100)        | YES  |     | NULL    |                |
| Dok1   | char(25)         | YES  | MUL | NULL    |                |
| Dok2   | char(25)         | YES  |     | NULL    |                |
| Pot    | decimal(12,2)    | NO   |     | 0.00    |                |
| Dug    | decimal(12,2)    | NO   |     | 0.00    |                |
| Status | char(1)          | YES  | MUL | NULL    |                |
| Opis   | char(40)         | YES  |     | NULL    |                |
| Marker | char(3)          | YES  | MUL | NULL    |                |
+--------+------------------+------+-----+---------+----------------+
18 rows in set (0.00 sec)

Hi,

I tried increasing the max_allowed_packet size but it makes no difference, I even made it smaller just to be sure but it consistently fails.

I ran a test using the MySQL Query Browser tool with compression on and off.

I can receive 80,882 rows of data in 15seconds with compression on and 39 seconds with compression on, so whatever is used to connect there (it's the Linux version of the tool), the compression works no problem at all when receiving data.

It definitely appears to be a bug either in the NET Connector when filling a datatable with a large amount of compressed records. The same amount of data works just fine with no compression.

Is this problem by the wayside now? I haven't really understood if you've accepted there is a compression issue with .NET and the connector and if the problem will be worked upon.

cheers.

Adam, "Verified" means that there is a test case or other reasonably easy way to reproduce reported, buggy, behavior. Here we depend on fetch from quite large table so I leave report without test case, which is fairly simple and posted in Bug#27865.
As report is verified, now we have to wait until someone is assigned to fix this. When will that be is impossible to tell now.

Probably related to Bug#25151 & Bug#27865.

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/27937

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/27937

Fixed in 5.0.8 and 5.1.2

A note has been added to the 5.0.8 and 5.1.2 changelog.

Hi,

The compression problem now seems to be fixed in 5.0.12.

Thanks.

Is there any chance this would effect JDBC connector 5.0.5.  My clients error begins..

Error. The server encountered an unexpected condition which prevented it from fulfilling the request

Error occurs with indentical conditions.

Jared, please search bugsdb for similar c/J reports and if none is found, post new one. I can't possibly keep track of multiple connectors problem in one report.