This discussion is archived
6 Replies Latest reply: Jul 29, 2012 3:09 PM by 798831 RSS

ThreadPoolExecutor.getCompletedTaskCount changed behaviour in Java 7

950535 Newbie
Currently Being Moderated
The behaviour of ThreadPoolExecutor has changed in Java 7. In Java 6, getCompletedTaskCount did not include tasks which terminated by throwing a RuntimeException, but in Java 7 it does.

This might be considered to be a bug. The javadoc for getCompletedTaskCount is vague about whether failed tasks are included in the count, although it is true that failed tasks did complete in some sense:
     * Returns the approximate total number of tasks that have
     * completed execution. ...
At the very least, the javadoc should be clarified. However, treating failed tasks as completed can lead to problems, such as storm drains where workload is diverted to where it is apparently being processed most quickly (but only apparently, the result is that most of the workload then fails).

Even if this is not deemed to be a bug, I think it would be helpful to note the change of behaviour in the Java 7 compatibility notes (http://www.oracle.com/technetwork/java/javase/compatibility-417013.html).

See https://bugs.eclipse.org/bugs/show_bug.cgi?id=382688 for background.
  • 1. Re: ThreadPoolExecutor.getCompletedTaskCount changed behaviour in Java 7
    jtahlborn Expert
    Currently Being Moderated
    just fyi, these forums are not bug reporting locations. that's what the java bug database is for.
  • 2. Re: ThreadPoolExecutor.getCompletedTaskCount changed behaviour in Java 7
    jtahlborn Expert
    Currently Being Moderated
    as a side note, if you are looking for feedback, while i agree that this is definitely a change in behavior (taking your word for it, never used that method call myself), i would argue that the old behavior is the buggy behavior. from the Executor's standpoint, i would consider any tasks which are not currently running to be considered "complete", regardless of whether they ended in an Exception or not. whether or not a task is successfully complete is up to your code. if you want to track what you consider to be successful completions versus total completions then you should be handling that separately.
  • 3. Re: ThreadPoolExecutor.getCompletedTaskCount changed behaviour in Java 7
    950535 Newbie
    Currently Being Moderated
    I understand that these forums are not for reporting bugs, but it seemed rash to raise a bug without first discussing whether or not others considered the behaviour to be a bug. I work on an open source project and it's certainly good form there to discuss issues on the forum before raising a bug as in many cases there isn't a bug at all.

    Anyway, you may be right that this is a bug in Java 6. I think it's unlikely to be fixed if I raise it, so I'd like to get the change of behaviour documented in the Java 7 compatibility notes (linked to above). How do I do that? Should I raise a bug or is there another route? Thanks.
  • 4. Re: ThreadPoolExecutor.getCompletedTaskCount changed behaviour in Java 7
    gimbal2 Guru
    Currently Being Moderated
    947532 wrote:
    so I'd like to get the change of behaviour documented in the Java 7 compatibility notes (linked to above). How do I do that?
    That is a VERY good question. I know of no official way of reporting problems with documentation. However I have two suggestions.

    - there is the 'documentation' forum: Documentation
    - there are the OpenJDK mailing lists


    EDIT: reading through the documentation forum, that seems to be a very effective way to get documentation mistakes fixed.
  • 6. Re: ThreadPoolExecutor.getCompletedTaskCount changed behaviour in Java 7
    798831 Newbie
    Currently Being Moderated
    To get something changed in documentation just file a bug against the documentation, just as you would the code. You can file it against the code to which the change relates.

    This was a functional bug in 6 - 6450207. The notion of Task completion matches the semantics of Futures where completion is indicated by isDone() and signifies normal completion, exceptional completion or cancellation. This is also indicated elsewhere in the TPE docs eg see afterExecute.

    http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/ThreadPoolExecutor.html#afterExecute(java.lang.Runnable,%20java.lang.Throwable)

    The question of whether this fix then warrants an entry in the compatibility notes is a tricky one. Naturally if this bug has surprised you, you see the change as an incompatibility and would like to see it documented. For others this is just a bug like a dozen others and they don't all need to be documented. I'm in the latter camp but sympathetic to the former. :) I will see how painful it is to make such changes.

    David Holmes

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points