Uploaded image for project: 'JGroups'
  1. JGroups
  2. JGRP-1877

System.nanoTime() can be negative

    XMLWordPrintable

Details

    • Bug
    • Resolution: Done
    • Major
    • 3.6
    • None
    • None

    Description

      According to the javadoc, System.nanoTime() should only be used to measure elapsed time, but not compute a target time in the future, as nanoTime() might return a a time in the future.

      Code like the one below might fail:

      Responses.waitFor()
      public boolean waitFor(long timeout) {
              long wait_time;
              final long target_time=System.nanoTime() + TimeUnit.NANOSECONDS.convert(timeout, TimeUnit.MILLISECONDS); // ns
      
              lock.lock();
              try {
                  while(!done && (wait_time=target_time - System.nanoTime()) > 0) {
                      try {
                          cond.await(wait_time,TimeUnit.NANOSECONDS);
                      }
                      catch(InterruptedException e) {
                      }
                  }
                  return done;
              }
              finally {
                  lock.unlock();
              }
          }
      

      When computing target_time, System.nanoTime() could return a negative value (numeric overflow) or a value in the future. In the first case, target_time could be negative, so the method would not block at all. In the latter case, target_time could be huge, so the method would block for a long time.

      Investigate all occurrences where we use nanoTime() to compute a time in the future, and see what impact a future value value could have. Possibly replace with System.currentTimeMillis() or the time service.

      Attachments

        Issue Links

          Activity

            People

              rhn-engineering-bban Bela Ban
              rhn-engineering-bban Bela Ban
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: