[
https://issues.apache.org/jira/browse/KAFKA-557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13473790#comment-13473790
]
Jay Kreps commented on KAFKA-557:
---------------------------------
1.1 Fixed
1.2 The long lines are due to use of String.format() which requires a single
string to format. Breaking the lines is going to be uglier as they need to move
to +.
1.3 The intention is to move the flush out of the synchronized block. I don't
know who put that in there, but that is not good, since that is likely the
slowest thing we are doing and has no need for synchronization. You raise a
good point which is that the flush might throw an IOException, so it should be
in the try catch. I reversed the order of the try/catch to fix this issue. With
respect to using match instead of if/else, I disagree with that. if/else reads
as english. I see us using match statements for simple if/else switches on
boolean variables and I think it is pretty nasty.
2.1 I don't have IDEA so I can't do that.
2.2 No, how I have it is right. I am asserting that the logEndOffset is
properly updated. I will add a test description to make that more clear.
2.3 Basically I am checking that we read something. Cleaned this up to make it
more readable.
2.4 Unfortunately there isn't a simple test that is easy to implement. One
unfortunate thing is that we implemented the shallow/deep iterator logic in
ByteBufferMessageSet not in MessageSet so at this layer I ONLY have access to
the wrapper message in the compressed case. There isn't a very meaning thing to
say about the offset as a result. Instead the test I am doing is just that I
can read something at offset 5 (which would not be true if the offsets had been
reassigned by the log).
> Replica fetch thread doesn't need to recompute message id
> ---------------------------------------------------------
>
> Key: KAFKA-557
> URL: https://issues.apache.org/jira/browse/KAFKA-557
> Project: Kafka
> Issue Type: Bug
> Components: core
> Affects Versions: 0.8
> Reporter: Jun Rao
> Priority: Blocker
> Labels: bugs
> Attachments: KAFKA-557.patch
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> With kafka-506, the leader broker computes the logical id for each message
> produced. This could involve decompressing and recompressing messages, which
> are expensive. When data is replicated from the leader to the follower, we
> could avoid recomputing the logical message id since it's the same.
--
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
