MySQL Bugs: #67453: MySQL Connector/J cannot use compression

Bug #67453	MySQL Connector/J cannot use compression
Submitted:	2 Nov 2012 6:25	Modified:	20 Nov 2012 8:13
Reporter:	Daniel Halperin (OCA)	Email Updates:
Status:	Duplicate	Impact on me:	None
Category:	Connector / J	Severity:	S3 (Non-critical)
Version:	5.1.22	OS:	Any
Assigned to:	Assigned Account	CPU Architecture:	Any
Tags:	compress, connector, java, useCompression

Description:
A year ago, Mark Matthews disabled compression in Connector/J. (http://bazaar.launchpad.net/~mysql/connectorj/5.1/revision/1109) As far as I can tell, there are no open or closed bug reports about why this happened, nor are any pointed to in that commit.

It is listed as a temporary change but has not been moved on. I tried to undo the commenting and recompile the driver, but compilation failed, so I couldn't "fix" (kluge) it myself.

I decided to create the bug report so at least it the issue might be tracked and so others don't get lost trying to find out why compression isn't broken. Google found nothing, and I tried off and on for a month until I thought to download the driver source.

How to repeat:
http://bazaar.launchpad.net/~mysql/connectorj/5.1/revision/1109

Hi Daniel,

Thanks for the report. We remember about this problem and I have to say that patch is already approved. We plan to include it into next release (5.1.23), it just requires some additional tests.

This bug is duplicate of Bug#11237

Hi,

Is there any date on when connectorj 5.1.23 is going to be released with useCompression=true functionality available again?  

Due to several bugs, Bug #14563127 and Bug #63135 in particular, we wish to move to 5.1.22.  However, the inability to have compression enabled (due to limited bandwidth issues), means that moving to 5.1.22 is proving difficult/impossible without compression.

We have patched, locally, a version of 5.1.22 reverting the commit (http://bazaar.launchpad.net/~mysql/connectorj/5.1/revision/1109 - Thank you very much for the link Daniel) to enabled the useCompression property.  We are thinking of running with this in production, after testing.  However, it would be great to know:

- What are the issues surrounding the hard coded useCompression=false, and if enabling it again is going to cause any serious issue we haven't yet come across (i.e. corruption etc)?  
-- It would be good to understand the associated issues, and gauge the risk of patching.  From the commits, and associated bug (thanks again Daniel), it looks relating to large data imports and large data sets.  However, it would be good to know exactly the issues.

- When is the release date of the 5.1.23? so we can gauge the risk associated with going with our custom patch.

Thank you in advance.
Dominic

Hi Dominic,

The problem with compression occurs when max_allowed_packet > 16M-2 (wrong split of compressed packets at this margin). If you don't plan to use that size you can revert 1109 commit.

There is no release date of 5.1.23 yet, but I believe that we want to release it in Feb.