[
https://issues.apache.org/jira/browse/IGNITE-2680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15372525#comment-15372525
]
Sergi Vladykin commented on IGNITE-2680:
----------------------------------------
First of all couple of notices on coding style
1. Stop making variable final and try to avoid changing code if no one asked
you to do that.
2. Never use abbreviations on class and method name, this is strongly
prohibited.
Overall I don't like your changes, for timeouts they are mostly wrong (see the
correct way below), for cancellation i don't like RunnableFuture because it
makes me think that queries will run in some separate threads, but it would be
wrong, so I'd prefer to avoid confusing staff like this.
Please rollback everything that you did in IgniteH2Indexing, MapQueryExecutor,
ReduceQueryExecutor and do the following instead:
For query timeouts:
1. In method IgniteH2Indexing.executeSqlQuery pass timeout.
2. Cast Connection to H2 JdbcConnection and get Session from there.
3. Before stmt.execute() if we have a timeout do
session.setQueryTimeout(timeout) - It accepts timeout in milliseconds.
4. In finally block after the statement execution clear the query timeout by
session.setQueryTimeout(0);
5. If method accepts time unit, it must have checks that argument is valid. For
example if we don't support precision higher than milliseconds, than we have to
check that argument is positive and is no less than 1 ms. Also describe these
restrictions in javadocs for all methods (for getters as well).
For query cancellation:
1. Pass additional parameter AtomicReference<GridAbsClosure> cancel
for local queries IgniteH2Indexing.executeSqlQuery(...) and all the way up;
for distributed queries to GridReduceQueryExecutor.query(...) and all the way
up;
2. For local queries wrap PreparedStatement.cancel() into GridAbsClosure and
try to CAS to this ref, if it does not succeed just throw cancellation
exception right away.
For distributed queries you need to put all the needed resources to send cancel
requests to all the parties and cancel reduce query the same way as local one.
3. QueryCursorImpl.close() must have this reference and attempt to get cancel
closure from it and CAS it to no-op constant and if succeeded call apply() on
that cancel closure.
I think once you'll implement this cancellation for local queries, it will be
obvious how to compose these cancellation refs for distributed queries.
> Terminating running SQL queries
> -------------------------------
>
> Key: IGNITE-2680
> URL: https://issues.apache.org/jira/browse/IGNITE-2680
> Project: Ignite
> Issue Type: Bug
> Affects Versions: 1.5.0.final
> Reporter: Denis Magda
> Assignee: Alexei Scherbakov
> Labels: important
>
> If to start a long running SQL query over a huge cache will millions of
> entries there should be a way terminate it. Even if {{QueryCursor}} is closed
> the query won't be cancelled consuming available resources.
> There should be a way to close a query having using an object that is related
> to it. Seems that ideally we can use {{QueryCursor.close()}} method for that;
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
