[
https://issues.apache.org/jira/browse/IGNITE-12424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16994438#comment-16994438
]
Ivan Pavlukhin commented on IGNITE-12424:
-----------------------------------------
[~samaitra], in your example, an expected result for me is that query is
aborted after 30s (explicit timeout). If we turn a _default timeout_
effectively to _max allowed timeout_ we will loose the ability to increase
timeouts in special cases. I suppose _max allowed timeout_ can be useful as
well, but it is a slightly different thing. Moreover we already have the logic
"explicit timeout overrides default one" for {{IgniteCache.query}} API. It is
good to be consistent among different APIs.
{quote}
Also, I had another question on SqlFieldsQuery.timeout, Is this also not
available for JDBC client users?
{quote}
If you assume so-called JDBCv2, then we do not support explicit timeout here
(https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/jdbc2/JdbcStatement.java#L294).
But a default timeout feature should work.
> Fix default query timeout behavior for thin JDBC
> ------------------------------------------------
>
> Key: IGNITE-12424
> URL: https://issues.apache.org/jira/browse/IGNITE-12424
> Project: Ignite
> Issue Type: Bug
> Components: sql
> Reporter: Ivan Pavlukhin
> Priority: Blocker
> Fix For: 2.8
>
>
> After IGNITE-7285 there appeared a buggy behavior for thin JDBC driver.
> Thin JDBC handles explicit query timeout on a client side. Default query
> timeout is tracked on a server side. As a server is not aware of explicit
> client timeout it is not possible to override a default timeout with longer
> explicit timeout (effectively a query will be cancelled after a default
> timeout expiration).
> The expected behavior is that an explicit query timeout always overrides a
> default one.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
