[
https://issues.apache.org/jira/browse/CHUKWA-743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Yang updated CHUKWA-743:
-----------------------------
Attachment: CHUKWA-743.patch
Removed the pid file locking java file, and use standard hadoop style shell
script for pid file locking. Shell script style file locking is far from
perfect, but it is more elegant than the misleading PidFile class.
I also thought about modifying PidFile class to bind to a port but that
strategy would yield similar result as shell script pid file test. Hence, I
decided to go with the simple approach to avoid complexity.
> race condition in PidFile
> -------------------------
>
> Key: CHUKWA-743
> URL: https://issues.apache.org/jira/browse/CHUKWA-743
> Project: Chukwa
> Issue Type: Bug
> Reporter: Alan Snyder
> Attachments: CHUKWA-743.patch
>
>
> I believe there is a race condition in org.apache.hadoop.chukwa.util.PidFile.
> The problem is that the creation and deletion of the file is not protected by
> any lock. Client A can delete the file just before Client B tries to acquire
> a lock. If at that moment Client C tries to create the file, it will succeed.
> Client B and Client C will both succeed in acquiring a lock because there are
> two different files (one is hidden because it was deleted after being
> opened). I have tested similar code on OS X and this is what happened.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
