[
https://issues.apache.org/jira/browse/HIVE-25203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
László Bodor updated HIVE-25203:
--------------------------------
Description:
While testing retry scenarios of HIVE-24786, we found that
HiveQueryResultSet.close() is called twice, which is not expected. There are 2
different issues here:
1. ResultSet should not handle Statement as in HiveQueryResultSet:
{code}
if (this.statement != null && (this.statement instanceof HiveStatement)) {
HiveStatement s = (HiveStatement) this.statement;
s.closeClientOperation();
{code}
The hiearchy of Connection(HiveConnection) -> Statement(HiveStatement) ->
ResultSet(HiveQueryResultSet) should be respected in a sense that the parent
can handle child but not the opposite way, only except a single case, where the
state of the result set has an effect of statement's state, which is
[Statement.closeOnCompletion|https://docs.oracle.com/javase/7/docs/api/java/sql/Statement.html#closeOnCompletion()],
which was introduced by HIVE-22698.
The above logic was introduced by
[HIVE-4974|https://github.com/apache/hive/blame/master/jdbc/src/java/org/apache/hive/jdbc/HiveQueryResultSet.java#L276].
Its intention was to make children able to return their parents, but that
doesn't mean they should handle their parents' lifecycle.
2. Also, HiveStatement should close HiveQueryResultSet only if it's not already
closed, so it would make sense to check ResultSet.isClosed() before closing.
This is for the very same reason as another change above, to avoid duplicated
close logic.
Background: under normal circumstances, a close operation is idempotent, we
should not worry about any side effects of calling it twice, but while testing
HIVE-24786, we found strange issues where in case of a SocketTimeoutException,
such code path was hit in the jdbc client, that made
HiveStatement.closeClientOperation() to be called twice, and it led to a
WARNING on HS2 side. This is not expected as the operation close is protected
by stmtHandle != null check, but yet it ran twice. To avoid situations like
this, cleaning up duplicated close calls would help.
was:
While testing retry scenarios of HIVE-24786, we found that
HiveQueryResultSet.close() is called twice, which is not expected. There are 2
different issues here:
1. ResultSet should not handle Statement as in HiveQueryResultSet:
{code}
if (this.statement != null && (this.statement instanceof HiveStatement)) {
HiveStatement s = (HiveStatement) this.statement;
s.closeClientOperation();
{code}
The hiearchy of Connection(HiveConnection) -> Statement(HiveStatement) ->
ResultSet(HiveQueryResultSet) should be respected in a sense that the parent
can handle child but not the opposite way.
The above logic was introduced by
[HIVE-4974|https://github.com/apache/hive/blame/master/jdbc/src/java/org/apache/hive/jdbc/HiveQueryResultSet.java#L276].
Its intention was to make children able to return their parents, but that
doesn't mean they should handle their parents' lifecycle.
2. Also, HiveStatement should close HiveQueryResultSet only if it's not already
closed, so it would make sense to check ResultSet.isClosed() before closing.
This is for the very same reason as another change above, to avoid duplicated
close logic.
Background: under normal circumstances, a close operation is idempotent, we
should not worry about any side effects of calling it twice, but while testing
HIVE-24786, we found strange issues where in case of a SocketTimeoutException,
such code path was hit in the jdbc client, that made
HiveStatement.closeClientOperation() to be called twice, and it led to a
WARNING on HS2 side. This is not expected as the operation close is protected
by stmtHandle != null check, but yet it ran twice. To avoid situations like
this, cleaning up duplicated close calls would help.
> HiveQueryResultSet is not expected to be closed twice
> -----------------------------------------------------
>
> Key: HIVE-25203
> URL: https://issues.apache.org/jira/browse/HIVE-25203
> Project: Hive
> Issue Type: Bug
> Reporter: László Bodor
> Assignee: László Bodor
> Priority: Major
>
> While testing retry scenarios of HIVE-24786, we found that
> HiveQueryResultSet.close() is called twice, which is not expected. There are
> 2 different issues here:
> 1. ResultSet should not handle Statement as in HiveQueryResultSet:
> {code}
> if (this.statement != null && (this.statement instanceof HiveStatement)) {
> HiveStatement s = (HiveStatement) this.statement;
> s.closeClientOperation();
> {code}
> The hiearchy of Connection(HiveConnection) -> Statement(HiveStatement) ->
> ResultSet(HiveQueryResultSet) should be respected in a sense that the parent
> can handle child but not the opposite way, only except a single case, where
> the state of the result set has an effect of statement's state, which is
> [Statement.closeOnCompletion|https://docs.oracle.com/javase/7/docs/api/java/sql/Statement.html#closeOnCompletion()],
> which was introduced by HIVE-22698.
> The above logic was introduced by
> [HIVE-4974|https://github.com/apache/hive/blame/master/jdbc/src/java/org/apache/hive/jdbc/HiveQueryResultSet.java#L276].
> Its intention was to make children able to return their parents, but that
> doesn't mean they should handle their parents' lifecycle.
> 2. Also, HiveStatement should close HiveQueryResultSet only if it's not
> already closed, so it would make sense to check ResultSet.isClosed() before
> closing. This is for the very same reason as another change above, to avoid
> duplicated close logic.
> Background: under normal circumstances, a close operation is idempotent, we
> should not worry about any side effects of calling it twice, but while
> testing HIVE-24786, we found strange issues where in case of a
> SocketTimeoutException, such code path was hit in the jdbc client, that made
> HiveStatement.closeClientOperation() to be called twice, and it led to a
> WARNING on HS2 side. This is not expected as the operation close is protected
> by stmtHandle != null check, but yet it ran twice. To avoid situations like
> this, cleaning up duplicated close calls would help.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
