Net::MySQL hangs for query results with one record

[mnikhil-git]

Hi,

I have checked that for the SELECT queries performed on the table/views with only one record, the session hangs for almost indefinite in Net::MySQL.

I think this behaviour is due to the way the packet/column length is processed in checking whether the returned query length is type of select query (or update query) and the recv function from IO::Socket is made to wait indefinitely unnecessary.

This case is reproducible for the results with one record or packet length of 1 byte.

Packet length of 1 byte are of generally from the table maintenance statements like Optimize, Repair table etc.,.

[mnikhil-git]

I think the difference is in checking if there is another packet with a data response, and the data packet protocol response from mysql should end with either 'FE 00 00 22 00' in hex code but it ends up with 'FE 00 00 02 00' when there is a single packet response and more so when the packet response is with a single record response.
I think I now have sufficient understanding of why 'optimize table' command hangs when using Net::MySQL module and will shortly provide the adhoc working patch over issue#1 here;

[mnikhil-git]

I looked around for a while in reading the packet stream and found that single record query result has a different end of the packet stream message orientation with footer ending with as noted above 'FE 00 00 02 00' in hex code as against 'FE 00 00 22 00' which is usual for other select or multi record query result set. So, in the check of '_has_next_packet', adding both the checks fixed my problem.

This patch is over the other patch (provided by Krisodb) available in #1

 -       return (substr($_[0],-5) ne "\xfe\0\0\x22\x00";
 +       return (substr($_[0],-5) ne "\xfe\0\0\x02\x00" and substr($_[0], -5) ne "\xfe\0\0\x22\x00");

[mnikhil-git]

@tsucchi any updates on this?

[tsucchi]

Please add test code or test case, or I can't apply any patch for this issue