[
https://issues.apache.org/jira/browse/STANBOL-217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13068166#comment-13068166
]
Bertrand Delacretaz edited comment on STANBOL-217 at 7/20/11 6:18 AM:
----------------------------------------------------------------------
Instead of configuring timeouts, could the engines make sure something's
written to the response at regular intervals, to avoid timing out?
[1] says " if a single byte is read or written, then the timeout (if
implemented by jetty) is reset" so maybe just writing one space character to
the output every 50 seconds or so would do. I haven't tried it, and buffers
might get in the way, and that would add extra spaces to the output, so just a
suggestion for now.
[1]
http://jetty.codehaus.org/jetty/jetty-6/apidocs/org/mortbay/jetty/nio/SelectChannelConnector.html#setMaxIdleTime(int)
was (Author: bdelacretaz):
Instead of configuring timeouts, could the engines make sure something's
written to the response at regular intervals, to avoid timing out?
[1] says " if a single byte is read or written, then the timeout (if
implemented by jetty) is reset" so maybe just writing one space character to
the output would do. I haven't tried it, and buffers might get in the way, and
that would add extra spaces to the output, so just a suggestion for now.
[1]
http://jetty.codehaus.org/jetty/jetty-6/apidocs/org/mortbay/jetty/nio/SelectChannelConnector.html#setMaxIdleTime(int)
> Plateform timeout when engine process more than 1 minute
> --------------------------------------------------------
>
> Key: STANBOL-217
> URL: https://issues.apache.org/jira/browse/STANBOL-217
> Project: Stanbol
> Issue Type: Bug
> Components: Enhancer
> Reporter: Florent ANDRE
> Attachments: global-timeout.patch
>
>
> After a first mail [1], I do some clean and investigations, and it seems that
> a kind of timeout occur somewhere in the platform when engine processing take
> more than 1 minute.
> This seems not related to an uncaught Throwable or OutOfMemoryError, or at
> least nothing appear in the logs or console.
> This is just on the browser side that the timeout occur, the engine continue
> to process.
> With the use of this curl call :
> time curl -m 600 -X POST -H "Accept: text/turtle" -H "Content-type:
> text/plain" -F "data=@document-important" http://localhost:8080/engines
> Browser timeout can be an eliminate usual suspect as -m means :
> -m/--max-time <seconds>
> Maximum time in seconds that you allow the whole operation to
> take. This is useful for preventing your batch jobs from hanging for hours
> due to slow
> networks or links going down. See also the --connect-timeout
> option.
> In order to test this well, I create an engine that do nothing more than
> wait. This engine is really simple, have just one parameter that allow to fix
> the wait period in ms. By default it's set to 1 minute (60000) that cause the
> bug. If you set this wait time lower (57000 for example), this work.
> 1 minute processing is important, but not huge if we consider big text files
> and a complete enhancement chain.
> [1]
> http://mail-archives.apache.org/mod_mbox/incubator-stanbol-dev/201105.mbox/%[email protected]%3E
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
