[
https://issues.apache.org/jira/browse/KAFKA-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jay Kreps updated KAFKA-1008:
-----------------------------
Attachment: KAFKA-1008-v6.patch
Hey Elizabeth, this basically looks good. A couple of minor things.
One is I'm not sure we are covering everything that needs to be locked. The
next is that we are using synchronized with the lock instance which doesn't
actually call lock (as in java that just acquires the monitor associated with
the lock argument--sucky right?).
I took a stab at reworking it. To make things not get too crazy I added a
helper method inLock which makes the try/finally locking pattern a little more
readable (hopefully).
Would you be willing to take a detailed look at this and let me know if you
think this works.
The next thing we need to do is actually get this tested on Windows. I'm not
sure if there is anyone who has access to a Windows machine and could reproduce
the old problem who could verify that this patch fixes it?
> 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-1008-v6.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
