[
https://issues.apache.org/jira/browse/KAFKA-802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13601393#comment-13601393
]
Jun Rao edited comment on KAFKA-802 at 3/13/13 5:28 PM:
--------------------------------------------------------
Sriram, agreed that it's better if the meaning for flush interval is consistent
btw the leader and the follower. After thinking a bit more, I think this is
doable. Basically, during shallow iteration, the offset returned for the
compressed message is the offset of the last uncompressed message in it. So,
the last offset is actually correct even if messages are compressed. The
problem is with the first offset. I think we can set first offset to nextOffset
at the beginning of append(). This way, whether we need to assign offsets or
not, we can alway obtain the right first offset. We can then use different
between last and first offset to drive log flush.
was (Author: junrao):
Sriram, agreed that it's better if the meaning for flush interval is
consistent btw the leader and the follower. After thinking a bit more, I think
this is doable. Basically, during shallow iteration, the offset returned for
the compressed message is the offset of the last uncompressed message in it.
So, the last offset is actually correct even if messages are compressed. The
problem is with the first offset. I think we can set first offset to nextOffset
at the beginning of append(). This way, whether we need to assign offsets or
not, we can alway obtain the right first offset. We can then use different
between last and first offet to drive log flush.
> Flush message interval is based on compressed message count
> -----------------------------------------------------------
>
> Key: KAFKA-802
> URL: https://issues.apache.org/jira/browse/KAFKA-802
> Project: Kafka
> Issue Type: Bug
> Components: core
> Affects Versions: 0.8
> Reporter: Jun Rao
> Assignee: Neha Narkhede
> Priority: Blocker
> Attachments: kafka-802.patch
>
>
> In Log.append(), we use compressed message count to determine whether to
> flush the log or not. We should use uncompressed message count instead.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
