[
https://issues.apache.org/jira/browse/GIRAPH-100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13161264#comment-13161264
]
Jakob Homan commented on GIRAPH-100:
------------------------------------
bq. In the future, I'll file separate issues for formatting cleanup.
Great. This also gives us a steady supply of newbie JIRAs, since the latest
batch is almost used up.
bq.We should file another JIRA to create a GiraphException and the various
types I suppose. Or do you want me to do it in this JIRA?
Either in this JIRA, or put the current ones in with FIXME/TODO annotations so
we can back and fix them easily, and then immediately open a new JIRA.
bq. but not sure how mocking can verify the behavior in this case.
It may end up being a challenge, but it's a strong guard against building up a
huge number of integration tests, calling them unit tests and then having tests
that run for four, six or nine hours (see: every other Hadoop ecosystem
project). Being able to swap out the backing dependency from a mock to a real
Hadoop cluster is a great way to test quickly (ie, often) as well as test
reality (ie, against a real cluster). I'll take a look at making sure we have
infrastructure that is amenable to this.
bq. we should file a separate JIRA for separating the tests into unittests
(mocking, individual class tests) and integration tests, but integration tests
can still be run locally and/or remote.
Can we go ahead and create test/integration as part of this JIRA and put
SuperstepHashPartitionerFactory there? That way it doesn't go into the
inappropriate examples directory but can still be bundled as part of the jar.
The remaining partitioning can probably be done as part of GIRAPH-22.
> Data input sampling and testing improvements
> --------------------------------------------
>
> Key: GIRAPH-100
> URL: https://issues.apache.org/jira/browse/GIRAPH-100
> Project: Giraph
> Issue Type: New Feature
> Components: graph
> Reporter: Avery Ching
> Assignee: Avery Ching
> Attachments: GIRAPH-100.patch
>
>
> It would be really nice to help debug an application by limiting the input
> data (% of input splits, max vertices per input split). Also, it would be
> nice for the workers to provide a little more debugging info on how far along
> they are with processing the input data.
--
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
