Hi TengYao,

Thanks for the KIP.

I want to ask Andrew's question in an inverted perspective: Which—if 
any—Producer APIs should users be allowed to invoke from within a Callback?

I agree about transactions being off limits. Just... no. But should users be 
able to call either send() variant from within a callback? That seems 
problematic. What about close()? I'm wondering if clientInstanceId() could be 
problematic since it potentially needs to call into the network thread to 
request the client ID from the cluster.

At first blush it appears that most of the APIs should be restricted.

I guess calling metrics() is OK :)

Thanks,
Kirk

On Tue, Dec 3, 2024, at 9:11 AM, Andrew Schofield wrote:
> Hi TengYao,
> Thanks for the KIP. From my point of view, calling Producer#flush in a 
> callback is a
> bad idea and it would be better to disallow it.
> 
> AS1: If we are tightening up the rules about which Producer methods can be 
> called
> in the callback, I wonder whether some other methods should be treated in the
> same way. It seems to me that it is unwise to change the transactional state 
> of the
> producer in a callback, so I would also prohibit Producer#initTransactions.
> 
> I wonder what others think about begin/commit/abortTransaction also.
> 
> Thanks,
> Andrew
> ________________________________________
> From: TengYao Chi <kiting...@gmail.com>
> Sent: 02 December 2024 02:51
> To: dev@kafka.apache.org <dev@kafka.apache.org>
> Subject: [DISCUSS] KIP-1118: Add Deadlock Protection on Producer Network 
> Thread
> 
> Hello everyone,
> 
> I would like to start a discussion thread on KIP-1118, which proposes
> adding deadlock protection on producer network thread.
> 
> Here is the KIP Link: KIP-1118
> <https://cwiki.apache.org/confluence/x/LorREw>
> Please take a look and let me know what you think, and I would appreciate
> any suggestions and feedback.
> 
> Best regards,
> TengYao
> 

Reply via email to