ignite-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vladimir Ozerov (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (IGNITE-5439) JDBC thin: support query cancel
Date Wed, 07 Nov 2018 09:00:01 GMT

    [ https://issues.apache.org/jira/browse/IGNITE-5439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16677871#comment-16677871

Vladimir Ozerov commented on IGNITE-5439:

[~alapin], [~tledkov-gridgain], 
Yes, looks like this would not that easy task to implement. 

To recap our previous discussions first. We have a blocking socket and we need to cancel the
request on a driver side, as well as do our best to cancel it on the server side. Regarding
cancelling request on the server in case of timeout (IGNITE-5438) side all is easy - all we
need add timeout parameter to requests (maintaining compatibility) and set this timeout on
the server. 

Things are a bit more complex for the client. First, we need to trigger a timeout/cancel from
the outside. For timeouts we may use executor service, timeout objects, whatever (see implementations
of other drivers). As you correctly mentioned semantics of this external action will be pretty
similar to {{Statement.cancel}} method. The most complex thing is work with synchronous socket.
I propose to do the following when cancel is triggered:
1) Every connection must maintain a reference to a thread which performs request at the moment,
cancellation flag, flag indicating whether request any is in progress.
2) External thread must set cancellation flag and then interrupt that thread. This should
only be performed if we know for sure that connection thread is really blocked on IO. We need
to utilize a kind of synchronized section for this.
3) Once interrupted thread must send special request to the server (need to introduce new
message type).
4) When request arrives, we need to acquire a critical section, trigger query cancel, then
send response back immediately. The very critical piece here is that we must maintain strict
invariant that once cancel response is sent, we must never send response of previously received
request. Otherwise, client will be broken due to unexpected content from the socket.
5) Once cancel request is sent, client socket must read for data from the server until paired
cancel response is received. Once we observed it, cancel flow is done.

One tricky part here is how to process cancel request is a timely manner on the server. Currently
we utilize async NIO filter which process requests in a separate thread pool. Unfortunately
this processing is fully blocking at the moment. That is, N long-running queries may block
all threads, so that cancel request will not be processed until there is a room in the thread
pool, which defeats our ides of "cancel and return ASAP". I think the solution is to process
cancel request synchronously in NIO server thread. This should be fairly easy to do - may
be a kind of special filter which will either process message synchronously, or delegate to
the thread pool.

> JDBC thin: support query cancel
> -------------------------------
>                 Key: IGNITE-5439
>                 URL: https://issues.apache.org/jira/browse/IGNITE-5439
>             Project: Ignite
>          Issue Type: Task
>          Components: jdbc
>    Affects Versions: 2.0
>            Reporter: Taras Ledkov
>            Assignee: Alexander Lapin
>            Priority: Major
>             Fix For: 2.8
> The JDBC {{Statement.cancel}} method must be supported.

This message was sent by Atlassian JIRA

View raw message