Jesse Yates created CALCITE-849:
-----------------------------------
Summary: Streams/Slow iterators dont close on statement close
Key: CALCITE-849
URL: https://issues.apache.org/jira/browse/CALCITE-849
Project: Calcite
Issue Type: Bug
Reporter: Jesse Yates
Assignee: Julian Hyde
Fix For: 1.5.0-incubating
This is easily seen when querying an infinite stream with a clause that cannot
be matched
{code}
select stream PRODUCT from orders where PRODUCT LIKE 'noMatch';
select stream * from orders where PRODUCT LIKE 'noMatch';
{code}
The issue arises when accessing the results in a multi-threaded context. Yes,
its not a good idea (and things will break, like here). However, this case
feels like it ought to be an exception.
Suppose you are accessing a stream and have a query that doesn't match anything
on the stream for a long time. Because of the way a ResultSet is built, the
call to executeQuery() will hang until the first matching result is received.
In that case, you might want to cancel the query because its taking so long.
You also want the thing that's accessing the stream (the StreamTable
implementation) to cancel the querying/collection - via a call to close on the
passed iterator/enumerable.
Since the first result was never generated, the ResultSet was never returned to
the caller. You can get around this by using a second thread and keeping a
handle to the creating statement. When you go to close that statement though,
you end up not closing the cursor (and the underlying iterables/enumberables)
because it never finished getting created.
It gets even more problematic if you are use select * as the iterable doesn't
finish getting created in the AvaticaResultSet.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
