5 Replies Latest reply on May 12, 2008 5:26 AM by kconner

    Question on BeanConfiguredAction implementation

    ldimaggio

      The action is now implemented in a way where a new instance of the action is created for every message being processed. Is this for a specific purpose/reason? It seems like it could adversely affect performance to create separate instance for each message.



        • 1. Re: Question on BeanConfiguredAction implementation
          kconner

          This code was originally donated from the community and, although it is distributed with the ESB, has never been used internally. The original contributor may have had a good reason for doing it this way.

          Creating a new instance on every invocation would affect performance and this is what the original codebase did/does.

          We 'fixed' this by introducing the ActionLifecycle/ActionPipelineProcessor interfaces and specifying that implementers had to be thread safe. We could, therefore, identify these actions and create a single instance per pipeline.

          The summary of the current action creation is therefore as follows
          - no interface/BeanConfiguredAction
          new instance created per message
          - ActionLifecycle/ActionPipelineProcessor
          single instance per pipeline

          The other issue with the BeanConfiguredAction is that it does not handle the lifecycle/notification callbacks.

          • 2. Re: Question on BeanConfiguredAction implementation
            kconner

            Having explained the current situation we can now discuss how we proceed. :)

            The current functionality of BeanConfiguredAction has to remain, we have already shipped it and we cannot know who is using it. We therefore have two options

            - extend the current configurator
            - write a new one

            Extending the current configurator would be straight forward, for example we could subclass the marker interface and infer single threaded as a consequence.

            Another possibility, which we have been discussing in the past, would be to create the annotated action support and leave the bean configurator as is.

            • 3. Re: Question on BeanConfiguredAction implementation
              tfennelly

               

              "Kevin.Conner@jboss.com" wrote:
              Another possibility, which we have been discussing in the past, would be to create the annotated action support and leave the bean configurator as is.


              +1

              I'm happy to donate the code for this (from Smooks).

              I think having to extend/implement a particular class/interface (ala the BeanConfiguredAction) is a really ugly way of getting this type of functionality.

              • 4. Re: Question on BeanConfiguredAction implementation
                kconner

                That is my feeling as well :)

                I'll create a task for this and assign it to 4.4.

                • 5. Re: Question on BeanConfiguredAction implementation
                  kconner

                  This is now covered under http://jira.jboss.com/jira/browse/JBESB-1715, we will get this done for 4.4.