[
https://issues.apache.org/jira/browse/KAFKA-463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Swapnil Ghike updated KAFKA-463:
--------------------------------
Attachment: kafka-463-v2.patch
1. Made the changes 1.1, 1.3, 1.5, 2 as recommended.
2. Made an appropriate change for 1.2. If all segments are deleted then
truncate entire segments.view and roll a new segment from that targetOffset,
otherwise check for appropriate segment to truncate and change the last segment
of segments.view or throw error if targetOffset is out of range.
3. A unit test that exercises all cases for truncateTo.
Perhaps not super-crucial, but here it goes anyways:
i. Added a check for contents.get().size > 0 in while loop in trunc and
truncLast, otherwise it can throw illegalArgumentException in Array.copy for
certain cases even when the passed argument is ok. Eg in trunc when newStart ==
0 and curr.length == 0. There is most probably no danger of changing the value
of contents between the while condition check and curr = contents.get(),
because any calls to trunc and truncLast are synchronized with the same lock,
thus there should be no other thread executing between while() and curr =
contents.get().
ii. truncLast does not throw exception for argument==-1, but throws exception
for anything less. Probably it should behave uniformly for all negative
integers. Made a change so that truncLast(-ve no) will wipe out the entire
segments.view. This is also similar to what trunc does when the argument is
greater than (segments.view.length-1).
iii. Changed the condition for throwing exception in truncLast to > because an
index which is equal to (segments.view.length-1) should not throw exception.
iv. Added max/min condition to avoid IllegalArgumentException in truncLast.
v. The unit test for truncLast did not check for all cases properly, fixed it.
vi. Combined the two different test cases for trunc by imitating the structure
of unit test for truncLast.
A question:
Since all calls to SegmentList.trunc, truncLast and append (which are the only
ways to modify contents) seem to be locked, so only one thread will be able to
modify SegmentList.contents at any time. Do we really need a
while(compareAndSet) for contents? I could be wrong, pls correct me whenever
you have free time.
> log.truncateTo needs to handle targetOffset smaller than the lowest offset in
> the log
> -------------------------------------------------------------------------------------
>
> Key: KAFKA-463
> URL: https://issues.apache.org/jira/browse/KAFKA-463
> Project: Kafka
> Issue Type: Bug
> Components: core
> Reporter: Jun Rao
> Assignee: Swapnil Ghike
> Priority: Blocker
> Labels: bugs
> Fix For: 0.8
>
> Attachments: kafka-463-v1.patch, kafka-463-v2.patch
>
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> When this happens, we should truncate all existing log segments.
--
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
