You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@giraph.apache.org by "Craig Muchinsky (JIRA)" <ji...@apache.org> on 2013/08/09 14:28:48 UTC

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

Craig Muchinsky created GIRAPH-734:
--------------------------------------

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