[
https://issues.apache.org/jira/browse/KAFKA-5997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ronald van de Kuil resolved KAFKA-5997.
---
Resolution: Not A Bug
> acks=all does not seem to be honoured
>
Yogesh BG created KAFKA-5998:
Summary: /.checkpoint.tmp Not found exception
Key: KAFKA-5998
URL: https://issues.apache.org/jira/browse/KAFKA-5998
Project: Kafka
Issue Type: Bug
GitHub user yew1eb opened a pull request:
https://github.com/apache/kafka/pull/3998
Fix array index out of bounds
This array access might be out of bounds, as the index might be equal to
the array length.
You can merge this pull request into a Git repository by running:
$ git
Ronald van de Kuil created KAFKA-5997:
-
Summary: acks=all does not seem to be honoured
Key: KAFKA-5997
URL: https://issues.apache.org/jira/browse/KAFKA-5997
Project: Kafka
Issue Type:
Github user asfgit closed the pull request at:
https://github.com/apache/kafka/pull/3996
---
Thanks all for reaching out.
Ted - I am looking at the 0.11.0 release. Particularly here
https://github.com/apache/kafka/blob/0.11.0/clients/src/main/java/org/apache/kafka/common/requests/AbstractResponse.java
In this release, the Server uses the following method in almost all cases
Hi Haseeb,
That is the point, the server should always send a response with the same
correlation id as the request it has received. If there's a bug in the
networking layer where a response is never sent back or there is reordering
somewhere in the stack, then this will be identified by the
Yes the idea of the correlation id is to make it easier for the client to
match a particular response to the request it answers. Kafka’s protocol
allows sending multiple requests without waiting for the response. In
theory you can just rely on ordering, but that can be a bit fragile if the
client
