[
https://issues.apache.org/jira/browse/HIVE-9423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15510234#comment-15510234
]
Peter Vary commented on HIVE-9423:
----------------------------------
This is the output of my not yet uploaded patch :)
{code}
Connecting to jdbc:hive2://localhost:10000
Unexpected end of file when reading from HS2 server. The root cause might be
too high concurrent number of connections. Please check the number of active
connections, and adjust hive.server2.thrift.max.worker.threads is applicable
Error: Could not open client transport with JDBC Uri:
jdbc:hive2://localhost:10000:null (state=08S01,code=0)
Beeline version 2.2.0-SNAPSHOT by Apache Hive
beeline>
{code}
The 'null' is because of the general exception logging, and the
TIOStreamTransport.java in Thrift 0.9.3 throws an exception without a message
this case, and in the HiveConnection.java the root exception message is added
to the message of the thrown exception. Shall I change HiveConnection.java, to
add the message only if it is not null?
Thanks,
Peter
> HiveServer2: Implement some admission control mechanism for graceful
> degradation when resources are exhausted
> -------------------------------------------------------------------------------------------------------------
>
> Key: HIVE-9423
> URL: https://issues.apache.org/jira/browse/HIVE-9423
> Project: Hive
> Issue Type: Bug
> Components: HiveServer2
> Affects Versions: 0.12.0, 0.13.0, 0.14.0, 0.15.0
> Reporter: Vaibhav Gumashta
> Assignee: Peter Vary
> Attachments: HIVE-9423.patch
>
>
> An example of where it is needed: it has been reported that when # of client
> connections is greater than {{hive.server2.thrift.max.worker.threads}},
> HiveServer2 stops accepting new connections and ends up having to be
> restarted. This should be handled more gracefully by the server and the JDBC
> driver, so that the end user gets aware of the problem and can take
> appropriate steps (either close existing connections or bump of the config
> value or use multiple server instances with dynamic service discovery
> enabled). Similarly, we should also review the behaviour of background thread
> pool to have a well defined behavior on the the pool getting exhausted.
> Ideally implementing some form of general admission control will be a better
> solution, so that we do not accept new work unless sufficient resources are
> available and display graceful degradation under overload.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
