[
https://issues.apache.org/jira/browse/HIVE-5268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13802175#comment-13802175
]
Carl Steinbach commented on HIVE-5268:
--------------------------------------
[~vaibhavgumashta] [~thiruvel] Thanks for tackling this problem. I took a quick
look at the patch and have some thoughts I want to share. One of our design
goals with HiveServer2 was to decouple session state from connection state, the
motivation being that Hive queries can take a long time to complete, and you
probably don't want your session/query to die if someone trips over your
network cable. As a result every RPC contains either a logical session ID, or a
logical operation ID. Because of this separation we can do interesting things
like multiplex multiple sessions over the same physical connection or reference
the same session over multiple physical connections. This property will also
make it a lot easier to implement session migration between HiveServer2
instances. It looks like this patch creates a coupling between physical
connection state and logical session state, and I think we should try to avoid
doing this.
I think we should try to view this issue as two separate problems: 1) making
sure that Thrift resources (e.g. threads) are reclaimed when a client
disconnects or times out due to inactivity, and 2) reclaiming resources
associated with the session (excluding the connection state) when a session
times out due to inactivity. Note that a connection timeout and session timeout
are not linked, i.e. a connection timeout shouldn't trigger a session timeout
and a session timeout shouldn't trigger a connection timeout.
> HiveServer2 accumulates orphaned OperationHandle objects when a client fails
> while executing query
> --------------------------------------------------------------------------------------------------
>
> Key: HIVE-5268
> URL: https://issues.apache.org/jira/browse/HIVE-5268
> Project: Hive
> Issue Type: Bug
> Components: HiveServer2
> Reporter: Vaibhav Gumashta
> Assignee: Thiruvel Thirumoolan
> Fix For: 0.13.0
>
> Attachments: HIVE-5268_prototype.patch
>
>
> When queries are executed against the HiveServer2 an OperationHandle object
> is stored in the OperationManager.handleToOperation HashMap. Currently its
> the duty of the JDBC client to explicitly close to cleanup the entry in the
> map. But if the client fails to close the statement then the OperationHandle
> object is never cleaned up and gets accumulated in the server.
> This can potentially cause OOM on the server over time. This also can be used
> as a loophole by a malicious client to bring down the Hive server.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
