You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@chukwa.apache.org by "Eric Yang (JIRA)" <ji...@apache.org> on 2015/04/13 01:20:13 UTC

[jira] [Updated] (CHUKWA-743) race condition in PidFile

     [ 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)