giraph-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hudson (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (GIRAPH-734) DiskBackedPartitionStore attempting to release a lock it doesn't own
Date Thu, 15 Aug 2013 15:27:48 GMT

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

Hudson commented on GIRAPH-734:
-------------------------------

FAILURE: Integrated in Giraph-trunk-Commit #1249 (See [https://builds.apache.org/job/Giraph-trunk-Commit/1249/])
GIRAPH-734 (claudio: http://git-wip-us.apache.org/repos/asf?p=giraph.git&a=commit&h=8af453cdab42b5276cec2e89d83ce5c87d70a137)
* CHANGELOG
* giraph-core/src/main/java/org/apache/giraph/partition/DiskBackedPartitionStore.java

                
> 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
>             Fix For: 1.1.0
>
>         Attachments: GIRAPH-734.patch
>
>
> 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

Mime
View raw message