[
https://issues.apache.org/jira/browse/CONNECTORS-764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13739547#comment-13739547
]
Karl Wright commented on CONNECTORS-764:
----------------------------------------
r1513820 rolls back HOPCOUNTREMOVEDPURGATORY, since when a row becomes
HOPCOUNTREMOVED it is removed from the index as well. Also adds code to
properly remove prereqevents rows related to HOPCOUNTREMOVED records on
prepareFullScan().
> Hopcount logic fails to notice when the max number of hops is increased
> between crawls
> --------------------------------------------------------------------------------------
>
> Key: CONNECTORS-764
> URL: https://issues.apache.org/jira/browse/CONNECTORS-764
> Project: ManifoldCF
> Issue Type: Bug
> Components: Framework crawler agent
> Affects Versions: ManifoldCF 1.3
> Reporter: Karl Wright
> Assignee: Karl Wright
> Fix For: ManifoldCF 1.4
>
>
> When you do something like the following:
> (1) Set the max hops for a job relatively low
> (2) Crawl
> (3) Increase the max hops
> (4) Crawl again
> ... the documents that are labeled with the state "Hop count exceeded" at the
> end of the first crawl are never touched again. This is because there are no
> additional links added to the intrinsiclink table during the second crawl,
> and thus the method reactivateHopcountRemovedRecords() is never called,
> leaving the documents in an incorrect state.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
