Filing Bugs Against the Core Libs

[David Holmes]

On 30/08/2016 1:25 PM, Russ Harmon wrote:
> On Mon, Aug 29, 2016 at 7:27 PM David Holmes <david.holmes at oracle.com
> <mailto: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.

Yes, but it would take a lot of reworking to allow the reason to bubble 
back up to the level where the decision to reject is made. Possible but 
probably detrimental to the common case of there being no rejection.

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

Yes that is true, if the bounded queue is the problem then rejection is 
a transient condition. Of course if you know that you haven't shutdown 
the executor then a (transiently) full queue must be the reason.

Cheers,
David

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