[
https://issues.apache.org/jira/browse/CONNECTORS-880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13897725#comment-13897725
]
Karl Wright commented on CONNECTORS-880:
----------------------------------------
Hi Florian,
In order to make progress here, we need to get in synch. First, if it is
possible for you to use trunk, that would help enormously; that is where this
weekend's work was committed. If you are, please check out and build:
svn co https://svn.apache.org/repos/asf/manifoldcf/trunk
cd trunk
ant make-core-deps make-deps
ant build
If you already are using trunk, please synch up, because you are out of synch:
cd trunk
svn update
ant build
Second, the "unexpected value" errors make no sense to me at all for the
moment. The only thing I can think of is that perhaps you have more than one
agents process running, and this case has somehow not been handled properly in
that context. Can you confirm this? If that's not what you think you are
doing, can you confirm that multiple running MCF instances are not
inadvertantly pointing to the same database instance?
Finally, the Solr connection refusals represent HTTP socket connections that
fail. That argues that your Solr connection parameters are wrong. When you
view the connection in the UI, what do you see?
> Under the right conditions, job aborts do not update "last checked" time
> ------------------------------------------------------------------------
>
> Key: CONNECTORS-880
> URL: https://issues.apache.org/jira/browse/CONNECTORS-880
> Project: ManifoldCF
> Issue Type: Bug
> Components: Framework crawler agent
> Affects Versions: ManifoldCF 1.4.1
> Reporter: Karl Wright
> Assignee: Karl Wright
> Fix For: ManifoldCF 1.6
>
>
> When a scheduled job is being considered to be started, MCF updates the
> last-check field ONLY if the job didn't start. It relies on the job's
> completion to set the last-check field in the case where the job does start.
> But if the job aborts, in at least one case the last-check field is NOT
> updated. This leads to the job being run over and over again within the
> schedule window.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
