[
https://issues.apache.org/jira/browse/NUTCH-1196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13151828#comment-13151828
]
Hudson commented on NUTCH-1196:
-------------------------------
Integrated in Nutch-nutchgora #70 (See
[https://builds.apache.org/job/Nutch-nutchgora/70/])
NUTCH-1196 Update job should impose an upper limit on the number of inlinks
(nutchgora) - forget to add to CHANGES.txt
NUTCH-1196 Update job should impose an upper limit on the number of inlinks
(nutchgora)
ferdy :
http://svn.apache.org/viewvc/nutch/branches/nutchgora/viewvc/?view=rev&root=&revision=1202739
Files :
* /nutch/branches/nutchgora/CHANGES.txt
ferdy :
http://svn.apache.org/viewvc/nutch/branches/nutchgora/viewvc/?view=rev&root=&revision=1202736
Files :
* /nutch/branches/nutchgora/src/java/org/apache/nutch/crawl/DbUpdateMapper.java
* /nutch/branches/nutchgora/src/java/org/apache/nutch/crawl/DbUpdateReducer.java
* /nutch/branches/nutchgora/src/java/org/apache/nutch/crawl/DbUpdaterJob.java
* /nutch/branches/nutchgora/src/java/org/apache/nutch/crawl/UrlWithScore.java
* /nutch/branches/nutchgora/src/java/org/apache/nutch/util/WebPageWritable.java
*
/nutch/branches/nutchgora/src/test/org/apache/nutch/crawl/TestUrlWithScore.java
> Update job should impose an upper limit on the number of inlinks (nutchgora)
> ----------------------------------------------------------------------------
>
> Key: NUTCH-1196
> URL: https://issues.apache.org/jira/browse/NUTCH-1196
> Project: Nutch
> Issue Type: Bug
> Reporter: Ferdy Galema
> Fix For: nutchgora
>
> Attachments: NUTCH-1196-v2.patch, NUTCH-1196.patch
>
>
> Currently the nutchgora branch does not limit the number of inlinks in the
> update job. This will result in some nasty out-of-memory exceptions and
> timeouts when the crawl is getting big. Nutch trunk already has a default
> limit of 10,000 inlinks. I will implement this in nutchgora too. Nutch trunk
> uses a sorting mechanism in the reducer itself, but I will implement it using
> standard Hadoop components instead (should be a bit faster). This means:
> The keys of the reducer will be a {url,score} tuple.
> *Partitioning* will be done by {url}.
> *Sorting* will be done by {url,score}.
> Finally *grouping* will be done by {url} again.
> This ensures all indentical urls will be put in the same reducer, but in
> order of scoring.
> Patch should be ready by tomorrow. Please let me know when you have any
> comments or suggestions.
--
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
