Uploaded image for project: 'Blazegraph (by SYSTAP)'
  1. Blazegraph (by SYSTAP)
  2. BLZG-293

ServicesManagerStartupTask - possible mix up with millisecs & nanos can cause unintended long delays

    Details

      Description

      In the options section of
      com.bigdata.jini.start.config.ServicesManagerConfiguration,
      DEFAULT_ZOOKEEPER_DISCOVERY_TIMEOUT_NANOS is set to a nanosecond
      based value (TimeUnit.MINUTES.toNanos(3) = 180000000000). Additionally, the
      option entry ZOOKEEPER_DISCOVERY_TIMEOUT_NANOS = "zookeeperDiscoveryTimeout"
      seems to imply that the value to be retrieved from the configuration
      is expected to also be a nanosecond based value. But whether the
      retrieved value or the default value is used for the value of the
      zookeeperDiscoveryTimeoutNanos variable, in the doStartup
      method of com.bigdata.jini.start.ServicesManagerStartupTask, the
      value of zookeeperDiscoveryTimeoutNanos is treated as a millisecond
      based value and is converted to nanoseconds; which results in much
      larger timeout value than is probably intended. For example,
      if the 180000000000 nanosecond default is treated as milliseconds, then
      the computation nanos = TimeUnit.MILLISECONDS.toNanos(180000000000)
      will result in a timeout of 180000000000000000 nanoseconds; which is
      not the intended 3 minute wait, but instead a wait of over 200 million
      days.

      See trac issue BLZG-273 for a similar bug. Additionally, it would probably
      be a good idea to search the whole codebase for this same inconsistency
      in the computation of timeouts.

        Activity

        There are no comments yet on this issue.

          People

          • Assignee:
            Unassigned
            Reporter:
            btmurphy btmurphy
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: