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

[2 May 2007 14:56] adam chapman
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.
[3 May 2007 9:03] Tonci Grgin
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.
[3 May 2007 12:36] adam chapman
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.
[7 May 2007 14:15] Tonci Grgin
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)
[8 May 2007 9:35] adam chapman
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.
[8 May 2007 9:42] adam chapman
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.
[21 May 2007 11:29] adam chapman
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.
[21 May 2007 12:00] Tonci Grgin
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.
[29 May 2007 6:58] Tonci Grgin
Probably related to Bug#25151 & Bug#27865.
[1 Jun 2007 15:28] Bugs System
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
[1 Jun 2007 15:28] Bugs System
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
[1 Jun 2007 15:29] Reggie Burnett
Fixed in 5.0.8 and 5.1.2
[6 Jun 2007 10:30] MC Brown
A note has been added to the 5.0.8 and 5.1.2 changelog.
[19 Jun 2007 7:33] adam chapman
Hi,

The compression problem now seems to be fixed in 5.0.12.

Thanks.
[27 Jun 2007 5:11] Jared S
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.
[28 Jun 2007 12:30] Tonci Grgin
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.