[
https://issues.apache.org/jira/browse/KAFKA-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13753311#comment-13753311
]
Sriram Subramanian commented on KAFKA-1008:
-------------------------------------------
Looks good.
1. OffsetIndex.scala
1.1 Why do you need to re-calculate this.maxEntries = this.mmap.limit / 8 after
remapping in resize instead of leaving it how it was previously (recalculated
during the method call of maxEntries)?
1.2 maybeLock should be something that exist outside OffsetIndex. Seems like OS
specific methods should reside together.
1.3 readLastOffset now locks. This is a behavior change on linux. This seems to
only do a read so does it need to be "maybeLock"?
2. Should we use the autolock for the cases below
TestUtils.scala
method - waitUntilLeaderIsElectedOrChanged
HighWaterCheckpoint.scala
method - write and read
3. Is autolock a better name than inlock?
> Unmap before resizing
> ---------------------
>
> Key: KAFKA-1008
> URL: https://issues.apache.org/jira/browse/KAFKA-1008
> Project: Kafka
> Issue Type: Bug
> Components: core, log
> Affects Versions: 0.8
> Environment: Windows, Linux, Mac OS
> Reporter: Elizabeth Wei
> Assignee: Jay Kreps
> Labels: patch
> Fix For: 0.8
>
> Attachments: KAFKA-0.8-1008-v7.patch, KAFKA-1008-v6.patch,
> KAFKA-trunk-1008-v7.patch, unmap-v5.patch
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> While I was studying how MappedByteBuffer works, I saw a sharing runtime
> exception on Windows. I applied what I learned to generate a patch which uses
> an internal open JDK API to solve this problem.
> Following Jay's advice, I made a helper method called tryUnmap().
--
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
