deniskuzZ commented on code in PR #3015:
URL: https://github.com/apache/hive/pull/3015#discussion_r841681619
##########
ql/src/java/org/apache/hadoop/hive/ql/lockmgr/DbTxnManager.java:
##########
@@ -721,7 +721,7 @@ private void stopHeartbeat() {
// The lock should not be held by other thread trying to stop the
heartbeat for more than 31 seconds
isLockAcquired = heartbeatTaskLock.tryLock(31000, TimeUnit.MILLISECONDS);
} catch (InterruptedException e) {
- // safe to go on
+ Thread.currentThread().interrupt();
Review Comment:
We shouldn't just swallow completely an interrupted exception. The least we
should do is restore the interrupted status.
**From the "Java Concurrency in Practice":**
Propagate the InterruptedException . This is often the most sensible policy
if you can get away with it just propagate the InterruptedException to your
caller. This could involve not catching InterruptedException , or catching it
and throwing it again after performing some brief activity specific cleanup.
Restore the interrupt. Sometimes you cannot throw InterruptedException , for
instance when your code is part of a Runnable . In these situations, you must
catch InterruptedException and restore the interrupted status by calling
interrupt on the current thread, so that code higher up the call stack can see
that an interrupt was issued, as demonstrated in Listing 5.10.
You can get much more sophisticated with interruption, but these two
approaches should work in the vast majority of situations. But there is one
thing you should not do with InterruptedException catch it and do nothing in
response. This deprives code higher up on the call stack of the opportunity to
act on the interruption, because the evidence that the thread was interrupted
is lost. The only situation in which it is acceptable to swallow an interrupt
is when you are extending Thread and therefore control all the code higher up
on the call stack. Cancellation and interruption are covered in greater detail
in Chapter 7.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
