Specifically, the stuffer thread is responsible for finding documents to
process and getting them to the worker threads via the internal queue that
the worker threads wait on.  The stuffer thread uses a query to do this.
Either the query is not finding any documents, or the stuffer thread is
down.  Probably it is the former, and the reason it is not finding any
documents is because the job is in the wrong state due to that runtime
exception.

Can you describe what code is throwing that runtime exception?  It would be
very helpful if you could provide a stack trace for it from the log.

Karl


On Wed, Mar 23, 2022 at 11:27 AM Karl Wright <daddy...@gmail.com> wrote:

> ' 1/ On the first and only one document of the seeding phase encountered,
> a runtime exception is triggered'
>
> The worker threads do not handle seeding.  If a runtime exception takes
> place during seeding, no documents will be queued, and that is the
> problem.  The state of the job must be incorrectly updated even though the
> seeding failed.  OR the job's state is properly updated but the
> corresponding thread that is supposed to know when the job is completed (by
> looking at the job queue) doesn't properly trigger.
>
> The architecture of ManifoldCF has many threads that are individually
> responsible for transitioning the job state based on the jobqueue.  If
> somehow the jobstate winds up not in the right state then those threads
> will not do the right thing.
>
> Karl
>
>
> On Wed, Mar 23, 2022 at 11:08 AM Julien Massiera <
> julien.massi...@francelabs.com> wrote:
>
>> Hi Karl,
>>
>> I had some time to investigate the problem I exposed in my first mail,
>> and here is the behavior I observed:
>>
>> 1/ On the first and only one document of the seeding phase encountered, a
>> runtime exception is triggered
>> 2/ The runtime exception is catched by the WorkerThread, logged, and the
>> WorkerThread stays alive (line 856 of the WorkerThread class)
>> 3/ The WorkerThread calls the getDocument method of its documentQueue
>> (line 121 of the WorkerThread class)
>> 4/ The documentQueue ends in an infinite 'wait' state because the queue
>> size is 0 and the resetFlag is false (lines 109 and 110 of the
>> DocumentQueue class)
>> 5/ Because of the infinite 'wait' state of the documentQueue, the job
>> stays freezed on the 'running' state and it is impossible to stop it until
>> the Agent is restarted
>>
>> I don't know much about the WorkerThread and the DocumentQueue logic, so
>> from there, I really need your help to understand this behavior and to
>> figure out what can be done to prevent the job from hanging in that case,
>> which, I assume, can happen in other circumstances with other repository
>> connectors
>>
>> Regards,
>> Julien
>>
>> -----Message d'origine-----
>> De : Julien Massiera <julien.massi...@francelabs.com>
>> Envoyé : jeudi 24 février 2022 15:08
>> À : dev@manifoldcf.apache.org
>> Objet : RE: WorkerThread runtime exceptions
>>
>> Yes I understand
>>
>> -----Message d'origine-----
>> De : Karl Wright <daddy...@gmail.com>
>> Envoyé : jeudi 24 février 2022 14:59
>> À : dev <dev@manifoldcf.apache.org>
>> Objet : Re: WorkerThread runtime exceptions
>>
>> I'm currently completely consumed with upgrading dependencies for Tika
>> and CXF.  This is a massive job and won't be done for probably another week
>> or two.  Once that is done I can try to look into your concern.
>>
>> Karl
>>
>>
>> On Thu, Feb 24, 2022 at 8:47 AM Julien Massiera <
>> julien.massi...@francelabs.com> wrote:
>>
>> > Hi,
>> >
>> >
>> >
>> > I have faced a situation where the MCF agent was still up but was not
>> > doing anything after a runtime exception.
>> >
>> >
>> >
>> > My use case was the following :
>> > I have updated the libs used by a repository connector but forgot one.
>> > During doc processing, a runtime exception <
>> > java.lang.NoSuchMethodError > has been throwed because the sub
>> > dependency lib was not up to date and thus the method called was
>> > missing. The exception was catched by the WorkerThread and displayed <
>> > Error tossed: .. > but then nothing and the job stayed in running
>> > status and I was not able to abort it until I killed and I restarted
>> > the agent.
>> >
>> >
>> >
>> > The catching clause is located in the WorkerThread class at lines
>> 853-857.
>> > I
>> > know this is a particular case but I am not sure that the fact the
>> > agent hangs after this exception is a normal behavior and furthermore
>> > I can imagine that it can happen with other unkown runtime exceptions.
>> > Is there something we can do to avoid the agent to be hanging in those
>> cases ?
>> >
>> >
>> >
>> > Regards,
>> >
>> > Julien
>> >
>> >
>> >
>> >
>>
>>
>>

Reply via email to