Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: V3
    • Fix Version/s: future release
    • Component/s: admin
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      10,076

      Description

      We currently arbitrarily set a "one-size fits all" timeout in start-domain.

      I suggest we cool-ify it like so:

      1) Start with the usual timeout – 600 seconds or whatever.
      2) For each of the very first 10 or 20 starts just note the actual start time in
      a special file in the config directory or log directory.

        • 10-20 allows them some time to make their system more complicated.
        • Or we wait to see a pattern where the start times start to be +- 20% of each
          other
          3) Double that amount of time and make that the timeout
          4) If it times out we say something smart like:
          "Based on your domain's history it takes an average of 17 seconds to start. The
          domain failed to start in 34 seconds. Check the server log for problems.
        • we now reset to (1) and start collecting history again...

      As a bonus this would be very useful for QE/Performance. We produce a file
      automatically with startup times.

        Activity

        Hide
        km added a comment -

        bn

        Show
        km added a comment - bn
        Hide
        Paul Davies added a comment -

        Consider also adding an option like --timeout to start-domain to give users some control over this behavior.

        Show
        Paul Davies added a comment - Consider also adding an option like --timeout to start-domain to give users some control over this behavior.
        Hide
        Tom Mueller added a comment -

        A fix for this issue was initially identified for possible inclusion in the 3.2 release, but after further 3.2 planning, the feature or improvement did not make the cut. This issue is being targeted for a future release. If based on a reevaluation, it is targeted for 3.2, then update the "fix version" again.

        Show
        Tom Mueller added a comment - A fix for this issue was initially identified for possible inclusion in the 3.2 release, but after further 3.2 planning, the feature or improvement did not make the cut. This issue is being targeted for a future release. If based on a reevaluation, it is targeted for 3.2, then update the "fix version" again.

          People

          • Assignee:
            Byron Nevins
            Reporter:
            Byron Nevins
          • Votes:
            2 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated: