[
https://issues.apache.org/jira/browse/KAFKA-49?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13155311#comment-13155311
]
Taylor Gautier commented on KAFKA-49:
-------------------------------------
Generally I think it's a good idea to have a version embedded into the
protocol. This allows for backwards and forwards compatibility. In a sense,
the request id works as such, so in some sense it's a matter of semantics, but
the only way to identify that there are multiple versions of the same request
is to have some kind of external mapping that says id 2 and id 8 are really the
same request, just different versions.
OTOH, if you use a version, you can then have:
id 2 version 1
id 2 veriosn 2
etc. and this is imho easier to manage.
Usually, the version should in fact be the first value in the protocol, so that
you never have formatting issues that lie outside the realm of the versioned
data.
Currently, all requests are preceded by a header, which contains the length of
the data. This is where I would start, we should either strive for:
version: 2 bytes
length: 4 bytes
or
length: 4 bytes
version: 2 bytes
Note that the message request already has a way to represent versions, using
the magic field, but honestly I find it a little bit non explicit for my taste.
I would also include a 64-bit "flags" area that will allow for future flags to
be set to indicate various things.
So, if I were to suggest a standard header for requests and responses it would
look like:
length: 2 bytes
version: 2 bytes
reuest id: 2 bytes
flags: 4 bytes
payload: n bytes
> Add acknowledgement to the produce request.
> -------------------------------------------
>
> Key: KAFKA-49
> URL: https://issues.apache.org/jira/browse/KAFKA-49
> Project: Kafka
> Issue Type: Bug
> Reporter: Jun Rao
>
> Currently, the produce request doesn't get acknowledged. We need to have a
> broker send a response to the producer and have the producer wait for the
> response before sending the next request.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
