1 2 Previous Next 15 Replies Latest reply on Oct 8, 2005 4:22 PM by adrian.brock

    MDB pooling - JBAS-2047

      This is the discussion thread for:
      http://jira.jboss.com/jira/browse/JBAS-2047

      The ServerSessionPool implementation is entirely configurable/replaceable, see jms-ds.xml

      I would be interested in an implementation that allows a thread single pool for all mdbs.

      Sub pools based on message parameters or the subscription are an enhancement to this.
      Infact, the current implementation can be viewed as one sub-pool per subscription.

      However, it needs to be understood what happens at exhaustion of the pool.
      i.e. How is it decided which subscriptions/mdb gets the next thread.
      I would think the default implementation of such a scheduling policy should be based on message priority.

      There are also issues relating to "singleton" and clean mdb shutdown that are currently implemented based
      on the thread pooling semantics.

        • 1. Re: MDB pooling

          It is also debatable whether this is a priority or even doable going forward
          since JMS integration is moving towards JCA1.5 inbound as more jms providers adopt this standard.

          It is the providers that control this, although there is some control at the appserver level
          through the JCA1.5 WorkManager.

          • 2. Re: MDB pooling - JBAS-2047
            genman


            In terms of a priority for JBoss, probably it's not a general feature many people would use, but it makes MDBs more useful for processing requests where certain resources need to do the work for particular messages are slow or unavailable.

            Alternatively, an easier way to dynamically deploy MDBs (with selectors) would be nice to have. Then some sort of interceptor or whatever could deploy a new MDB instance/thread pool to do the work for a certain message. I guess if you could take a deployed "template" MDB and via JMX deploy a "clone" with a different selector that would work well enough.

            • 3. Re: MDB pooling - JBAS-2047

              You can already attach multiple invoker proxy bindings to an MDB.

              e.g. you can get an MDB to listen to multple topic subscriptions (either from the same
              jms server or different ones)

              So I guess the solution would be to have a "template invoker proxy binding"
              and add management methods to the MDB Container that lets you add/remove
              invoker proxy bindings with specific overrides like your selector.

              Such a solution would also apply to JCA1.5 with the "activation config properties".

              Why don't you experiment?

              • 4. Re: MDB pooling - JBAS-2047
                genman

                 

                "adrian@jboss.org" wrote:

                So I guess the solution would be to have a "template invoker proxy binding"
                and add management methods to the MDB Container that lets you add/remove
                invoker proxy bindings with specific overrides like your selector.


                This feature surfaced again at my company.

                I guess I don't understand the call flow. Here's the existing stack trace, where would this go?

                 com.example.MDB.onMessage
                 sun.reflect.GeneratedMethodAccessor171.invoke
                 sun.reflect.DelegatingMethodAccessorImpl.invoke
                 java.lang.reflect.Method.invoke
                 org.jboss.ejb.MessageDrivenContainer$ContainerInterceptor.invoke
                 org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke
                 org.jboss.ejb.plugins.MessageDrivenInstanceInterceptor.invoke
                 org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext
                 org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions
                 org.jboss.ejb.plugins.TxInterceptorCMT.invoke
                 org.jboss.ejb.plugins.RunAsSecurityInterceptor.invoke
                 org.jboss.ejb.plugins.LogInterceptor.invoke
                 org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke
                 org.jboss.ejb.MessageDrivenContainer.internalInvoke
                 org.jboss.ejb.Container.invoke
                 org.jboss.ejb.plugins.jms.JMSContainerInvoker.invoke
                 org.jboss.ejb.plugins.jms.JMSContainerInvoker$MessageListenerImpl.onMessage
                 org.jboss.jms.asf.StdServerSession.onMessage
                


                Would the code go into the JMSContainerInvoker, or after? I'll poke around, I just wanted to know if you had some place in mind.


                • 5. Re: MDB pooling - JBAS-2047
                  genman

                  Okay, I think I see how this can work.

                  Here's the general call flow.

                  org.jboss.ejb.MessageDrivenContainer.internalInvoke calls its first interceptor. The invocation would need to include the MDB container configuration. This must provide enough object references and general data so that a new MDB can be deployed from a template configuration. Things that might be included: DeploymentInfo, MBeanServer, BeanMetaData, ServiceControllerMBean, etc.

                  A new interceptor checks that onMessage is being called, and the JMS Message is examined. For this message, a special header is checked. If the POOL_ID for the message is not set, then the request is forwarded to the MDB. If a POOL_ID is set and it doesn't exist, then a new MDB is created with a selector that matches the POOL_IDs.

                  To me though, it feels like selectors are the wrong method though.

                  • 6. Re: MDB pooling - JBAS-2047

                    No the MessageDrivenContainer knows nothing about how it is invoked or what it
                    invokes.
                    Go back and read what I said then ask for clarifications.

                    • 7. Re: MDB pooling - JBAS-2047
                      genman

                      Okay, I think I understand a lot better now. There is an object bound to JNDI that creates the ServerSessionPool which itself is a factory that implements ServerSessionPoolFactory.

                      It seems reasonable to just extend/replace org.jboss.jms.asf.StdServerSessionPool with a version that does as I want.

                      To get a single thread pool, it would make sense, then, to replace StdServerSessionPoolFactory to have threads tied to a pool that this class manages or at least has a reference to. (Each StdServerSessionPool created would share a common thread pool.)

                      I can probably create what I want with this approach, though it would be nice to also change the signature of ServerSessionPoolFactory.getServerSessionPool() to allow for a more generalized configuration parameter object to get passed in.

                      It seems like JCA 1.5 uses a work management model, so perhaps I should just wait for JCA 1.5?

                      http://www-128.ibm.com/developerworks/java/library/j-jca2/

                      • 8. Re: MDB pooling - JBAS-2047

                         

                        "genman" wrote:

                        I can probably create what I want with this approach, though it would be nice to also change the signature of ServerSessionPoolFactory.getServerSessionPool() to allow for a more generalized configuration parameter object to get passed in.


                        Agreed.


                        It seems like JCA 1.5 uses a work management model, so perhaps I should just wait for JCA 1.5?

                        http://www-128.ibm.com/developerworks/java/library/j-jca2/


                        You mean JBoss4? Or this:
                        http://jira.jboss.com/jira/browse/JBAS-1434

                        • 9. Re: MDB pooling - JBAS-2047
                          genman


                          Hmm, I should have looked at the new JCA 1.5 adaptor, which is probably what I want to be working on, not the old JMS adaptor. It has more of what I want and more sane class interfaces.

                          With values from activation options (JmsActivation), I can probably come up with some configuration keys that specify the appropriate behavior.

                          The general is idea is that

                          src/main/org/jboss/resource/adapter/jms/inflow/JmsServerSession.java

                          onMessage(Message)

                          would include some sort of "plug in" (like the DLQHandler) for generating new session pools with selectors based on the contents of the message. I don't yet know what it'll look like.

                          • 10. Re: MDB pooling - JBAS-2047

                            "would include some sort of "plug in" (like the DLQHandler) for generating new session pools with selectors based on the contents of the message. I don't yet know what it'll look like."

                            Yes, I'm hoping the inflow adapter will have a lot more pluggable components
                            the JMSContainerInvoker is pretty rigid in terms of changing implementation/policy. :-(

                            The current inflow rar still uses ConnectionConsumer/ServerSessionPool
                            but I would prefer it to use JMS vendor specific plugins that will be capable of
                            a lot more optimizations and behaviours/features (including workarounds for known
                            "broken" vendors who only provide full behaviour through vendor specific api).

                            If I only had time to work on it... :-)
                            I believe Tim Fox is going to work on some of this for the new JBoss Messaging?

                            • 11. Re: MDB pooling - JBAS-2047
                              genman

                               

                              "adrian@jboss.org" wrote:

                              Yes, I'm hoping the inflow adapter will have a lot more pluggable components
                              the JMSContainerInvoker is pretty rigid in terms of changing implementation/policy. :-(


                              This is going away, at least for the default configuration for 4.0? I'd rather not have to try to deal with the JMSContainerInvoker

                              "adrian@jboss.org" wrote:

                              The current inflow rar still uses ConnectionConsumer/ServerSessionPool
                              but I would prefer it to use JMS vendor specific plugins that will be capable of
                              a lot more optimizations and behaviours/features (including workarounds for known
                              "broken" vendors who only provide full behaviour through vendor specific api).

                              If I only had time to work on it... :-)
                              I believe Tim Fox is going to work on some of this for the new JBoss Messaging?


                              I thought JBoss Messaging was working on just the JMS implementation, not the EJB container and JCA 1.5 adaptor. And if I work on anything it'd be for the new .rar.

                              I was thinking that the org.jboss.resource.adapter.jms.inflow.DLQHandler had a fairly decent interface. Perhaps I would do the following:

                              /**
                               * An interface for inflow message Handling.
                               */
                              public interface InflowHandler
                              {
                              
                               /**
                               * Set up the handler.
                               * @throws Exception for any setup failure
                               */
                               void setup(JmsActivation activation) throws Exception;
                              
                               /**
                               * Tear down the handler.
                               */
                               void teardown();
                              
                               /**
                               * Handles the message, return true if the message should not be further processed.
                               */
                               boolean handle(Message msg);
                              
                               /**
                               * Notification that the message was delivered
                               */
                               void messageDelivered(Message msg);
                              
                              }
                              


                              I would probably make DLQHandler a subclass of InflowHandler and change the signatures slightly. The activation parameters would include a list of classes. What do you think?

                              • 12. Re: MDB pooling - JBAS-2047

                                We are trying to unify the "interceptor"s on the aop model.
                                In future this will include the rar implementations, e.g. applying interceptors
                                to the DataSource or inflow.

                                I've already started a prototype here:
                                http://www.jboss.com/index.html?module=bb&op=viewtopic&t=70511

                                • 13. Re: MDB pooling - JBAS-2047

                                   

                                  "adrian@jboss.org" wrote:
                                  We are trying to unify the "interceptor"s on the aop model.


                                  This does not mean that until we get there, the old models cannot duplicate the
                                  behaviour.

                                  • 14. Re: MDB pooling - JBAS-2047
                                    genman

                                     

                                    "adrian@jboss.org" wrote:
                                    "adrian@jboss.org" wrote:
                                    We are trying to unify the "interceptor"s on the aop model.


                                    This does not mean that until we get there, the old models cannot duplicate the
                                    behaviour.


                                    Until the Aspect/POJOize JCA arrives, would the interceptor interface I suggested be appropriate? Is JCA 1.5 for MDBs going to be a 4.0 feature?

                                    1 2 Previous Next