Hey, One additional option would be to make it not configurable at all and just use a java.util.concurrent.Executors.newCachedThreadPool()
This would exhibit very similar properties to the current behaviour but avoid creating the hundreds to thousand threads we observe. Probably nobody really want the current behaviour, but it usually is so quick that nobody cares. Fabian On Tue, Oct 4, 2016 at 7:53 AM, Fabian Lange <[email protected]> wrote: > Hi, > what do you guys think about: > https://github.com/apache/karaf/pull/246 > > As noticed by me, and already reported here: https://issues.apache.or > g/jira/browse/FELIX-5247 > > The current default behaviour is that every "resolve()" call will create a > new Executor Pool with number of CPU Cores as size. This is not very > efficient. > In my opinion this is unexpected behaviour by Felix, but fortunately we > can use other constructors. > > I left in my PR the default behaviour, but added a new one, which can > re-use a bounded or unbounded ThreadPoolExecutor. I did not use a > FixedThreadPool because i wanted to mimic the current behaviour, which is: > After the resolve call, these Threads are gone again. > > What do you guys think? Should we change the current "implicit default" to > re-use a Thread Pool? > Is a ThreadPoolExecutor with timeout fine to mimic the current behaviour, > or would we want to change this, lets say to have a dedicated thread pool > always available for Felix Resolve calls? (This would then be like > Executors.newFixedThreadPool()) > > I am trying to get this change into karaf 4.0.8. > > Fabian > > > -- > Fabian Lange | Performance Expert > mobil: +49 (0) 160.3673393 > > codecentric AG | Merscheider Straße 1 | 42699 Solingen | Deutschland > > Sitz der Gesellschaft: Solingen | HRB 25917| Amtsgericht Wuppertal > Vorstand: Michael Hochgürtel . Mirko Novakovic . Rainer Vehns > Aufsichtsrat: Patric Fedlmeier (Vorsitzender) . Klaus Jäger . Jürgen Schütz >
