[jira] [Commented] (KAFKA-14565) Improve Interceptor Resource Leakage Prevention

["Chris Egerton (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/KAFKA-14565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17656141#comment-17656141 ] 

Chris Egerton commented on KAFKA-14565:
---------------------------------------

[~beardt] thanks for identifying this issue. Have you considered either altering the {{AbstractConfig::getConfiguredInstances}} method, or the logic in the client classes that leverage it, to invoke {{close}} on any interceptors that have already been instantiated and configured in the scenario described in this ticket? This would allow us to address the resource leak problem without altering public interface (which requires a KIP) or requiring action on the part of developers.

> Improve Interceptor Resource Leakage Prevention
> -----------------------------------------------
>
>                 Key: KAFKA-14565
>                 URL: https://issues.apache.org/jira/browse/KAFKA-14565
>             Project: Kafka
>          Issue Type: Improvement
>          Components: clients
>            Reporter: Terry Beard
>            Assignee: Terry Beard
>            Priority: Major
>             Fix For: 3.5.0
>
>
> The Consumer and Producer interceptor interfaces and their corresponding Kafka Consumer and Producer constructors do not adequately support cleanup of underlying interceptor resources. 
> Currently within the Kafka Consumer and Kafka Producer constructors,  the AbstractConfig.getConfiguredInstances()  is delegated responsibility for both creating and configuring each interceptor listed in the interceptor.classes property and returns a configured  List<ConsumerInterceptor<K,V>> interceptors.
> This dual responsibility for both creation and configuration is problematic when it involves multiple interceptors where at least one interceptor's configure method implementation creates and/or depends on objects which creates threads, connections or other resources which requires clean up and the subsequent interceptor's configure method raises a runtime exception.  This raising of the runtime exception produces a resource leakage in the first interceptor as the interceptor container i.e. ConsumerInterceptors/ProducerInterceptors is never created and therefore the first interceptor's and really any interceptor's close method are never called.  
> To help ensure the respective container interceptors are able to invoke their respective interceptor close methods for proper resource clean up, I propose defining a default open method with no implementation and check exception on the respective Consumer/Producer interceptor interfaces.  This open method will be responsible for creating threads and/or objects which utilizes threads, connections or other resource which requires clean up.  Additionally, the default open method enables implementation optionality as it's empty default behavior means it will do nothing when unimplemented.  
> Additionally, the Kafka Consumer/Producer Interceptor containers will implement a corresponding maybeOpen method which throws a checked exception.  In order to maintain backwards compatibility with earlier developed interceptors the maybeOpen will check whether the interceptor's interface contains the newer open method before calling it accordingly.   



--
This message was sent by Atlassian Jira
(v8.20.10#820010)