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@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@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev

James R. Perkins

JBoss by Red Hat