[
https://issues.jboss.org/browse/TEIID-3781?page=com.atlassian.jira.plugin...
]
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)