[
https://issues.apache.org/jira/browse/NUTCH-3162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18065155#comment-18065155
]
ASF GitHub Bot commented on NUTCH-3162:
---------------------------------------
lewismc commented on code in PR #906:
URL: https://github.com/apache/nutch/pull/906#discussion_r2920120575
##########
src/java/org/apache/nutch/indexer/IndexingJob.java:
##########
@@ -143,6 +145,8 @@ public void index(Path crawlDb, Path linkDb, List<Path>
segments,
+ RANDOM.nextInt());
FileOutputFormat.setOutputPath(job, tmp);
+ // Driver-level error tracking: categorization + LOG.error only (no job
counters; see ErrorTracker Javadoc).
Review Comment:
I've put this comment in here for the time being. Ultimately I think it is
fine to track driver-level errors in memory (via errorTracker) even though they
are not written to the MapReduce counter(s). I've documented this behavior in
ErrorTracker.java.
> Latency metrics to properly merge data from all threads and tasks
> -----------------------------------------------------------------
>
> Key: NUTCH-3162
> URL: https://issues.apache.org/jira/browse/NUTCH-3162
> Project: Nutch
> Issue Type: Bug
> Components: fetcher, indexer, parser
> Affects Versions: 1.22
> Reporter: Sebastian Nagel
> Assignee: Lewis John McGibbney
> Priority: Major
> Fix For: 1.23
>
>
> The latency metrics (NUTCH-3134) have to issues:
> 1. Only the data from one thread is used, in case, a tool is multi-threaded.
> That's definitely the case for Fetcher. The "emitCounters" methods needs to
> increment the counter values, instead of calling "setValue". However, this is
> not the correct approach for the percentiles, see also next point.
> 2. If running full cluster mode with multiple parallel tasks, the task
> counters are summed up to the job counter value. However, the values of the
> latency percentiles then turn out to be too high.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
