[wildfly-dev] Thread Pool Utilities

[James Perkins]

I made the assumption that they were no-op because they were likely shared
thread-pools where as using it like an API each extension that uses it has
it's own thread-pool.

A stop would work for the shutdown, but you'd really need to use the
shutdownNow() if the timeout has been reached. A ThreadPoolExecutor by
default won't interrupt running threads during a shutdown. Though it does
make sense that the service should be the one that handles it. Maybe each
stop() should do something like;

shutdown();
awaitTermination();
shutdownNow();

I do think them being services makes sense. For example in batch-jberet a
thread-pool is exposed as a capability. That's another thing on my todo
list for thread-pools, but out of scope of this :)

On Tue, Dec 15, 2015 at 11:10 AM, Brian Stansberry <
brian.stansberry at redhat.com> wrote:

> I haven't really thought about this and it's quite possible changing
> this stuff is the right thing to do. So just take the following as being
> about clarification and not opposition:
>
> I don't understand the significance of having the thread subsystem or not.
>
> IIRC these services don't expose those methods because the Service
> stop() method is meant to control the pool lifecycle. So if these are
> still MSC services, that reasoning still applies. (Note: it may have
> been bad reasoning.)
>
> Also, these are still used in much the same fashion as they were before
> when we used the threads subsystem. The use has just been inlined into
> other subsystems.
>
> On 12/15/15 12:13 PM, James Perkins wrote:
> > Hello All,
> > The thread-pool utilities don't currently allow the shutdown() or
> > shutdownNow() [1] to be executed on the delegate executor. This made
> > sense when we had a thread subsystem, but now that we don't it makes
> > these executors hard to use for things like graceful shutdown. For
> > example if a graceful shutdown limit has been reached threads submitted
> > from these thread-pools continue running as there's no way to shut them
> > down and kill running threads.
> >
> > I'd propose that since these are utilities now that these methods be
> > exposed for usage [2]. Does anyone see an issue with that? Or have
> > alternative ides?
> >
> >
> > [1]
> > :
> https://github.com/wildfly/wildfly-core/blob/69fed63548cbebed86e31ba376f0f7f147fe04a2/threads/src/main/java/org/jboss/as/threads/ManagedExecutorService.java#L71-L84
> > [2]:
> >
> https://github.com/wildfly/wildfly-core/compare/master...jamezp:thread-pool-shutdown
> >
> > --
> > James R. Perkins
> > JBoss by Red Hat
> >
> >
> > _______________________________________________
> > wildfly-dev mailing list
> > wildfly-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >
>
>
> --
> Brian Stansberry
> Senior Principal Software Engineer
> JBoss by Red Hat
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>



-- 
James R. Perkins
JBoss by Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20151215/2812f303/attachment.html