-
Notifications
You must be signed in to change notification settings - Fork 172
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Kafka Connect | Inconsistent behaviour with REST API in Distributed Mode #50
Comments
Hi: we have a similar issue : Most of it has been temporarily solved by downloading the replicas of the Kafka cluster (Kafka Connect pods) from 3 to 1 - so this seems like a problem with balancing - however this is not ok for Prod environment and we are still searching for the root cause. Our architecture needs a Kafka connector that provisions a topic when there are changes in Cloudant, we had also to (in real time) create a connector when the user logs in for the first time. We have been able to create the Kafka Connectors via the Kafka Connect REST API (https://docs.confluent.io/platform/current/connect/references/restapi.html), Even worst, after the first fail it behaves badly providing the SocketTimeoutException to subsequent POST creation requests, We have been googling this issue ("SocketTimeoutException kafka connect api") and a few people got it but a clear solution is not available beyond obvious ones like changing timeouts. The POST request to the Kafka Connect API: Our code is just creating the previous request: URL apiUrl = new URL(kafkaConnectApiUrl.get()); String data = "{\n "name": "" + dbName + """ |
Hi @moisescastellano we have the same issue with Connect Timeout. Have you figured out a solution for this? |
When running the following request against the kafka connect cluster in distributed mode (2 worker pods) in k8s, the following can be observed:
Where the connector called
test
does not exist.The requests are running in quick succession. As you can see, occasionally the server responds with a 500 and other times, a 404. The working theory is that occasionally, the follower worker gets the request, forwards the request to the leader, receives a 404 back and then returns a 500. Is this desired behaviour, or should the follower simply be echoing the leader's response back? I would expect to see a 404 in all cases.
I am not sure if this is related, but the behaviour was first noticed after upgrading to cp-kafka-connect 7.2.1
The text was updated successfully, but these errors were encountered: