[
https://issues.apache.org/jira/browse/TIKA-1762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14987315#comment-14987315
]
Bob Paulin commented on TIKA-1762:
----------------------------------
So I did some more testing with different ExecutorService implementations and
the good news is it appears they do not start creating threads until tasks are
submitted to them. So instantiating a pool default in the default constructor
of a parser should be no worse than what we're currently doing as long as we
have a reasonable thread keep alive time to wind down unused threads. So I'm
thinking of modifying the default thread pool to include a keep alive and
create it within the constructor of a parser through the static
TikaConfig.getDefaultConfig(). SO:
{code}
public NetworkParser(URI uri, Set<MediaType> supportedTypes) {
this(uri, supportedTypes,
TikaConfig.getDefaultConfig().getDefaultExecutorService());
}
public NetworkParser(URI uri, Set<MediaType> supportedTypes,
ExecutorService executorService)
{
this.uri = uri;
this.supportedTypes = supportedTypes;
this.executorService = executorService;
}
{code}
> Create Executor Service from TikaConfig
> ---------------------------------------
>
> Key: TIKA-1762
> URL: https://issues.apache.org/jira/browse/TIKA-1762
> Project: Tika
> Issue Type: Improvement
> Reporter: Bob Paulin
> Fix For: 1.11
>
>
> Create a configurable executor service that is configurable from the
> TikaConfig.
> Konstantin Gribov added a comment - 23/Sep/15 09:55
> Bob Paulin, I have two ideas on the issue:
> by default use common thread pool, configured via and contained in
> TikaConfig as Tyler Palsulich suggested,
> you can pass thread pool for parser invocation via ParserContext with
> fallback to default if now thread pool/executor service in context.
> Also o.a.tika.Tika#parse(InputStream, Metadate) produces
> o.a.tika.parser.ParsingReader and anonymous Executor with unbounded daemon
> thread creation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
