[
https://issues.apache.org/jira/browse/FELIX-4987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14707184#comment-14707184
]
Thomas Watson commented on FELIX-4987:
--------------------------------------
I'm going to try something like the following so that the pool of threads
quickly can go to zero threads when idle which is shortly after startup.
new ThreadPoolExecutor(
// Always want to go to zero threads when idle
0,
// use the number of processors - 1 because we use the current thread
when rejected
Math.max(Runtime.getRuntime().availableProcessors() - 1, 1),
// idle timeout; make it short to get rid of threads quickly after
resolve
5,
// unit for timeout
TimeUnit.SECONDS,
// use sync queue to force thread creation
new SynchronousQueue<Runnable>(),
// try to name the threads with useful name
new ThreadFactory() {
@Override
public Thread newThread(Runnable r) {
return new Thread(r, "Resolver thread - " +
adaptor.toString()); //$NON-NLS-1$
}
},
// use a rejection policy that simply runs the task in the current
thread once the max threads is reached
new RejectedExecutionHandler() {
@Override
public void rejectedExecution(Runnable r, ThreadPoolExecutor
exe) {
r.run();
}
});
I register a different instance of the resolver as a service, for that I will
likely use the default behavior which will create/shutdown the internal
executor. If that proves to be an issue then I may register it using a
PrototypeSeviceFactory such that the executor is created/shutdown when the new
service object is created/destroyed.
> Dynamic package resolution with unresolvable or fragment package exports can
> lead to invalid wirings
> ----------------------------------------------------------------------------------------------------
>
> Key: FELIX-4987
> URL: https://issues.apache.org/jira/browse/FELIX-4987
> Project: Felix
> Issue Type: Bug
> Components: Resolver
> Environment: All
> Reporter: Thomas Watson
> Assignee: Guillaume Nodet
> Fix For: resolver-1.6.0
>
>
> With the latest code in trunk calling
> org.apache.felix.resolver.ResolverImpl.resolve(ResolveContext, Resource,
> Requirement, List<Capability>) with a List<Capability> containing a
> Capability from a fragment will lead to an invalid Wire.
> This looks similar to FELIX-4897 and appears to be a regression.
> There are two types of failures.
> 1) Where the fragment has a valid host to resolve against. In this case I
> would expect the Wire.getProvider() to be the host revision for the fragment,
> but the current code returns the fragment revision
> 2) Where the fragment has no valid host available. In this case I would
> expect no Wire to be returned in the result from the ResolverImpl.resolve
> call.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
