Filing Bugs Against the Core Libs

[Martin Buchholz]

On Mon, Aug 29, 2016 at 8:25 PM, Russ Harmon <eatnumber1 at google.com> wrote:

>
> > The actual code that throws it doesn't know the exact reason.
>
>
> To my understanding though, the reason is not outside of the purview of the
> JDK (aka, the rejection is not decided upon by outside code), and therefore
> some refactoring of the existing code could make it known.
>
>
Like David, I have a hard time seeing how to make this clearly better.  The
only interface to the RejectedExecutionHandler is the rejectedExecution
method, and that does not allow for any way to pass a reason.


>
> > But you
> > seem to be running a custom RejectedExeceptionHandler so it should be
> > able to determine whether the executor is shutdown, or if using a
> > bounded queue which may have become full.
> >
>
> There's a race condition if I do that.


It's true we have a "reason reporting race" then.
ThreadPoolExecutor code is doing something like

if (isShutdown()) handler.rejectedExecution(command, this)

but how to pass the reason to the handler?

In practice, rechecking the shutdown status in the handler is good enough
for most monitoring purposes.  If the pool turns out to be shutdown, but
the shutdown happened in a race, does it matter to the caller?  Retry will
be futile in such a case anyway.


> If the executor has not been
> shutdown, and the executor has reached capacity, the
> RejectedExceptionHandler will be called. I can then check the queue size in
> the RejectedExceptionHandler, but it's possible that tasks completed before
> I'm able to check the size, so the queue won't appear full.
>
> I think that this is actually what has occurred in my case. The stack trace
> I linked earlier shows a non-full queue, but I know that the executor was
> not shutting down. Therefore, it must have been caused by the queue filling
> up, then depleting before the size was read for generation of the error
> message.
>
>