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

Tom Bentley commented on KAFKA-12286:
-------------------------------------

{quote}we will have options to deal with it if it does.{quote}

Just to note that one path to doing that is to decouple the serialized type 
from the Java type in a versioned way. Concretely 
[KIP-625|https://cwiki.apache.org/confluence/display/KAFKA/KIP-625%3A+Richer+encodings+for+integral-typed+protocol+fields#KIP625:Richerencodingsforintegraltypedprotocolfields-PublicInterfaces]
 describes migrating fields from 32 to 64 bits, for example.

> Consider storage/cpu tradeoff in metadata record framing schema
> ---------------------------------------------------------------
>
>                 Key: KAFKA-12286
>                 URL: https://issues.apache.org/jira/browse/KAFKA-12286
>             Project: Kafka
>          Issue Type: Improvement
>            Reporter: Jason Gustafson
>            Priority: Major
>
> KIP-631 calls for unsigned varints in order to represent the api key and 
> version. We are also adding a frame version, which will be unsigned varint. 
> The use of the varint means we can save a byte from each of these fields 
> compared to an int16. The downside is that it is that the serialization is a 
> little more expensive. For varints, we typically require one call to compute 
> the size of the field and a separate call to actually write it. If this 
> becomes an issue, there are a couple options:
> 1. We can use the int16 and pay the extra 3 bytes.
> 2. We can let the generated classes compute the encoded api key and version 
> as a byte and fail if we ever exceed the range of varint that can fit in a 
> single byte. This would let us replace `writeUnsignedVarint` with `writeByte`.
> The second option seems reasonable to me. I think it's extremely unlikely 
> we'll ever need more than a byte for either the api key or the version. At 
> least it should be years before that happens and we will have options to deal 
> with it if it does.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to