MDB pooling - JBAS-2047

[adrian.brock]

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.

[adrian.brock]

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.

[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.

[adrian.brock]

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?

[genman]

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.

[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.

[adrian.brock]

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.

[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/

[adrian.brock]

"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

[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.

[adrian.brock]

"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?

[genman]

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

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?

[adrian.brock]

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

[adrian.brock]

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.

[genman]

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?