4 Replies Latest reply on Sep 30, 2009 12:55 PM by Daniel Kulp

    Lazy initialization of CXF endpoints?

    Adrian Trenaman Newbie

      Do we perform extensive lazy initialization of our CXF jax-ws endpoints? I've noticed that in some of the services we're using we experience a 'first-time' invocation penalty of about 4 times the subsequent average response call.

       

      Any idea what could be causing this?

        • 1. Re: Lazy initialization of CXF endpoints?
          Daniel Kulp Newbie

          Well, yes and no.   We don't really do FULL lazy init as some things like wsdl parsing and JAXBContext creation and such occur up front.   However, some stuff does occur on a first hit and some other things occur on a first hit per operation.

           

          There was a query last week on users@cxf about true "complete" lazy init where we would register a small "stub" on the address at load time and not do any init until first hit.   That would be quite a bit of work.   Doable, just not a priority right now.

           

          The things that occur on first hit include (not limited to):

          1) EffectivePolicy determination - parsing and processing an ws-policy things to determine the effective policy and the interceptors and such that are needed.

           

          2) Schema construction - if validation is turned on, we have to create a Schema object for the schema validator.   This is deferred until it's needed.  

           

          3) WrapperHelpers - for jaxws doc/lit/wrapped, we read/write to the wrapper objects, but we need to unwrap to call the method.   We generally use asm to generate some helpers to handle this (and fallback to reflection if asm not available).    This is on a per-operation basis.

           

          Obviously, things like having the JIT kick in for parts of the above and things also have an affect.

          • 2. Re: Lazy initialization of CXF endpoints?
            Daniel Kulp Newbie

            Actually, I wanted to mention something else:

             

            With CXF 2.3, a LOT of the Spring constructed things have also changed to lazy-init="true".    With 2.2.x and earlier, by default, something like 55-60 objects are created up-front, many are never used.    With 2.3, I've shrunk that number to about 7.   (and may try to get it even smaller)   Thus, startup of a default Bus is MUCH faster plus a LOT of things aren't loaded until needed.

             

            However, that means when things are needed, they need to be loaded in.   For example, in 2.2.x, the RMManager is loaded immediately.   With 2.3, the RMManager isn't loaded until something actually uses RM.     With 2.2.x, the WorkQueueManager is loaded immediately.  With 2.3, it's loaded the first time an async call is made or other similar action that requires it.

             

            Thus, with 2.3, things will change a bit.   It should allow faster init and lower memory usage by only loading the stuff that is actually in use and when they are needed.

             

            Of course, that's all for 2.3 which won't be out till Q1.   Something to look forward to though.  

            • 3. Re: Lazy initialization of CXF endpoints?
              lorinda visnick Newbie

              "With CXF 2.3, a LOT of the Spring constructed things have also changed to lazy-init="true" "

               

              but, if users KNOW they are going to use some Spring constructed thing, they can change/override the lazy-init setting so that they do not have to take the hit at the time of first use... right?

               

              is there any one place that lists which items are lazy init'd vs which are not?

               

              tia

              lorinda

              • 4. Re: Lazy initialization of CXF endpoints?
                Daniel Kulp Newbie

                Not yet, no, as it's kind of still a work in progress. 

                 

                That said, with spring, the only real way to force it to be created if it's marked lazy-init is to actually use it somehow or depend on it.    Thus, any beans they construct would have to have a depends-on="..." thing with the bean IDs (which would need documenting) of the things they want loaded before they are or they would need to have the beans injected into their bean or they would need to implement ApplicationContextAware, get the context, and force loading.    All of them require a bit extra work.