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

Swapnil Ghike updated KAFKA-546:
--------------------------------

    Attachment: kafka-546-v3.patch

Thanks for the comments. The fixes are as follows:

20. Changed ConsumerIterator to iterator until it reaches or passes 
ctiConsumerOffset.

21. Reverted this change because as discussed: 
i. On commit of a part of a compressed message, the fetchOffset that will be 
checkpointed will be the actual fetchOffset, and not the offset of the last 
message in the compressed message set.
ii. We need to keep fetchOffset to make sure that ShallowIterator works fine 
under normal conditions.

22.1 Remove zkConsumerConnector.
22.2 The comments in the test case should be helpful in this regard.
22.3 Changed the test to use deep iterator over compressed message set.

Other random changes:
1. Imports optimized over changes that were pulled in via rebase.
2. I had missed removing the calls to toInt() at a couple places in KAFKA-556 
for FileMessageSet.sizeInBytes(). Fixing this.
                
> Fix commit() in zk consumer for compressed messages
> ---------------------------------------------------
>
>                 Key: KAFKA-546
>                 URL: https://issues.apache.org/jira/browse/KAFKA-546
>             Project: Kafka
>          Issue Type: New Feature
>    Affects Versions: 0.8
>            Reporter: Jay Kreps
>            Assignee: Swapnil Ghike
>         Attachments: kafka-546-v1.patch, kafka-546-v2.patch, 
> kafka-546-v3.patch
>
>
> In 0.7.x and earlier versions offsets were assigned by the byte location in 
> the file. Because it wasn't possible to directly decompress from the middle 
> of a compressed block, messages inside a compressed message set effectively 
> had no offset. As a result the offset given to the consumer was always the 
> offset of the wrapper message set.
> In 0.8 after the logical offsets patch messages in a compressed set do have 
> offsets. However the server still needs to fetch from the beginning of the 
> compressed messageset (otherwise it can't be decompressed). As a result a 
> commit() which occurs in the middle of a message set will still result in 
> some duplicates.
> This can be fixed in the ConsumerIterator by discarding messages smaller than 
> the fetch offset rather than giving them to the consumer. This will make 
> commit work correctly in the presence of compressed messages (finally).

--
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

Reply via email to