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. >> >> > >
