felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Watson (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FELIX-4988) ResolverImpl uses an internal ExecutorService
Date Mon, 03 Aug 2015 21:46:06 GMT

    [ https://issues.apache.org/jira/browse/FELIX-4988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14652598#comment-14652598

Thomas Watson commented on FELIX-4988:

Sorry, attached the patch to the wrong issue.

> ResolverImpl uses an internal ExecutorService
> ---------------------------------------------
>                 Key: FELIX-4988
>                 URL: https://issues.apache.org/jira/browse/FELIX-4988
>             Project: Felix
>          Issue Type: Bug
>          Components: Resolver
>         Environment: All
>            Reporter: Thomas Watson
> Latest code in trunk for org.apache.felix.resolver.ResolverImpl.ResolverImpl constructor
will create an internal ExecutorService based on the results of Runtime.getRuntime().availableProcessors().
> I would much rather be able to pass in my own ExecutorService so I can control the behavior
and lifecycle of the executor myself.  The current implementation will create a new ExecutorService
using java.util.concurrent.Executors.newFixedThreadPool(int) and shuts it down each resolve()
operation.  It would be much better to be able to control the ExecutorService from outside
of the ResolveImpl.
> The code in its current form will force me to use org.apache.felix.resolver.ResolverImpl.ResolverImpl(Logger,
int) and passing in 1 for parallelism to prevent extraneous thread creation for each framework
resolve operation. 

This message was sent by Atlassian JIRA

View raw message