glassfish
  1. glassfish
  2. GLASSFISH-13170

Add log messages for module resolution time

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Invalid
    • Affects Version/s: 3.1
    • Fix Version/s: None
    • Component/s: OSGi
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      13,170

      Description

      To help diagnose the start-up time regression, it would be helpful to know how
      long it takes to resolve a particular module. We already have this information for
      top-level services using the log messages enabled with the
      javax.enterprise.system.core.level=FINE logger setting. However, this doesn't
      break down the information to the module level.

      This is a request to have module resolution times at the available in log files
      for diagnostic purposes.

        Activity

        Hide
        Richard S. Hall added a comment -

        I don't think this is possible to do. Think of the traveling salesman problem. How would you calculate how much time each specific stop contributed to the overall time consumed while finding a solution?

        Show
        Richard S. Hall added a comment - I don't think this is possible to do. Think of the traveling salesman problem. How would you calculate how much time each specific stop contributed to the overall time consumed while finding a solution?
        Hide
        Sanjeeb Sahoo added a comment -

        This is what Richard said:

        "I don't think it can work like that. It is not like each module has their own
        resolve() method that we can use to break it down. There is one resolve process
        for the entire framework and that can span multiple modules."

        Secondly, modules are resolved by underlying module system, not by glassfish. We support multiple module systems. Equinox resolves all bundles at startup. So, I am not sure what we can do in GlassFish. No point having a request that we will never fix.

        Show
        Sanjeeb Sahoo added a comment - This is what Richard said: "I don't think it can work like that. It is not like each module has their own resolve() method that we can use to break it down. There is one resolve process for the entire framework and that can span multiple modules." Secondly, modules are resolved by underlying module system, not by glassfish. We support multiple module systems. Equinox resolves all bundles at startup. So, I am not sure what we can do in GlassFish. No point having a request that we will never fix.
        Hide
        Tom Mueller added a comment -

        Richard's comment didn't say this was impossible; he just said he didn't think it was doable. However, it is. All that is necessary is keep two timestamps with each module, one that marks the time that module resolution started and another when module resolution finished. Then to print the inclusive time, just take the difference in the timestamps. To print the exclusive time (the time exclusive of dependent modules), just calculate the inclusive time and subtract the inclusive time for each module that the module depends on.

        Reopening this so that it can be considered for a future release.

        Show
        Tom Mueller added a comment - Richard's comment didn't say this was impossible; he just said he didn't think it was doable. However, it is. All that is necessary is keep two timestamps with each module, one that marks the time that module resolution started and another when module resolution finished. Then to print the inclusive time, just take the difference in the timestamps. To print the exclusive time (the time exclusive of dependent modules), just calculate the inclusive time and subtract the inclusive time for each module that the module depends on. Reopening this so that it can be considered for a future release.
        Hide
        Sanjeeb Sahoo added a comment -

        Not possible. See comments by Richard.

        Show
        Sanjeeb Sahoo added a comment - Not possible. See comments by Richard.
        Hide
        Tom Mueller added a comment -

        Bulk update to reassign dochez issue to component lead.

        Show
        Tom Mueller added a comment - Bulk update to reassign dochez issue to component lead.
        Hide
        Richard S. Hall added a comment -

        I don't think it can work like that. It is not like each module has their own
        resolve() method that we can use to break it down. There is one resolve process
        for the entire framework and that can span multiple modules.

        Show
        Richard S. Hall added a comment - I don't think it can work like that. It is not like each module has their own resolve() method that we can use to break it down. There is one resolve process for the entire framework and that can span multiple modules.
        Hide
        Tom Mueller added a comment -

        In profiling programs, the time consumed by each method is reported as both the
        inclusive and exclusive time, i.e., the time including all called methods as well
        as the time spent just in this method. A similar design could be used for module
        resolution.

        Show
        Tom Mueller added a comment - In profiling programs, the time consumed by each method is reported as both the inclusive and exclusive time, i.e., the time including all called methods as well as the time spent just in this method. A similar design could be used for module resolution.
        Hide
        Richard S. Hall added a comment -

        Given that lots of modules can be resolved as a result of resolving a single
        module, it may be hard to get precise information, since it may take a long time
        to resolve bundle foo because it ended up resolving 100 other bundles.

        Show
        Richard S. Hall added a comment - Given that lots of modules can be resolved as a result of resolving a single module, it may be hard to get precise information, since it may take a long time to resolve bundle foo because it ended up resolving 100 other bundles.

          People

          • Assignee:
            Sanjeeb Sahoo
            Reporter:
            Tom Mueller
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: