Hi Maxence,

Pausing and restarting a job causes all of its documents to have their
docpriority field be recalculated.  It should not be necessary to do this
in order to have job complete, though.

All documents that are queued have their docpriority set at the time they
are added to the queue, but the docpriority they are given depends on how
many documents in the same document bin that have already been given
docpriority values.  This is done to make sure documents from all bins are
given an equal chance of being crawled.  But since documents are given a
docpriority when queued, there may well have been plenty of other documents
"in front" of them that are already queued and must be processed before
there's any chance of getting crawled.  So it is possible that documents
from one job may appear to block documents from another -- but this will
eventually correct itself and those documents will be crawled.

If you see *no* activity at all, however, then I wonder if somehow
documents have been queued with a null docpriority.  You can test this by
looking at the Document Status report and verifying that there is no reason
the documents should not be crawlable, and then looking in the database to
see what they have for their docpriority field.  Please let me know what
you find.

Thanks,
Karl
On Mon, Jun 4, 2018 at 4:20 AM msaunier <[EMAIL PROTECTED]> wrote:
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB