[
https://issues.apache.org/jira/browse/HIVE-9423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15525466#comment-15525466
]
Peter Vary commented on HIVE-9423:
----------------------------------
Hi [~ctang.ma],
I have tried to dig deeper about what happens when the server closes the
connection, but the client still tries to read.
I have not found a definitive answer for it, the best thing which I have found
is a stackoverflow discussion:
http://stackoverflow.com/questions/10240694/java-socket-api-how-to-tell-if-a-connection-has-been-closed
This tells us, that if the server closes the connection, and nothing unplanned
happens, then the client should not get an IOException. Is it possible to check
the Thrift server output to find out more about that Sentry case?
As for the error messages you are absolutely right, again. I will post a new
patch with revised error messages, and if you still have better ones then feel
free to suggest something (to tell the truth, until now phrasing messages was
not in my expertise :)
Thanks,
Peter
> HiveServer2: Provide the user with different error messages depending on the
> Thrift client exception code
> ---------------------------------------------------------------------------------------------------------
>
> 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.2.patch, HIVE-9423.3.patch, HIVE-9423.4.patch,
> 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)
