Uploaded image for project: 'JBoss Enterprise Application Platform'
  1. JBoss Enterprise Application Platform
  2. JBEAP-6826

EJB's async methods' Future#get should treat zero timeout as "don't wait"

    XMLWordPrintable

Details

    • Bug
    • Resolution: Done
    • Major
    • 7.1.0.DR8
    • None
    • EJB
    • None

    Description

      Say there is an asynchronous EJB method:

      @Asynchronous
public Future<Boolean> method() {
   ...
}

      Calling Future#get with a zero timeout:

      if (bean.method().get(0, TimeUnit.MILLISECONDS))

      results in a block until the task is finished.
      Instead I expected zero waiting, because java.util.concurrent.Future.get(long, TimeUnit) doesn't specify any special treatment for a zero timeout value.

      Attachments

        Issue Links

          clones

          Bug - A problem that impairs or prevents the functions of the product. WFLY-6672 EJB's async methods' Future#get should treat zero timeout as "don't wait"

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Closed
          is cloned by

          Bug - A problem that impairs or prevents the functions of the product. JBEAP-6825 EJB's async methods' Future#get should treat zero timeout as "don't wait"

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Verified
          is incorporated by

          Component Upgrade - A task tracking an update to a bundled component or revision of component upstream of the project. JBEAP-6829 (7.1.0) Upgrade ejb-client from 2.1.6 to 2.1.7

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Closed

          Activity

            People

              istudens@redhat.com Ivo Studensky
              istudens@redhat.com Ivo Studensky
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: