[
https://issues.apache.org/jira/browse/STANBOL-217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13043386#comment-13043386
]
Olivier Grisel edited comment on STANBOL-217 at 6/3/11 3:15 PM:
----------------------------------------------------------------
Stanbol itself does not implement any kind of timeout logic. The behavior you
observe might come from the HTTPService implementation provided by Felix:
https://svn.apache.org/repos/asf/felix/trunk/http.jetty/src/main/java/org/apache/felix/http/jetty/Activator.java
look for the line: connector.setMaxIdleTime( 60000 );
AFAIK there is know way to override this behavior using the public OSGi
HTTPService configuration or API.
The solution is either use faster engines and restrict to engines that do not
do synchronous lookup to remote network resources (e.g. prefil the EntiyHub
with a precomputed SolrYard index of your knowledge base and use in offline
mode) or do a POST request to the ContentHub API and do polling to fetch the
results later. As noted earlier the current ContentHub implementation is a hack
because of the use of the InMemoryStore for the content item streams.
was (Author: ogrisel):
Stanbol itself does not implement any kind of timeout logic. The behavior
you observer might come from the HTTPService implementation provided by Felix:
https://svn.apache.org/repos/asf/felix/trunk/http.jetty/src/main/java/org/apache/felix/http/jetty/Activator.java
look for the line: connector.setMaxIdleTime( 60000 );
AFAIK there is know way to override this behavior using the public OSGi
HTTPService configuration or API.
The solution is either use faster engines and restrict to engines that do not
do synchronous lookup to remote network resources (e.g. prefil the EntiyHub
with a precomputed SolrYard index of your knowledge base and use in offline
mode) or do a POST request to the ContentHub API and do polling to fetch the
results later. As noted earlier the current ContentHub implementation is a hack
because of the use of the InMemoryStore for the content item streams.
> 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
