[
https://issues.apache.org/jira/browse/TIKA-1762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14958183#comment-14958183
]
Bob Paulin commented on TIKA-1762:
----------------------------------
So I have create the code to perform the configuration and some utility classes
to work with the ParseContext. I like the idea of passing the Thread Pool
around via the ParseContext. I'm not so sure on the defaulting. I've
considered a few options but I'm not sure I like any of them:
a) Initialize default Executor in Parser Constructor.
This could create too many thread pools. Defeats the purpose of thread pools
if they are not shared by parsers.
b) Create a singleton threadpool
This removes the possibility of having too many pools but multiple instances of
TikaConfig will change the configuration
c) Provide a utillity class to use threads as a default but the ParseContext
ExecutorService if set.
Configuration remains independent within TikaConfig Instances. Requires least
amount of change in parsers. Unbounded thread issue remains.
I went with option c since it's the least impactful but I'd be interested in
thoughts on other implementations.
revision 1708723
> 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)
