[
https://issues.apache.org/jira/browse/GIRAPH-274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eli Reisman updated GIRAPH-274:
-------------------------------
Attachment: GIRAPH-274-alt-1.patch
Tried this several times today, works fine for long jobs again (60+ min data
load in etc.) not a pretty solution, but at least its an option until we have a
more elegant fix decided on as I need to be scaling out and was blocked up on
this issue for more than a week now.
I'm open to suggestions as to why this works, but it worked before and
apparently still does now. One suggestion is the PredicateLock fix involved
calling progress() from inside locked code while at various times in other
parts of Giraph process() is called outside of locked environment? but I'm not
going to hazard a guess as to whats really going on here. Both solutions are
basically the same. Ideas anyone? :)
> Jobs still failing due to tasks timeout during INPUT_SUPERSTEP
> --------------------------------------------------------------
>
> Key: GIRAPH-274
> URL: https://issues.apache.org/jira/browse/GIRAPH-274
> Project: Giraph
> Issue Type: Bug
> Affects Versions: 0.2.0
> Reporter: Jaeho Shin
> Assignee: Jaeho Shin
> Fix For: 0.2.0
>
> Attachments: GIRAPH-274-alt-1.patch, GIRAPH-274.patch
>
>
> Even after GIRAPH-267, jobs were failing during INPUT_SUPERSTEP when some
> workers don't get to reserve an input split, while others were loading
> vertices for a long time. (related to GIRAPH-246 and GIRAPH-267)
--
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
