You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@spark.apache.org by "Cody Koeninger (JIRA)" <ji...@apache.org> on 2018/04/25 14:25:00 UTC

[jira] [Commented] (SPARK-24067) Backport SPARK-17147 to 2.3 (Spark Streaming Kafka 0.10 Consumer Can't Handle Non-consecutive Offsets (i.e. Log Compaction))

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

Cody Koeninger commented on SPARK-24067:
----------------------------------------

Given the response on the dev list about criteria for backporting, I think this is in a grey area.

In one sense, it's a new option.  But there have been reports of non-consecutive offsets even in normal non-compacted topics, which totally break jobs, so this could be seen as a critical bug.

I'd lean towards merging it to the 2.3 branch, but because I'm the one who wrote the code, I'm not comfortable making that call on my own. 

[~srowen] you merged the original PR, do you want to weigh in?

> Backport SPARK-17147 to 2.3 (Spark Streaming Kafka 0.10 Consumer Can't Handle Non-consecutive Offsets (i.e. Log Compaction))
> ----------------------------------------------------------------------------------------------------------------------------
>
>                 Key: SPARK-24067
>                 URL: https://issues.apache.org/jira/browse/SPARK-24067
>             Project: Spark
>          Issue Type: Bug
>          Components: DStreams
>    Affects Versions: 2.3.0
>            Reporter: Joachim Hereth
>            Assignee: Cody Koeninger
>            Priority: Major
>
> SPARK-17147 fixes a problem with non-consecutive Kafka Offsets. The  [PR w|https://github.com/apache/spark/pull/20572]as merged to {{master}}. This should be backported to 2.3.
>  
> Original Description from SPARK-17147 :
>  
> When Kafka does log compaction offsets often end up with gaps, meaning the next requested offset will be frequently not be offset+1. The logic in KafkaRDD & CachedKafkaConsumer has a baked in assumption that the next offset will always be just an increment of 1 above the previous offset.
> I have worked around this problem by changing CachedKafkaConsumer to use the returned record's offset, from:
>  {{nextOffset = offset + 1}}
>  to:
>  {{nextOffset = record.offset + 1}}
> and changed KafkaRDD from:
>  {{requestOffset += 1}}
>  to:
>  {{requestOffset = r.offset() + 1}}
> (I also had to change some assert logic in CachedKafkaConsumer).
> There's a strong possibility that I have misconstrued how to use the streaming kafka consumer, and I'm happy to close this out if that's the case. If, however, it is supposed to support non-consecutive offsets (e.g. due to log compaction) I am also happy to contribute a PR.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@spark.apache.org
For additional commands, e-mail: issues-help@spark.apache.org