kafka-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gwen Shapira (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (KAFKA-3563) Maintain MessageAndMetadata constructor compatibility
Date Fri, 29 Apr 2016 22:48:14 GMT

     [ https://issues.apache.org/jira/browse/KAFKA-3563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Gwen Shapira updated KAFKA-3563:
--------------------------------
    Fix Version/s: 0.10.0.0

> Maintain MessageAndMetadata constructor compatibility 
> ------------------------------------------------------
>
>                 Key: KAFKA-3563
>                 URL: https://issues.apache.org/jira/browse/KAFKA-3563
>             Project: Kafka
>          Issue Type: Improvement
>    Affects Versions: 0.10.0.0
>            Reporter: Grant Henke
>            Assignee: Grant Henke
>             Fix For: 0.10.1.0, 0.10.0.0
>
>
> The MessageAndMetadata constructor was changed to include timestamp information as a
part of KIP-32. Though the constructor may not be used in general client usage, it may be
used in unit tests or some advanced usage. We should maintain compatibility if possible. 
> One example where the constructor is used is Apache Spark: https://github.com/apache/spark/blob/master/external/kafka/src/main/scala/org/apache/spark/streaming/kafka/KafkaRDD.scala#L223-L225
> The old constructor was:
> {code}
> MessageAndMetadata[K, V](topic: String,
>    partition: Int,
>    private val rawMessage: Message,
>    offset: Long,
>    keyDecoder: Decoder[K], valueDecoder: Decoder[V])
> {code}
> And after KIP-32 it is now:
> {code}
> MessageAndMetadata[K, V](topic: String,
>    partition: Int,
>    private val rawMessage: Message,
>    offset: Long,
>    timestamp: Long = Message.NoTimestamp,
>    timestampType: TimestampType = TimestampType.CREATE_TIME,
>    keyDecoder: Decoder[K], valueDecoder: Decoder[V])
> {code}
> Even though _timestamp_ and _timestampType_ have defaults, if _keyDecoder_ and _valueDecoder_
were not accessed by name, then the new constructor is not backwards compatible. 
> We can fix compatibility by moving the _timestamp_ and _timestampType_ parameters to
the end of the constructor, or by providing a new constructor without _timestamp_ and _timestampType_
that matches the old constructor. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message