[ 
https://issues.apache.org/jira/browse/TIKA-4813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tim Allison updated TIKA-4813:
------------------------------
    Description: 
Problem: Tika's timeout system was three incoherent knobs. A parser's own 
configured timeout got overwritten by an unrelated stall-detector setting. 
Timeouts couldn't compose across nesting (PDF → zip → OCR). A single timed-out 
subprocess could kill the whole worker JVM instead of just failing that one 
document.

Proposal: every external call gets min(what it asked for, time left on the 
task). ParseTimeout (new, in tika-core) holds that remaining-time clock per 
task, shared automatically across recursion. ProcessUtils/TikaHttpClient apply 
the rule internally and checkpoint the clock while waiting, so a legitimately 
slow call doesn't look like a hang. TikaTimeoutException is now catchable (was 
an uncaught  RuntimeException), so one slow embedded file gets recorded and 
skipped instead of aborting the whole document; running out of total time now 
truncates cleanly instead of ending the pipes process.

  was:
Problem: Tika's timeout system was three incoherent knobs. A parser's own 
configured timeout got overwritten by an unrelated stall-detector setting. 
Timeouts couldn't compose across nesting (PDF → zip → OCR). A single timed-out 
subprocess could kill the whole worker JVM instead of just failing that one 
document.

Proposal: every external call gets min(what it asked for, time left on the 
task). ParseTimeout (new, in tika-core) holds that remaining-time clock per 
task, shared automatically across
  recursion. ProcessUtils/TikaHttpClient apply the rule internally and 
checkpoint the clock while waiting, so a legitimately slow call doesn't look 
like a hang. TikaTimeoutException is now catchable (was an uncaught  
RuntimeException), so one slow embedded file gets recorded and skipped instead 
of aborting the whole document; running out of total time now truncates cleanly 
instead of crashing the JVM.


> Clean up timeout logic in 4.x
> -----------------------------
>
>                 Key: TIKA-4813
>                 URL: https://issues.apache.org/jira/browse/TIKA-4813
>             Project: Tika
>          Issue Type: Task
>            Reporter: Tim Allison
>            Priority: Minor
>
> Problem: Tika's timeout system was three incoherent knobs. A parser's own 
> configured timeout got overwritten by an unrelated stall-detector setting. 
> Timeouts couldn't compose across nesting (PDF → zip → OCR). A single 
> timed-out subprocess could kill the whole worker JVM instead of just failing 
> that one document.
> Proposal: every external call gets min(what it asked for, time left on the 
> task). ParseTimeout (new, in tika-core) holds that remaining-time clock per 
> task, shared automatically across recursion. ProcessUtils/TikaHttpClient 
> apply the rule internally and checkpoint the clock while waiting, so a 
> legitimately slow call doesn't look like a hang. TikaTimeoutException is now 
> catchable (was an uncaught  RuntimeException), so one slow embedded file gets 
> recorded and skipped instead of aborting the whole document; running out of 
> total time now truncates cleanly instead of ending the pipes process.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to