[ 
https://issues.apache.org/jira/browse/NUTCH-1842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16649315#comment-16649315
 ] 

Yossi Tamari edited comment on NUTCH-1842 at 10/14/18 9:42 AM:
---------------------------------------------------------------

While I agree it is a minor issue for 2.X, I think it's a major one for 1.X: if 
a segment fails, the pages that where in it will never be fetched (unless the 
default value is changed, but most users are not aware that they need to do 
this).


was (Author: yossi):
While I agree it is a minor issue for 2.X, I think it's a major one for 1.X: if 
a segment fails, the pages that where in it will never be fetched.

> crawl.gen.delay has a wrong default value in nutch-default.xml or is being 
> parsed incorrectly 
> ----------------------------------------------------------------------------------------------
>
>                 Key: NUTCH-1842
>                 URL: https://issues.apache.org/jira/browse/NUTCH-1842
>             Project: Nutch
>          Issue Type: Bug
>          Components: generator
>    Affects Versions: 1.9
>            Reporter: kaveh minooie
>            Priority: Minor
>
> this is from nutch-default.xml:
> <property>
>   <name>crawl.gen.delay</name>
>   <value>604800000</value>
>   <description>
>    This value, expressed in milliseconds, defines how long we should keep the 
> lock on records 
>    in CrawlDb that were just selected for fetching. If these records are not 
> updated 
>    in the meantime, the lock is canceled, i.e. they become eligible for 
> selecting. 
>    Default value of this is 7 days (604800000 ms).
>   </description>
> </property>
> this is the from o.a.n.crawl.Generator.configure(JobConf job)
> genDelay = job.getLong(GENERATOR_DELAY, 7L) * 3600L * 24L * 1000L;
> the value in config file is in milliseconds but the code expect it to be in 
> days. I reported this couple of years ago on the mailing list as well. I 
> didn't post a patch becaue I am not sure which one needs to be fixed. 
> considering all the other values in config file are in milliseconds it can be 
> argued to that consistency matters, but 'day' is a much more reasonable unit 
> for this property.
> Also this value is not being used in 2.x ?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to