[
https://issues.apache.org/jira/browse/GIRAPH-274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13427119#comment-13427119
]
Jaeho Shin commented on GIRAPH-274:
-----------------------------------
Maybe I wasn't clear enough. My intention of creating a separate thread is to
rather make sure progress() gets called even in those periods the main thread
is busy in some long running external code or I/O calls than prettifying the
code. With the current approach of instrumenting progress() calls along the
path, even if we do call it next to every normal statement, it'll still get
killed whenever Giraph calls any other code that takes more than 600s to
return. It seems as we push Giraph to the limit, we are seeing some unexpected
parts become extremely slow. We're currently trying to understand its behavior
by profiling it. I'll post here if we find something interesting.
> 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.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
