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

Dmitri Pavlov commented on KAFKA-17704:
---------------------------------------

I've attached a docker lab that is possible to run to try to reproduce the 
issue. There is a README file with commands to run.

> possible race condition in TTL credentials when connectors recycled on single 
> node instance
> -------------------------------------------------------------------------------------------
>
>                 Key: KAFKA-17704
>                 URL: https://issues.apache.org/jira/browse/KAFKA-17704
>             Project: Kafka
>          Issue Type: Bug
>    Affects Versions: 3.7.1
>            Reporter: Doug Whitfield
>            Priority: Minor
>         Attachments: For_community.zip.001, For_community.zip.002, 
> For_community.zip.003, For_community.zip.004, For_community.zip.005, 
> For_community.zip.006, For_community.zip.007, 
> image-2024-10-07-11-17-41-951.png, logstoupload.log
>
>
> This is related to https://issues.apache.org/jira/browse/KAFKA-9228 and 
> https://issues.apache.org/jira/browse/KAFKA-17627 but in single node instance 
> and only related to credentials (as far as we know currently), so maybe 
> something else is in play?
> In some cases, when TTL is used with a single node, passwords are not passed 
> properly.
> In the "logstoupload.log" file you can see that at 09:14 the password does 
> not get change, but at 09:24 it does get changed.
> We are able to "reliably" reproduce this in prod-like environment where this 
> log comes from in Kubernetes, but we have only captured this "race condition" 
> in test rarely where we are not using Kubernetes. We have seen it without 
> Kubernetes though.
> We hope to provide something more reproducible next week, but perhaps 
> uploading this "full" log will allow you to guide us so we can make this more 
> reproducible.



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

Reply via email to