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