Bug #77987 | Calling StatementImpl.cancel() doesn't kill a query when using streamed results | ||
---|---|---|---|
Submitted: | 7 Aug 2015 19:50 | Modified: | 2 Oct 2015 18:53 |
Reporter: | KUNO OSPALD | Email Updates: | |
Status: | Verified | Impact on me: | |
Category: | Connector / J | Severity: | S3 (Non-critical) |
Version: | 5.1.35 | OS: | Any |
Assigned to: | Filipe Silva | CPU Architecture: | Any |
[7 Aug 2015 19:50]
KUNO OSPALD
[10 Aug 2015 19:32]
Mark Matthews
This patch won't work correctly, it removes a required safety guard, which prevents you from canceling *future* statements. It's more like statementExecuting isn't getting set correctly for streaming statements?
[10 Aug 2015 23:11]
KUNO OSPALD
Thank you for looking at this bug report. Your assumption that statementExecuting is not set correctly for streaming content is correct. But I don't understand why the existing code would prevent "canceling *future* statements" without any synchronization.
[18 Aug 2015 10:06]
KUNO OSPALD
Hi Mark, Did you have a chance to look into this issue again? Kuno
[2 Oct 2015 18:53]
Filipe Silva
Hi Kuno, Thank you for this bug report. What Mark meant by "canceling *future* statements" is a consequence of the behavior observed in MySQL 5.6 and lower versions that, when you issue a KILL QUERY statement without an active running query in that connection, the next one gets killed before starting, and it doesn't event need to be issued from the same Statement instance. This doesn't happen in MySQL 5.7 though. You are right regarding statementExecuting not being set correctly for streaming statements and it should be fixed. This bug report is now verified as described.
[5 Oct 2015 16:14]
Filipe Silva
May be interested in following the related Bug#77658.