3 Replies Latest reply on May 28, 2009 4:29 PM by alesj

    What are the current thoughts for solving JBKERNEL-25 (Imple

    smarlow

      Do we have an understanding of how the parallel deployment support will work? I am curious since this could help AS get through boot quicker (assuming we can get some concurrency going and not end up single threaded due to contention).

        • 1. Re: What are the current thoughts for solving JBKERNEL-25 (I
          starksm64

          Rather than looking at parallel deployment first, I think the consensus was to look at using on-demand as the first step in improving the boot times.

          • 2. Re: What are the current thoughts for solving JBKERNEL-25 (I
            alesj

             

            "smarlow@redhat.com" wrote:
            Do we have an understanding of how the parallel deployment support will work? I am curious since this could help AS get through boot quicker (assuming we can get some concurrency going and not end up single threaded due to contention).

            The Controller is already thread safe (A).
            So it's really just a matter of identifying parallel deployments == ControllerMode.ASYNCHRONOUS.
            And then pushing them to existing Executor in AbstractController.

            I guess the hard part is to test that (A) still works after this changes.
            Using Byteman (ex Toast) could come in handy.



            • 3. Re: What are the current thoughts for solving JBKERNEL-25 (I
              alesj

               

              "scott.stark@jboss.org" wrote:
              Rather than looking at parallel deployment first, I think the consensus was to look at using on-demand as the first step in improving the boot times.

              My current list, in no particular order.

              * use On_Demand where it makes sense (X)
              * analyze our services, add @MCAnnotations, @DisableAOP({DisableType.?}) (Y)
              * federated resources lookup
              ** usage of AnnotationEnvironment
              ** fix Metadata's paradigm
              *** only asking for what it needs, not checking all against some constraints
              ** cache other resources, as we're doing the scanning anyway
              ** limit what we're scanning
              *** jboss-scanning.xml
              *** (X) jboss-classloading.xml
              * usage of (X) will limit the class sharing/lookup == speed up
              * profile service loading profiles on demand
              ** e.g. usage @MDR enterprise bean triggers JMS profile load
              * parallel deployment
              * xyz ...

              For (X) and (Y) I'm looking into hacking some MC based tool
              to help us identify potential services that could use this, either (X) or (Y).
              I need to check how I can re-use Tattletale to help me.