Hi Guillaume,
i just updated the jira with 10 screenshots showing the threads and stack
traces of them. Unfortunately with pooled threads there is no easy way to
capture where they were triggered, but you can see that they all execute
stacks like this:
Thread "pool-17-thread-5":
at
org.apache.felix.resolver.ResolverImpl.mergeUses(org.apache.felix.resolver.ResolverImpl$ResolveSession,
org.osgi.resource.Resource,
org.apache.felix.resolver.ResolverImpl$Packages,
org.osgi.resource.Capability, java.util.List, org.osgi.resource.Capability,
java.util.Map, java.util.Set) (line: 1033)
at
org.apache.felix.resolver.ResolverImpl.computeUses(org.apache.felix.resolver.ResolverImpl$ResolveSession,
java.util.Map, java.util.Map, org.osgi.resource.Resource) (line: 853)
at
org.apache.felix.resolver.ResolverImpl.access$500(org.apache.felix.resolver.ResolverImpl$ResolveSession,
java.util.Map, java.util.Map, org.osgi.resource.Resource)
at org.apache.felix.resolver.ResolverImpl$6.run() (line: 1231)
at org.apache.felix.resolver.ResolverImpl$EnhancedExecutor$1.run()
(line: 2442)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(java.util.concurrent.ThreadPoolExecutor$Worker)
(line: 1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run() (line: 617)
at java.lang.Thread.run() (line: 745)
with newCachedThreadPool() we would not end up with 8 Threads doing
nothing. That would happen with a newFixedThreadPool().
a cached one would grow on demand and shrink back to 0 (like you suggested)
The question for me is if this is important to configure or if this
improvement would make the need for configuration go away
Fabian
On Tue, Oct 4, 2016 at 8:51 AM, Guillaume Nodet <gno...@apache.org> wrote:
> It seems to me that running the features service is not something which is
> done very frequently, at least in a production system, so I would rather
> use a thread pool which has 0 core threads, so that we don't end up with 8
> threads doing nothing at all as with an Executors.newCachedThreadPool().
>
> Are you sure the number of threads you saw are actually created by the
> resolver used by the FeaturesService ?
>
> 2016-10-04 8:06 GMT+02:00 Fabian Lange <fabian.la...@codecentric.de>:
>
> > 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 <
> fabian.la...@codecentric.de>
> > 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
> > >
> >
>
>
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Red Hat, Open Source Integration
>
> Email: gno...@redhat.com
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
>
