- if the reference is being filtered, it would be filtered from everywhere, and the document should thus get removed from the queue at the end of the job, because it is unreachable.- the referencing document definitely has a parseable reference to the document in question, and in any case having it be a "seed" should make the hopcount be zero;Hmm. This is not at all what I would have expected.If "skueskill" is directly referenced by a seed document, or (worse) is in the seed list, I cannot see *how* the document can possibly have this state.
- even if the hopcount tables have gotten corrupted, the fact that the document is a first-level reference or a seed should overwrite the record for that document.So I am at a complete loss to explain this behavior.
Let me look through the code and see if I can find any code path that could lead to this behavior.
KarlOn Tue, Aug 13, 2013 at 9:01 AM, Erlend Garåsen <email@example.com> wrote:
On 8/13/13 2:47 PM, Karl Wright wrote:Unfortunately, yes. A bording task which must be done.
Looks like you need to re-enable connector debugging before we can see
I added 60 mins as a time offset value, but I'm not 100% sure whether the given result from Document status was created by this job run or is an old entry in the database:
Also, does the missing document (skuespill) appear in the Document
Status report after the crawl? Can you include that here if it does?
(I am betting it does not...)
Idenfifier: http://www.ibsen.uio.no/skuespill.xhtmlStatu: Hopcount exceeded
State: Out of scopeRetry count / limit: N/A
Scheduled: 01-01-1970 01:00:00.000
Scheduled action: Process