[teiid-issues] [JBoss JIRA] (TEIID-3781) Queries are not killed even if the client sends a cancel request

[Steven Hawkins (JIRA)]

    [ https://issues.jboss.org/browse/TEIID-3781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13255334#comment-13255334 ] 

Steven Hawkins commented on TEIID-3781:
---------------------------------------

> I am not sure what is the exact point prior to which is cancellation "safe" (without TimeoutException).

This should be logged as a different issue.  From these logs you can see that the server is sending a response to the client about the cancellation:

08:06:44,972 DEBUG [org.teiid.TRANSPORT] (New I/O worker #63) processing message:MessageHolder: key=2 contents=Invoke interface org.teiid.client.DQP.cancelRequest
...
08:06:46,782 DEBUG [org.teiid.TRANSPORT] (New I/O worker #63) send message: MessageHolder: key=2 contents=true

However I can see on the client side that there is a soft dead lock between the main reader thread and the cancel thread, such that the synchronization of the cancel method can prevent it from receiving the response.

> Queries are not killed even if the client sends a cancel request
> ----------------------------------------------------------------
>
>                 Key: TEIID-3781
>                 URL: https://issues.jboss.org/browse/TEIID-3781
>             Project: Teiid
>          Issue Type: Quality Risk
>          Components: Query Engine
>    Affects Versions: 7.0
>            Reporter: Salvatore R
>            Assignee: Steven Hawkins
>             Fix For: 8.12.1, 8.13
>
>
> I have different behaviors when I try to cancel the following queries:
> {code:sql}
> SELECT COUNT(*)
> FROM
> 	(SELECT * FROM my.address) as x1,
> 	(SELECT * FROM my.address) as y1
> {code}
> and
> {code:sql}
> SELECT COUNT(*)
> FROM
> 	(SELECT * FROM my.address limit 10000) as x1,
> 	(SELECT * FROM my.address limit 10000) as y1
> {code}
> where "my.address" is a table with around 20000 rows in MySQL.
> The first query is immediately cancelled but the second one continues to run until the end and it is never killed.
> Looking at the generated plans, the main difference is that the first query is fully pushed down to MySQL while the second one is not.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)