[jira] [Commented] (GIRAPH-734) DiskBackedPartitionStore attempting to release a lock it doesn't own

["Claudio Martella (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/GIRAPH-734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13735971#comment-13735971 ] 

Claudio Martella commented on GIRAPH-734:
-----------------------------------------

nice catch. do you want to provide a patch?
                
> DiskBackedPartitionStore attempting to release a lock it doesn't own
> --------------------------------------------------------------------
>
>                 Key: GIRAPH-734
>                 URL: https://issues.apache.org/jira/browse/GIRAPH-734
>             Project: Giraph
>          Issue Type: Bug
>          Components: graph
>    Affects Versions: 1.0.0, 1.1.0
>            Reporter: Craig Muchinsky
>
> Within the DiskBackedPartitionStore.GetPartition and DiskBackedPartitionStore.AddPartition classes call() method there is a pattern whereby the write lock is temporarily released and re-acquired to allow some offload/load methods to be called without the lock. I ran into a situation where the offload method threw an exception which caused the outer finally which releases the write lock to fire, however it hadn't re-acquired the lock so IllegalMonitorStateException is thrown, masking the original exception.
> I believe this nested offload/load logic either needs to be in a try/finally of its own where it re-aquires the lock in the finally, or the outer finally's unlock needs to be guarded with lock.isWriteLockedByCurrentThread().
> To reproduce this issue, simply put an older version of guava (like 11) into the classpath before the version that giraph needs (12) and it will throw a runtime exception from within the offload logic.

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