[
https://issues.apache.org/jira/browse/RANGER-5476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18055724#comment-18055724
]
Vyom Mani Tiwari commented on RANGER-5476:
------------------------------------------
Thank you for your thoughtful feedback and suggestions!
You raise an excellent point about API design. You're absolutely right that
relying on implicit interruption isn't ideal from an API contract perspective.
Adding an explicit close() or stop() method to RangerAdminClient would indeed
be a cleaner design. However, as you noted, this would require implementing the
method across all ~20 implementations of the interface, which is a larger
change.
I think we can address this in two phases:
*Phase 1* Fix the InterruptedException handling in
RangerRESTClient.shouldRetry() to properly respect thread interruption. This
solves the deadlock issue immediately without breaking changes.
*Phase 2* Consider adding a close() or shutdown() method to RangerAdminClient
interface as a default method (Java 8+) with a no-op implementation, allowing
implementations to override it for graceful shutdown. This would be a cleaner
long-term design.
> PolicyRefresher.stopRefresher() can deadlock when retrying HTTP request
> -----------------------------------------------------------------------
>
> Key: RANGER-5476
> URL: https://issues.apache.org/jira/browse/RANGER-5476
> Project: Ranger
> Issue Type: Bug
> Components: Ranger
> Affects Versions: 2.7.0
> Reporter: Naoki Takezoe
> Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> PolicyRefresher.stopRefresher() can deadlock when it's called while
> RangerRESTClient is retying server error, because it interrupts itself and
> wait for the completion of the thread:
> https://github.com/apache/ranger/blob/fe379d0a40aa4ae93c978a2c4d3a77fc9df2fbbb/agents-common/src/main/java/org/apache/ranger/plugin/util/PolicyRefresher.java#L167-L175
> But this interruption is caught and ignored in RangerRESTClient when it's
> retrying server error, so PolicyRefresher will never get control back.
> https://github.com/apache/ranger/blob/fe379d0a40aa4ae93c978a2c4d3a77fc9df2fbbb/agents-common/src/main/java/org/apache/ranger/plugin/util/RangerRESTClient.java#L665-L669
> It looks like RangerRESTClient shouldn't ignore InterruptedException but I
> wonder if it affect existing use cases. Rather, it might be better to provide
> a way to stop RangerAdminClient safely and call it from
> PolicyRefresher.stopRefresher().
--
This message was sent by Atlassian Jira
(v8.20.10#820010)