[
https://issues.apache.org/jira/browse/GIRAPH-291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13430916#comment-13430916
]
Eli Reisman commented on GIRAPH-291:
------------------------------------
I realize we are grasping at straws here, but this approach is starting to look
just like the 267 one and that one does not work. One thing I am toying with in
the 246-9 version is including another call to progress in waitMsecs before the
lock is locked. This was its called in the barrier waits even when they are not
waitForever, at least once. It does not seem likely to make a difference, but
again none of this makes sense to me as all of these solutions are very
similar. I will believe and cherish any and all that will complete a long
cluster job at this point.
I will attempt to run jobs (tomorrow AM probably at this point, the heavy cron
job loads have begun :( for the night) and if I get any definitive answers, I
will post them immediately.
Thank you for being so proactive about this everyone, it was a frustrating step
backward to have to tangle with this problem again. I'm sure with you guys on
the case a great solution is around the corner.
> PredicateLock should have a constructor to take in a custom waiting time and
> additional testing
> -----------------------------------------------------------------------------------------------
>
> Key: GIRAPH-291
> URL: https://issues.apache.org/jira/browse/GIRAPH-291
> Project: Giraph
> Issue Type: Improvement
> Reporter: Avery Ching
> Assignee: Avery Ching
> Attachments: GIRAPH-291.patch
>
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
