Okay, I pushed a commit to just drop TreeCache's use of CloseableExecutorService entirely. I am hoping clients don't really need this... I can't imagine what you'd use it for.
On Thu, Jul 21, 2016 at 5:39 PM, Jordan Zimmerman < [email protected]> wrote: > OK with me. Just make sure that setExecutor(ExecutorService > executorService) works correctly. But, I’m concerned there’s a bug > in CloseableExecutorService. I’d like to see it fixed if there is one. > > -Jordan > > On Jul 21, 2016, at 4:38 PM, Scott Blum <[email protected]> wrote: > > In that case, I have no idea why TreeCache would use > CloseableExecutorService at all, it's a pointless (and in fact, > destructive) wrapper at this point. How about I just eliminate it? > > On Thu, Jul 21, 2016 at 5:31 PM, Jordan Zimmerman < > [email protected]> wrote: > >> I forget now who wrote CloseableExecutorService. As I recall, the desire >> was to be able to have an object that looks like an ExecutorService but >> could handle an externally managed ExecutorService or an internally managed >> one. This way, the code could always treat it as internally managed - being >> able to call shutdownNow, etc. - but if it was provided by a client it >> would only close threads actually used by the instnace. >> >> -Jordan >> >> >> On Jul 21, 2016, at 4:28 PM, Scott Blum <[email protected]> wrote: >> >> Looks like a real bug... for some reason, the single-arg constructor >> for CloseableExecutorService defaults to NOT actually shutting down the >> underlying executor. This makes absolutely no sense to me, but it's the >> source of the bug... most of the code paths to construct a TreeCache use >> the 1-arg constructor. Only one of them uses the 2-arg constructor with >> the right setting. >> >> I have to admit, the design of CloseableExecutorService is kind of >> WTF-inducing for me... >> >> On Thu, Jul 21, 2016 at 5:18 PM, Jordan Zimmerman < >> [email protected]> wrote: >> >>> Please open an issue in Jira if this is a real bug. >>> >>> > On Jul 21, 2016, at 4:16 PM, Scott Blum <[email protected]> wrote: >>> > >>> > Okay, now I can repro it; the difference was you adding the loop to >>> wait for the thread to start up. >>> >>> >> >> > >
