Hey Jorge,
I looked into it, and can reproduce the second LISTEN port in a
vanilla Kafka Connect cluster without any connectors running.
Using jstack, I see that there are two threads that appear to be
waiting in the corresponding accept methods:
"RMI TCP Accept-0" #15 daemon prio=5 os_prio=31 c
Hi Luke,
This gets a +1 from my end. I believe non-binding because if I understand
it correctly, binding votes for releases are only issued by PMCs (
https://cwiki.apache.org/confluence/display/KAFKA/Release+Process#ReleaseProcess-Afterthevotepasses
).
I did the following validations:
- Verified s
Hi all,
I'm testing apache kafka connect for a project and I found that the main
process listens to two different ports, the one to provide REST api, 8083
by default, and a different unprivileged port that changes its number each
restart. For instance, this is fragment of the output from netstat c
Hi Hari,
You might want to ask in the client repo (kafkajs?)
They should be able to help you.
Thanks.
Luke
On Fri, May 19, 2023 at 3:00 PM HariBabu kuruva
wrote:
> Hi All,
>
> I am trying to implement kafka acl for one of the topics.
> it's a kafka cluster with 1 broker.
>
> Below are the ACL'
Hi All,
I am trying to implement kafka acl for one of the topics.
it's a kafka cluster with 1 broker.
Below are the ACL's applied on the topic
Current ACLs for resource `ResourcePattern(resourceType=TOPIC,
name=ibxkb.test.topic, patternType=LITERAL)`:
(principal=User:kafkauser, host=*, o
