You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Guillaume Nodet (JIRA)" <ji...@apache.org> on 2015/08/19 09:54:46 UTC

[jira] [Resolved] (FELIX-4988) ResolverImpl uses an internal ExecutorService

     [ https://issues.apache.org/jira/browse/FELIX-4988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Guillaume Nodet resolved FELIX-4988.
------------------------------------
       Resolution: Fixed
         Assignee: Guillaume Nodet
    Fix Version/s: resolver-1.6.0

Committing to https://svn.apache.org/repos/asf/felix/trunk ...
	M	resolver/src/main/java/org/apache/felix/resolver/ResolverImpl.java
Committed r1696530


> 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
>            Assignee: Guillaume Nodet
>             Fix For: resolver-1.6.0
>
>
> 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
(v6.3.4#6332)