Filing Bugs Against the Core Libs

[Russ Harmon]

On Mon, Aug 29, 2016 at 7:27 PM David Holmes <david.holmes at oracle.com>
wrote:

> Hi Russ,
>
> On 26/08/2016 5:39 AM, Russ Harmon wrote:
> > Hello,
> >
> > I'd like to report a (minor) feature request / bug in the core libs.
> What's
> > the best way for me to do that?
>
> Brian already gave you the general answer, but in this case one of your
> colleagues at Google, Martin Buccholz, is one of the primary maintainers
> of the java.util.concurrent code.
>

Thanks for the pointer. I'll reach out to Martin.


> > I recently ran into this stack trace
> > <https://gist.github.com/eatnumber1/10190a7cbe152ffe65135e1aa2678299>.
> It's
> > not very useful to me, since I can't determine from either the message or
> > the stack trace why the task was rejected. It would be much more helpful
> if
> > either a) the message stated the reason, or b) the stack trace pointed
> at a
> > line of code which unambiguously indicated a reason (e.x. a list of "if"
> > statements which throw this exception, so I can look at the condition to
> > see why the task was rejected)
>
> It is documented to be thrown:
>
>     * If the task cannot be submitted for execution, either because this
>     * executor has been shutdown or because its capacity has been reached,
>     * the task is handled by the current {@code RejectedExecutionHandler}.
>
> 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.


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


> Cheers,
> David
>
> > Thanks,
> > Russ Harmon
> > Google Site Reliability Engineer
> >
>